Что тормозит QA-процесс: ищем проблемы с помощью Lean, Six Sigma и Кайдзен

Столкнулись с тем, что QA-команда много работает, а релизы всё равно тормозят? Проблема часто не в том, что тестировщики работают медленно или их не хватает. Мы видим на практике, что чаще всего собака зарыта в самих процессах. Например, когда специалистам приходится стоять в очереди на тестирование, ждать готовности стенда, возвращаться на доработку или повторную проверку. В итоге люди постоянно заняты, а скорость поставки продукта не растёт. Но как обнаружить такие дыры?

В «Лаборатории Качества» мы применяем принципы Бережливого производства (Lean), Шесть сигм (Six Sigma) и Кайдзен не как набор отдельных модных методик, а как диагностический цикл для поиска проблем в QA-процессах. 

Нам это помогает увидеть, где именно теряется время, почему возникают лишние переделки и какие изменения действительно повысят эффективность команды. Читайте статью, если хотите узнать, как внедрить устойчивые улучшения.

Можно ли выбрать что-то одно?

Нередко компании используют Бережливое производство (Lean), Six Sigma и Кайдзен как отдельные инструменты – берут тот, который кажется самым простым или больше нравится. Но эти методы работают не по отдельности, а как единый процесс.

Сначала вы смотрите, как движется работа: сколько времени уходит на каждый этап, где всё замедляется. Потом находите конкретное место сбоя – например, долгое ожидание стенда или частые поломки автотестов. Дальше подбираете решение именно под эту проблему: если дело в нехватке ресурсов – настраиваете резервирование, если в нестабильных тестах – дорабатываете их или среду. И наконец, закрепляете изменения, чтобы улучшения остались надолго.

Мы разберём этот процесс шаг за шагом. Покажем понятные расчёты, пороговые значения и один сквозной пример: одни и те же цифры будут переходить из этапа в этап – так вы увидите, как всё связано между собой.

В статьях про Lean в тестировании часто показывают только витрину: перечисляют семь потерь, описывают DMAIC, приводят цифру в 3,4 дефекта на миллион. И дело не в том, что эти данные неверны. Такая подача не помогает руководителю ответить на самый важный вопрос: с чего начать именно в его команде и что делать дальше.

Методы Lean нередко подают как разные варианты на выбор, хотя на деле это последовательные стадии одного цикла. Мы покажем, как они связаны между собой.

Три японских термина – не просто красивые слова, а чёткая цепочка: она подсказывает, в каком порядке устранять проблемы и выстраивать улучшения.

В западных разборах всё крутится вокруг муда и её семи видов, а мура и мури упоминают будто для галочки. В Toyota, где и были разработаны принципы бережливого производства, подход другой: сначала выравнивают поток задач – (убирают мура). Это снимает перегрузку (мури), и только потом борьба с потерями (муда) становится по-настоящему эффективной.

Поэтому главное правило системы простое: устранять проблемы нужно строго по порядку – сначала мура, потом мури, и только затем муда. Это важно.

Именно этот принцип и лежит в основе подхода Toyota – он помогает не распыляться на мелкие проблемы, а бить точно в цель. Вот как сформулировал суть сам создатель производственной системы компании:

---

«Всё, что мы делаем, – смотрим на время между заказом клиента и получением денег. И сокращаем этот отрезок, убирая всё, что не добавляет ценности»

 – Тайити Оно, создатель производственной системы Toyota

---

Стадия 1. Составляем карту потока и получаем конкретные данные

Карта потока создания ценности (VSM) – это карта всего пути задачи: от самого первого запроса до того момента, когда результат доходит до пользователя. Каждый этап на ней отмечают тремя цифрами – они показывают, сколько времени уходит на работу, на ожидание и на потери. Относится к концепции бережливого производства (Lean).

Важно понимать: VSM не исправляет проблемы – она помогает их увидеть. Именно с этой карты стоит начинать любые улучшения. Без цифр мы обычно бросаемся чинить то, что бросается в глаза, а не то, что реально, но тихо съедает время и деньги.

На каждом шаге процесса мы смотрим три метрики. Их важно понимать точно, так как именно на них строится вся дальнейшая работа с цифрами.  

Одна ошибка может свести на нет всю ценность карты потока.

Показатель %C&A нужно снимать с того, кто принимает работу, а не с того, кто её делал. Автор всегда уверен, что передал всё как надо. А правду видит тот, кто принял задачу – и вернул с вопросами.

