Что такое «понимание задачи» и как оно помогает в проектах

Ошибочно считать, что запуск продукта — это только про разработку, технологии и дизайн. Очень легко оступиться задолго до старта всего этого – на этапе первоначальных обсуждений. Если подрядчик и заказчик эффективно не синхронизировались на старте, ничего хорошего из дальнейшей работы не выйдет.

Чтобы такого не происходило, мы всегда составляем понимание задачи. Оно помогает в самом начале зафиксировать общую картину, не прибегая к громоздким ТЗ и многотомным документам. Просто делаем понятную и полезную точку опоры для всей команды. 

Что такое понимание задачи

Понимание задачи (ПЗ) — это краткое описание того, что мы узнали о заказчике и его продуктовой идее: кто инициатор, в каком контексте работает бизнес, какие цели и ограничения стоят перед проектом. Это документ — саммари, фиксирующее общий язык между заказчиком и командой, и помогающее быстрее двигаться к нужному результату.

Для нас ПЗ — не файлик, который делается где-то на первой встрече, и после этого теряется в ворохе документов. 

ПЗ не статично. Оно развивается вместе с продуктом: от первых встреч и гипотез к discovery-фазе, затем к MVP и   масштабированию с поддержкой. На каждом шаге появляются новые данные, уточняются метрики, корректируются сценарии и архитектурные решения.

Итак, ПЗ – это фундамент цифрового продукта, который позволяет:

• соотнести бизнес-цели и продуктовые гипотезы;
• определить приоритеты на ближайший этап (например, какие сценарии включаем в MVP, а какие откладываем);
• зафиксировать риски и ограничения, чтобы избежать недопониманий;
• держать команду и заказчика в одном информационном поле.

Так, ПЗ становится не только инструментом фиксации договоренностей, но и рабочим артефактом, вокруг которого выстраивается продуктовая стратегия.

Как создать понимание задачи

Создание понимания задачи может занимать много времени — до недели с учетом всех возможных этапов подготовки — переговоров, написания, корректировок и формирования решения. Но в долгосрочной перспективе это того стоит. Конкретнее о профитах поговорим чуть позже, а пока перейдем к тому, как мы готовим понимание задачи.

Встреча с заказчиком

Сразу оговоримся — это не первый контакт с заказчиком. Мы предполагаем, что до встречи по пониманию задачи у нас уже есть какие-то вводные: название компании, направление бизнеса и первичный запрос, сформулированный в 2-3 словах («нам нужен личный кабинет» или «разработайте нам маркетплейс»).

На встрече собираются ключевые люди. Со стороны заказчика — основатель компании, или владелец бизнеса, иногда руководитель направления. С нашей стороны — продюсер продукта, аналитик, архитектор или тимлид, а также UX-дизайнер. Подробнее о том, как правильно подобрать команду для цифрового продукта, рассказали в отдельной статье. 

Что нужно обсудить для понимания задачи

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

Затем говорим о пользователях, ЦА продукта: кто эти люди, для чего и в каких условиях будут (предположительно) использовать продукт, какие задачи хотят решать.

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

Когда все обговорили, кратко и устно резюмируем. Мы обязательно проговариваем, как в итоге поняли задачу — фактически, тезисно повторяем все, что сообщил заказчик и что нам удалось выяснить и сформулировать с ним вместе во время разговора. Часто первичный запрос, с которым клиент к нам пришел, к этому моменту сильно меняется. Вот вам пример:

Чувствуете разницу? Задача серьезно изменилась. А значит и решение будет уже совершенно другим — по форме, содержанию, временным и денежным затратам.

Итак, если задача в целом понята верно, и клиент это подтвердил, можно уже сейчас верхнеуровнево предположить, каким может быть решение. Если нет, значит мы что-то упустили во время разговора. Конечно, начинать все сначала не придется, но лишние 10-15 минут на уточнения и корректировку ПЗ потратить нужно будет.

Чтобы точнее настроиться на восприятие целей (и метрик, если они сразу проговариваются), прочтите наш  текст о практике целеполагания в цифровых продуктах. В нем мы разбираем, как именно размытые формулировки задач становятся причиной провала проектов.

Затем берем пару дней на создание документа с пониманием задачи и формулировку нашего предложения по реализации задуманного.

Работа после встречи

После встречи мы формулируем все услышанное и оговоренное в документ. Внутри – общие очертания желаемого продукта, а также гипотезы и измеримые цели. Например:

• «Сократить время обработки заявки с 5 дней до 2»;
• «Проверить гипотезу: пользователи будут использовать чат-бот для оформления заказов»;
• «Первый релиз MVP должен покрывать три ключевых сценария — регистрация, заказ и оплата».

Так формируется общий ориентир, вокруг которого дальше строится продуктовое проектирование, планирование MVP и дорожная карта продукта.

Что внутри понимания задачи

Документ, который получается в итоге, обычно состоит из трех частей:

О клиенте

Кратко описываем, кто заказчик и в каком контексте работает бизнес. Например: на каком рынке он действует, какие у него ключевые продукты или сервисы, кто конкуренты, кто клиенты.

О задаче

Фиксируем, ради чего создается продукт. Формулируем задачу со слов клиента максимально подробно — со всеми озвученными пожеланиями, условиями и подробностями. 

Наше решение

Определяем, как будем двигаться дальше. На этом этапе речь не о ТЗ, а о стратегии, и вот что мы фиксируем здесь в рамках понимания задачи:

• каким может быть путь продукта — фаза проектирования, разработка и запуск MVP, дальнейшее масштабирование;
• какие гипотезы проверим в ближайших итерациях;
• как будет выглядеть первая версия (MVP) и какие сценарии в нее войдут.

Такой документ не закрывает все вопросы, но дает общее направление: зачем делаем продукт, как будем подходить к его созданию, и какие шаги приведут нас к результату. 

Что дальше

После того как понимание задачи собрано, мы презентуем его заказчику. Это момент синхронизации: мы вместе смотрим на то, как сформулированы цели, сценарии и гипотезы, и вправе уточнить детали или что-то доработать.

Потом, дополняя зафиксированное ПЗ, мы формулируем коммерческое предложение (КП). Помимо всего того, что уже есть в ПЗ, КП включает также: 

• архитектурная гипотеза: основные технологии и компоненты системы, интеграции, работа с данными;

• состав команды и роли по этапам разработки;

• ориентировочные сроки и диапазоны затрат;

• возможные риски и способы их контролировать.

Следующий шаг чаще всего – это проектирование продукта. О нем мы написали в отдельной статье. А после – разработка, релиз и дальнейшее развитие. 

В чем профит понимания задачи

Работая над пониманием задачи, мы даем себе из будущего (когда проект уже вовсю идет) несколько преимуществ:

Четкие границы

Если мы понимаем задачу и знаем цель, которую преследует продукт, у нас меньше вероятности свернуть с намеченного пути и потратить время на что-то лишнее. Фактически, любую идею, фичу или изменение в продукте мы прогоняем через фильтр ПЗ.

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

Быстрый старт

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

Прозрачность и предсказуемость

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

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

Предсказуемый результат 

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

Лояльность клиента 

Это уже вопрос клиентского сервиса. Мы не просто удовлетворяем первичный запрос заказчика, а через разговор узнаем (а порой и помогаем ему узнать), что действительно нужно ему и его бизнесу. И почему именно это.

Управляемые риски

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

Вместо ситуации «делаем продукт ради продукта» получается краткий, но осмысленный набросок пути от идеи до измеримого результата.

Вывод

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