В прошлой статье мы говорили о том, как выбирать «пилотную» команду исходя из типов людей и их реакции на внедрение нового процесса. «Пилотная» команда может понадобиться в условиях, когда у вас есть несколько проектов или команд на одном проекте и есть желание поменять “то, что есть” на легковесную и в тоже время достаточно четко определенную методологию, как например, Scrum.

Вне зависимости от того, была ли возможность подобрать людей в Scrum команду, важно правильно выбрать проект, который вы будете делать с использованием Scrum. Вторым важным фактором выбора «пилотной» команды, является правильный выбор проекта.

Проектом может быть отдельный модуль для существующей системы, очередной выпуск (релиз) или новый продукт. Важно, чтобы проект учитывал оптимальную комбинацию следующих параметров: размера, продолжительности, важности и вовлеченности бизнеса. Как говорит Майк Кон: не обязательно, чтобы все параметры были подобраны «идеально». Постарайтесь выбрать проект, который сбалансирован по указанным параметрами так, что они попадают в «оптимальную зону», как показано на рисунке.

В моих случаях с выбором команды как «пилотной», учёт этих параметров оказал благоприятное влияние.

1. Длина проекта

Оптимальный срок для пилотной команды, когда она задействована в выпуске (релизе), продолжительностью в 3-4 месяца. Если проект или релиз длится меньше, то сложно увидеть выгоды, а для проектов более 6 месяцев будет много шансов отклониться от общей цели на последних месяцах, при том, что долгое время наблюдались выгоды от использования гибких методов и предпринятых изменений.

Если говорить о командах, которые уже практикуют гибкие методы некоторое время, то, как рекомендацию для них, можно указать наличие регулярных дедлайнов каждые 3-4 месяца. Даже если идёт разработка проекта (выпуска/релиза) длинной в год и более, то важно проводить полную стабилизацию продукта как можно чаще. Для этого важно найти баланс между усилиями на подготовку к выпуску (системное/финальное) тестирование, и между важностью получения обратной связи от заказчика и пользователей, с тем, чтобы конечный выпуск уже учитывал все нужды и обеспечил максимальное состояние готовности.

2. Размер

Было бы сложно менять устоявшиеся процессы, когда вовлечено большое количество участников, т.е. большие команды или даже несколько команд сразу на одном проекте. Таким образом, выбор проекта с начальной командой из 3-9 человек даёт возможность сосредоточиться на улучшении процессов и получить осознанный результат, который потом уже легче адаптировать на несколько тесно взаимодействующих команд.

3. Важность проекта

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

4. Вовлеченность бизнеса

Главным благоприятным фактором является всесторонняя поддержка идеи изменить имеющиеся подходы. Идеально, если представители заказчика уже осознали необходимость менять существующие подходы, так как старые доказали свою несостоятельность. Как минимум они должны понимать, что они могут получить (наглядность, регулярность) и какие роли им придётся исполнять для взаимодействия с командой (Владелец Продукта или Заказчик, который договаривается с Владельцем Продукта).

В целом, правильный выбор команды и проекта даёт возможность получить максимально полезный опыт от внедрения Scrum подхода и дальше распространять его на другие команды. В тоже время, он не даёт стопроцентной гарантии успеха 🙂 Нам остается делать только лучшее из того, что мы можем делать в данный момент и не терять из виду нашей цели.