Как правильно оценить разработку сайта и приложения
Точная цена по короткому описанию создаёт ложную уверенность. Пока не определены роли, интеграции, данные и требования к качеству, команда оценивает собственные предположения. Правильная оценка разработки сайта или приложения показывает диапазон, состав работ и условия, при которых он изменится.
Сначала сравняйте объём
Два предложения могут называться одинаково — «интернет-магазин» или «мобильное приложение» — и включать разный продукт. В одном варианте есть типовая авторизация и каталог, в другом — несколько ролей, персональные цены, остатки из ERP, возвраты, программа лояльности и работа без сети.
Зафиксируйте первую версию через пользовательские сценарии. Не «личный кабинет», а «покупатель видит заказы, повторяет покупку и скачивает документ». Для каждого сценария укажите платформу, роль, данные, интеграции и критерий готовности. Такой список становится общей базой для оценки.
Пять драйверов, которые меняют смету
Первый драйвер — продуктовые сценарии и число состояний. Оплата включает успех, отказ, повтор, возврат и уведомления. Второй — роли и права: чем сложнее матрица доступов, тем больше логики и проверок. Третий — интеграции и качество внешних API. Четвёртый — миграция данных и контента. Пятый — нефункциональные требования: нагрузка, безопасность, доступность, работа без сети и поддерживаемые устройства.
Количество экранов полезно для грубой оценки интерфейса, но плохо описывает бизнес-логику. Один экран расчёта тарифа может потребовать больше времени, чем десять информационных страниц.
Разложите стоимость по этапам и ролям
Полный цикл обычно включает исследование, проектирование, дизайн, разработку клиентской и серверной частей, интеграции, тестирование, инфраструктуру, запуск и управление. Если строка отсутствует, это не всегда экономия: работу может выполнять заказчик или она появится дополнительным счётом.
Попросите подрядчика показать трудозатраты по этапам и состав команды. Тогда видно, есть ли аналитик, кто проектирует архитектуру, сколько заложено на контроль качества и поддержку релиза. Ставки сравнивают только после выравнивания объёма и ролей.
Оценка диапазоном: где находится неопределённость
На раннем этапе разумнее использовать вилку. Нижняя граница предполагает, что исходные данные подтверждаются и интеграции работают ожидаемо. Верхняя учитывает известные риски. Рядом должен быть список допущений: кто предоставляет контент, готов ли API, сколько платформ поддерживается, нужна ли миграция и кто принимает решения.
Неопределённость можно разделить на продуктовую, техническую и организационную. Продуктовая связана с приоритетами пользователей. Техническая — с легаси, нагрузкой и внешними системами. Организационная — со скоростью согласований, доступами и участием экспертов заказчика.
Когда нужна отдельная аналитика
Если неизвестные влияют на архитектуру или могут изменить объём в несколько раз, полезен ограниченный этап исследования. Команда проверяет API, разбирает данные, прототипирует спорные маршруты и собирает бэклог. На выходе заказчик получает основание для более узкого диапазона, а не обещание начать разработку как можно скорее.
Исследование особенно важно для модернизации действующей системы, миграции, нескольких интеграций, высокой нагрузки и сложной матрицы ролей.
Три метода и их границы
Аналоговая оценка сравнивает проект с похожими работами и подходит для раннего ориентира. Экспертная декомпозиция оценивает отдельные сценарии и задачи; она точнее при понятном бэклоге. Итерационное планирование использует реальную скорость команды после первых циклов и уточняет прогноз по мере разработки.
Scrum Guide закрепляет ответственность разработчиков за размер элементов бэклога и допускает уточнение объёма по мере обучения. Это важный принцип: оценивать должны специалисты, которые будут выполнять работу, а прогноз нужно регулярно пересматривать.
Как сравнить два коммерческих предложения
Соберите таблицу с одинаковыми строками: сценарии первой версии, исключения, этапы, роли, интеграции, платформы, требования к качеству, срок, гарантия и поддержка. Отдельно выпишите допущения и риски. Разница в цене станет объяснимой: одна команда включила нагрузочное тестирование и миграцию, другая оставила их за рамками.
Проверьте порядок работы с изменениями. Кто оценивает новую функцию, как она влияет на срок, что можно заменить в текущем объёме и где хранится решение? Без этого фиксированная смета быстро превращается в спор о том, что подразумевалось в начале.
Красные сигналы в оценке
Опасны точная сумма без состава работ, один итоговый срок без контрольных точек, отсутствие тестирования и запуска, неизвестный состав команды, неопределённые интеграции и обещание включить все будущие пожелания. Ещё один сигнал — скидка без изменения объёма: она может скрывать меньшее количество проверок, слабую аналитику или перенос важных работ за границы договора.
Шаблон запроса на оценку
Передайте цель продукта, аудиторию, три–пять критических сценариев, список ролей, платформы, интеграции, источники данных, ограничения по сроку и качеству. Попросите вернуть диапазон, декомпозицию, допущения, риски и следующий шаг для уточнения.
В Qtim предварительную оценку связывают с объёмом первой версии и техническими неизвестными. Можем обсудить мобильное приложение и сделать разбор проекта.