Например, чтобы понять реальную картину, спросите разработчика, какая доля багов приходит с понятными шагами для воспроизведения. Или спросите тестировщика, насколько часто требования приходят без пробелов в граничных случаях. Так вы получите честные данные, на которых можно строить улучшения.

Карта потока выдаёт три главных показателя

Они складываются из построчных данных – PT, LT и %C&A. Эти итоговые цифры – как диагноз для процесса: сразу видно, где он тормозит и сколько времени и ресурсов теряется зря. 

Total LT = сумма Lead Time всех шагов          # сквозное время задачи
Total PT = сумма Process Time всех шагов       # чистая работа

Activity Ratio = Total PT / Total LT × 100%     # доля времени, когда над задачей работали
# В реальных потоках сплошь и рядом 2–15%. Остальное — ожидание.

Rolled %C&A = %C&A(шаг1) × %C&A(шаг2) × ...    # сквозное «годно с первого раза»
# Перемножается! Пять шагов по 80% дают 0.8^5 = 33%.
# То есть две трети задач где-то по пути идут на переделку.

Activity Ratio помогает понять, почему процесс идёт медленно: из‑за самой работы или из‑за ожиданий. Rolled %C&A (он же rolled first‑pass yield в Six Sigma) показывает, сколько задач приходится переделывать. Его главная особенность – он перемножается: даже неплохие 80–90% на каждом этапе в сумме могут дать очень низкий общий результат. Именно эту проблему часто упускают из виду.

В статье мы разберём один сквозной пример на всех этапах

В команде – 6 разработчиков и 2 QA‑инженера. Менеджмент замечает, что тестирование тормозит релизы, и предлагает решение: нанять ещё одного тестировщика. Мы построили карту потока по 12 задачам – и с её помощью смотрим, где на самом деле прячется проблема.

Activity Ratio = 12 / 108 = 11%
# 89% времени задача просто ждёт. Люди при этом заняты по горло.

Rolled %C&A = 0.70 × 0.85 × 1.0 × 0.75 × 0.90 = 40%
# 60% задач где-то идут на переделку. Два узких горла — груминг (70%)
# и тестирование (75%), и они бьют по одному и тому же: возвраты.

Карта сразу показывает, что первоначальная гипотеза неверна. Дело не в том, что тестирование идёт медленно: на саму работу уходит всего 3 часа. И нехватка людей тут ни при чём.

Главная проблема – в долгих ожиданиях (Activity Ratio 11%) и в том, что многое приходится переделывать (Rolled %C&A 40%). Причём переделки возникают на двух конкретных этапах.

Если бы в команду взяли ещё одного тестировщика, эти цифры не изменились бы: задачи всё равно застревали бы в той же очереди.

Стадия 2. Диагностика типа проблем

VSM не просто показывает, где есть проблемы, – она ещё помогает понять, какого они рода. В этом суть всей системы – и именно этого не хватает в поверхностных обзорах.

Три сводные метрики указывают на три разных типа проблем, и для каждого нужен свой подход. Если перепутать тип, получится, что лечим не ту болезнь – и улучшения не дают результата.

Почему «загрузить людей на 100%» – самая дорогая ошибка

Здесь нужна математика очередей, потому что интуиция врёт именно в этом месте. Дон Райнертсен (писатель, прославился как один из главных авторов концепции бережливой разработки продуктов) перенёс теорию массового обслуживания на разработку, и вывод контринтуитивный: время ожидания в очереди зависит от загрузки не линейно, а экспоненциально. Для простой очереди множитель ожидания считается так:

Ожидание ∝ U / (1 − U)       # U — загрузка ресурса (0..1)

  U = 50%  →  множитель  1×
  U = 80%  →  множитель  4×
  U = 90%  →  множитель  9×
  U = 95%  →  множитель 19×

# Догрузив тестировщика с 80% до 95%, вы получаете не +19% работы,
# а рост времени ожидания задачи в очереди почти впятеро.

Вот почему добавление ещё одного человека в перегруженную команду нередко ускоряет работу куда сильнее, чем кажется. А попытки выжать из текущих сотрудников «ещё немного» почти всегда дают обратный эффект – процесс только замедляется.

Главный практический вывод Райнертсена прост: управлять нужно не загрузкой людей, а размером очереди. Загрузку точно оценить сложно, а очередь всегда видна – например, на доске задач. Стоит ограничить количество задач в работе – и загрузка сама придёт в здоровый диапазон.

