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

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

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

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

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

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

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

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

Кто участвует во встрече. На встречу для уточнения задачи клиента мы стараемся звать команду, которую предполагаем задействовать на этом проекте. Но это не значит, что если речь идёт о создании сложного сервиса с нуля (с проектированием, дизайном, разработкой и т.д.), мы придём огромной толпой. Достаточно представителя от каждого из направлений.

Если мы говорим о разработке сайта, то обязательный минимум на встрече — руководитель проекта и тимлид. Если нужен дизайн — зовём ведущего дизайнера. Предполагается, что на нас будет ещё и формирование позиционирования и написание текстов? Тогда пригласим на встречу редактора.

Как готовимся к встрече. Какой-то сверхсерьёзной и долгой подготовки к первой встрече не требуется. Мы обычно:

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

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

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

Мы задаём много вопросов, стараясь разделять их на тематические блоки. Конечно, вопросы от встречи к встрече меняются — универсального списка нет, ведь всё зависит от клиента, проекта, сферы бизнеса и т.д.

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

Всю информацию, которую нам удаётся получить на встрече, мы аккуратно фиксируем.

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

Сколько времени длится встреча. Мы закладываем на встречу с клиентом 1-1,5 часа. Меньше просто не хватит, мы же не на блиц-опросе. Наша задача — узнать клиента, а также помочь ему (и нам, конечно же) понять, что именно нужно его бизнесу и как этого можно достичь совместными усилиями. Кроме того, в процессе разговора, помимо заранее подготовленных вопросов, появляется ещё куча новых, на обсуждение которых тоже требуется время.

Дольше 1,5-2 часов мы стараемся не сидеть. Как правило, к этому времени изматываются и клиент, и команда, и тогда разговор перестает быть информативным.

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

Первичный запрос, с которым клиент пришел на встречу

Нужно разработать сервис, на котором клиенты и исполнители будут искать друг друга

Задача, сформулированная после встречи

Нужно максимально быстро и недорого проверить востребованность услуги по поиску исполнителей/клиентов

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

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

Затем мы берём пару дней на создание документа с пониманием задачи и формулировку нашего решение

Формирование понимания задачи и её решения

Структурно документ с пониманием задачи состоит из трех основных тематических блоков:

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

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

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

• что мы будем делать — разрабатывать сайт, проектировать интерфейс, проводить редизайн;
• какими средствами мы это будем делать — с использованием каких технологий;
• кто именно это будет делать — размер и состав команды, зоны ответственности;
• как мы будем это делать — верхнеуровневый план работы над проектом;
• в течение какого времени — примерные оценки по времени;
• сколько это будет стоить — примерные оценки по срокам.

Что дальше

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

В чем профит

Итак, чтобы сформировать, написать и утвердить понимание задачи, требуется много телодвижений. И всё это ради того, чтобы найти и предложить клиенту оптимальное решение — это и есть основной профит ПЗ. А к нему — ещё несколько бонусов. Например:

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

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

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

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

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

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

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

Вывод

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

Полезные материалы:

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

1. Киевская видео-лекция о понимании задачи от Ильи Бирмана
2. Большой урок о понимании задачи из продвинутого курса Главреда от Максима Ильяхова (доступен бесплатно)
3. Лекция про понимание задачи и вопросы Горбунова из курса «Переговоры и отношения с клиентами» от Ильи Синельникова (доступна по платной подписке)

Фото в заголовке: by Zuzana Ruttkay on Unsplash