5 – Как планировать разработку

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

Потери информации в процессе передачи сообщения.

Автор теории – Предраг Мицич.

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

Чем тщательнее вы проговариваете требования – тем лучше. А в идеале не только проговаривать, но и показывать на примерах, рисунках, схемах, таблицах – где угодно. Главное – донести суть и проверить, насколько правильно она понята. Только после того, как вы убедились в правильном понимании исполнителем всех ваших требований – отпускайте функционал в дальнейшую проработку.

В случае гибкой разработки все иначе. Рассмотрим 3 инструмента, помогающие в планировании при гибкой разработке:

– Use Case

– Нагляднее других инструментов помогает описать функционал, но заковывает в «рамки креативности» автора.

– User Story

– Позволяет планировать релизы проще, чем в остальных методах, но увеличивается риск разрастания ошибочных гипотез.

– Job Story

– Максимально точно помогает сосредоточиться на выполнении задач пользователей, но не имеет иерархии и сложно выявить зависимости.

Выбирайте инструмент исходя из особенностей команды и проекта. Если работаете только с аккаунт-менеджером и не общаетесь с финальными исполнителями – следует выбрать диаграммы вариантов использования. Но в случае участия всей команды выбирайте более гибкую методику – получите массу продуктовых идей, и тем самым добьётесь большей объективности в гипотезах.

Во время планирования релиза с командой откройте список «болей пользователей», которые должен закрыть ваш продукт. Каждый участник встречи предлагает свой вариант решения, а вы заносите в таблицу. В процессе генерации идей важно не критиковать решения, а собрать максимальное их количество. Я люблю использовать онлайн-таблицы Google Sheets для подобных задач.

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

В результате у вас получится продуктовый бэклог в виде онлайн-таблицы, отражающий:

– Боль/проблему пользователя;

– описание функционала, который эту проблему решает (и как решает);

– Важность для пользователя;

– Важность для бизнеса;

– Сложность реализации;

– Совокупный балл приоритета;

– Критерий приёмки (каким образом функционал должен быть реализован, чтобы уйти в релиз).

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