Раскрываем основные этапы оценки проекта с нуля, рассказываем о подходах в планировании бюджета, а также даем оценку условного стартапа
Разработка стартапа в IT требует креативности и технических знаний. Но в большей мере она требует вложений и умения эффективно управлять финансами. В статье мы раскрываем основные этапы оценки проекта с нуля, рассказываем о подходах в планировании бюджета, а также даем оценку условного стартапа.
Но для начала небольшое задание: представьте сумму, которой, как вам кажется, достаточно для запуска условного IT-продукта. Будет интересно сравнить ее c результатом расчета в конце статьи.
Для оценки бюджета на разработку любого продукта необходимо сформировать представление о нем. Чем более детальным оно будет, тем ближе окажется оценка к реальным будущим затратам. Для этого нужно провести идею стартапа через три последовательных этапа: оценить границы продукта, сопоставить их с предполагаемым объемом работ и выбрать метод оценки. Рассмотрим каждый из них.
Идея стартапа может звучать так: «Платформа для виртуального туризма и путешествий во все уголки мира». Или так: «Сервис для удаленной медицинской консультации и диагностики». Очевидно, что это будут совершенно разные продукты. Попытка оценить их по какой-то условной вилке цены на разработку стартапа не приведет ни к чему конкретному и хорошему.
Чтобы претендовать на объективность оценки, необходимо определить требования к продукту. Для этого нужно выписать исчерпывающий список вопросов и ответить на них (хотя бы гипотетически).
Список вопросов к будущей платформе для виртуального туризма может начинаться так:
Если же мы беремся развивать идею сервиса для удаленной медицинской консультации и диагностики, начало перечня может быть таким:
Каждый из таких вопросов требует поиска информации и оценки возможных вариантов. В зависимости от уровня подготовки и технических знаний будущего владельца продукта, этот этап может занять от нескольких дней до нескольких недель. В любом случае, мы рекомендуем не пренебрегать им и уделить достаточно времени на изучение всех нюансов.
Составив исчерпывающий список вопросов и ответов, следует определить функциональные и нефункциональные требования к продукту. Функциональные требования описывают действия пользователей. Нефункциональные — характеризуют саму платформу.
Перечень функциональных требований к будущему сервису для удаленной медицинской помощи может начинаться так:
Нефункциональные требования могут быть следующими:
Ответив на подобные вопросы и составив полный список требований, можно более точно определить границы и объем работ по разработке стартапа.
Когда у вас уже есть требования к продукту, наступает время для проработки его архитектуры. Архитектура — это структурное описание компонентов, модулей, интерфейсов и связей между ними, которое определяет общую концепцию продукта. В нем должны быть конкретизированы технические моменты: аппаратное и программное обеспечение, сети, базы данных и другие компоненты, необходимые для функционирования продукта. Это своего рода платформа для разработки, развертывания и сопровождения продукта, которая дает понимание его структуры и взаимодействия между компонентами.
Довольно часто стартапы запускаются группой разработчиков-энтузиастов, которые берут на себя финансовые риски и готовы работать за идею до тех пор, пока продукт не начнет генерировать прибыль. Если у вас своя команда, вы можете разделить архитектуру на блоки и оценить объем, который можете осуществить своими силами. А затем выделить блоки работ, которые планируете отдать на аутсорс, и считать бюджет на них.
Но чаще у владельца будущего продукта есть только он сам. Возможно, еще потенциальный инвестор. Последний теоретически готов поддержать идею, но пока не представляет, сколько будет стоить реализация. В таком случае лучшим решением будет обратиться в компанию, которая занимается заказной разработкой. Опираясь на описание границ и требований к продукту, специалисты составят архитектуру продукта, определят состав проектной команды и подсчитают примерное количество часов на каждого.
В оценке объема работ применяют следующие методы:
1. Декомпозиция требований. Функциональные и нефункциональные требования к продукту разбивают на отдельные задачи и подзадачи.
Комбинирование различных методов оценки помогает более реалистично прогнозировать объем работ. А значит, приблизить к расчету бюджета на разработку.
Читайте также: «Дискавери-фаза проекта: зачем она нужна?»
Существуют десятки методов расчета бюджета на разработку стартапа. Выбор конкретного метода зависит от многих факторов, включая тип продукта, его цели, масштаб и сложность реализации. Перечислим пятерку наиболее распространенных:
Этот метод схож с оценкой бюджета на строительство архитектурного объекта. Бюджет составляется на основе оценки стоимости каждого этапа разработки, включая затраты на персонал, оборудование, программное обеспечение, маркетинг и другие расходы.
Сначала определяются все конкретные задачи и ресурсы, необходимые для их выполнения, а затем суммируются все предполагаемые затраты.
Этот метод предполагает анализ бюджетов других успешных стартапов в аналогичной области. На наш взгляд, он самый ненадежный, поскольку из расчета выпадают множество факторов: уникальность продукта, конъюнктура рынка на момент запуска, доступность ПО и т. д.
В этом методе бюджет на разработку стартапа составляется на основе опыта и экспертного мнения специалистов в области разработки и запуска стартапов. К нему чаще всего приходят стартаперы, которые хотят привлечь внешний капитал для реализации продукта. Эксперты сопоставляют десятки разных методик, которые позволяют составить привлекательную оценку для инвесторов.
Данный метод предполагает минимизацию затрат на начальном этапе разработки стартапа с последующим увеличением бюджета по мере роста и развития бизнеса. Он помогает минимизировать риски и избежать затрат на разработку продукта, который окажется невостребованным на рынке. Поэтому метод оценки Lean Startup часто применяют для запуска MVP, сопоставляя функционал продукта с имеющимся бюджетом.
Необходимо учитывать, что бюджет на разработку стартапа подвержен изменениям. В процессе разработки важно регулярно отслеживать и корректировать затраты в соответствии с изменяющимися условиями и требованиями.
Читайте также: «Что такое MVP в IT?»
На разработку минимальной жизнеспособной версии стоит закладывать не менее полугода. Более реалистичный прогноз — от года. При этом первоначальную версию бюджета стоит пересматривать как минимум раз в месяц. Потому что по мере проектирования и разработки будут уточняться критерии, требования и границы продукта. Важно отдавать себе отчет, что бюджет на разработку стартапа не может быть жестким. Но и сопоставлять новые вводные с финансовыми возможностями тоже нужно.
Приведем упрощенный пример бюджета на разработку стартапа, составленный по методу сметного расчета на 12 месяцев. В расчете мы исходим из того, что владелец продукта решил идти по пути инхаус-разработки на базе своего проектного офиса.
Внимание! Данные в таблице не являются полными и точными. Количество часов и ставки указаны условно.
В сравнении с заказной разработкой, запуск стартапа силами инхаус-команды обойдется дороже примерно на 30 %, если не вдвое. В эту игру стоит вступать со стартовой ставкой около 60 миллионов рублей. Если же вы делаете выбор в пользу аутсорс-команды, убедитесь в компетенция и надежности компании.
Читайте также: «Разработка продукта: инхаус vs. аутсорс».
Бюджет на разработку стартапа может быть только предварительной оценкой. Фактические затраты в 99 % случаев оказываются иными. Это зависит от различных факторов, таких как изменения в требованиях, сложности технической реализации и другие обстоятельства. Большинство из них невозможно предугадать на старте. Но можно снизить уровень неопределенности и расходов, отказавшись от идеи самостоятельного найма и управления проектом. В любом случае важно быть готовым к маневрам и гибко управлять финансовыми ресурсами проекта.
Читайте также: «PnL-модель: почему она важна для любого бизнес-плана и стартапа».