Бюджет проекта в IT — это не “смета на разработку”, а договорённость о том, сколько денег и времени вы готовы сжечь ради результата, с прозрачными правилами контроля изменений: что делаем, когда, за сколько и что считаем отклонением.

Главная боль новичка-руководителя (и вечная боль тимлида, которого “поставили порулить”) в том, что деньги утекают не из-за злых разработчиков, а из-за тумана: расплывчатый scope (объём работ), отсутствие базовой финансовой модели и вера в магическое “успеем к пятнице”. В итоге бюджет проекта превращается в философскую категорию.

Я видел проекты, где “управление бюджетом” сводилось к фразе: «Ребята, только без перерасхода». Это примерно как попросить сервер не падать, потому что вам неудобно. Работает плохо. Зато работает системный подход: бюджетировать IT-проект как продукт — через декомпозицию, риски, контроль изменений и регулярные срезы по факту.

Что именно вы бюджетируете: деньги, время или неопределённость

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

Обоснование: даже в типовом проекте (сайт, CRM, интеграция с 1С, мобильное приложение) реальная стоимость определяется не “ценой часа”, а количеством итераций, качеством требований и скоростью принятия решений. Чем чаще меняете вводные — тем больше платите за переделки.

Практический вывод: сначала выберите модель управления (фикс/тайм-энд-материалс/гибрид), потом считайте бюджет. Иначе вы пытаетесь измерять температуру линейкой.

Подводный камень: считать бюджетом только разработку. Тестирование, аналитика, дизайн, DevOps, лицензии, поддержка, обучение пользователей — это не “потом”, это и есть финансовая реальность.

Мини-словарь, чтобы не утонуть в терминах

• Scope — объём работ (что входит/не входит).
• MVP (Minimum Viable Product) — минимальная версия, которая уже даёт ценность, а не “черновик”.
• Burn rate — скорость “сжигания” бюджета (например, ₽/неделю).
• Baseline — базовый план (стоимость/сроки), от которого считаем отклонения.
• Change request — формализованное изменение (что меняем, на сколько денег/дней).

Как бюджетировать IT-проект: схема, которая переживает реальность

1) Декомпозиция: из “хотим приложение” в список работ

Тезис: пока проект не разложен на понятные куски, бюджета нет — есть фантазия.

Обоснование: оценка “целиком” почти всегда оптимистична. Работает разбиение на эпики/фичи/задачи (например, в Jira/YouTrack), плюс явные нефункциональные требования: безопасность, нагрузка, отказоустойчивость.

Практический вывод: фиксируйте WBS (Work Breakdown Structure — структура работ) хотя бы на уровне фич и интеграций. Для России типовой список быстро разрастается: авторизация через Госуслуги? Эквайринг? Интеграция с 1С? Уведомления через SMS-шлюз?

Подводный камень: “потом допишем”. Потом — это самый дорогой временной период проекта.

2) Оценка: делаем вилку и сразу обсуждаем риск

Тезис: одна цифра — обман, даже если вы честный человек. Вилка — инструмент управления.

Обоснование: оценка в часах/спринтах работает только вместе с допущениями: кто в команде, какая готовность требований, какие зависимости от внешних подрядчиков (1С-ники, интеграторы, инфобез).

Практический вывод: просите команду давать оценку “оптимист/реалист/пессимист” и отдельно список рисков. Это и есть нормальное управление бюджетом.

Подводный камень: “Сделайте оценку, но риски не пишите, у нас и так нервно”. В итоге риски всё равно придут, только без подписи.

3) Резерв: не “запас на распил”, а плата за неполные требования

Тезис: резерв — это не роскошь, а страховка от типовых сюрпризов.

Обоснование: в проектах с высокой неопределённостью резерв 10–30% — нормальная практика. Чем хуже входные данные, тем выше резерв.

Практический вывод: выделяйте отдельной строкой: контингент (на неизвестное) и менеджмент-резерв (на изменения, которые бизнес всё равно захочет).

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