Правила выбора инструмента простые

• Если видите долгие ожидания и низкий Activity Ratio – проблема в очереди. Решают лимиты WIP (Стадия 03). Нанимать людей или требовать работать быстрее тут не поможет.
• Если низкий Rolled %C&A – значит, много переделок. Нужно внедрять poka‑yoke на том шаге, где показатель падает.
• Если на одном шаге %C&A неожиданно низкий – не стоит действовать наугад. Разберите причину с помощью подхода DMAIC.
• Если проблемы сразу по всем фронтам – исправляйте по порядку: сначала выровняйте поток (mura), потом снимите перегрузку (muri), затем уберите потери (muda).

В нашем примере карта выявила две основные проблемы: очередь (Activity Ratio – 11%) и переделки на двух этапах (Rolled %C&A – 40%). Значит на третьей стадии понадобятся два инструмента: лимит WIP, чтобы справиться с очередью, и poka‑yoke – чтобы сократить переделки. Действуем по правилу mura, а затем muda: сначала выравниваем поток, а потом точечно улучшаем качество отдельных шагов.

Стадия 3. Выбрать и применить контрмеру

Контрмера А. Лимит WIP – против очереди

Механика. Лимит WIP работает на базе закона Литтла – простого, но фундаментального правила из теории очередей. Суть такая: в стабильном потоке время выполнения задач напрямую зависит от их количества. Держите в работе меньше задач – и они будут проходить через систему быстрее.

WIP = Throughput × Lead Time

  WIP        — задач одновременно «в работе»
  Throughput — сколько задач в день выходит из шага
  Lead Time  — сколько в среднем задача проводит на шаге

# Перестановка даёт лимит, а не «возьмём 2 на человека наугад»:
Целевой лимит WIP = Throughput × Целевой Lead Time

Лимит рассчитывается, исходя из реальной пропускной способности команды и целевого времени цикла, а не на глаз. Покажем на примере.

# Из карты: шаг тестирования выпускает ~2 задачи в день (throughput).
# Сейчас Lead Time на шаге = 28 ч ≈ 3.5 рабочих дня.

Фактический WIP = 2 × 3.5 = 7 задач висят в тестировании разом.
# Вот источник переключения: 2 инженера жонглируют семью задачами.

# Хотим Lead Time = 1 день. Тогда:
Целевой лимит WIP = 2 × 1 = 2 задачи
# Ставим лимит колонки = 3 (небольшой запас), а не 7.

Как внедрить, чтобы результат сохранился

• Ставьте лимит на колонку, а не на отдельного сотрудника. Если лимит достигнут – новую задачу не берём: вся команда помогает завершить то, что уже в работе.
• Важно дать команде право не брать новые входящие задачи. Без этого лимит превращается просто в цифру на доске. Если сверху постоянно подкидывают «срочно» поверх лимита – система не работает.
• Эффект следует из закона Литтла: при том же объёме выполненной работы (throughput) и меньшем количестве задач в работе (WIP) время выполнения (Lead Time) сокращается пропорционально. Это не про то, что все стали усерднее трудиться, – это простая арифметика.

Где возникают проблемы

Закон Литтла работает только при стабильном потоке: сколько задач заходит, столько примерно и выходит. Если есть mura – то есть скачки в поступлении задач, – лимит WIP будет то создавать заторы, то пустовать.

Поэтому действовать нужно по цепочке mura, затем muri, потом muda: сначала хотя бы примерно выровнять поток входящих задач – например, через классы обслуживания или ограничение числа одновременно стартующих задач. И только потом ставить лимит WIP. Пытаться применять лимит на хаотичном, неровном потоке – значит лечить не причину, а симптом.

Контрмера Б. Poka‑yoke – боремся с переделками 

Механика. Poka‑yoke (метод Сигео Синго из Toyota) напрямую повышает показатель %C&A на этапе – не за счёт более тщательного поиска ошибок, а за счёт того, что делает ошибку невозможной.

Синго выделял два уровня защиты – и это не просто нюанс, а выбор силы решения:

• контролирующий poka‑yoke не даёт совершить ошибку – это самый надёжный вариант;
• предупреждающий – только сигнализирует о ней, но человек может его проигнорировать, поэтому он слабее.

Мы в компании всегда, где возможно, выбираем контролирующий вариант – он даёт устойчивый результат и заметно снижает переделки.

