image

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

— Это слишком дорого, что если сделаем без функции Х?
*делаем расчет* Столько.
— Все равно дорого, а сколько будет стоить разработка только под платформу Y?
*делаем перерасчет* Столько.
— Ух ты, то есть, если мы откажемся от платформы Y, то сможем сделать не только Х, но и Z?
*очередной перерасчет* Увы, нет.
— Жаль, тогда давайте сделаем без Z, во сколько нам обойдется?

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

Но, как и любой другой процесс, характеризующийся словами “рутина”, “точность” и “вычисления”, подобные расчеты скорее всего могут быть автоматизированы. Давайте проверим, действительно ли это так.

Процесс расчетов


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

Шаг 1: Оценка задач


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

  • Каталог товаров
  • Корзина и оплата заказов
  • Новости магазина
  • Контакты

После этого командой разработчиков осуществляется определение временных трудозатрат на реализацию всех перечисленных задач:
Задача
UI/UX
Back-end
Android
iOS
Каталог товаров
4 дня
2 дня
3 дня
4 дня
Корзина и оплата заказов
3 дня
5 дней
4 дня
5 дней
Новости магазина
2 дня
2 дня
1 день
2 дня
Контакты
1 день
2 дня
2 дня
3 дня

Шаг 2: Расчет сроков разработки проекта


Как бы ни старалась разработчики, но их оценка сроков крайне редко соответствует действительности. Так что, первым делом, отталкиваясь от сложности проекта и опыта команды, мы определяем страховку: количество дополнительного времени, необходимого для разрешения различных непредвиденных обстоятельств. Обычно страховка выглядит как некоторый множитель (процент), на который увеличивается общий срок разработки.

Далее нам следует определить очередность этапов выполнения работ (workflow). Вне зависимости от используемой методологии (agile или waterfall) нам нужно знать в каком порядке нашей командой выполняются различные виды работ. В рассматриваемом нами примере с мобильным приложением порядок мог бы выглядеть следующим образом:

image

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

Теперь мы располагаем всей необходимой информацией и можем приступить к расчету сроков:

В случае с Waterfall: суммируем количество времени для каждого вида работ (UI/UX, Back-end, etc.), добавляем к ним страховку, и, учитывая их очередность, находим самую длительную последовательность работ, которая, собственно, и представляет общее количество времени, необходимое для реализации проекта.

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

Шаг 3: Расчет стоимости разработки проекта


Следующее, что нам следует получить — это себестоимость проекта, которая обычно формируется из двух типов затрат: общих ежемесячных расходов (аренда офиса, оплата серверов, лицензий на ПО, etc.) и зарплат непосредственных исполнителей проекта. Что касается зарплат менеджмента, то они больше подходят к первой категории, так как являются более “пассивной” статьей расходов, и в некоторых случаях они могут быть опциональными (к примеру, если речь идет о небольшой команде фрилансеров).

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

Расчет расходов на зарплаты исполнителей зависит от используемой методологии разработки:

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

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

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

1. Прибыль: здесь все довольно просто, мы либо прибавляем желаемый процент от себестоимости проекта, либо добавляем соответствующий пункт к “общим расходам” (если желаем получать фиксированный ежемесячный доход).

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

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

Итак, теперь мы располагаем итоговой стоимостью проекта. Но что делать, если клиент, услышав результат, спросит нас: “А что если сделаем без X?”.

Автоматизация вычислений


Можно ли разработать приложение, которое бы производило подобные расчеты автоматически? Ознакомившись с процессом вычислений, теперь мы можем сказать, что да, это возможно, но не без пары нюансов. И первый из них — это расчет налоговой части.

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

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

  1. Храним данные на сторонних серверах приложения (SaaS). Быстро и удобно, но требует доверия к владельцам сервиса.
  2. Разворачиваем приложение на собственных серверах. Этот вариант требует трудозатрат на настройку и сопровождение приложения, но позволяет самостоятельно контролировать безопасность данных. Дополнительно можно сделать приложение доступными только из собственной инфраструктуры, но это лишает определенных удобств, таких как возможность обратиться к расчетам с личного телефона за пределами офиса.
  3. Реализация программы для расчетов в виде самостоятельного десктоп-приложения, хранящего все данные в локальном файле. Этот случай не предполагает никакой настройки окружения и позволяет самостоятельно контролировать безопасность данных, жертвуя возможностью предоставления общего доступа к данным.

Тем не менее, несмотря на перечисленные проблемы, автоматизация процесса расчетов все равно возможна, и она несет за собой ряд преимуществ:

— Жизнь сотрудника, занимающимся расчетами, станет немного легче
— Клиенты смогут получать перерасчеты в считанные секунды
— Стоимость разработки станет чуть более справедливой и конкурентной

На сегодняшний день существует очень небольшое количество решений для подобного вида расчетов, и все они имеют достаточно высокий порог вхождения из-за своей монструозности. В связи с этим хотелось бы задать вопрос аудитории Хабра: а каким способом выполняются расчеты в вашей компании?

Комментарии (5)



  1. stanwin
    14.03.2018 17:23

    "То есть, сначала независимо друг от друга выполняется разработка бэк-энда и пользовательского интерфейса, и при их завершении начинается параллельное программирование приложения под разные платформы." А если до того как начинать реализацию правильно описать поведение бэкэнда (API) то работа над клиентскими приложениями может выполнятся параллельно с реализацией бэкэнда. Клиент ведь будет работать независимо от существования сервера. На моём месте работы мы поступаем именно так. Разве само наличие бэкэнда так важно для работы над клиентом?


    1. cobhc Автор
      14.03.2018 17:33

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

      А так да, можно вести разработку клиентского приложения используя mock-сервер.


  1. gavrilovm
    14.03.2018 19:54

    Разве никто не тестирует разрабатываемые сервисы?
    Тяп-ляп и в продакшен! С вас 1 млн. рублей! :D


    1. cobhc Автор
      14.03.2018 20:04

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