Предисловие
Эта статья — не критика Agile или Kanban как подходов и не попытка доказать, что в IT «всё делают неправильно». Я делюсь наблюдениями из собственного опыта работы с качеством в промышленности, энергетике, а затем — в IT‑продуктах.
Речь пойдёт не о терминах и инструментах, а о том, как часто теряется системное мышление, когда сложные управленческие модели упрощаются до ритуалов.
Если у вас уже выстроена работа и всё стабильно — это отлично. Если нет — возможно, некоторые наблюдения покажутся полезными
Качество как система, а не как роль
Общаясь с разными людьми «почему именно QA», в большинстве случаев ответ один и тот же: потому что проще попасть в IT, потому что меньше кода, много рекламы курсов, рекомендаций знакомых, можно быстро начать зарабатывать.
Очевидно, что человеку не интересно само тестирование. Не интересно разбираться в продукте, искать причины ошибок, думать, как пользователь и как система. QA для него -это просто запасной вход в IT, а не профессия. И рынок сейчас это очень быстро показывает – конкуренция огромная, но многие кандидаты не имеют системности, должного опыта, долго не задерживаются, выгорают или просто пропадают после первых сложностей.
QA - это не «проще». Это отдельная роль, требующая внимания, логики и вовлеченности. Хороший тестировщик - это не тот, кто просто нашел баг, а тот, кто понял откуда он взялся и как его можно было предотвратить. Ничего не напоминает? Возьмём, к примеру, любую производственную систему, в ней обязательно будет отдел/департамент/управление качества в той или иной форме. В этих отделах есть такие же «тестировщики» и QA-инженеры, которые занимаются поиском несоответствий, причин этих несоответствий, точно так же составляют репорты со всей необходимой информацией и назначают их на разработчиков этих продуктов и документов. Я знаю это, потому что сам был в этой сфере более 10 лет в различных ролях от инженера по качеству до руководителя департамента и технического аудитора. В момент моего перехода из индустрии в IT, у меня было странное ощущение дежавю: Люди другие, термины другие, инструменты современные — а проблемы… те же самые:
«Мы это не учли», «Давайте быстро пофиксим», «Главное — не виноватый, а чтобы работало», «Потом разберёмся»
Разница только в том, что в промышленности ошибка могла стоить миллионы долларов или жизни людей, а в IT — чаще всего тоже деньги, репутация и нервы команды. Логика схожа, и самое забавное: всё это давно описано.
Деминг, Шухарт, Тайити Оно, Исикава - люди, которые решали эти проблемы 30–60 лет назад и сейчас, большинство практик QA в IT — это упрощённые и вырванные из контекста версии их идей.
Lean, Kanban, Flow, Value Stream, WIP, Muda, Agile - звучит солидно и современно. Проблема в том, что очень часто за этими словами уже да��но нет системы.
Остались ритуалы, доски и встречи, а смысл потерялся.
Вытягивающий vs выталкивающий методы производства
Термин Канбан с японского языка имеет дословный перевод: “Кан» значит видимый, визуальный, и “бан” значит карточка или доска. Карточка — это единственное сходство между сферой IT и Lean производством. Не все согласятся с этим, поэтому будем разбираться.
Давайте представим некий автомобиль, состоит из разных узлов и деталей, собранный на автозаводе, доставляется в дилерский центр вместе с десятками других автомобилей. Если покупатель забрал автомобиль - на складе образуется пустота (Gap) - нехватка одного автомобиля. Дилерский центр посылает сигнал на завод - сколько автомобилей и в какой комплектации ему надо возместить. Столько, сколько надо восполнить. Завод со склада отгрузил автомобиль в дилерский центр - теперь пустота (Gap) уже на складе. Промежуточные этапы сборки авто получают сигнал со склада, и так до самого начала цепочки. Пока сигналов нет - конвейер должен стоять. Он не должен производить автомобилей больше, чем нужно. Каждый последующий этап ставит задачу предыдущему этапу, передавая карточку с заданием и конкретной комплектацией. Таким образом весь конвейер делает один такт и последний Канбан приходит на склад материалов, чтобы получить всё для начала производства нового автомобиля. Это метод вытягивания, который был придуман Тайити Оно в Японии на производстве Тойота.
При физическом производстве, на конце у нас есть объект, для воспроизведения которого нужно заново пройти все этапы производства. В IT код создаётся один раз и масштабируется. Не нужно заново переписывать операционку каждый раз, когда вы продаете компьютер, а вот сам компьютер нужно каждый раз полностью производить от производства плат и добычи металлов до сборки в Китае. Поэтому и есть сверхприбыль в IT, ведь вы сделали продукт в 1 экземпляре, но при продаже этот продукт умножается на столько копий, на сколько нужно и нет необходимости «создавать сотни автомобилей для склада впрок».
В IT чаще производство по методу выталкивания, от начала и до конца: DevOps не ставят задачу тестировщикам, тестировщики - разработчикам, а разработчики аналитикам не ставят задачи. Нельзя иметь готовый сайт, готовый код, готовый user story и ждать клиента, чтобы моментально ему это вручить и сразу делать то же самое, что мы только что отдали - в этом вся принципиальная разница, это относится ближе к push-системам.
На практике это выражается просто: в push-подходе у команды одновременно 15–20 активных задач, из которых реально движутся 3–4. В вытягивающем подходе задач меньше, но они доходят до конца быстрее и с меньшим количеством возвратов.
Многие, кто декларируют, что используют Канбан, по факту передвигают карточки по доске, а система не меняется. Люди начинают упрощать инструмент: доска с карточками визуализирует процесс работы, вместо управления разработкой, основанной на данных. Без достаточных достоверных данных - оценка времени на задачи напоминает гадание на кофейной гуще. Причинно-следственные связи, статистика, конкретика необходимых ресурсов почему-то отбрасываются и уходят на второй план.
Конечно, многие команды успешно применяют WIP (Work in Progress) - лимиты и метрики потока - и это уже шаг к настоящему Канбан, хотя в чистом виде ни его, ни Scrum я нигде не встречал, а вот смесь фреймворков вследствие часто изменяющихся или неправильно выстроенных процессов – явление частое.
Именно здесь часто и начинается путаница. Канбан как часть индустриальной системы управления потоком подменяется Канбан-доской, как визуальным инструментом, а затем незаметно смешивается с Agile-практиками. В итоге обсуждается уже не система управления качеством и потоком, а набор удобных ритуалов, которые должны как-то работать.
��огда практики становятся ритуалами, и где мы обманываем себя?
Многие слова звучат модно - Agile, Lean, Kanban, Muda, Mura. Лично мне они напоминают культ: практического смысла в этом мало и есть более понятные аналоги этих слов. Это было модно лет 10-15 назад, для экзотики, чтобы привлечь внимание. Просто берем систему, которая застыла лет 20 назад и будем использовать без привнесения чего-то нового со временем. У некоторых сотрудников такие внедрения вызывают отторжение, а нам наоборот их нужно вовлечь, ведь людям проще общаться на одном языке. Возможно, это сработает для топ-менеджмента, как некоторое ноу-хау.
Некоторые люди часто используют тот же Agile, как ритуал, а не как систему мышления - и при этом игнорируют десятилетиями отработанные индустриальные подходы к качеству. Agile задумывался как ответ на тяжёлые, неповоротливые процессы.
И он действительно дал: гибкость, скорость, обратную связь. Но в реальности Agile в разработке часто превращается в следующее:
требования фиксируются поверхностно («потом уточним»),
сложные сценарии откладываются («не в этот спринт»),
дефекты принимаются как норма («Ну… бывает»),
ретроспективы и дейли заканчиваются общими выводами.
Например: Фича прошла все этапы разработки проверки и релиза, но через несколько дней поступают жалобы пользователей, транзакции не проводятся, поддержка долго разбирается в проблеме. Формально баг исправили быстро с помощью хотфикса. Причины могли быть в коде, неполном тестировании, но также и в требованиях, которые недостаточно описаны, допускали несколько интерпретаций. Agile не запрещает этого, он просто не требует.
Еще один пример: Поиск AQA для автоматизации однообразных процессов. Первое время он тестирует руками, чтобы ознакомиться с системой, разобраться в окружении и паттернах поведения. Время идет, срочные задачи продолжают падать и времени на автоматизацию просто нет. Высококвалифицированный и высокооплачиваемый сотрудник тонет в рутине и выполняет не ту работу, для которой он нанимался. Или возьмем упрощенный вариант, когда QA занимается просто работой тестировщика, никак не влияя на процессы и не улучшая их. Выглядит со стороны все это, как очередное соответствие тренду: да, у нас есть профессионалы, но делают они явно не то. Каждое действие должно иметь ценность, и, если оно приносит минимальную ценность или не приносит вовсе - нужно от него избавляться или делать его эффективнее.
Agile ретроспектива vs Индустриальный анализ коренных причин несоответствий (RCA)
Agile-ретроспектива часто выглядит так:
что пошло не так?
что можно улучшить?
что будем делать в следующий раз?
Индустриальный RCA задаёт более жёсткие вопросы:
где именно система дала сбой?
какая защита отсутствовала? Или могла бы быть?
почему этот дефект смог дойти до пользователя?
что необходимо, чтобы он не повторился вообще?
Разница принципиальная: Agile часто улучшает поведение людей, а индустриальный подход улучшает поведение системы. На мой взгляд в финтехе второе критичнее и приоритетнее. Финтех - это не то место, где «потом исправим» и именно поэтому практики, придуманные десятки лет назад для заводов, вдруг оказываются более современными, чем кажется. Давайте сравним:
Agile без индустриального мышления качества усиливает хаос. Например: Фичи выпускаются быстро, метрики растут, но данные разные, друг с другом не сходятся, релизы частые, но нестабильные, ведь Agile ускорил поток и принятие решений.
Agile с индустриальным фундаментом создаёт надёжные системы, используя лучшее из обоих подходов вместе. В этом случае релизов меньше, но они стабильнее, с расследованием коренных причин проблем, контролем качества данных и меньшим тушением пожаров.
Исключения есть и будут, когда компания намеренно делает продукт/разработку сомнительного качеств�� в угоду другим преимуществам: первым выйти на рынок и заявить о себе. Или собрать большую часть клиентов, пока конкуренты доводят свою разработку до идеала. Илон Маск, запустивший множество ракет, улучшая их с каждой итерацией после запусков. Главное идти на это осознанно и не забывать про улучшения, отладку продуктов и процессов в будущем.
Вполне разумно могут подниматься вопросы о неуместности сравнения индустрии и IT. В IT огромная вариативность затрат ресурсов на задачи, так как они бывают как огромными, так и незначительными - все это диктуется требованиями рынка. В индустрии с серийным производством многие процессы повторяются, а значит, стандартизированы и вариативность там небольшая, и все же, если бывает- её можно оптимизировать и отладить. Прогнозирование разработки возможно с вероятностным подходом, но он требует статистики, ведь в IT много нового и непрогнозируемого, зачастую сравнимо с исследовательской работой. В таком случае что мы можем сделать в такой ситуации? И что из индустрии может пригодиться?
1. Качество как управленческая функция
Это зона ответственности всей компании, всей команды, а не только QA. Если каждый отдел и сотрудник в нём выполняет свою работу в полном объеме, вовремя и в соответствии с требованиями, то его клиент, а смежный отдел или коллега - это именно клиент, только внутренний, гораздо быстрее начнет свою часть работы с меньшим риском допустить несоответствие. QA уже не выступает в качестве единственного фильтра в самом конце процесса. Это звучит, примерно, как «У нас есть тормоза, можно разгоняться без оглядки» или «У нас есть пожарные, а это значит, что дом можно строить из картона». Проверки, какими бы они частыми и внимательными ни были - не гарантируют 100% качества. Если дефект регулярно доходит до тестирования, значит он уже давно живёт в системе и тестировщик просто последний, кто это увидел.
Как на это можно влиять? Даже несколько коллегиальных встреч с обсуждением входов-выходов процессов, ощутимо упростят работу всей команде разработки. Каждый отдел, а не только QA управляет рисками и принимает решения за релиз, формируя quality gates.
2. Метод «5 Почему?»
Метод «5 почему?» в IT любят, но часто используют его так, будто цель - найти виноватого.
Например, инцидент: пользователи не могут оплатить заказ.
Плохой разбор: почему? - баг. почему? - не заметили. Вывод: «QA будь внимательнее». Поздравляю, система не изменилась вообще. Очень легко остановиться на «Не протестировали, забыли», но сложнее задать следующий вопрос: «Почему система позволила не протестировать?».
В хорошем разборе инцидента мы пришли к тому, что: требования часто изменялись и не проходили ревью, ответственность размывалась между командами.
Правильный вывод: не «быть внимательнее», а изменить требования и процессы, не забывая своевременно информировать всех участников и делиться опытом применения метода с менее опытными коллегами, новичками. Один из примеров про улучшение процессов и quality gates был описан выше.
3. Диаграмма Исикавы (Fishbone - рыбья кость)
Отличный инструмент, для исследования проблемы одновременно с разных сторон: процессы, инструменты, архитектура, данные, окружение, коммуникации, усталость команды.
Например: падает автотест ночью - часто настоящая причина в данных/окружении, а не в самом тесте.
4.5S
Порядок это не эстетика и не порядок на столе, а скорость и надёжность в работе. В IT 5S это: репозитории и документация, тестовые данные, окружения, дашборды, Jira/Confluence
Пример 5S для QA:
1)Sort: удалить мёртвые тест-кейсы и дубликаты
2)Set in order: единый шаблон тест-кейса/чеклиста + теги
3)Shine: регулярная чистка тестовых данных
4)Standardize: стандарты в ТЗ с четкими критериями
5)Sustain: стабильность благодаря автоматическим проверкам в CI
Беспорядок в тестах - это шум, в котором увеличиваются пропущенные дефекты.
5.Потери и Lean
Если переводить Lean дословно, то это звучит - худой, ведь метод исключает все лишние операции, запасы, расходы. Однако, некоторые понимают это ошибочно, в виде экономии на всем, урезании бюджетов, увольнении сотрудников. Это сработает 2-3 раза, дальше сокращать будет некого и экономить не на чем. В действительности, дефекты, найденные поздно - обходятся дороже всего и являются огромной потерей.
Тайити Оно говорил о 7 видах потерь (муда), если перевести их на язык IT, получится очень знакомо.
Потери в IT:
Ожидание — QA ждёт окружение, доступы, данные
Переделки — баги найдены после релиза
Лишняя работа — излишние нерелевантные проверки
Очереди — бэклог багов, к которым никто не вернётся
Движения — ручные регрессии кликом по одному сценарию
Избыточность — 5 согласований одного поля
Дефекты — сюрприз в проде
Не так давно добавили восьмой вид потерь, и это – нереализованный человеческий потенциал, талант.
Заключение
Ниже приведено упрощенное сравнение, которое я неоднократно наблюдал при применении принципов промышленного качества в ИТ-командах.
Индустриальный подход | IT-подход |
Управление потоком на основе данных и ограничений | Управление задачами через статусы и встречи |
Раннее выявление дефектов | Исправление дефектов после релиза |
Анализ коренных причин (RCA) | Быстрые фиксы и разбор на ретро |
Ограничение незавершённой работы (WIP) | Параллельное выполнение максимального числа задач |
Качество - ответственность всей системы | Качество - зона ответственности QA |
Улучшение поведения системы | Улучшение поведения людей |
Дефект - сигнал о проблеме процесса | Дефект - рабочая неизбежность |
Этот контраст объясняет, почему одни команды работают быстро, но выгорают, в то время как другие работают медленнее, но остаются предсказуемыми.
Эти подходы я применял на практике в IT-командах, где раннее выявление дефектов, анализ коренных причин и ограничение незавершённой работы позволяли снижать количество инцидентов, ускорять релизы и уменьшать нагрузку на команды. Детали этих кейсов выходят за рамки статьи, но именно они показали, что индустриальные принципы качества остаются актуальными и в цифровых продуктах. Ключевой вывод заключается не в том, что индустрия лучше, чем IT, а в том, что многие проблемы надежности в современных командах разработчиков ПО возникают из-за утраты системного подхода к качеству - то, что промышленность использовала десятилетия назад и что можно сознательно возродить, не отказываясь от Agile.