Привязка к карте простая: находим шаг с низким %C&A и работаем именно с ним.

В нашем примере проседали груминг (70%) и тестирование (75%) – и причина у обоих одна: работа уходит дальше, не будучи доведённой до нужного состояния. Контрмеры:

Контрмера В. DMAIC в поисках причины

Механика. DMAIC (каркас Six Sigma) используют не каждый день, а только когда на карте виден этап с низким %C&A, а причина проблемы неочевидна.

Он помогает не бросаться чинить первый попавшийся симптом, а разобраться в настоящей причине. Его сила – в пяти чётких шагах: они задают системный подход.

Обратите внимание: DMAIC не заменяет poka‑yoke – он помогает к нему прийти. На этапе Improve выбирают подходящую контрмеру из уже знакомого набора. Инструменты не соперничают: они – звенья одной цепи.

Где Six Sigma не работает

Целевая метрика Six Sigma – 3,4 дефекта на миллион – рассчитана для ситуаций, где есть миллион одинаковых возможностей для ошибки. В разработке такого не бывает: каждая задача уникальна.

Поэтому не стоит гнаться за «сигма‑уровнем» в тестах – это попытка подогнать живую работу под жёсткую формулу. И не нужно убирать всю вариативность: часть её – это творческая составляющая процесса. Райнертсен прямо предупреждает: не стоит уничтожать вариативность в разработке.

Лучше взять из Six Sigma каркас DMAIC и полезные инструменты анализа – Парето, «5 почему», диаграмму Исикавы. А сложную статистику оставить для поточного производства, где процессы действительно повторяются.

Стадия 4. Закрепление результата с помощью Кайдзен

Важно!
Кайдзен – это метод непрерывного улучшения. Майк Ротер, автор книги «Toyota Kata» показал, как часто смысл искажают: «кайдзен‑воркшоп раз в квартал» даёт улучшения примерно раз в год – это никак не тянет на непрерывность.

Настоящий механизм – ката улучшения: научный метод, который встраивают в обычную недельную работу. Именно он не даёт улучшениям из третьей стадии незаметно сойти на нет.

Четыре шага каты – это, по сути, контур управления, который навешивается на любую контрмеру.

Ротер подчёркивает: цель нужна не для того, чтобы её обязательно достичь, а чтобы направлять эксперименты и извлекать из них уроки. Если что‑то не сработало – это тоже результат, а не провал. Тут цель чёткая и узкая, срок – короткий, шаг – совсем маленький, а пробовать новое нужно постоянно.

Сквозной пример: к чему пришли

• Команда прошла два витка цикла. 
• На первом витке разобрались с очередью. По закону Литтла увидели, что в тестировании одновременно висит 7 задач (WIP = 7), и поставили лимит на колонку – не больше 3 задач. Это помогло упорядочить поток.
• На втором витке взялись за переделки. На этапе тестирования применили подход DMAIC и ввели обязательное поле для шагов воспроизведения бага – это работает как контролирующий poka‑yoke: ошибку просто не получится пропустить.
• Через полтора месяца картина заметно изменилась. Возвраты багов упали с 40% до 12%, а качество тестирования выросло: показатель %C&A поднялся с 75% до 90%. В целом по потоку Rolled %C&A вырос с 40% примерно до 62%, а сквозное время выполнения задач (Lead Time) сократилось на 34%.
• Стало ясно, что проблема была не в нехватке людей – узкими местами оказались очередь и постоянные переделки. Поэтому от найма новых сотрудников отказались.
• Дальше команда перешла к третьему витку – теперь в фокусе оказался груминг, где %C&A держался на уровне 70%. Карта процессов чётко показала его как следующее узкое место.

В этом и суть подхода: цикл не заканчивается, он каждый раз подсвечивает, куда двигаться дальше.

Стадия 5. Поддержание цикла улучшений

Две вещи из Lean, без которых цикл быстро перестаёт работать. Это не разовые инструменты, а базовые условия – они держат всю систему.

1. Andon, право остановить релиз

В Toyota любой рабочий может остановить конвейер, если видит дефект. В QA это прежде всего про культуру: у тестировщика должно быть реальное право сказать «релиз не едет». Без этого весь подход теряет смысл: качество превращается из обязательного условия в пожелание, а метрики вроде %C&A некому отстаивать.

