Совместное формирование бэклога продукта оказалось очень полезным. Ранее Майкл считал, что может сделать все: и обеспечивать поставку нового продукта, и управлять остальными задачами компании. В результате его усилия распределялись между многочисленными объектами и ни один не получал должного внимания. Решив, что требования к разработке продукта сейчас важнее, чем производство, планирование пространства и подбор персонала, Майкл признал, что обладает ограниченным ресурсом энергии и должен выбирать, как ее использовать.

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

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

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

Заказываемые компоненты и детали были новыми на рынке, часто новее доступных прототипов, их было трудно найти. К тому же сотрудникам отдела закупок часто приходилось описывать компоненты поставщику, не имея технических знаний, которые позволили бы им это сделать качественно. Результат – потерянное время и недовольство. Инженеры запрашивали компонент, закупщики старались найти его, поставщики старались предоставить альтернативу, закупщики возвращались к инженеру с альтернативным предложением, иногда инженеры соглашались на аналог, тогда закупщики возвращались к поставщику, но за это время компонент продавался кому-то другому. Такое происходило каждую неделю.

Чтобы решить проблему закупки компонентов, мы наняли в группу инженеров-разработчиков двух младших инженеров. Они были «младшими» только потому, что у них не было кандидатской степени MIT. Теперь старший инженер обращался с запросом компонента к младшему инженеру, а уже тот работал с отделом закупок и был уполномочен принимать решения по аналогам и идти на компромиссы. Чтобы повысить вероятность получения наиболее подходящей альтернативы, всех инженеров оснастили сотовыми телефонами. Решение по предлагаемому аналогу принималось в реальном времени поставщиком, отделом закупок, младшим инженером и, при необходимости, старшим инженером, который запросил эту деталь.

Вы можете подумать, что ускорение процесса закупки – тривиальное достижение. Тем не менее ежедневный скрам показал, что эта проблема приводила к самым большим потерям времени: не давала старшим инженерам работать друг с другом и с Майклом, деморализовала их, препятствовала получению заметных результатов.

Извлеченные уроки

Активное участие Майкла в разработке продукта существенно сфокусировало работу подразделения и привело к успешному решению критических проблем. Привлечение младших инженеров к закупкам освободило старших инженеров для работы над сложными проблемами и одновременно ускорило получение компонентов.

Результатом стала успешная демонстрация подсистемы на выставке, через месяц после которой BigTel купила TechCore за $1,43 млрд. Майкл помог команде сфокусироваться на наиболее ценных задачах, и это обеспечило рентабельность инвестиций в размере почти $1 млрд за шесть месяцев. Неплохо.

Вместо того чтобы громко заявлять: «У нас будет новая роль – владелец продукта», можно просто предложить собраться вместе и обсудить, что делать дальше. Люди часто с подозрением относятся к новому жаргону и новым методологиям – и не без оснований. В этом разделе мы рассмотрим важность общения с бизнесом на простом языке или, по крайней мере, на деловом.

MegaBank – это один из крупнейших финансовых институтов Соединенных Штатов с филиалами по всей стране и достаточной капитализацией для влияния на финансовые рынки. За год компания MegaBank осуществила внутренние и внешние переводы на сумму $39,6 трлн. Эти переводы осуществлялись с помощью «Системы денежных переводов» (Fund Transfer System, FTS), которая успешно завершает все транзакции, обеспечивает их безопасность и ведет журналы для аудита.

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

С момента первого внедрения FTS заказчики от MegaBank поменялись. Менеджер первого релиза Генри получил повышение. Прямая подчиненная Генри, Мэри, заняла его позицию, но посчитала исправление ошибок и усовершенствование системы слишком трудоемкими и менее важными, чем другие ее обязанности. Она делегировала все коммуникации и координацию проекта следующему сотруднику в иерархии – Лори, резкому менеджеру с очень ограниченным пониманием функций FTS. Лори с трудом удавалось управлять задачами проекта.

Руководство MegaFund FTS назначило дату релиза на 15 октября. Шел май, а команда все еще не понимала, как FTS может добиться от заказчиков четкого направления развития и сотрудничать с ними для обсуждения возможных альтернативных вариантов достижения целей второй версии системы.

Как скрам помог проекту MegaBank FTS

Пэт встретилась с Генри, Мэри и Лори и рассказала, что команда FTS собирается использовать скрам, который уже применяется для успешного управления другими проектами в MegaBank. Не понимая, что это для них значит и сколько времени на это потребуется, Генри, Мэри и Лори просто надеялись, что скрам поможет им более тесно сотрудничать с командой разработки FTS.

Меня попросили организовать встречу и представить скрам. Я выступил с краткой и взвешенной презентацией, в числе прочего сказав, что в других проектах компании мы используем упорядоченный список требований, которые заказчики ожидают увидеть готовыми через месяц. Каждый месяц команды демонстрируют заинтересованным лицам завершенную функциональность и все вместе рассматривают и обсуждают список того, что необходимо делать дальше. Затем команда выясняет, что сможет сделать за следующий цикл.

Генри, Мэри и Лори остались очень довольны: скрам казался им легким, понятным и требовал только одной официальной встречи в месяц (обзора спринта). С таким объемом они точно справятся, хотя до встречи опасались, что переход на новый процесс разработки потребует обучения, новых форм, новых отчетов и множества накладных расходов. Однако скрам показался им очень простым.