пяти «почему»,

чтобы выяснить коренную причину проблемы. Как и многое в бережливом мышлении, эта техника зародилась в японской автомобильной промышленности, но отлично подошла agile-командам. Согласно этой простой практике, члены команды задают вопрос «почему» и делают это не менее пяти раз (хотя получают ответы), пока не обнаружат первопричину проблемы.

В нашем примере команда может использовать метод пяти «почему», задавая примерно такие вопросы:

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

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

• Почему существует так много подобных изменений? Потому что, прежде чем команда сможет выпустить ПО для пользователей, она должна сделать обзор со старшими руководителями, которые практически всегда запрашивают некие базовые, фундаментальные изменения.

• Почему топ-менеджеры почти всегда запрашивают базовые, фундаментальные изменения? Потому что каждый из них имеет собственное, довольно специфическое мнение о том, как программа должна выглядеть и функционировать, какие технические средства следует использовать, чтобы ее создать, но команда не слышит этих мнений до тех пор, пока она не напишет весь код и не сделает презентацию для старших менеджеров.

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

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

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

Понимание первопричины долгого времени выполнения дает несколько вероятных решений. Команда может создавать ПО более итеративно и попросить менеджеров принимать участие в демонстрации в конце каждой итерации, а не только основного релиза. Менеджеры могут делегировать свое право утверждать продукт тому (например, владельцу продукта), кто принимает более активное участие в проекте и чаще встречается с командой, и доверить этому человеку право принимать полномочные решения. Кроме того, команды и менеджеры могут продолжать создавать программы таким же образом и оставить неизменными длительные сроки выполнения, но обзавестись аккаунт-менеджерами для работы с пользователями и клиентами, чтобы управлять их ожиданиями.

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

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме пяти «почему»,:

  1. Случай 1 – Обыкновенная Модель Пяти Волн
  2. Случай 3 – Неудавшаяся Модель Пяти Волн
  3. ПРОДВИЖЕНИЕ ДОМА РОТШИЛЬДОВ К МИРОВОЙ СЛАВЕ И ПРИЗНАНИЮ ПРИ “ПЯТИ ФРАНКФУРТЦАХ"
  4. Прогресс экономической теории на протяжении последних двадцати пяти лет. Вводная лекция о предмете курса
  5. Почему? По кочану, вот почему!
  6. Обратная Логика Может Быть Применена При Убывающей Последовательности из Пяти Волн. Организация Механической Торговли
  7. Почему клиент должен купить именно у вас, а не у кого-нибудь из ваших конкурентов? И почему он вообще должен именно сейчас что-то купить, а не сэкономить деньги и не пройти мимо?
  8. Волны или к Фазе Второй Попытки. Третья Волна - Исходный Уверенный Подъём Четвёртая Волна – Откат Пятая Волна – вторая попытка в том же направлении Случай 2 – Неправильная Модель Пяти Волн
  9. Если данное соотношение больше, чем 1.5, тогда данная сделка стоит того, чтобы принять её во внимание. Обратная Логика Может Быть Применена При Убывающей Последовательности из Пяти Волн. Правила: Второй Тип Торговли (Продажа в конце подъёма Пятой Волны)
  10. Почему вы рекомендуете этот бизнес?
  11. Почему мы здесь?
  12. Почему же я не богат?
  13. Почему?
  14. 5. Почему?… В дополнение к этому…