Как понять заказчика: принципы CustDev для разработчиков

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

haithem ferdi / unsplash

Яна Горфан

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

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

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

Понять друг друга и создать совместными усилиями крутой продукт помогают принципы Customer Development (CustDev) — методологии, которая проверяет жизнеспособность идеи или прототипа будущего ПО.

Заказчики с Марса, или Почему люди говорят на одном языке, но не понимают друг друга

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

Почему понимать заказчика — важно?

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

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

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

Как использовать принципы CustDev для понимания задачи

User First

Принцип №1

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

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

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

Ищите ценность

Принцип №2

Ценность — это то, что делает пользователя счастливым, а заказчику позволяет зарабатывать. Как это ни парадоксально, чтобы найти ценность, нужно отделить эмоции от фактов и собрать как можно больше информации о проблеме. Чтобы как-то оцифровать этот процесс, я вывела для себя критерий измеримости/субъективности.

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

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

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

Создавайте гипотезы

Принцип №3

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

Как это бывает

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

Отсюда возникает сразу несколько продуктовых гипотез.

Написать скрипт для автоматизированной обработки заказов, интегрировать его в сайт и CRM-систему. Такое решение будет быстрым и дешёвым, но проиграет в долгосрочной перспективе, ведь большинство конкурентов уже используют мобильные приложения для монетизации клиентской базы.

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

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

От ХЗ к ТЗ: задавайте правильные вопросы, фиксируйте ответы и предлагайте решения

Итак, ваша цель — понять, какую проблему вы должны преодолеть, и найти оптимальное решение, которое впишется в жизнь пользователя и сделает её проще, а не наоборот. Так, если мы создаём функциональность для заказа такси с несколькими детскими креслами, будет здорово добавить её в уже существующее приложение, а не заставлять пользователя устанавливать новое.

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

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

Вопрос	Ответ
Расскажите подробнее о ваших клиентах: кто эти люди, как они вас находят, в каких случаях они пользуются вашими услугами?	Это люди 25+, живут в крупных городах России, имеют средний доход. Во время коротких праздников (майские, июньские, ноябрьские) они любят куда-нибудь отправиться отдохнуть, при этом заранее ничего не планируют — это чаще спонтанное решение. Наш сервис помогает подобрать и забронировать горящие туры на праздничные даты без наценок. В основном нас находят через поиск, также мы используем рекламные каналы.
Расскажите пошагово, как обычно происходит бронирование с точки зрения пользователя?	Пользователь заходит на сайт, при помощи фильтров выбирает направление и даты, открывает каталог туров, выбирает подходящее предложение и нажимает на кнопку «Бронировать». Дальше заполняет свои данные, и после подтверждения брони оператором вносит оплату — для этого менеджер отправляет электронное письмо со ссылкой на платёжную систему.
С какой проблемой сталкивается пользователь в процессе бронирования?	Менеджер не всегда мгновенно видит новое бронирование, к этому моменту у туроператоров часто уже заканчивается срок предложения.
Что происходит, когда пользователь сталкивается с этой проблемой?	Клиент бронирует тур в другом месте либо отменяет поездку.
Как часто данная проблема проявляется? Есть ли статистика? Сколько в деньгах вы теряете?	Судя по аналитике, это около 30% от общего количества бронирований. С учётом среднего размера нашей комиссии мы теряем на таких бронированиях около 500 тысяч рублей в месяц.
Как вы сейчас решаете эту проблему? Что не так в текущем решении? Сколько денег вы на него тратите?	Мы наняли пять новых менеджеров и выстроили график работы таким образом, чтобы новые бронирования проверялись круглосуточно. Зарплата менеджера — 50 тысяч рублей в месяц.
Как мобильное приложение поможет решить проблему, на ваш взгляд?	Приложение поможет автоматизировать весь процесс, ускорит обработку заказов и увеличит вероятность повторного заказа от одного клиента.
Как вы поймёте, что проблема решена?	Отток клиентов сократится примерно на 30%.
Что изменится в работе компании, когда вы решите проблему?	Мы сможем повысить обороты компании и захватить дополнительно 10% рынка.
В какой системе / в каких системах сейчас работают ваши менеджеры? Как получают заказы? Как бронируют туры? Как выставляют счета на оплату? Как взаимодействуют с клиентами?	Мы получаем бронирования через виджет на сайте, затем менеджеры вручную заносят их в amoCRM. Они используют систему Galileo для проверки мест у туроператора, выставляют счёт с помощью «Робокассы» и общаются с клиентами через телефон и корпоративную электронную почту со встроенными шаблонами писем.

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

Ответы на вопросы зафиксируйте в письменном виде и дополните своим вариантом решения. Вот так может выглядеть фоллоу-ап для заказчика из предыдущего примера:

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

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

CRM-система также станет частью платформы, она будет автоматически принимать новые заказы, отправлять запрос в систему бронирования туроператора по API и генерировать письмо со ссылкой на оплату тура.

Так вы будете экономить более 3 млн рублей в год на персонале и получите 6 млн дополнительного дохода. Платформа окупит себя максимум через 3 года и позволит масштабировать бизнес без дополнительных затрат на персонал.

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

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