Перед тем как переделывать Analyzo, мы сначала написали дизайн-документ с перечнем уже построенного, разбором источников данных и планом первой версии. Документ показал четыре блокера: показатели хранились без привязки к сайту, клиентский портал закрывал от клиента его данные, прав доступа по каналам не существовало и сбор данных шел двумя параллельными конвейерами. Вердикт документа сводился к доработке существующего стека, ведь первая версия на нем занимала 22–30 человеко-дней против 90 и более при переписывании с нуля.
Discovery фаза перед разработкой — это короткий предпроектный этап, на котором заказчик и исполнитель выясняют, что строить, для кого и сколько это стоит, прежде чем подписывать договор на сам продукт. Так выглядел результат такого этапа в нашем случае: блокеры, вердикт и оценка.
Discovery фаза: за что платит заказчик на самом деле
Вы платите за сужение вилки оценки. По классической оценке Барри Боэма (1981 год), которую называют конусом неопределенности, на старте проекта, до сбора требований, итоговые трудозатраты могут оказаться и в четыре раза больше первой оценки, и в четыре раза меньше. Подрядчик, которого просят назвать цену по двум абзацам брифа, закладывает запас под все, чего не знает. За discovery платят потому, что неизвестное убирают до того, как начнется работа с почасовой оплатой.
Автор разбора по системному анализу, опубликованного на Хабре, выделяет три ключевых результата этапа: предложение по технической реализации, границы проекта и оценку стоимости и сроков.
| Вопрос | До discovery | После discovery |
|---|---|---|
| Что строим | Два абзаца брифа и список пожеланий | Роли, сценарии и граница первой версии с перечнем того, что в нее не входит |
| Как строим | Подрядчик сам выбирает схему и сервисы | Описание архитектуры и интеграций с обоснованием выбора |
| Сколько стоит | Вилка, которая может доходить до четырехкратной в обе стороны | Оценка по разобранным сценариям с названными допущениями |
| Что считать готовым | Договариваются по ходу работы | Критерии, которые проверяются при приемке |
Если после discovery вам по-прежнему говорят «оценка ориентировочная, уточним по ходу», этап свою работу не сделал. Границы и допущения должны быть записаны так, чтобы по ним можно было спорить.
Когда discovery фаза не нужна
Этап занимает деньги и время, поэтому иногда его разумно пропустить. Он избыточен, если продукт небольшой и понятный, например лендинг с формой, бот с одной функцией или внутренний инструмент для себя. Он избыточен и тогда, когда подрядчик много раз строил такое же и показывает рабочие образцы. Наконец, этап лишний, когда вы уже подготовились: прототип есть, с будущими пользователями поговорили, критерии приемки записаны.
В таких случаях, на мой взгляд, хватает недели. Сначала запишите границы первой версии на одной странице, а затем проверьте экспериментом интеграцию с чужим сервисом, потому что по нашему опыту она дает больше всего неожиданностей. Этап целиком можно пропустить, когда стоимость возможной ошибки меньше стоимости самого этапа.
А когда этап нужен? Если хотя бы на два из пяти вопросов вы отвечаете «пока не знаем»: кто платит за продукт, что входит в первую версию, как он встроится в рабочие системы, какие внешние сервисы понадобятся и какой бюджет допустим. Правда, это порог нашей практики, учебники такого числа не дают. Когда неясно даже, для кого продукт, начните с позиционирования IT и SaaS-продукта, потому что discovery отвечает на вопрос, как строить, и вопрос «для кого» закрывается раньше него.
Недельный вариант собирается так: два первых дня вы выписываете сценарии и границы первой версии, на третий и четвертый проверяете на реальных данных узел, который вызывает у вас больше всего сомнений, а в последний день подрядчик читает страницу и называет оценку с допущениями. Если допущений набралось много, недельный вариант не справился, и пора переходить к полной версии.
Четыре риска, которые проверяет discovery перед разработкой
Содержание этапа можно строить по четырем рискам продукта, которые выделяет Мартин Каган из Silicon Valley Product Group: ценность (купят и будут ли пользоваться), удобство (поймут ли, как это делать), реализуемость (сможет ли команда построить с имеющимися сроками, навыками и технологиями) и жизнеспособность для бизнеса. К последней относятся каналы продаж, юридические ограничения, стоимость привлечения клиента и способ зарабатывать на продукте. Каждый шаг этапа закрывает один из этих рисков.
| Риск | Вопрос | Чем проверяют |
|---|---|---|
| Ценность | Нужен ли продукт тем, ради кого его строят | Разговоры с представителями целевой аудитории, проверка предложения до разработки |
| Удобство | Поймет ли человек сценарий без подсказок | Кликабельный прототип и просмотр, как по нему проходят задачу |
| Реализуемость | Можно ли построить это в срок на выбранных технологиях | Техническая проверка рискованных мест, список интеграций, архитектурная схема |
| Жизнеспособность | Сходится ли экономика и есть ли путь к клиентам | Расчет цены и юнит-экономики, проверка каналов и ограничений |
Реализуемость в Analyzo закрылась исследованием каналов в дизайн-документе до начала интеграции. В том же дизайн-документе по рекламным каналам выяснилось, что у Telegram Ads нет официального API, данные там идут выгрузками или через реселлера, а у Avito Реклама есть публичное API с агентским мультиаккаунтом, и этот канал попал в кандидаты первой версии.
Дизайн-документ закрыл реализуемость, но ценность в Analyzo осталась непроверенной: за 90 дней в продукте не появилось ни одной внешней регистрации. Из источников данных подключали Метрику и Вебмастер, а Директ, VK, Google и CRM ни разу. Продукт при этом работал без единого внешнего пользователя, и вопрос, кому он нужен, остался открытым.
Этапы discovery фазы по неделям
В модели Double Diamond, которую описывает Design Council, первый ромб посвящен тому, чтобы понять, в чем проблема, прежде чем что-то предполагать. Для этого нужны разговоры с людьми, которых проблема касается. Ориентир ниже рассчитан на B2B-продукт с одной-двумя ролями и несколькими интеграциями, а чем больше неопределенности, тем длиннее цепочка.
- Неделя 1. Цели и контекст. Встречи с заказчиком, метрика успеха, существующие системы, ограничения по бюджету и срокам. Итог: записанные цели и список вопросов без ответа.
- Недели 1–2. Рынок и пользователи. Разбор аналогов и несколько разговоров с будущими пользователями по каждому сегменту, пока ответы не начнут повторяться.
- Недели 2–3. Роли, сценарии и границы. Кто работает в продукте, какие задачи решает, какие функции входят в первую версию и какие нет.
- Недели 3–4. Прототип. Кликабельные экраны ключевых сценариев и проверка на людях, которые раньше продукт не видели.
- Недели 4–5. Архитектура и техническая проверка. Схема частей, список внешних сервисов, пробная реализация самого рискованного узла.
- Недели 5–6. Оценка и план. Трудозатраты по сценариям, этапы поставки, допущения и риски с владельцами.
Расспросите собеседников о последнем случае, когда у них возникала эта задача. Кто ее решал, какими инструментами, сколько это стоило времени и денег и что мешало. За таким ответом стоит событие, которое можно проверить. Если у собеседника задача не возникала за последние месяцы, это тоже данные о ценности.
Студии, которые продают такой этап, называют разные сроки, от нескольких дней до восьми недель, и чем больше неизвестных, тем дольше он идет. Если на шаге с разговорами выяснилось, что покупатель не тот, остальную цепочку перестраивают, и это нормальный результат этапа.
Результаты discovery: артефакты, по которым можно получить оценку
Артефакт на выходе у этапа один: комплект документов, который живет отдельно от исполнителя. Эти документы называют артефактами этапа, а кликабельный прототип в них означает набор связанных экранов, по которым можно пройти сценарий мышкой.
| Артефакт | Что внутри | Для чего нужен дальше |
|---|---|---|
| Карта ролей и сценариев | Кто что делает в продукте, какие права у каждой роли | Основа оценки и тестовых проверок |
| Прототип | Экраны ключевых сценариев со связями между ними | Согласование с командой и проверка удобства |
| Архитектура и интеграции | Части системы, внешние сервисы, ограничения | Проверка реализуемости и расчет затрат |
| Границы первой версии | Что входит и что отложено | Защита от расползания объема |
| Оценка и план этапов | Часы по сценариям, допущения, риски | Основа для бюджета и договора |
Проверка качества у такого комплекта одна: передайте его другому подрядчику и попросите оценку. Если он называет ее по документам, без многочасового созвона, материалы рабочие. В разборе, который опубликовал руководитель отдела системного анализа, на этап поставили одного начинающего аналитика, и разработчики посмотрели на его артефакты и не смогли дать по ним оценку. Заказчика компания потеряла.
Из этого же комплекта потом собирается техническое задание, и чем точнее границы и сценарии, тем меньше в нем допущений, которые подрядчик достраивает сам.
Когда discovery окупается: сколько стоит и сколько длится
Открытые цифры студий расходятся, и одна из причин в том, что под словом discovery каждая студия может держать свой набор работ. Одна студия называет полноценный этап длиной в один-два месяца и стоимостью примерно от 700 тысяч до миллиона рублей. Другая предлагает свой вариант от 300 тыс. рублей на восемь недель и приводит среднерыночные данные, от 500 тысяч до полутора миллионов рублей и срок от двух дней до месяца.
Эти числа взяты со страниц, где этап продается, поэтому читайте их как порядок величины, независимой статистики за ними нет. Цена складывается из числа ролей и сценариев, числа разговоров с пользователями, кликабельного прототипа, сложности интеграций и состава команды. Дешевый вариант без прототипа и разговоров закрывает только реализуемость и оставляет ценность и удобство без проверки.
Сопоставьте стоимость этапа с ценой ошибки в вилке. Если разработка стоит миллионы, а оценка без разбора колеблется в четыре раза в обе стороны, платная неделя-другая выглядит страховкой. А если бюджета на полный этап нет? Для продукта с бюджетом в сотни тысяч рублей этап в полном объеме съест заметную часть денег, и рабочий вариант собирается из недели на эксперимент и страницы с границами.
Этап лучше покупать с ограничениями. В договоре фиксируют список документов на выходе, срок и потолок часов, а отдельной строкой записывают право остановиться после discovery. Если оценка вас не устроила, вы забираете материалы и платите только за сделанное, поэтому этап не обязывает вас продолжать с той же студией.
Discovery для стартапа своими силами
Без подрядчика основатель может пройти тот же путь в сокращенном виде. Начните с трех-пяти гипотез о ценности: кто платит, за что и вместо чего. Затем поговорите с людьми из целевой аудитории и записывайте их формулировки дословно, они пригодятся для текстов продукта. После этого нарисуйте прототип главных сценариев и покажите его тем, кто продукта не видел.
Параллельно возьмите самое рискованное техническое место и потратьте на него день или два: подключите чужой сервис, выгрузите реальные данные, проверьте скорость ответа модели. Результат такой проверки весит больше презентации архитектуры. Затем соберите список функций первой версии, прикиньте цену и точку окупаемости по юнит-экономике и только после этого идите к подрядчикам с готовым комплектом. С ним вы приходите со сценариями и границами и спрашиваете, какие допущения исполнитель закладывает в цену.
Где проект теряет деньги на самом discovery
Сам этап бывает источником проблем. В другом случае из разбора на Хабре требования получились хорошо детализированные и заказчик продолжил работу, но при заложенных 180 часах ушло больше 300, то есть в 1,7 раза больше, а ожидания заказчика совпали с результатом не полностью: команда еще не понимала, что такое discovery на практике. Три правила помогают.
- Нужна команда из нескольких ролей. В описанном выше хорошем результате работали два аналитика, архитектор и дизайнер интерфейсов, а заказчик участвовал в решениях. Один начинающий аналитик из другого случая с этапом не справился.
- Каждое решение записывается, и у него есть ответственный. Договоренность, которая жила в устном разговоре, в споре о цене уже не помогает.
- Результат описан до старта. В договоре перечислены документы на выходе, срок, лимит часов и порядок действий, если лимит заканчивается раньше, чем документы готовы.
Красные флаги из этого раздела собираются в короткий перечень: оценка «ориентировочная, уточним по ходу», один начинающий аналитик на весь этап, решения без записи и документы, которые не может оценить другая студия.
Главный вопрос к студии до старта звучит просто. Покажите комплект артефактов из прошлого проекта без названий клиентов. По нему видно, насколько конкретны сценарии, есть ли в оценке допущения и можно ли по этим бумагам работать без автора. Если разработку вы планируете именно у этой студии, договоритесь, что материалы остаются у вас и после этапа.
С чего начать на этой неделе
Перед тем как подписывать договор на разработку, пройдите по короткому списку. Пропущенный пункт возвращается правками и спором о том, что входило в цену. Я бы не подписывала договор, пока хотя бы один пункт остается пустым.
- Записано, кто платит за продукт и что он получит, а гипотеза о ценности проверена в разговорах с людьми.
- Есть прототип, который прошли люди, не видевшие продукт раньше.
- Самое рискованное техническое место проверено экспериментом.
- В документе есть строка о том, что в первую версию не входит.
- Оценка разложена по сценариям, у каждого допущения есть название.
- Комплект документов могут прочитать и оценить в другой студии.
Если вы запускаете продукт и хотите до разработки проверить позиционирование, аудиторию и план вывода на рынок, оставьте заявку на didvi.ru, и мы разберем их на стратегической сессии. О том, как связать запуск с каналами, мы писали в статье про вывод продукта на рынок.
Частые вопросы
Чем discovery отличается от технического задания?
Discovery отвечает на вопросы, что строить и стоит ли, а ТЗ фиксирует уже выбранный результат и правила приемки. Материалы этапа становятся основой ТЗ, поэтому сначала идет разбор, потом документ.
Платить за discovery отдельно или в составе разработки?
Отдельный договор дает право забрать материалы и получить вторую оценку у другой студии. Внутри общего договора проще сохранить непрерывность команды, но проверить свободу выбора труднее.
Нужна ли discovery для ИИ-продукта?
Да, с одним дополнением: до разработки проверяют, что выбранная модель справляется с вашими примерами. Небольшая выборка реальных запросов за день-два показывает, достаточно ли качества, и без нее оценка стоимости остается угадыванием.
Сколько людей участвует в discovery?
В хорошем описанном случае работали два аналитика, архитектор и дизайнер интерфейсов, а заказчик участвовал в решениях. На простом продукте роли совмещают, на сложном добавляются специалисты по данным и безопасности.
Что делать, если discovery показала, что продукт строить не стоит?
Это тоже результат этапа: вы заплатили за разбор и не потратили бюджет на продукт, которого никто не купит. Дальше можно сузить идею до сегмента, где ценность подтвердилась, или начать с сервиса на готовых блоках, а собственный продукт отложить до подтверждения спроса.