Короткий ответ: завышенную стоимость нельзя определить по одной сумме. Проверять нужно состав работ, допущения, количество сценариев, интеграции, этапы, риски и то, что останется у заказчика после запуска. Дорогое предложение может быть обоснованным, а дешёвое — неполным.
Самая частая ошибка — сравнить три итоговые цифры, не выровняв входные данные. Один подрядчик включил аналитику, QA, миграцию и поддержку, второй посчитал только разработку экранов, а третий заложил сложный обмен с внешней системой. В итоге заказчик принимает не самое выгодное предложение, а самое неполное.
1. Сначала выровняйте объём
До проверки цены соберите единый лист сравнения. В нём должны быть одинаково описаны пользователи, роли, ключевые сценарии, интеграции, объём данных, платформы и критерии запуска. Если этого нет, любые выводы о завышении будут предположением.
| Параметр | Что спросить | Почему влияет на цену |
|---|---|---|
| Сценарии | Сколько сквозных маршрутов входит? | Каждый маршрут имеет состояния, ошибки и тесты |
| Роли | Какие права и согласования нужны? | Роли влияют на интерфейс, API и приёмку |
| Интеграции | Какие системы и события обязательны? | Документация, лимиты и ошибки требуют работы |
| Данные | Нужна ли миграция и очистка? | Перенос редко равен простой загрузке файла |
| Запуск | Что включено в релиз и поддержку? | Без этого стоимость владения скрыта |
Практический шаг: попросите каждого подрядчика заполнить одну и ту же таблицу. Если исполнитель отказывается раскрывать состав, это не доказывает завышение, но делает предложение плохо сравнимым.
CTA: Paladin Engineering может провести короткий разбор входных данных и помочь отделить обязательный контур от функций, которые безопаснее перенести на следующий этап — через разработку веб-систем.
2. Ищите не высокую сумму, а необъяснимые блоки
В смете нормально видеть аналитику, UX/UI, backend, frontend, интеграции, тестирование, DevOps, запуск и поддержку. Вопрос возникает, когда крупный блок не связан с результатом или повторяет работу из другого раздела. Просите показать, какой артефакт или работа стоит за каждой значимой строкой.
| Признак | Что уточнить | Нейтральное объяснение |
|---|---|---|
| Крупный блок «разработка» | Какие функции и роли внутри? | Сумма может включать много сценариев |
| Отдельный «резерв» | Какие риски он покрывает? | Резерв полезен, если причины описаны |
| Повторная аналитика | Где заканчивается discovery и начинается разработка? | Этапы могут пересекаться по формулировкам |
| Неясная поддержка | Какие часы, реакции и задачи входят? | Поддержка должна иметь границы |
| Разные единицы расчёта | Часы, дни или фиксированная сумма? | Нужно привести предложения к одной модели |
Не требуйте искусственной детализации до каждой минуты. Слишком мелкая смета тоже может создавать ложную точность. Нужен разумный уровень: блок, результат, допущение, зависимость и правило изменения объёма.
3. Проверьте допущения и исключения
Именно в допущениях часто скрывается разница между предложениями. В одном расчёте дизайн уже готов, в другом его нужно делать. В одном заказчик предоставляет чистые данные и доступ к API, в другом подрядчик должен исследовать старую систему. Оба расчёта могут быть честными, но сравнивать их напрямую нельзя.
- какие материалы и доступы предоставляет заказчик;
- какое число ролей, экранов, интеграций и типов данных заложено;
- включены ли состояния ошибок, уведомления и мобильная адаптация;
- есть ли миграция, импорт, настройка окружений и публикация;
- что происходит, если внешний API ограничен или меняет формат;
- какие работы перенесены в отдельный этап или исключены;
Попросите ответить на вопрос: «Что должно быть правдой, чтобы эта оценка сохранилась?» Ответ покажет зависимость суммы от решений, которые ещё не приняты. Это полезнее, чем спорить, почему один час стоит дороже другого.
4. Сравните стоимость ошибки, а не только стартовую цену
Низкая оценка может быть разумной, если проект небольшой и ограничения понятны. Риск начинается, когда в ней отсутствуют критические части: права доступа, обработка ошибок, тестирование, резервное копирование, мониторинг или передача кода. Тогда экономия переносится в будущую переделку и зависимость от подрядчика.
| Область | Вопрос для проверки | Что должно быть видно |
|---|---|---|
| Безопасность | Как проверяются права и чувствительные данные? | Сценарии, ограничения, тесты и журналирование |
| Качество | Что проверяет QA и кто принимает? | Критерии, окружение, список дефектов |
| Эксплуатация | Как узнаём о сбое после запуска? | Логи, мониторинг, ответственный и процедура |
| Владение | Что передаётся заказчику? | Код, репозитории, доступы, документация |
| Изменения | Как меняется срок и бюджет? | Формальный процесс согласования |
NIST SSDF рекомендует встраивать безопасные практики в жизненный цикл разработки, а OWASP ASVS предлагает проверяемую основу для требований безопасности. Для заказчика из этого следует практический вывод: безопасность и эксплуатация должны появляться в разговоре о составе работ, а не только в финальном обещании.
5. Простой способ проверить предложение
Сведите предложения к четырём слоям: обязательный MVP, необходимые риски, опциональные функции и стоимость владения после запуска. Затем задайте одинаковые вопросы каждому исполнителю и запишите ответы рядом с цифрами.
- отметьте, какие работы обязательны для первого сценария;
- выделите функции, которые можно отложить без потери проверки гипотезы;
- проверьте, кто отвечает за данные, интеграции и доступы;
- сравните количество этапов и промежуточных результатов;
- оцените не только бюджет запуска, но и поддержку, инфраструктуру и изменения;
- попросите объяснить три самых дорогих блока простым языком;
После такой сверки обычно видно одно из трёх. Предложения примерно одинаковы — значит, разницу нужно обсуждать через команду, сроки и риски. Одно заметно дороже, но включает больше результата — сравнение было нечестным. Одно заметно дешевле, но содержит много исключений — низкая цена требует проверки, а не автоматического выбора.
Как Paladin Engineering может помочь
Paladin Engineering помогает разобрать коммерческие предложения и подготовить технически сопоставимый контур: сценарии, роли, интеграции, критерии приёмки и этапы. Мы не обещаем определить «правильную цену» без фактуры — сначала проверяем, одинаковый ли объём сравнивается и какие риски заложены в каждом варианте.
CTA: если у вас уже есть два-три предложения, подготовьте их без персональных данных и секретов, добавьте описание главного сценария — этого достаточно для первого предметного разбора. Напишите в Paladin Engineering, чтобы согласовать формат проверки.
FAQ: проверка стоимости разработки
Высокая цена всегда означает более качественный проект?
Нет. Цена может быть выше из-за состава работ, команды, сроков или рисков, но это нужно показать в предложении и подтвердить результатами этапов.
Нужно ли выбирать самый дешёвый вариант?
Только после проверки одинакового объёма, исключений, качества входных данных и стоимости поддержки. Неполный расчёт часто выглядит дешевле до старта.
Как попросить подрядчика раскрыть смету без конфликта?
Сформулируйте это как запрос на сопоставимость: попросите этапы, допущения, исключения и критерии результата. Это нормальная часть коммерческого сравнения.
Что делать, если точную стоимость пока нельзя назвать?
Попросить диапазон, факторы неопределённости и короткий этап проверки. Честная неопределённость полезнее точной цифры без основания.
Какие строки сметы чаще всего забывают?
Интеграции, миграцию данных, QA, окружения, публикацию, мониторинг, поддержку и передачу доступов. Но для конкретного проекта состав нужно проверять отдельно.
Можно ли сравнить фрилансера и студию одной таблицей?
Да, если сравнивать не статус исполнителя, а результат, роли в команде, ответственность, процесс, сроки, передачу и поддержку. Формат подрядчика сам по себе не доказывает ни дороговизну, ни экономию.
Комментарии