Как контролировать бюджет IT-проекта: отчётность, которая показывает правду

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

Пять причин перерасхода

1. 01Неоформленное расширение объёма. Просьбы «заодно добавьте» по отдельности стоят по 2–4 часа, а в сумме дают 15–20% бюджета, которых нет в смете.
2. 02Недооценённые интеграции. Чужая система ведёт себя не так, как в документации, и работа удваивается — эту оценку нельзя было дать заранее без аудита.
3. 03Решения, ожидающие заказчика. Простой команды оплачивается заказчиком, даже когда причина в том, что три недели не согласовывали дизайн.
4. 04Качество как невидимая статья. Тестирование урезали ради срока, ошибки нашлись в продакшене, исправление стоит в 5–10 раз дороже.
5. 05Отсутствие прогноза. Заказчик видит «потрачено 60%», но не видит, что при текущем темпе до конца нужно ещё 80%.

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

Отчётность, которая закрывает эти причины

Демонстрация в этом списке стоит особняком, потому что она единственная не подделывается. Задача может быть «закрыта» в трекере и не работать. Экран, на котором сценарий проходит от начала до конца, — это факт.

Как обращаться с расширением объёма

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

1. 01Любая просьба вне согласованного объёма получает оценку в часах — до начала работ.
2. 02Заказчик принимает решение: делаем сейчас за счёт бюджета, откладываем на следующий этап или отказываемся.
3. 03Решение фиксируется в журнале изменений с датой и автором.
4. 04Если бюджет исчерпан, а объём вырос, вопрос решается на уровне бюджета — не за счёт тестирования.

Фраза «мы это сделаем, не переживайте» в ответ на просьбу вне объёма — не любезность. Это перенос конфликта на конец проекта, где он обойдётся дороже обеим сторонам.

Что должно быть в договоре

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

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

Что зависит от заказчика

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