Где всё ломается?
В Toyota, если рабочий дёргает шнур, к нему бегут помогать, а не наказывать. Если у тестировщиков формально есть право остановить релиз, но за каждое такое решение устраивают разбор вроде «почему QA опять всех задержал», то этим правом перестанут пользоваться уже через неделю. А следом незаметно начнёт падать и общий показатель качества – Rolled %C&A. Право остановки работает только там, где сама остановка – нормальная часть процесса, а не повод для упрёков.

2. Визуализация на стене, а не в презентации

Три ключевые метрики цикла – Activity Ratio, Rolled %C&A и WIP по колонкам – должны быть на виду у команды и регулярно обновляться. Если они перекочуют в квартальный отчёт, цикл быстро превратится в «инициативу на квартал» – а такие инициативы обычно заканчиваются вместе с отчётным периодом.

Обзор системы из всех 5 стадий

Порядок внедрения для команды, которая начинает с нуля:

1. Сначала сделайте карту – хватит одной встречи на час. Без неё вы будете исправлять проблемы наугад. 
2. Затем внедрите один poka‑yoke на этапе с самым низким %C&A: быстрая победа поможет команде поверить в результат. 
3. Когда заметите очередь – введите лимит WIP. 
4. Ката используйте в ретроспективах: это поможет закреплять улучшения и повторять работающие шаги. 
5. DMAIC применяйте только тогда, когда столкнулись с непонятной проблемой – не как рутину, а как инструмент для разбора конкретного случая.
6. Andon и визуализацию вводите сразу, с первого дня: это не отдельные шаги, а среда, в которой команда будет работать.

Улучшение – это не проект с началом и концом, а способ работы. Если превратить его в «инициативу» на квартал, оно исчезнет вместе с этим кварталом.

Мы в «Лаборатории Качества» не предлагаем внедрять все эти методики по шаблону, так как у каждой команды своя боль. Где‑то проблема в очередях, где‑то – в переделках, где‑то – в перегрузке или слабом входном контроле. 

Поэтому мы выстраиваем систему точечно: сначала карта потока по проекту клиента, потом по метрикам находим, где именно рвётся процесс. Затем подбираем решение под реальную причину и оставляем команде готовый контур каты – чтобы улучшения продолжались. Этот подход мы активно используем во время наших аудитов.

Давайте разберём именно ваш проект: исследуем текущие процессы, найдём узкие места и подберём подходящий цикл улучшений. Первый разговор ни к чему не обязывает – просто обсудим, где можно повысить эффективность и как это сделать без лишней нагрузки на команду.

Список использованных источников

1. Оно, Т. Toyota Production System: Beyond Large-Scale Production / Т. Оно. — Cambridge, MA : Productivity Press, 1988. — 176 с. — ISBN 978-0-915299-14-2.
2. Синго, С. Изучение производственной системы Тойоты с точки зрения организации производства / С. Синго ; пер. с англ. — М. : Институт комплексных стратегических исследований, 2006. — 312 с. — ISBN 5-903148-04-4.
3. Поппендик, М. Бережливое производство программного обеспечения: от идеи до прибыли / М. Поппендик, Т. Поппендик ; пер. с англ. — М. : Вильямс, 2009. — 288 с. — ISBN 978-5-8459-1531-9.
4. Ротер, М. Toyota Kata: управление, развивающее людей / М. Ротер ; пер. с англ. — СПб. : Питер, 2018. — 384 с. — ISBN 978-5-4461-0736-2.
5. Райнертсен, Д. Управление потоком разработки программных продуктов / Д. Райнертсен ; пер. с англ. — М. : Лори, 2014. — 344 с. — ISBN 978-5-85582-903-5.
6. Мартин, К. Картирование потока создания ценности / К. Мартин, М. Остерлинг ; пер. с англ. — М. : Альпина Паблишер, 2021. — 236 с. — ISBN 978-5-9614-5125-4.
7. Литтл, Дж. A Proof of the Queueing Formula L = λW / Дж. Литтл // Operations Research. — 1961. — Vol. 9, № 3. — P. 383–387. — DOI: 10.1287/opre.9.3.383.
8. Toyota Motor Corporation. Production System. — Toyota City : Toyota Motor Corporation, 2020. — URL: https://global.toyota/en/company/vision-and-philosophy/production-system/ (дата обращения: 28.08.2026).
9. Art of Lean, Inc. Lean Terms and Definitions. — Los Angeles : Art of Lean, 2019. — URL: https://artoflean.com (дата обращения: 28.08.2026).