В итоге наше терпение лопнуло и мы заказали дизайн-концепцию у другого исполнителя – маленькой студии всего с тремя дизайнерами. И результат не заставил себя долго ждать: уже через две недели эта студия провела нам потрясающую презентацию, а директор радостно восклицала: «Дима, тот же бриф, надо же! Тот же бриф!»
5 – Как планировать разработку
Недосказанность всегда против вас
После подписания договора и назначения установочной встречи ваша основная задача – договориться, как именно исполнитель будет создавать продукт.
Самая большая ошибка, которую здесь можно совершить, – увериться в том, что вас понимают на 100%. Даже если вам так кажется, это всё равно не так. Просто при передаче информации другому человеку она проходит через несколько коммуникационных этапов – и смысл постепенно теряется.
Потери информации в процессе передачи сообщения.
Автор теории – Предраг Мицич.
В случае водопадной разработки требования к результатам каждого этапа должны быть подробно описаны. Переспросите исполнителя, как он понял требования и какие задачи собирается выполнять. Это может показаться невероятным, но после такого упражнения вы сделаете немало новых открытий. Во-первых, в сфере разработки есть понятия, которые часто все трактуют по-своему. А во-вторых, все, что очевидно для вас – не очевидно для других.
Чем тщательнее вы проговариваете требования – тем лучше. А в идеале не только проговаривать, но и показывать на примерах, рисунках, схемах, таблицах – где угодно. Главное – донести суть и проверить, насколько правильно она понята. Только после того, как вы убедились в правильном понимании исполнителем всех ваших требований – отпускайте функционал в дальнейшую проработку.
В случае гибкой разработки все иначе. Рассмотрим 3 инструмента, помогающие в планировании при гибкой разработке:
– Use Case
– Нагляднее других инструментов помогает описать функционал, но заковывает в «рамки креативности» автора.
– User Story
– Позволяет планировать релизы проще, чем в остальных методах, но увеличивается риск разрастания ошибочных гипотез.
– Job Story
– Максимально точно помогает сосредоточиться на выполнении задач пользователей, но не имеет иерархии и сложно выявить зависимости.
Выбирайте инструмент исходя из особенностей команды и проекта. Если работаете только с аккаунт-менеджером и не общаетесь с финальными исполнителями – следует выбрать диаграммы вариантов использования. Но в случае участия всей команды выбирайте более гибкую методику – получите массу продуктовых идей, и тем самым добьётесь большей объективности в гипотезах.
Во время планирования релиза с командой откройте список «болей пользователей», которые должен закрыть ваш продукт. Каждый участник встречи предлагает свой вариант решения, а вы заносите в таблицу. В процессе генерации идей важно не критиковать решения, а собрать максимальное их количество. Я люблю использовать онлайн-таблицы Google Sheets для подобных задач.
После того, как идеи сгенерированы – проставьте вместе с командой оценки важности для пользователей и бизнеса, а также оценки сложности реализации. Затем проранжируйте решения по методу скоринга, как в первой главе при составлении задания на разработку.