«Нужен сайт». С такого запроса удобно начать оценку страниц и функций. Но пока неизвестно, что мешает покупке: человек не понимает услугу, не может объяснить её коллеге или не получает ответа после обращения. В последнем случае новая страница вряд ли поможет.
В главах 30–35 разберём, как превратить технологическую или экспертную услугу в интернет-проект и проверить основания для разработки до её начала. Такой же порядок пригодится для интеграции, автоматизации, кабинета и платформы.
В конце получится комплект для решения «строить / не строить» и передачи в производство:
- коммерческая модель: глава 31;
- карта решений: глава 32;
- доказательства и ворота: глава 33;
- ТЗ на функцию первой версии: глава 34;
- матрица ответственности: глава 35.
Документы связаны: карта решений опирается на коммерческую модель, а ТЗ — на результаты проверки. Если основания не подтвердились, следующий документ пока не собирают.
На какую часть покупки повлияет проект
Клиент говорит: «нужен сайт», «сделайте кабинет», «автоматизируйте продажи». Оценивать удобно, смысла пока мало. Кто покупает? В какой ситуации? Какое решение принимает? Почему сейчас? Что меняется после запуска?
Сайт помогает человеку пройти часть пути к покупке. Он объясняет предложение, показывает доказательство, собирает данные, передаёт человека сотруднику. Он не создаёт цену бездействия, не чинит убыточную услугу и не заставляет продажи отвечать вовремя.
Поэтому сначала выясни, где останавливается покупка, и лишь затем выбирай форму решения.
Входная диагностика
Восстанови одну недавнюю покупку и один отказ. Спроси о событии, участниках, прошлых попытках, причине выбора, задержке, результате и той части маршрута, на которую способен повлиять проект.
Раздели ответы на факты, гипотезы и пожелания. Записи разговоров, сделки, сроки ответа и платежи: факты. «Финансовому директору нужен калькулятор»: гипотеза. «Хотим солиднее»: пожелание. Гипотезу ещё нужно проверить, а пожелание — связать с задачей.
Три решения
Разработка не обязательна.
- Не строить: ограничение вне цифрового пути или экономика не сходится.
- Сначала проверить: покупка и предложение не подтверждены.
- Строить ограниченную версию: повторяемый разрыв найден, цифровой механизм на него влияет.
Красные флаги: аудитория «все компании», успех равен посещаемости, ни одной разобранной продажи, функции скопированы у конкурента, у обращений нет владельца. Это основание для отдельного этапа снижения неопределённости, не для лекции клиенту.
Что клиент получает до разработки
Диагностика имеет результат и приёмку. Клиент получает протокол фактов, критические неизвестные, план глав 31–35 и решение о шаге. Доступ к покупателям, сделкам и сотрудникам оговаривают заранее. Без него модель подтвердить нельзя.
Разработку пока не начинают. Сначала коммерческую модель восстанавливают по реальным случаям и проверяют с покупателями. На ней будет основана карта решений следующей главы.
Контрольная точка
Перед главой 31 готовы:
- коммерческий разрыв;
- минимум одна покупка и один отказ;
- гипотезы и источники проверки;
- три допустимых решения;
- платный этап с доступами и критериями.
Иначе оценка разработки будет опираться на непроверенные предположения о нужном объёме работ.