Оценка бюджета ИТ-проекта: методы и точность на разных стадиях
На пресейле дают оценку «5 миллионов», заказчик соглашается, а через три месяца выясняется, что реальная стоимость — 7,5. Переговоры, нервы, скандал. Кто виноват? Никто. На старте оценка не может быть точной, и это нормально. Проблема не в том, что оценка меняется, а в том, что мы не говорим об этом заказчику открыто и не объясняем правила игры. Оценка бюджета — это не про точность, а про управление ожиданиями.
Три уровня точности оценки
На инициации (пресейл) требований нет, архитектуры нет, есть только примерный опыт. Погрешность — –25% / +75%. Что говорить заказчику: «Это предварительная оценка, точность будет расти по мере уточнения требований».
На планировании (после ТЗ) требования описаны, WBS на верхнем уровне готова. Погрешность — –10% / +25%. Что говорить заказчику: «Базовый бюджет утверждён, отклонения возможны в пределах 25%».
На детальном планировании (полная WBS) проект разбит на рабочие пакеты. Погрешность — –5% / +10%. Что говорить заказчику: «Детальный бюджет, отклонения возможны только через процедуру изменений».
Главное правило: на каждом этапе говорите заказчику: «Это предварительная оценка, мы уточним, когда узнаем больше». Никогда не давайте одно число на старте, всегда — диапазон.
Методы оценки — когда какой брать
Аналоговая оценка — смотрим на прошлый проект и говорим «примерно столько же». Быстро, но низкая точность (±30–50%). Для пресейла.
Параметрическая — считаем по формуле, например, сайт — 10 страниц × 50 000 рублей за страницу. Точность выше (±15–25%), но нужны нормативы.
Bottom-up — суммируем оценки всех задач. Самая точная (±5–10%), но требует детальной WBS. Подробнее — в статье WBS для ИТ-проекта.
Трёхточечная (PERT) — оптимистичная + наиболее вероятная + пессимистичная. Учитывает неопределённость (±10–20%).
Стоимость story point — для Agile: сколько стоит один story point × их количество. Требует исторических данных.
Из чего состоит бюджет
Бюджет = прямые затраты + накладные расходы + резервы. Прямые затраты — зарплата команды, лицензии, серверы, подрядчики. Накладные — аренда, административные расходы, налоги. Резерв на известные риски (contingency) — 5–15% от бюджета, на случай, если риски из реестра наступятся. Управленческий резерв (management) — 5–10%, на случай, если случится что-то, что мы даже не предусмотрели.
Базовый план по стоимости = прямые затраты + накладные + contingency. Управленческий резерв — вне базового плана, расходуется только по решению руководства.
Как не провалить бюджет
На старте давайте диапазон, а не одно число: «Бюджет проекта составит 8–12 миллионов рублей». Фиксируйте допущения: «Оценка действительна при условии, что API останется стабильным». Уточняйте оценку по мере уточнения требований — после ТЗ уточняем, после детальной WBS — ещё раз уточняем. Закладывайте резервы и не тратьте их просто так — резерв не «свободные деньги», а страховка. И считайте прогноз по ходу проекта — если вы уже потратили 60% бюджета, а сделали 40% работ, проект, скорее всего, выйдет дороже.
Как считать прогноз по ходу проекта
Прогнозная стоимость = (фактические затраты / выполненный объём) × общий объём. Пример: бюджет проекта 10 000 000 руб., плановый объём работ 100%. На текущий момент потратили 4 000 000 руб., сделали 30% работ. Прогноз = (4 000 000 / 30%) × 100% = 13 333 333 руб. Проект идёт с перерасходом. Более точный метод — EVM, подробнее в статье EVM для ИТ-проекта.
Что в понедельник утром
Проверьте, есть ли у вашего проекта утверждённый бюджет. Если нет — начните с простой сметы: прямые затраты + накладные + резервы. Убедитесь, что вы заложили резервы (хотя бы 10–15%). Если бюджет утверждён — посчитайте прогноз: сколько уже потратили и сколько сделали.
Заключение
Оценка бюджета — это не про точность, а про управление ожиданиями. Давайте диапазон на старте, фиксируйте допущения, закладывайте резервы и уточняйте оценку по ходу.