Сколько стоит разработка веб-приложения

Вилку «от и до» вам назовут в любой студии. Разбираем то, что полезнее — из каких строк складывается смета и какие из них двигают её в разы.

Коротко

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

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

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

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

Обычная ситуация. Компания рассылает одно и то же описание трём исполнителям и получает предложения, различающиеся втрое. Первая реакция — кто-то завышает. На практике причина почти всегда в другом.

Разное понимание объёма. Один исполнитель прочитал «личный кабинет» как просмотр документов, второй заложил заказы и обмен с учётной системой, третий добавил роли и историю изменений. Все трое ответили честно на разные вопросы.

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

Разный состав команды и её загрузка. Одна и та же работа у команды с готовыми наработками по похожим задачам и у команды, которая делает это впервые, занимает разное время.

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

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

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


Первая строка выглядит самой необязательной и определяет остальные шесть. Смета, в которой на разбор задачи выделен день, обычно означает, что оценивали по названию задачи.

СМЕТА БЕЗ ЧАСТИ СТРОК

Когда приложение собирает ассистент

Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.

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

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

• личные кабинеты, заявки, согласования, реестры и внутренние порталы
• правки в чате без нового релиза
• заявленный эффект — в 10–50 раз меньше трудозатрат на типовое решение

Заказчик считает экраны, исполнитель считает состояния — отсюда основное расхождение в ожиданиях по этой строке.

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

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

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

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

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

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

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

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

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

Единственная строка, стоимость которой определяет не ваша сторона. Отсюда правило — оценивать интеграции отдельно от остального и после того, как выяснено состояние систем на другой стороне.

От чего зависит цена связки.

• Есть ли описанный API. Если да, работа предсказуема. Если нет, начинается обмен файлами, разбор формата и сверка — и оценка меняется кратно.
• Кто владеет системой на другой стороне. Своя 1С с доступным подрядчиком — одна история. Сервис партнёра, у которого нет ответственного за обмен, — другая.
• Направление и частота. Односторонняя выгрузка раз в сутки заметно дешевле двустороннего обмена в реальном времени.
• Что делать при сбое. Очередь, повторные попытки, уведомление ответственного. Без этого связка формально есть, а на практике однажды тихо перестанет работать.

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

Строка, которую недооценивают чаще любой другой, потому что роли кажутся настройкой.

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

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

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

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


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

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


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

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

С ЧЕГО НАЧИНАЕТСЯ РАБОТА

Сначала разбор процесса и демо, потом разговор об объёме

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

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

• разбор процесса и демо — до начала проекта
• видно заранее, какие требования платформа закрывает, а какие нет

Одна и та же работа может быть посчитана тремя разными способами, и от способа зависит, кто несёт риск ошибки в оценке. Это не деталь договора, а то, что определяет ваше поведение в проекте.

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

Оплата по времени. Платите за фактически потраченные часы. Риск на вас, зато можно менять требования по ходу, не переоформляя договор. Работает, когда есть кто-то на вашей стороне, кто следит за приоритетами и объёмом. Без такого человека модель превращается в бесконечный проект.

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

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

Отдельно про запас в оценке. В нём нет ничего неправильного — это плата за перенос риска на исполнителя. Проблема возникает, когда запас есть, а описание объёма отсутствует. Тогда спор о том, входило ли требование в смету, неизбежен.

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

Что входит в эксплуатацию веб-приложения.

• Инфраструктура. Сервер или облако, база данных, хранилище файлов, резервные копии.
• Обновления. Библиотеки и платформы стареют, и часть обновлений обязательна по требованиям безопасности.
• Мониторинг. Кто-то должен узнать, что приложение недоступно, раньше пользователей.
• Поддержка пользователей. Забытые пароли, права, вопросы «а почему не видно».
• Изменения. Основная статья. Процессы меняются, и каждое изменение имеет цену.

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

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

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

Что стоит собрать заранее.

• Описание процесса так, как он идёт сейчас. Со всеми обходными путями и исключениями. Именно исключения определяют половину объёма, и именно их забывают.
• Список ролей и того, что каждая видит. Отдельно отметьте права, зависящие от данных — филиал, свои клиенты, порог суммы.
• Перечень систем для обмена. По каждой — кто ею владеет, есть ли API, есть ли живой контакт того, кто в ней разбирается.
• Число пользователей сейчас и через два года. От этого зависит и архитектура, и экономика лицензий.
• Что считается результатом. Одна метрика, по которой вы поймёте, что проект удался.
• Что уже есть. Таблицы, старое приложение, наработки. Данные из них придётся переносить.

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

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

Состав работ, который стоит за этими строками, разобран в статье про этапы разработки веб-приложения.

Смета на веб-приложение почти никогда не сравнима с другой сметой напрямую, потому что за одинаковыми названиями строк стоят разные объёмы. Шесть вопросов, которые делают предложения сравнимыми.

1. Сколько времени выделено на разбор задачи? Если меньше нескольких дней, оценивали по названию, и она изменится.
2. Что входит в интерфейс — экраны или состояния? Ответ показывает, считал ли исполнитель реальный объём.
3. Как оценены интеграции и что будет, если API не окажется? Единственная строка, способная удвоить проект.
4. Заложены ли роли, зависящие от данных? Уточните на своём примере с филиалами или порогами сумм.
5. Что происходит после запуска и сколько это стоит? Поддержка, обновления, стоимость типовой правки.
6. Что остаётся у нас, если мы прекратим работу? Код, данные, документация, доступы.

Ни один ответ сам по себе не дисквалифицирует исполнителя. Расхождение между ответами двух исполнителей на один и тот же вопрос — самый информативный результат такого опроса.

Пять ошибок, которые повторяются в большинстве проектов.

• Сравнивать итоги вместо состава. Две сметы с одинаковой суммой могут описывать разные проекты, и дешёвая часто означает меньший объём, а не лучшую цену.
• Не заложить приёмку и обучение. Работа заказчика в проекте есть всегда, и это рабочее время сотрудников, которое кто-то оплачивает.
• Оставить интеграции на потом. Самая непредсказуемая строка, отложенная на второй этап, превращается в отдельный проект с новым бюджетом.
• Считать только создание. Владение за три года пропускают почти всегда, а оно определяет реальную стоимость решения.
• Экономить на разборе задачи. Единственная строка, экономия на которой гарантированно возвращается переделками.

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

Готовый сервис выигрывает, когда процесс у вас типовой и вы готовы подстроить его под логику сервиса. Признак прост — вы описываете свой процесс словами вендора и не появляется оговорок вида «а у нас ещё».

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

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