Как вместе с клиентом из идеи спроектировать приложение

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

Как правило, клиент обращается в IT-компанию уже с идеей. У него много планов и представлений о том, каким должен быть продукт, но не всегда заказчик хорошо понимает техническую сторону вопроса. Наша задача — за руку с клиентом пройти путь от замысла к четкому плану действий. 

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

Что такое discovery-фаза и зачем она нужна

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

Без этого этапа риски берёт на себя уже сама разработка: туманные требования превращаются в переделки после первых релизов, а оценка «на глаз» — в превышение бюджета. Discovery решает четыре задачи:

• Снимает неопределённость. У клиента и у команды появляется общее понимание, что именно строим и для кого.
• Фиксирует объём работ. Артефакты discovery становятся основой для оценки сроков и бюджета.
• Выявляет риски заранее. Технические ограничения и пробелы в бизнес-логике дешевле найти на бумаге, чем в коде.
• Готовит MVP. Из полного списка фич сразу выделяется минимальный рабочий набор для первого запуска.

Проводим интервью 

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

Вопросы: 

1. Кто целевая аудитория продукта? Здесь мы выясняем портрет потенциального клиента: пол и возраст, географию, уровень дохода и так далее.

1. Какую проблему решает продукт? И действительно ли будущее приложение закрывает боли пользователей? 

1. Как будет происходить монетизация? Узнаем как клиент видит заработок на продукте, если монетизация вообще предполагается проектом. Например, для социального проекта прибыльность может не учитываться. 

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

1. Изучал ли клиент рынок? Важно понять какие решения были у конкурентов, что из этого мы можем взять во внимание, а что сделать по-другому. Если заказчик не проводил мониторинг, мы берем эту задачу на себя.

1. Кто будет продвигать продукт? Узнаем, есть ли у клиента свои маркетинговые мощности или потребуется рекомендации от нас.

Обсуждаем роли в системе 

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

• роль Водитель;
• роль Пассажир. 

В зависимости от роли будут меняться пользовательские истории. То есть интерфейс и функциональности ПО.

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

С клиентом мы обсуждаем сколько всего нужно “ролей”, и как они будут взаимодействовать в системе.  Так же определяем какие приложения необходимы (веб и мобильное приложение, админ-панель и так далее).

Когда discovery-фаза обязательна, а когда можно обойтись

Discovery оправдан не для любого проекта — иногда это лишний этап, который только тормозит запуск. Вот как мы сами решаем с клиентом, нужен ли отдельный discovery:

Ситуация	С discovery-фазой	Без discovery-фазы
Сложный продукт с несколькими ролями пользователей	Архитектура и пользовательские сценарии продуманы до старта кодирования	Высокий риск переделывать модули после первых релизов
Жёсткий бюджет и сроки	Чёткая оценка объёма работ и приоритизация MVP-фич	Оценка «на глаз», риск выйти за бюджет на середине проекта
Понятная узкая задача — лендинг, доработка существующего модуля	Избыточный этап, который тормозит запуск	Можно стартовать сразу с коротким ТЗ

Составляем набор артефактов 

Для каждого проекта мы формируем индивидуальный пул артефактов.

• MindMap  — это ментальная карта фичей. Здесь обозначаем, какие приложения потребуются
  внутри проекта, прописываем роли, (администратор, модератор и так далее), и то, как роли взаимодействуют с будущим приложением.
• Пользовательские истории. Раскрываем как каждая роль взаимодействует с системой.
• BPM диаграмма наглядно показывает как роли взаимодействуют с системой и друг другом.  Этот артефакт помогает избежать дыр в бизнес-процессах.  Когда мы видим перед собой схематичное взаимодействие, сразу становится очевидным, какие важные процессы в приложении остались не задействованными. 
• Дизайн-концепт. Обязательно рекомендуем нашим клиентам сделать  этот артефакт. Представляет из себя 2-3 варианта экрана будущего продукта. 
• Предварительная оценка сроков и бюджета. На основе MindMap и пользовательских историй формируем ориентир по срокам и стоимости разработки MVP.

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

Сколько длится и сколько стоит discovery-фаза

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

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

Как говорил предприниматель и автор методологии Customer Development Стив Бланк: «Ни один бизнес-план не выживает после первого контакта с клиентом». Discovery-фаза — это и есть первый контролируемый контакт идеи с клиентом, пока цена ошибки ещё минимальна.

Типичные ошибки на discovery-фазе

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

• Пропустить интервью и сразу рисовать интерфейс. Красивый макет без проверенных требований приходится переделывать, когда выясняется, что он не закрывает реальную задачу клиента.
• Не фиксировать роли и пользовательские истории письменно. Договорённости на словах расходятся в понимании команды и клиента уже через пару недель разработки.
• Растянуть discovery на месяцы «для перестраховки». Чрезмерно долгое исследование превращается в способ не начинать разработку и само становится риском для сроков проекта.
• Не привлекать заказчика к утверждению артефактов. Если MindMap и дизайн-концепт не согласованы с клиентом явно, решения команды могут разойтись с реальными ожиданиями.

Перед началом работы 

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

P.S.: Очень удобно выделять MVP при помощи цветов на MindMap. Таким образом вы с клиентом видите целостную картину фичей и что является минимальным рабочим продуктом.

Так на дискавери-фазе мы проектируем  будущее приложение вместе с клиентом.

Обсудить ваши идеи

Частые вопросы о discovery-фазе

Что такое discovery-фаза простыми словами?

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

Сколько длится discovery-фаза в разработке приложения?

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

Сколько стоит discovery-фаза?

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

Чем discovery отличается от обычного брифа или ТЗ?

Бриф — это анкета с общими вопросами о проекте, которую клиент обычно заполняет сам. Discovery — совместная работа команды и клиента: интервью, анализ рынка, проработка ролей и артефактов. Готовое ТЗ — один из результатов discovery, а не его замена.

Можно ли пропустить discovery-фазу и сразу начать разработку?

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

Какие артефакты я получу в результате discovery?

Базовый набор — MindMap фичей, пользовательские истории по ролям, BPM-диаграмма бизнес-процессов, дизайн-концепт из 2-3 экранов и предварительная оценка объёма работ для MVP. Набор артефактов формируется индивидуально под задачу.

Кто участвует в discovery-фазе со стороны подрядчика?

Как правило, в discovery участвуют бизнес-аналитик, который проводит интервью и собирает требования, и дизайнер, который готовит дизайн-концепт. Для сложных продуктов дополнительно подключается технический архитектор, чтобы заранее оценить ограничения и риски.