Дмитрий Ершов - Без ТЗ - Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов

Дизайнеры нарисовали шесть вариантов эскизов, но бизнес-заказчику ни один из них не нравился. Однажды директор подошла ко мне и спросила: «Дима, может быть, я слишком требовательна, но по-моему, у них получается как-то не очень».

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

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

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

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

Самая большая ошибка, которую здесь можно совершить, – увериться в том, что вас понимают на 100%. Даже если вам так кажется, это всё равно не так. Просто при передаче информации другому человеку она проходит через несколько коммуникационных этапов – и смысл постепенно теряется.

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

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

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

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

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

– Use Case

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

– User Story

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

– Job Story

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

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

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

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

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