Почему смета вырастает в середине проекта и как этого избежать

Проект начинался на 600 тысяч, а закончился на миллион. Обычно в этом винят подрядчика, но настоящих причин шесть, и ответственность распределяется по-разному.

1. Расползание объёма

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

Что делать. Завести список пожеланий и правило: всё, чего нет в ТЗ, идёт в этот список, а не в работу. Раз в две недели список разбирается: что берём сейчас с пересчётом, что откладываем на следующий этап. Просьбы никуда не деваются — они перестают протекать в бюджет незаметно.

2. Дизайн, утверждённый не тем, кто решает

Макеты согласовал маркетолог, а на середине разработки их увидел собственник, и ему не понравилось. Переделка макетов — это ещё и переделка уже свёрстанного.

Что делать. Определить, чья подпись под макетом окончательна, и получить именно её до начала вёрстки. Если решение принимает несколько человек — собрать их одновременно, а не по очереди.

3. Недооценённые интеграции

«Интеграция с 1С» в смете стоит 80 тысяч. Выясняется, что у клиента доработанная конфигурация, обмена по расписанию нет, а выгрузка идёт файлом непонятного формата. Работа вырастает втрое, и оценивавший её человек не соврал — он просто не мог знать.

Что делать. Любую интеграцию оценивать после того, как подрядчик получил доступ к системе и посмотрел, что там. До этого — говорить о вилке, а не о цене.

4. Контент, которого нет

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

Что делать. Договориться о контенте на старте — кто пишет, к какому сроку, в каком объёме. Если внутри некому, включить в смету сразу: это дешевле, чем срочно докупать в конце.

5. Данные из старой системы

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

Что делать. До оценки выгрузить данные и посмотреть на них. Полчаса просмотра экономят недели споров.

6. Оценка, сделанная в вакууме

Единственная причина, которая целиком на стороне подрядчика: задачу оценивали, не заглянув в существующий код. В унаследованном проекте трёхдневная задача легко становится двухнедельной — не из-за сложности, а из-за того, что рядом всё держится на честном слове.

Что делать. Требовать, чтобы доработку существующей системы оценивали после аудита кода, а не по описанию. Аудит на 20–40 тысяч, показавший реальное состояние, окупается на первой же задаче.

Резерв — это норма

Разработка не производство: одинаковых проектов не бывает, и всё предсказать нельзя. Здоровая практика — закладывать резерв 15–20% от бюджета и относиться к нему как к части плана, а не как к провалу.

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