Сколько стоит софт построить: из чего состоит бюджет разработки приложения

в 8:42, , рубрики: skillbox, Блог компании Skillbox, обучение, разработка мобильных приложений, разработка приложений, управление проектами, финансы в IT

Сколько стоит софт построить: из чего состоит бюджет разработки приложения - 1

Мы публикуем перевод материала Александра Савченко, сотрудника компании Django Stars. Он рассказывает, как оценивать стоимость создания мобильных приложений, учитывая как прямые, так и косвенные статьи расходов.

Определение стоимости разработки конкретного приложения — важная задача как для компании, так и для программиста, который работает самостоятельно. Сразу стоит сказать, что 100%-ной точности достичь вряд ли получится, но этот обзор поможет приблизиться к максимальной корректности оценки.

Skillbox рекомендует: Практический курс «Мобильный разработчик PRO».
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

Вы оцениваете не строки кода, а продукт в целом

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

Кроме прямых затрат (время, которое расходуется исключительно на работу над приложением), есть и косвенные, которые далеко не всегда учитываются:

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

Также вам необходимо принять во внимание такие важные вещи, как:

  • Коммуникации. Для сверки расходных статей нужно всегда держать руку на пульсе рабочего процесса. А это значит постоянное общение с другими членами своей команды. Они, кроме всего прочего, должны хорошо понимать, над чем работают, и знать нюансы позиционирования проекта.
  • Планирование и брейнсторминг. Свежие идеи — всегда хорошо, но, к сожалению, никто не может гарантировать, что очередная сессия мозгового штурма даст ответы на все вопросы и поможет работать дальше.
  • Дополнительные задачи. В ходе разработки вы можете получить новые идеи и предложения. Некоторые из них потребуют использования дополнительных временных и трудовых ресурсов.

Учитываем неявные факторы

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

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

Факторы можно разделить на три категории:

  1. Все, что точно известно на данный момент — например, необходимость регистрации домена, аренды хостинга с определенными характеристиками и т.п.
  2. Факторы, которые пока еще неизвестны, но их появление можно предсказать, — например, перенос дедлайна или технические работы на сервере.
  3. Факторы, которые неизвестны и которые сложно предсказать.

Пошаговая оценка стоимости разработки

Пользовательские истории и задачи разработчиков

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

Уточняем масштаб работ

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

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

Оценка времени реализации каждой задачи

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

Выглядеть это может так: для разработки системы управления трафиком в оптимальной ситуации нужно 10 дней; реально — где-то дней 20; если возникают проблемы, то месяц. Еще нужно учитывать и коэффициент коррекции, который составляет около 95%.

Сколько стоит софт построить: из чего состоит бюджет разработки приложения - 2
Оценка сроков

Сколько стоит софт построить: из чего состоит бюджет разработки приложения - 3
Калькуляция времени выполнения таска с учетом 95%-ного коэффициента коррекции

На иллюстрациях приведен пример расчета времени выполнения отдельных тасков. Для «Traffic Management» это 33 дня, причем возможны и отклонения от расчетных сроков.

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

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

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

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

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

Сам просчет позволяет команде понять масштабы работы и минимизировать риски. Главное правило — не спешить, а также быть осторожными со своими желаниями.

Skillbox рекомендует:

Автор: fokus-lop

Источник

* - обязательные к заполнению поля