Бюджет проекта и сроки: одна таблица, которая спасает нервы

Вам нужен не “финансовый план на 40 страниц”, а управляемая сводка: люди, этапы, артефакты, контрольные точки.

Два кейса из жизни (и один из них больно узнаваемый)

Кейс №1: “Сделаем личный кабинет за 2 месяца” (спойлер: сделали за 5)

Заказчик хотел личный кабинет для клиентов с оплатой и уведомлениями. Оценили “по верхам”, бюджет проекта утвердили, сроки поставили “как у конкурента на лендинге”. На 3-й неделе выяснилось: нужна интеграция с 1С, разные роли пользователей, логирование действий (требования ИБ), и ещё “чтобы работало в старых браузерах у бухгалтерии”.

Что спасло: ввели change requests с оценкой влияния (дни/рубли), сделали MVP (оплата + статусы) и отдельно “расширение”. Бюджет вырос примерно на 25%, но перестал быть черным ящиком. Срок сдвинули официально, без цирка с ночными релизами.

Ошибка: пытались “всё включить” в первоначальную сумму, вместо честного управления изменениями.

Кейс №2: “Фикс-прайс без фикс-скоупа” — классика жанра

Подрядчик взял проект фиксированной стоимостью, но требования были в стиле “как у Тинькофф, только проще”. Управление бюджетом отсутствовало: каждое уточнение превращалось в конфликт. Итог — срыв сроков, выгорание команды, юридические письма и продукт, который стыдно показывать.

Что должно было быть: либо фикс-скоуп (чёткий перечень функций и критериев приёмки), либо time & materials с лимитом, либо гибрид: фикс на этап discovery (предпроектное обследование) и дальше итерации.

Как руководителю контролировать расходы: короткий рабочий регламент

1. Раз в неделю — план/факт по бюджету и срокам: сколько потратили, что сделали, что мешает.
2. Единый backlog — все хотелки только туда. Никаких “в чате накину идею”.
3. Change requests — любое изменение = оценка влияния на бюджет проекта и сроки.
4. Демки (показ результата) — каждые 1–2 недели. Без демо вы финансируете надежду.
5. Критерии приёмки — “готово” означает измеримо готово (работает сценарий, пройдены тесты, обновлена документация).

Коммерческие факторы: где в IT прячется “скрытая цена”

Если вы считаете, что бюджетировать IT-проект — это просто “умножить часы на ставку”, то у вас скоро будет платная подписка на разочарование.

• Предпроект (discovery): интервью, прототипы, бизнес-анализ. Часто оплачивается отдельно, но экономит месяцы переделок.
• Инфраструктура: облако, резервные копии, домены, сертификаты, мониторинг.
• Лицензии: трекеры, тест-менеджмент, BI, СУБД — даже если часть замените опенсорсом, администрирование останется.
• Инфобез и соответствие: аудит, модели угроз, журналы, права доступа.
• Поддержка: исправления, обновления, реакции на инциденты. Это отдельный бюджет, не “потом как-нибудь”.

Кстати, похожие разборы про работу в IT и управленческие навыки появляются на https://itokno.ru — полезно держать в закладках, если вы строите карьеру не по обещаниям, а по цифрам.

Экспертный вердикт и инструмент: чек-лист контроля бюджета и сроков

• Что именно считаем результатом? Перечень функций + нефункциональные требования + критерии приёмки.
• Какая модель оплаты? Fixed price только при фикс-скоупе; иначе — T&M с лимитами и демо.
• Есть ли baseline? Утверждённый план по срокам/деньгам, от которого считаем отклонения.
• Как принимаются изменения? Change request с влиянием на бюджет проекта, сроки и риски.
• Где резерв? Отдельной строкой, с правилами использования.
• Как часто вы видите продукт? Демка раз в 1–2 недели, иначе контроль — иллюзия.
• Кто отвечает за решения? Если бизнес “думает неделю” — сроки платит проект.

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