Понимание задачи: когда делать и как готовить

Объясняем, как правильно поговорить перед постановкой сроков и бюджетов, чтобы ожидания по итогам проекта сошлись с реальностью. Примеры и полезные материалы прилагаются.

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

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

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

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

Например, если фича никак не влияет на достижение цели проекта, но при этом требует дополнительного времени на разработку, мы её не делаем.

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

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

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

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

Документ с пониманием задачи – это 3 основных тематических блока.

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

Второй блок — о задаче. Здесь наша детальная формулировка задачи со слов клиента — со всеми озвученными пожеланиями, условиями и подробностями.

Третий блок — наше решение. Подробно объясняем, как будем решать задачу заказчика. Фактически это КП, в котором зафиксировано:

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

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

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

До встречи по ПЗ у нас уже должны быть какие-то вводные: название компании, направление бизнеса и первичный запрос, который чаще всего не очень конкретный: «Нам нужен личный кабинет» или «Разработайте нам сервис». Все это обычно есть в первоначальной заявке на сотрудничество. Если чего-то нет — добываем. На основе вводных заранее определяем, кого из команды позвать на встречу для уточнения задачи.

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

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

Вопросы нужно разделить на тематические блоки, а ответы в ходе разговора записывать. Удобно делать это в табличке. Так будет проще вести беседу.

В конце встречи проговариваем, как в итоге мы поняли задачу. Тезисно повторяем всё, что удалось выяснить и сформулировать вместе с заказчиком во время разговора. Как правило, первичный запрос, с которым клиент к нам пришел, к этому моменту сильно меняется.

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

После встречи берём время на создание документа с пониманием задачи и формулировку решения, которое предложим заказчику.

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

Цельное составление ПЗ (проведение встречи + фиксация всей нужной информации в документе) занимает от одного дня до недели. Срок зависит от сложности проекта и вводных, которые дает нам клиент. Так или иначе, потраченное время всегда окупается: страхуем и себя, и заказчика от потенциальных проблем на проекте и получаем бонусы.

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

Очень много о понимании задачи мы почерпнули из материалов Бюро Горбунова. Если тема вас заинтересовала, рекомендуем ознакомиться: