Цикл Деминга (PDCA)

"Есть у революции начало, нет у революции конца!"
 -- Ю. С. Каменецкий

На одной из своих презентаций Деминг нарисовал цикл (который он назвал циклом Шухарта) состоящий из четырех шагов: Plan-Do-Check-Act (PCDA), ну или по русски: Планируй-Выполняй-Проверяй-Принимай решение.
Этот цикл получил широкое распространение и рассматривается в таких стандартах как ISO 9000 и ISO 20000. Этакий стандарт для проведения непрерывных улучшений. Под катом я постараюсь систематизировать, в первую очередь для себя, что вкладывается в понятие цикла PDCA. Но если есть желание почитать мои мысли по этому поводу или подискутировать, то прошу.
Как я уже сказал, цикл PDCA появился в разрезе управления качеством. Есть некая проблема, с которой надо бороться. Чтобы не изобретать каждый раз процесс для борьбы с проблемой, можно взять рассматриваемую методику и применять ее до тех пор, пока проблема не будет решена.
Итак 4 шага цикла:
Планирование - определяем какими первопричинами может быть вызвана проблема и пытаемся их устранить. Для чего определяем одно изменение которое будем вносить в имеющуюся систему. Можно и несколько, но в этом случае возникает сложность с оценкой влияния каждого из изменений на получившийся результат и будет проблема на этапах Check и Act. На этом же этапе необходимо определиться с показателями, которые качественно или хотя бы количественно позволят оценить эффект от внедрения изменений.
Выполнение - вносим изменение в систему. Если есть возможность, то лучше вносить изменение не во всю систему, а в некоторую небольшую часть. Например, Facebook все обновления дизайна и новые функции тестирует на небольшой группе серверов. И основная часть пользователей даже не знает, что уже запущено изменение.
Проверка - берем показатели из этапа планирования и проверяем, в результате внедрения изменения мы их достигли или нет.
Принятие решения - самый сложный этап. Хотя в оригинальном цикле он и называется Act, на нем происходит выбор одного из трех решений:
1. Run Again - запустить цикл еще раз. Расскажу по секрету, после любого решения цикл нужно запускать еще раз, ведь одно из названий у этого подхода: цикл непрерывных улучшений. Но, именно этот вариант решения срабатывает когда положительный эффект от изменения наблюдается, но проблема до конца не решена. Поэтому, для той же самой проблемы мы начинаем новый цикл. С планирование нового изменения. Либо продолжаем применять тоже самое решение. В этом случае цикл может чуть поменяться и выглядеть так, как предлагает Олег Скрынник:

Но это не "классическое" понимание цикла PDCA.2. Abandon - отказаться от изменения, поскольку его результаты неудовлетворительны. Самое главное, это не принять решение, что все плохо и изменения не удались, а начать новый цикл, запланировав, выполнив и так далее нового изменения направленного на решение проблемы.
3. Adopt - утвердить изменение. Это для случая, когда изменение решило проблему и дальнейших изменений проблема не требует. Но, опять же, нельзя прерывать цикл. Решили эту проблему? Выбираем следующую и опять запускаем цикл PDCA. Только постоянная работа над совершенствованием дает результат. Как только мы прекратила улучшения и начали почивать на лаврах, мы поехали вниз.

Ну и в заключении, небольшой пример.
Есть несколько специализированных команд, которые работают над одним проектом. В процессе работы выясняется, что время от появления ТЗ на новое требование, до передачи ее в эксплуатацию составляет несколько месяцев, причем это время от требования к требованию растет.
Plan: Нас не устраивает время прохождения требования через разработку, следовательно целевым показателем мы можем установить время от передачи ТЗ в разработку, до передачи реализованного требования в эксплуатацию. Применив, например, теорию ограничения систем, мы находим "узкое место" - тестирование. В начале итерации они простаивают, в конце итерации они перегружены и не успевают протестировать все то, что остальные команды реализовали. Принимаем решение организовать буфер перед отделом тестирования, чтобы сделать работу более равномерной в рамках всей итерации.
Do:  Не стремимся закончить тестирование всех требований до конца итерации, часть тестирования оставляем на начало следующей итерации, чтобы у тестироващиков всегда была работа.
Check: После нескольких итераций выясняется, что отдел тестирования загружен более равномерно, но существенного сокращения сроков передачи требований в эксплуатацию не наблюдается.
Act: Изменение не принесло пользы, отказываемся от него и начинаем новую итерацию (Abandon).
Plan: Оставляем тот же самый целевой показатель, но пробуем переформировать команды из специализированных, в кросс-функциональные (так называемые Feature-team). Чтобы эти команды могли получив требование полностью выполнить все работы по нему (и поправить БД, и внести изменения в Backend, и внести изменения во Frontend, и протестировать).
Do: Формируем несколько кросс-функциональных команд.
Check: Время прохождения требований существенно сократилось, в связи с тем, что одно требование теперь не ходит между разработчиками Frontend-а и Backend-а несколько итераций.
Act: Подводя итоги выясняется, что при формировании кросс-функциональных команд, основная масса требований стала переходить в эксплуатацию быстрее, но появились требования которые на командах "зависают", т.к. в них нет специалистов такого уровня, которые могли бы эти задачи решить. Продолжаем улучшения (Run again).
Plan: Высококлассных специалистов выводим из команд и формируем команду рейнджеров, которые обучают специалистов других команд и приходят на помощь в экстренных ситуациях.
И т.д.