Находите первопричины обнаруживаемых проблем
Находите первопричины обнаруживаемых проблем
Проводить измерения и видеть объективную истину в отношении проекта и команды – это только первая часть видения целого. Вторая часть – понимать первопричины (или фактические причины) проблемы.
первопричины
В конце главы 6 мы обещали вернуться к причинно-следственному анализу, потому что, будучи важной частью бережливого мышления, он также является одним из методов вывода для команд XP. Команды XP и lean-группы используют метод пяти «почему», чтобы выяснить коренную причину проблемы. Как и многое в бережливом мышлении, эта техника зародилась в японской автомобильной промышленности, но отлично подошла agile-командам. Согласно этой простой практике, члены команды задают вопрос «почему» и делают это не менее пяти раз (хотя получают ответы), пока не обнаружат первопричину проблемы.
пяти «почему»
В нашем примере команда может использовать метод пяти «почему», задавая примерно такие вопросы:
• Почему среднее время выполнения так велико? Потому что выполнение пожеланий большинства пользователей требует более шести месяцев, чтобы превратить их в программное обеспечение.
Почему среднее время выполнения так велико?
• Почему требуется более шести месяцев, чтобы превратить запросы в программное обеспечение? Потому что эти запросы на функции почти всегда отодвигаются, чтобы освободить место в расписании для изменений, поступивших в последнюю минуту.
Почему требуется более шести месяцев, чтобы превратить запросы в программное обеспечение?
• Почему существует так много подобных изменений? Потому что, прежде чем команда сможет выпустить ПО для пользователей, она должна сделать обзор со старшими руководителями, которые практически всегда запрашивают некие базовые, фундаментальные изменения.
Почему существует так много подобных изменений?
• Почему топ-менеджеры почти всегда запрашивают базовые, фундаментальные изменения? Потому что каждый из них имеет собственное, довольно специфическое мнение о том, как программа должна выглядеть и функционировать, какие технические средства следует использовать, чтобы ее создать, но команда не слышит этих мнений до тех пор, пока она не напишет весь код и не сделает презентацию для старших менеджеров.
Почему топ-менеджеры почти всегда запрашивают базовые, фундаментальные изменения?
• Почему команда не может услышать эти мнения до тех пор, пока она не напишет весь код и не проведет презентацию? Потому что топ-менеджеры слишком заняты, чтобы поговорить с командой в начале проекта, они появятся только на финальной презентации – и после ее завершения отправят команду обратно к чертежной доске.