В результате у вас получится продуктовый бэклог в виде онлайн-таблицы, отражающий:
– Боль/проблему пользователя;
– описание функционала, который эту проблему решает (и как решает);
– Важность для пользователя;
– Важность для бизнеса;
– Сложность реализации;
– Совокупный балл приоритета;
– Критерий приёмки (каким образом функционал должен быть реализован, чтобы уйти в релиз).
Из верхней части списка выделите решения, которые войдут в релиз. В процессе разработки потребуется декомпозировать каждую функциональность на более мелкие части и делить по спринтам. Об этом в следующей главе.
Вовлечённость
Вторая проблема, с которой вы можете столкнуться на этапе планирования релиза, – отсутствие вовлечённости. Это может происходить из-за того, что вы не даёте разработчику возможность придумывать идеи, а поручаете только выполнять их.
У вас может быть экспертное мнение в своей профессиональной области, но во время разработки нового функционала это всего лишь гипотезы.
Точно такие же гипотезы (а может и лучше), могут возникнуть и у исполнителя. Дайте ему возможность поучаствовать в процессе формирования идей – и получите вовлечённых помощников.
Заподозрив другие причины отсутствия искорки в глазах, – такие как личные проблемы, полное непонимание происходящего или незаинтересованность в выполнении проекта, – как можно скорее выясните, в чём дело.
Отсутствие понимания и личные проблемы – скорее всего, временное влияние, которое можно исправить, а вот с категорической незаинтересованностью разобраться уже гораздо сложнее. Поговорите с руководителем исполнителя, если он есть. Если ситуация не изменится – переходите к обсуждению расторжения договора.
Исполнитель может быть вовлечённым и профессиональным, но без вас он проект не завершит. Обязательно договоритесь, насколько часто вы будете встречаться для обсуждения статуса и деталей задач.
Для средних по длительности проектов достаточно двух встреч на спринт (от недели до месяца): На первой вы обсуждаете, что уже сделано, что и почему не сделано и план на неделю, а на второй собираете список из «почему не сделано» и ищете закономерные возможности для устранения закономерных проблем. Если вы лично не можете принимать участие в подобных обсуждениях, найдите помощника, который будет защищать ваши интересы как заказчика, но никогда не пускайте всё на самотёк.
Тараканы
Помните, мы составляли список «страхов» в запросе на разработку? Откройте его во время планирования задач с исполнителем и ещё раз обсудите ваши действия в том случае, если страхи оправдаются. Пусть подрядчик помнит, чтó вас беспокоит. Но также спросите и о его страхах. Скорее всего, среди них будут:
– микроменеджмент с вашей стороны;
– отсутствие вовлечённости (противоположная проблема);
– невыполнение обещаний (обычно под этим подразумевается непредоставление материалов в срок или затягивание согласований).
Заранее предпримите все необходимые меры, чтобы страхи исполнителя не оправдались. Как сделать это с микроменеджментом, я расскажу в следующей главе, а решить проблемы отсутствия вашей вовлечённости или невыполнения обещаний вы должны самостоятельно.