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

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

Ниже порядок проверки, который мы советуем, когда к нам приходят со сметой другого подрядчика и просят второе мнение.

Сначала посмотрите, из каких частей она состоит

Сумму в конце сметы пропустите и откройте её структуру. Работы по заказной системе бывают пяти видов, и в смете должна быть каждая:

Вид работ	Обычная доля	Если её нет
Разбор процесса и проектирование	10–15%	Подрядчик считает по вашему описанию в трёх абзацах
Разработка	40–50%	Такого не бывает
Интеграции с учётной системой и сервисами	15–25%	Обмен с 1С появится в допсоглашении
Перенос данных	5–15%	Справочники и историю будете переносить сами
Запуск и стабилизация	10–15%	Ошибки первых недель станут отдельным счётом

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

Отдельно ищите тестирование и управление проектом. Иногда они разнесены по строкам разработки, иногда стоят отдельно. Если их нет нигде, спросите, кто проверяет результат до того, как его увидите вы.

Проверьте, насколько мелко разбита разработка

Строка «Личный кабинет клиента, 320 часов» ничего не говорит ни вам, ни, скорее всего, самому подрядчику. Это число получено прикидкой целиком, и ошибиться в нём можно вдвое в любую сторону.

Рабочий ориентир: строка разработки не крупнее 16–40 часов, и её можно прочитать без программиста. «Клиент видит список своих заказов с фильтром по статусу и дате, 12 часов» проверяется: вы понимаете, о чём речь, и можете сказать, нужно ли это. «Модуль заказов, 200 часов» не проверяется никак.

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

Найдите всё, что записано «по согласованию»

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

• интеграцию с 1С или другой учётной системой;
• перенос данных из старой системы и таблиц;
• доработки после первых недель работы;
• хостинг, лицензии и платные сервисы (SMS, почта, карты, распознавание документов).

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

Сверьте, чьё время нужно с вашей стороны

Ни одна система не делается без человека заказчика, который объясняет, как процесс работает на самом деле, и проверяет готовые части на своих данных. По нашим проектам это 20–30% рабочего времени одного сотрудника на весь срок разработки.

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

Фиксированная цена или оплата по часам

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

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

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

Не забудьте про год после запуска

Смета обычно заканчивается датой запуска, а расходы нет. Поддержка и развитие работающей системы стоят в год порядка 15–20% стоимости разработки: хостинг, обновления, исправления, небольшие доработки. Для системы за 4 млн ₽ это 600–800 тыс. ₽ в год.

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

Вопросы подрядчику до подписания

Ответы на них по смете не видны, поэтому их задают устно и записывают в протокол встречи:

1. Сколько ролей пользователей заложено и какие именно.
2. Какие интеграции входят в цену и что вы видели, чтобы их оценить.
3. Смотрели ли вы на наши данные, прежде чем считать перенос.
4. Сколько времени нужно от нашего сотрудника и на каких этапах.
5. Что будет, если объём вырастет: как это оценивается и кто решает.
6. Что входит в гарантию и сколько стоит поддержка после неё.
7. Передаёте ли вы исходный код и доступы и в какой момент.

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

Частые вопросы

Почему сметы на одну задачу отличаются в три раза? Обычно потому, что в них посчитаны разные работы. В одной нет переноса данных и интеграций, в другой есть. Разница в ставке часа объясняет обычно не больше полутора раз. Остальное в составе работ.

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

Можно ли проверить смету, если в команде нет программиста? Можно проверить всё, что описано выше: состав работ, размер строк, скрытые позиции, ваше время, поддержку. Для оценки самих часов нужен человек, который делал похожие системы. Это может быть второй подрядчик.

Сколько стоит такая система в целом? Ориентиры по типам проектов собраны в отдельных статьях: B2B-платформа, SaaS, интеграция с 1С.

Правило

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