Управленческие решения в проектах: что это такое и как их принимать?

Проект — это временная система. Команда, подрядчики, поставки, график, деньги, ожидания клиента. Любое отклонение тянет цепочку последствий. Решение в проекте почти всегда трогает три вещи: срок, бюджет, качество (или объём работ).

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

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

Что такое управленческое решение?

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

В проектном бизнесе решение считается управленческим, если выполняется хотя бы одно условие: меняется план работ, меняется бюджет, меняются роли и ответственность, меняются отношения с клиентом или подрядчиком (сроки, объём, оплата, санкции).

Самая частая ловушка — путать «обсудили» и «решили». Обсуждение даёт ощущение движения, проекту нужен факт решения: формулировка, владелец, дата, проверяемый результат. Иначе остаётся надежда, что команда «сама разрулит».

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

Какие решения встречаются в проектах чаще всего?

Чтобы не усложнять, удобно держать в голове 4 типа решений:

• Операционные: «как сделать сегодня» — замена исполнителя на смене, перенос работ на завтра из‑за доступа, перестановка задач в бригаде.
• Плановые: «как уложиться в неделю/этап» — пересборка графика, изменение последовательности, выравнивание ресурсов. На эту тему полезен материал про календарный график и зависимости задач.
• Финансовые: «как сохранить маржу и кассу» — согласование закупок, лимиты на подотчёт, решение по перерасходу, перенос платежей.
• Стратегические для проекта: «что будет считаться успехом» — изменение объёма работ, смена правил приёмки, пересогласование сроков с заказчиком.

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

Метод: цикл решения от сигнала до фиксации

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

Цикл полезен, когда есть давление времени: заказчик просит ответ «сейчас», поставщик переносит отгрузку, бригада простаивает. В такие моменты мозг стремится выбрать первый терпимый вариант. Цикл возвращает контроль.

Идея простая: сначала формулируется решение, потом — скорость. Скорость без формулировки даёт хаос, потом всё равно приходится «разбирать полёт» уже на последствиях.

1. Шаг 1. Зафиксируй сигнал: что произошло и где это видно (факт, дата, источник).
2. Шаг 2. Сформулируй вопрос решения одним предложением. Формат: «что мы делаем с … до … при условии …».
3. Шаг 3. Назови ограничения: бюджет, срок, договор, доступы, ресурсы.
4. Шаг 4. Собери минимум данных под решение. Обычно хватает 3–7 пунктов: цифры, сроки, последствия по людям, риски по качеству.
5. Шаг 5. Сгенерируй 2–3 варианта, включая вариант «ничего не менять» (он тоже вариант).
6. Шаг 6. Выбери критерии. Чаще всего: маржа, касса, срок этапа, риск переделок, риск конфликта с клиентом.
7. Шаг 7. Прими решение и назначь владельца исполнения.
8. Шаг 8. Зафиксируй решение: что делаем, кто делает, срок, что считаем выполнением, где подтверждение.

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

Реальные ситуации из проектного бизнеса

Ситуация 1. Стройка/ремонт: заказчик просит «добавить пару работ». Формулировка звучит мелко: перенести пару розеток, сделать нишу, поменять тип плинтуса. Внутри проекта это изменение объёма, материалов, сроков, приёмки. Вопрос решения: «берём изменения в текущий договор или оформляем допработы?» Минимум данных: трудозатраты мастеров, новые материалы, влияние на критический путь по графику, риск переделки уже выполненного. Рабочее решение часто выглядит так: фиксируется допсмета, срок согласования, кто оплачивает материалы, кто подписывает объём. Фиксация обязательна, иначе команда сделает, деньги останутся «за кадром».

Ситуация 2. Агентство: подрядчик задерживает исходники, команда простаивает. Вопрос решения: «держим подрядчика и переносим релиз или меняем подрядчика и платим дороже?» Данные: стоимость замены, штрафы по договору с клиентом, влияние на маржу, скорость входа нового подрядчика, риск качества. Критерий часто один: что дешевле для проекта с учётом потерь времени. В проектном бизнесе потеря недели может стоить дороже прямой переплаты.

