Сколько стоит разработка приложения. Считаем в Excel

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

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

В качестве примера, для наглядности, взял последнее ТЗ, которое готовил для канала — MVP простенького мессенджера с групповыми переписками. Если кратко, то логика работы такая: пользователь авторизуется, заполняет свой профиль, может найти и общаться с другими пользователями, добавиться в групповой чат, либо создать собственный.

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

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

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

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

Вёрстка. Учтено время на само создание вёрстки экрана и исправление придирок техдира (чтоб у программиста не было проблем при внедрении) и ПМа (что-то съехало или не соответствует дизайну). Этап не учитывается, если приложение делается на типовом внешнем виде фреймворка.

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

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

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

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

Тестирование и отладка. Финальная проверка ПМом и багфикс допущенных ошибок.

Выходит 9 часов на экран при шаблонном дизайне и 16 часов, если нужно делать индивидуальный. Само собой, с моей оценкой можно не согласиться — начинающий программист потратит в три раза больше времени (в основном, на этапе багфикса), сеньору будет достаточно пары часов, вместо девяти на экран. Но так как задача шаблона дать прогноз по бюджету — ориентируемся на средние значения, как по таймингу, так и по стоимости часа.

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

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

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

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

В случае заказа у «золотой сотни» я бы добавил временной коэффициент +30% и скорректировал бы ставки часа под конкретную компанию (явно там программист будет стоить не 1200р/час).

Давайте теперь разберём как из сметы мессенджера сделать смету вашего произвольного приложения. Для этого нам понадобится нижний блок.

Здесь заносятся количество экранов приложения и стоимость часа каждого из специалистов. Я записал средние значения по рынку — дизайнер и верстальщик 1000р, программист 1200, техдир 3600 и ПМ 500р.

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

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

В случае примера с мессенджером это 324 300р и 422 300р соответственно.

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

ТЗ которые размещены на канале:

Пожелания по другим типовым идеям принимаются в группе поддержки.