Не всё то готово, что оплачено: почему 70% проекта съедают 85% бюджета

Проект готов на 70%, но деньги заканчиваются быстрее, чем работа. Когда пора бить тревогу и можно ли ещё спасти бюджет? На примере разработки сайта разберём, как рассчитать реальную стоимость завершения проекта, предсказать перерасход и выбрать решение, пока ситуация не стала критической.

Деньги ещё есть, но проект уже выходит за бюджет

Представим небольшую студию, которая разрабатывает корпоративный сайт. На проект выделено 300 000 ₽, работа идёт по графику, основные этапы уже завершены. Руководитель смотрит на отчёт: готовность составляет 70%, из бюджета потрачено 255 000 ₽.

Формально проект ещё не вышел за смету. На оставшиеся работы есть 45 000 ₽, а команда уверяет, что основная сложность уже позади. Кажется, достаточно немного сократить расходы на последних этапах, и всё получится.

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

Предположим, оставшиеся 30% проекта изначально оценивались в 90 000 ₽. Теперь на их выполнение осталось вдвое меньше денег. Даже если команда больше не допустит ни одного отклонения от первоначальных оценок, проект всё равно окажется дороже запланированного.

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

Чтобы не обнаружить перерасход в день финальной приёмки, нужно научиться оценивать стоимость ещё не выполненной работы.

Как организовать контроль расходов на бесплатной канбан-доске

Для начала важно связать финансовый план с конкретными результатами проекта. Если бюджет существует в одной таблице, задачи — в другой системе, а изменения обсуждаются в переписке, восстановить причины перерасхода становится сложно.

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

В описании карточек можно фиксировать согласованный объём и плановые затраты, а с помощью чек-листов проверять выполнение обязательных этапов. Вложения позволяют хранить технические задания и материалы для приёмки, метки — выделять задачи с риском превышения бюджета. Если появляются дополнительные требования, их можно оформлять отдельными карточками, не смешивая с первоначальной работой. Канбано работает за 0 ₽, без ограничений по количеству пользователей, досок и карточек. Можно создать бесплатную канбан-доску для управления проектом и подключить к ней сотрудников и подрядчиков.

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

Почему считать готовность по количеству задач опасно

Допустим, в проекте десять задач. Семь из них закрыты, значит, проект готов на 70%? Не обязательно.

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

Количество карточек не отражает стоимость работы. Поэтому для финансового контроля полезнее заранее разделить проект на результаты с определённым бюджетом.

Для нашего условного сайта первоначальная смета выглядит следующим образом:

Предположим, первые три этапа полностью завершены и приняты. Их стоимость по первоначальному плану составляет 210 000 ₽, или 70% общего бюджета. Это и есть основание говорить о 70% готовности в нашем примере. Не количество закрытых задач и не субъективная оценка руководителя, а бюджетная стоимость принятых результатов.

Однако фактические расходы оказались другими:

На выполненную работу потратили на 45 000 ₽ больше первоначальной оценки. Остальные этапы даже не завершены, а бюджет уже испытывает дефицит. Это гораздо более полезная информация, чем сообщение «проект готов на 70%».

Как рассчитать, насколько эффективно расходуется бюджет

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

В нашем примере достаточно трёх показателей:

• Общий бюджет проекта (BAC) — 300 000 ₽.
• Освоенный объём (EV) — 210 000 ₽, то есть плановая стоимость завершённых результатов.
• Фактические затраты (AC) — 255 000 ₽.

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

Теперь рассчитаем индекс эффективности затрат:

Индекс эффективности = Освоенный объём / Фактические затраты

Получаем:

210 000 / 255 000 ≈ 0,82.

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

Значение 0,82 означает, что на каждый потраченный рубль приходится примерно 82 копейки выполненного объёма в плановой оценке.

Важно правильно интерпретировать результат. Это не показатель профессионализма сотрудников и не оценка их личной продуктивности. Причины отклонения могут находиться в первоначальной смете, изменениях требований, повторной работе или неверно определённой сложности проекта. Но число позволяет перейти от обсуждения «кажется, мы тратим слишком много» к конкретной финансовой оценке.

Три сценария: сколько будет стоить завершение сайта

Зная фактические затраты и стоимость оставшихся работ, можно рассчитать несколько вариантов развития ситуации.

Сценарий 1. Больше никаких перерасходов

На интеграции и тестирование первоначально выделили 90 000 ₽. Предположим, команда выполнит оставшиеся задачи ровно за эту сумму.

255 000 + 90 000 = 345 000 ₽.

Итоговый перерасход составит 45 000 ₽, или 15% бюджета.

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

Сценарий 2. Расходы продолжают расти с прежней скоростью

Теперь предположим, что финансовая эффективность сохранится на уровне предыдущих этапов.

Для оценки используем рассчитанный индекс:

Прогноз стоимости = Общий бюджет / Индекс эффективности

300 000 / 0,8235 ≈ 364 286 ₽.

При таком развитии событий перерасход составит около 64 000 ₽, или 21,4%.

Это уже более серьёзная проблема. На оставшиеся работы потребуется примерно 109 000 ₽, а неизрасходованный бюджет составляет только 45 000 ₽.

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

Сценарий 3. Команда заново оценила оставшиеся работы

Третий вариант обычно требует больше усилий, зато позволяет учесть актуальную информацию.

Руководитель просит специалистов повторно оценить интеграции и тестирование. После уточнения требований выясняется, что интеграции потребуют 80 000 ₽ вместо 60 000 ₽, а тестирование — 45 000 ₽ вместо 30 000 ₽.

Оставшиеся работы теперь оцениваются в 125 000 ₽.

