Независимо от амбиций владельцев и соотношения между фиксированной и почасовой оплатой, общая стоимость стадии концепции не должна превышать 10–15 % от бюджета проекта. Даже если по итогу работы станет понятно, что не удается найти хорошее решение и нет смысла переходить к реализации цифрового продукта, потери бизнеса останутся приемлемыми. Гораздо хуже сразу начать активную проектную работу, пытаясь на ходу искать концептуальные решения, и в итоге потратить почти весь бюджет на напрасные усилия.
Прогнозирование сроков работы над концепцией аналогично оценке стоимости. Есть доступное бизнесу временное окно для того, чтобы понять, в каком направлении можно развивать компанию. Оно зависит от рыночной ситуации и темперамента владельцев. Концепция должна давать принципиальный ответ – стоит ли игра свеч и есть ли возможность запустить компанию с новой бизнес-моделью. Завершив эту стадию, у команды должно оставаться достаточно времени для реализации проекта. Поэтому работу над концепцией продукта всегда стоит четко ограничивать по длительности – по моему опыту, она не должна превышать двух месяцев. Это связано и с психологическими аспектами: отсутствие видимых результатов может привести к потере мотивации и контроля над ситуацией.
Многим кажется, что на этой стадии нужно подготовить лишь презентации, схемы решения и наброски макетов интерфейса на уровне дизайна. Это неверно. Такие результаты не уменьшают неопределенность, а остаются хорошо оформленными гипотезами. Чтобы их проверить, недостаточно фокус-групп и глубинных интервью. Нужен действующий прототип продукта, который позволит убедиться в том, что найденная бизнес-модель действительно привлекает клиентов компании и дает качественные результаты.
Главным критерием успешного завершения стадии и прохождения контрольной точки можно назвать снижение неопределенности до уровня, когда бизнес сможет сказать: «Да, мы готовы рискнуть и продолжить проект» или «Риски слишком высоки, мы останавливаем работы». Это еще одна причина не обращаться сразу в компании, занимающиеся разработкой, и тем более не использовать гибкие методики типа Scrum. Такие компании зарабатывают на продаже человеко-часов своих специалистов и выигрывают независимо от того, терпит ли проект неудачу или начинает приносить пользу его владельцам. Не в их интересах, чтобы бизнес мог отказаться от проекта на ранней стадии, когда бюджет еще не израсходован. Делая упор на быстрый переход к разработке, они упускают выбор той самой стены, к которой предстоит приставить лестницу.
В отличие от описанной ситуации, проджект-раннер действует иначе. Его мотивация связана с успехом проекта, и он, как и владельцы компании, хочет как можно раньше понять, стоит ли инвестировать свое время. Такого результата можно добиться, только проработав все уровни проекта и потом связав их вместе. На уровне бизнеса это выражается в понимании реалистичности принципиальной схемы решения и определении способа ее реализации. Владелец озвучивает свое видение бизнес-модели, а проджект-раннер помогает выбрать подходящие технологические инструменты. Только тогда начинают фигурировать мобильные приложения, онлайн-сервисы, голосовые ассистенты, нейронные сети и другие модные и не очень термины.
После выбора проджект-раннер и команда могут перейти к трем уровням модели продукта – функциональному, интерфейсному и техническому. Формулируют, что цифровой продукт должен делать, как выглядеть и как быть устроен. Нельзя ограничиться, например, только внешним видом, нужно найти сочетание формы и внутренней реализации, ведь это разные стороны одной монеты. Безусловно, это должно быть детализировано не больше, чем требуется для проверки работоспособности идеи и возможности ее реализации. Дополнять модель продукта должен действующий прототип, который отражает видение дизайна и подтверждает, что не осталось открытых технических вопросов, способных помешать разработке.
Только после этой работы у проджект-раннера появляется достаточно информации, чтобы понять, можно ли уложиться в сроки и бюджет. Несмотря на то, что модель продукта на стадии концепции только обретает контуры, это уже расчет, основанный на фактах, а не предположениях. Благодаря этому можно сформулировать требования к специалистам для следующих стадий и выяснить их доступность, как и текущую стоимость привлечения. Организационный уровень становится прогнозом и задает границы, в которых должен оставаться проект.