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

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

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

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

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

В 2016 году я столкнулся с довольно неприятной ситуацией. Моя компания уже провела тендер на разработку собственного сайта и выбрала исполнителя. Третий месяц тянулся один из первых этапов работ по «водопадному» процессу – разработка эскизных дизайн-концепций.

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

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

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

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

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

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

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

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

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

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

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

– Use Case

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

– User Story

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

– Job Story

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У вас может быть экспертное мнение в своей профессиональной области, но во время разработки нового функционала это всего лишь гипотезы.