Как избежать превращения процесса в формальность?

Случалось ли вам сталкиваться с тем, что благие начинания (внедрение скрама, канбана, написания RCA, проведение FST анализа…) со временем превращаются в формальность?

Кажется, отличные практики, на первой итерации находятся импрувменты, которые лежат на поверхности. А со временем стирается смысл этих практик и остается простое следование процессу. Часто вижу такое, когда прихожу в другой проект, это видно со стороны, когда что-то делается для галочки.

Как с этим быть?

1. В первую очередь, вспомните, для чего, для какой цели эти практики внедрялись, какую проблему решали?

Эта цель уже достигнута, проблема решена? Если да, то есть ли смысл вообще продолжать эту практику? Оцените кост и бенефит и избавьтесь от ненужных процессов.

Например, в одном из моих проектов были очевидные области для улучшений: были пробелы в тестовой области и в автоматизации процесса тестирования, было много faulty fixes (когда люди своими изменениями в коде вносят в код новые проблемы), большой lead time для всех активностей, часто проблемы всплывали на стороне заказчика, пропущенный всеми нашими Quality assurance процедурами. В этот период мы ввели процесс написания RCA по каждой проблеме.  В течение года мы писали RCA, не для галочки, а раскапывали до истинных причин. И сразу делали предложенные импрувменты, на каждой итерации выбирали quick wins, который стоят дешевле, а пользы принесут больше (об этом подробнее в следующих пунктах). За этот год много проблемных областей были покрыты, и большинство проблем исчезло. Отпала необходимость написания RCA. Да, проблемы иногда случались, но мы уже выбирали среди них те, ради которых стоит писать полноценный RCA, а для остальных делали просто краткий анализ и оценку коста и бенефита от импрувмента.

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

Например, у вас был скрам, вы делали большие фичи. И вот количество фич уменьшилось, задания в девелопменте «высосаны из пальца», команда привлекается к maintenance работе. Очевидно, что в этом случае скрам уже не является идеальным решением и проще перевести команду в maintenance и пользоваться Канбаном, пока не появятся новые фичи.

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

Например, можно провести KaiZen workshop.

Шаг 1. Опишите проблему, ситуацию в данный момент. Опишите негативные последствия этого. (например, много faulty fixes, 2-4 в месяц, это подрывает доверие заказчика, мы тратим лишнее время на фиксы).

Шаг 2. Опишите желаемое положение дел и последствия (0 faulty fixes, доверие заказчика, освобождается время на написание новых фич).

Шаг 3. Опишите, какие шаги необходимо сделать на пути к цели, какие инструменты вам помогут. (например, писать RCA по каждому faulty fix, сразу планировать наиболее приоритетные импрувменты).

Шаг 4. Составьте план. До какого момента вы будете повторять практику? Когда будет сделан первый шаг? (запланировать, по каким существующим faulty fixes будет написан RCA, договориться, кто и за какой срок пишет RCA по новым faulty fix).

Шаг 5. Следование плану и контрольные проверки. Завести реестр faulty fixes, заносить туда результаты всех RCA, список предложенных импрувментов, расставлять приоритеты, сразу планировать наиболее важные импрувменты и включать их в бэклог работы команды с высшим приоритетом (это очень важно! потому что обычно импрувменты делаются по остаточному принципу,  и на них никогда не хватает времени). Создать регулярные митинги, на которых будет проверяться статус.

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

© Ирина Захарьина
Share