255 000 + 125 000 = 380 000 ₽.

Прогнозируемый перерасход достигает 80 000 ₽, или 26,7%.

Сведём результаты:

Теперь руководитель видит не одну условную цифру, а диапазон возможных расходов с понятными предположениями.

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

Если для завершения требуется 125 000 ₽, надежда потратить оставшиеся 45 000 ₽ уже не является финансовым планом.

Сколько нужно сэкономить, чтобы всё-таки уложиться в смету

Иногда после обнаружения перерасхода руководитель ставит задачу: завершить проект строго в пределах первоначальных 300 000 ₽.

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

По исходной смете осталось выполнить работу стоимостью 90 000 ₽. Денег осталось 45 000 ₽.

Следовательно, дальнейшие затраты должны быть вдвое эффективнее первоначального плана:

90 000 / 45 000 = 2.

Этот показатель называют требуемой эффективностью завершения проекта. В нашем случае он равен 2,0.

Фактический индекс предыдущих этапов составлял 0,82. То есть команда должна не просто устранить прежний перерасход, а перейти к уровню финансовой эффективности, который значительно выше первоначально запланированного.

Можно ли добиться такого результата? Теоретически да, но для этого нужны реальные изменения:

• сократить согласованный объём оставшихся работ;
• отказаться от необязательных функций;
• найти более дешёвый способ реализации без потери обязательного качества;
• устранить конкретную причину повторных расходов;
• пересмотреть условия привлечения внешних специалистов.

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

Где именно проект начал терять деньги

Финансовый индекс показывает масштаб отклонения, но не объясняет его причину. Для принятия решения нужно вернуться к смете и посмотреть, какие работы подорожали.

В нашем примере аналитика превысила бюджет на 5 000 ₽, дизайн — на 15 000 ₽, разработка — на 25 000 ₽.

Начать стоит с самого крупного отклонения — разработки. Но и здесь недостаточно просто спросить исполнителя, почему он потратил больше времени.

Полезнее разделить расходы по причинам.

• Ошибка первоначальной оценки. Например, интеграция с внешним сервисом оказалась сложнее, чем предполагалось. В этом случае нужно повторно проверить оценки похожих работ, которые ещё предстоит выполнить.
• Изменение требований. Заказчик попросил дополнительный функционал после утверждения технического задания. Нужно установить, были ли эти изменения согласованы и кто должен оплачивать дополнительный объём.
• Повторная работа. Команда переделывала готовый результат из-за неполных исходных данных, поздних замечаний или ошибок. Здесь важно изменить этап, на котором возникает проблема, а не просто увеличить бюджет на исправления.
• Ожидания и зависимости. Сотрудник не мог завершить работу без решения другого участника, а затем пришлось выполнять её в сжатые сроки с дополнительными затратами. Такие случаи требуют пересмотра порядка взаимодействия.
• Изменение стоимости ресурсов. Подрядчик увеличил цену, понадобились дополнительные инструменты или более дорогие специалисты. Эти обстоятельства следует учесть в прогнозе ещё не выполненных этапов.

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

Что делать руководителю в первые 48 часов

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

Первый день — восстановить финансовую картину

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

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

Второй день — определить стоимость завершения

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

После этого подготовьте несколько сценариев и сравните их последствия:

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

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

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

Один из частых источников незаметного перерасхода — изменения, которые никто не оформляет как дополнительные работы.

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

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

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

Поэтому для каждой дополнительной работы нужно фиксировать четыре вещи:

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

Если новый объём согласован вместе с дополнительным бюджетом, финансовый план можно официально скорректировать. Но важно сохранять историю изменений, иначе станет невозможно отличить первоначальные ошибки оценки от новых требований.

Не стоит просто переписывать смету под уже понесённые расходы. Так проект формально всегда будет соответствовать бюджету, даже если его финансовые результаты ухудшаются.

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

До сих пор мы рассматривали внутренние затраты студии. Но у проекта есть ещё один показатель — сумма договора с клиентом.

Допустим, студия согласовала разработку сайта за 350 000 ₽. При первоначальном бюджете затрат в 300 000 ₽ планировалась разница между выручкой и расходами в размере 50 000 ₽.

Теперь возьмём прогноз второго сценария: 364 286 ₽.

350 000 − 364 286 = −14 286 ₽.

Вместо положительного финансового результата проект может принести убыток около 14 000 ₽.

Это упрощённый расчёт без отдельного разбора налогов, накладных расходов и других особенностей финансового учёта. Но он показывает, почему своевременная оплата со стороны заказчика не гарантирует прибыльность проекта.

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

Как не превратить финансовый контроль в бюрократию

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

В ней достаточно пяти основных показателей:

• плановый бюджет результата;
• бюджетная стоимость фактически выполненной работы;
• реальные затраты;
• актуальная оценка оставшейся работы;
• прогноз полной стоимости проекта.

При этом полезно разделять обычный контроль и действия при отклонениях.

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

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

Когда бюджет ещё можно спасти

Нет универсальной отметки, после которой проект автоматически становится финансово безнадёжным. Даже при готовности на 70% может оставаться достаточно возможностей сократить затраты, если большая часть дорогих работ ещё впереди.

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

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

Вернёмся к нашему примеру. У студии осталось 45 000 ₽, а прогноз полной стоимости проекта составляет от 345 000 до 380 000 ₽. Скрывать эту разницу до финальной приёмки означает добровольно отказаться от возможности управлять ситуацией.

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

Главный вопрос финансового контроля — не «сколько мы уже потратили?», а «сколько денег потребуется, чтобы выполнить всё, что мы ещё обещали?»

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