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

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

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

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

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

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

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

Поставляйте как можно быстрее

Есть еще одна lean-ценность – поставляйте как можно быстрее.

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