Как определить бюджет и сроки запуска цифрового продукта — советы заказчикам

Основные этапы разработки цифрового продукта

MVP (Minimum Viable Product)

Минимально жизнеспособный продукт может быть реализован в виде легковесного решения или инструмента из категории low-code — подхода к разработке программного обеспечения, не требующего написания программного кода. Например, сайт, созданный с помощью конструктора Tilda, или мобильное приложение в Adalo или Bubble. Необходимо отметить, что MVP может не являться ИТ-продуктом. 

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

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

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

Например, набор посадочных страниц (лендингов) компании-интегратора ИТ-решений для B2B-клиентов, создаваемый для проверки спроса и тестирования новых методов продвижения. На каждый лендинг закладывается 20 часов дизайна и 20 часов верстки, которые оплачиваются в соответствии с часовой ставкой команды и вырабатываются еженедельно.

Еще пример. Веб-приложение с базой данных стартапов и инвесторов на рынке России и за рубежом. Первая версия кабинета стартапа оценена в 50 часов lowcode-разработчика. Первая версия кабинета инвестора — аналогично 50 часов. Административная панель управления сервисом — еще 50 часов. Итого 150 часов на первую версию, которые разбиваются на итерации по 25 часов в неделю.

Разработка в классическом кросс-платформенном стеке с командой разработки

Как правило, применяется при работе над более тяжеловесным продуктом, в котором есть клиентская и серверная часть, базы данных, бэкапы и сервера. При таком подходе можно встретить модели оплаты как за результат, так и за время. 

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

Например, онлайн-сервис по организации клининга помещений у B2B-заказчиков с веб-сайтом и мобильными приложениями клиента и клинера, а также административной панелью. Веб-сайт клиента оценен в 50 часов дизайна и 50 часов frontend-разработчика. 

Веб-сайт клинера — аналогично для первой версии. Мобильные приложения клиента и клинера оценены в трудозатраты по 100 часов каждое. Административная панель управления сервисом оценена еще в 100 часов frontend-разработчика. Также на серверную часть в первой версии закладывается 200 часов backend-разработчика. 

Итого 600 часов команды разработки с несколькими ролями, которые разбиваются на итерации по 50 часов в неделю с поэтапной реализацией функционала, который можно посмотреть и протестировать по итогам каждой недели.

Поддержка и развитие

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

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

Например, доработка сайта интернет-магазина выпечки на популярной CMS-системе. На поддержку и развитие команда заложила 20 часов backend-разработчика, 20 часов frontend-разработчика и 20 часов контент-менеджера. Итого 60 часов ежемесячно, которые вырабатываются с предоставлением отчетности заказчику. Соотношение аванса и остатка оплаты оставляем за скобками.

Модели бюджетирования

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

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

Этот подход часто становится попыткой заказчика перенести риски на команду разработки. Особенно часто это встречается среди неопытных заказчиков с низким уровнем компетенций в части работы с IT. Обычно такие клиенты с подозрением относятся к оплате за время, которое потратила команда разработки на проект.

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

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

Наиболее распространенные ошибки

Размытое видение цифрового продукта у заказчика

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

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

Модель оплаты за результат с размытым видением продукта

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

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

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

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

Попытка сэкономить за счет команды с более дешевыми рейтами/ставками

Закладывая бюджет, заказчик может сэкономить на двух уровнях: объем работ и команда разработчиков. Объем работ учитывает непосредственно продукт и его функционал. Выбирая команду, заказчик может оценивать стоимость услуг исполнителя. 

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

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

Итеративный подход и классический подход

Если при разработке проектов команда использует итеративный подход, работа разбивается на итерации/этапы/спринты. Обычно они длятся одну-две недели или месяц в зависимости от команды и параметров проекта. 

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

Также возможно использование классической модели — «водопада» (waterfall). Этот подход имеет свое отражение в методологии PMBoK (Project Management Body of Knowledge) — своде знаний по управлению проектами. 

Такой метод подходит для продуктов (проектов) с фиксированным видением и границами функционала. Использование этой модели часто обусловлено корпоративной культурой компании, в которой реализуются крупные долгосрочные проекты с высокой долей производственной или hardware составляющей. 

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

Формируется дорожная карта, общий scope, границы проекта, которые делятся на итерации и реализуются по частям. Сегодня при планировании запуска продуктовых стартапов чаще всего наблюдается такой подход — итеративный с управлением границами и функционалом продукта на каждой итерации. 

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

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

Советы заказчику

• Выпишите свои пожелания и требования по продукту

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

• При запросе оценок/смет от разных команд разработки используйте структурированное на бумаге (в документе) видение продукта

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

Вас должны насторожить предложения с ощутимо меньшими оценками трудозатрат/объемов работ (риск недооценки объемов работ и границ бюджета проекта) и очень низкими ставками в час (риск нехватки компетенций у команды).

• Отдавайте предпочтения командам разработки и отдельным разработчикам, классическим или no-code/low-code, которые предлагают разбивать весь объем работ на понятные этапы/итерации, предоставляют отчеты по выработке часов с использованием инструментов учета времени и поддерживают ведение качественной документации по продукту, например в формате онлайн-базы знаний.

Фото на обложке: mrmohock / Shutterstock