Ситуация 3. Производство под заказ: обнаружен дефект на этапе, когда переделка бьёт по сроку. Вопрос решения: «исправляем сейчас и двигаем отгрузку или принимаем риск и компенсируем сервисом?» Данные: вероятность рекламации, стоимость сервисного выезда, репутационный риск, условия договора по штрафам, доступность материалов на переделку. Здесь важно разделить эмоции и риск‑аппетит компании: какой уровень рекламаций допустим, что дороже — штраф или потеря повторных заказов.

Ситуация 4. Любой проект: руководитель проектов ведёт 5 объектов и постоянно «зависает» на согласованиях. Здесь решение уже управленческое на уровне системы: «какие решения делегируются, какие эскалируются, какие лимиты вводятся». Это стыкуется с темой структуры управления и прав решений. Хорошая отправная точка — материал 101 про структуру управления проектом. Когда права решений закреплены, команда меньше ждёт руководителя.

Вопросы для самопроверки

Эти вопросы помогают быстро оценить, насколько решения в проектах управляемы:

• Какие решения в проектах повторяются чаще всего, и во что они уже превращены: правило, лимит, шаблон согласования?
• Какие решения команда может принимать без тебя, и где это написано?
• Какие решения регулярно «всплывают» уже как последствия (перерасход, срыв сроков, конфликт), хотя их можно было принять заранее?
• Есть ли в проектах единый формат фиксации решения: владелец, срок, критерий готовности, подтверждение?
• Где команда берёт данные под решения: из отчёта, из таблицы, из чата, из головы?
• Сколько времени занимает получить цифры по проекту: остаток бюджета, план‑факт, список обязательств по оплатам?
• Какие решения чаще всего принимаются без оценки влияния на деньги?
• Есть ли правило, когда решение обязательно поднимается на согласование: сумма, риск, влияние на срок, влияние на договор?
• Кто фиксирует договорённости после планёрки, и где команда потом их проверяет?
• Как выглядит эскалация: что делает руководитель проекта, если решение «зависло» больше суток?
• Что в проектах считается «красной зоной» и автоматически требует внимания: кассовый разрыв, перерасход по статье, срыв критической поставки?
• Какая ошибка в решениях повторялась три раза за полгода, и почему она не превратилась в правило?

Скрипты общения с коллегами

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

Скрипт 1. Запрос данных под решение.

• «Нужно принять решение по [вопрос]. Пришли, пожалуйста, до [время] три пункта: 1) текущий статус, 2) два варианта действий, 3) влияние на срок/бюджет. Источник цифр укажи в одном предложении».
• «Чтобы не гадать, нужен план‑факт по статье [статья] и обязательства по оплатам до [дата]. Дашь сегодня до [время]?»

Скрипт 2. Согласование изменения объёма работ с руководителем проекта или сметчиком.

• «Есть запрос на изменение: [что меняем]. Скажи, это влияет на материалы или только на работу? Если влияет, оцени стоимость и срок поставки».
• «Давай оформим это как изменение: сумма, срок, кто утверждает. Без фиксации команда сделает, а проект потеряет деньги».

Скрипт 3. Эскалация, когда решение зависло.

• «Решение по [вопрос] нужно до [время], иначе [последствие]. Варианты такие: А — [коротко], Б — [коротко]. Я рекомендую вариант [А/Б] по причине [1 строка]. Подтверди, пожалуйста, сегодня».
• «Если до [время] подтверждения не будет, выбираю вариант [А/Б] и фиксирую в проекте. Это нужно, чтобы команда не стояла».

Скрипт 4. Закрытие решения после встречи (чтобы договорённость стала фактом).

• «Фиксирую итоги: 1) делаем [решение], 2) владелец [имя], 3) срок [дата], 4) критерий готовности [что принимаем], 5) подтверждение [где лежит: акт/письмо/заказ/скрин]. Если есть правки — напиши до [время]».

Как закреплять решения, чтобы они работали?

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

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

Если используешь Приложение 101 как опору по финансам проекта, логика простая: решение связывается с движением денег и подтверждающими документами. Тогда меньше споров «кто согласовал» и «почему оплатили». Когда нужна более плотная аналитика и контроль показателей, в PRO+ проще держать управленческую картину в одном месте.

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

И последнее. Если команда реально работает итерациями (короткие циклы, еженедельные план‑факты, ретро по ошибкам), управленческие решения становятся спокойнее. В стройке это тоже применимо при адаптации к реальности объекта. Есть хороший контекст в материале Agile в строительстве.