Проектный треугольник: сроки, бюджет и содержание

Фраза «быстро, дёшево, качественно - выберите любые два» звучит как шутка менеджеров, но за ней стоит рабочая модель планирования. Проектный треугольник (он же тройственная ограниченность, triple constraint) утверждает простую вещь: содержание, срок и бюджет проекта связаны жёстко, и произвольно задать все три значения сразу нельзя. Заказчик, который требует добавить функции, сдать раньше и не выходить за смету, просит не сложного, а невозможного. Ниже разберём, как устроена эта связь, какой формулой она описывается и как считать цену каждого изменения. Калькулятор под этим абзацем переводит требования заказчика в конкретные цифры: новый срок, нужный размер команды и рост бюджета.

Три ограничения и качество в центре

Классическая формулировка PMBOK описывает проект тремя базовыми ограничениями:

• Содержание (scope) - что именно должно быть сделано: перечень работ, функций, разделов, объём поставки. Измеряется в единицах результата и в трудоёмкости (человеко-днях).
• Срок (time) - календарная длительность от старта до приёмки.
• Стоимость (cost) - бюджет: оплата труда, оборудование, подряд, накладные.

Стороны треугольника не независимы: они связаны через трудоёмкость. Если обозначить объём работ $V$ (человеко-дни), численность команды $N$, длительность $T$ (дни) и долю рабочего времени, уходящую на полезную работу, $e$, то базовое соотношение выглядит так:

$V = N \cdot T \cdot e$

Бюджет прямых затрат при средней ставке $r$ рублей за человеко-день:

$C = N \cdot T \cdot r = \frac{V \cdot r}{e}$

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

Правило двух вершин: третья становится следствием

Главное практическое правило звучит так: свободно фиксировать можно только две вершины, третья вычисляется. Это прямое следствие формулы выше - в уравнении с тремя связанными величинами задание двух определяет третью.

Рассчитать для своей задачи

Отсюда три типовые конфигурации проекта:

1. Фиксируем содержание и срок - расчётной становится стоимость. Так работают проекты «к дате»: сдать корпус к 1 сентября, объём работ определён, значит бюджет подстраивается численностью и сверхурочными.
2. Фиксируем содержание и бюджет - расчётным становится срок. Типично для грантов и внутренних разработок: денег ровно столько, сколько выделено, значит проект идёт столько, сколько идёт.
3. Фиксируем срок и бюджет - расчётным становится содержание. Именно так устроены итеративные подходы: команда и длительность спринта постоянны, а объём поставки определяется тем, что успели. Подробнее эта логика разобрана в материале про Agile и Waterfall.

Ошибка формулировки задачи в курсовой почти всегда одна и та же: студент объявляет фиксированными все три вершины и потом «подгоняет» расчёт. Правильный ход - назвать расчётную величину явно.

Расширение содержания: что происходит с двумя сторонами

Самое частое возмущение проекта - рост содержания (scope creep). Заказчик просит добавить модуль, раздел, ещё одну площадку. Дальше возможны только три исхода, и все они выводятся из формулы:

• срок растёт при неизменной команде: $T = V / (N e)$;
• бюджет растёт при неизменном сроке - приходится увеличивать $N$;
• часть работ уходит из поставки, то есть содержание фиксируют заново.

Четвёртого исхода нет - но именно его чаще всего пытаются получить, ничего не меняя формально. Тогда расплачивается качество: работы выполняются, но без запаса на проверку.

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

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

$L = \frac{N(N-1)}{2}$

Рассчитать для своей задачи

Линейная модель потерь описывает это достаточно точно для учебных расчётов:

$e(N) = 1 - k\,(N-1), \qquad T = \frac{V}{N\,e(N)}$

где $k$ - доля рабочего времени, которую каждый новый участник отнимает у остальных на коммуникацию (в задачах берут 2-5%). Отсюда знаменитый вывод Брукса: добавление людей к опаздывающему проекту задерживает его ещё сильнее, потому что при большом $N$ произведение $N\,e(N)$ перестаёт расти, а с некоторого момента убывает.

Числовой пример, который повторяет настройки калькулятора выше. Пусть базовая трудоёмкость 600 человеко-дней плюс 15% резерва на качество, то есть $V = 690$; команда $N_0 = 6$, $k = 0{,}03$. Тогда $e(6) = 0{,}85$, эффективная производительность $6 \cdot 0{,}85 = 5{,}1$ человеко-дня в день, а срок $T_0 = 690 / 5{,}1 \approx 135$ дней. Бюджет при ставке 8 тыс. рублей за человеко-день: $C_0 = 6 \cdot 135 \cdot 8 = 6480$ тыс. рублей.

Теперь заказчик просит и содержание больше на 20%, и срок короче на 20%. Новый объём $V_1 = 600 \cdot 1{,}2 \cdot 1{,}15 = 828$ человеко-дней, целевой срок $T_1 = 108$ дней, значит нужна производительность $828 / 108 \approx 7{,}7$. Проверка вариантов даёт $N_1 = 11$ (при десяти получается лишь $10 \cdot 0{,}73 = 7{,}3$). Бюджет: $C_1 = 11 \cdot 108 \cdot 8 = 9504$ тыс. рублей - рост почти в полтора раза при росте содержания всего на пятую часть. Это и есть цена одновременного давления на две вершины. Калькулятор выше считает то же самое без промежуточных округлений и даёт ту же команду из 11 человек при росте бюджета на 47%.

Треугольник в договоре: фиксированная цена и оплата по времени

Модель не абстрактна: она напрямую отражена в типах контрактов.

Рассчитать для своей задачи

• Фиксированная цена (fixed price) закрепляет содержание и стоимость. Расчётная вершина - срок и, неявно, риск исполнителя: любое расширение требований оформляется дополнительным соглашением, иначе подрядчик режет качество.
• Оплата по времени (time and material) закрепляет ставку и темп, оставляя содержание подвижным. Расчётная вершина - стоимость, риск на заказчике.
• Смешанные схемы (цена с потолком, оплата за этап) - попытка разделить риск: содержание фиксируют по этапам, а не по проекту целиком.

Поэтому в учебной работе разбор проектного треугольника логично доводить до типа договора: он показывает, кто платит за смещение вершины.

Как применять треугольник в курсовой

Чтобы раздел не остался пересказом, доведите его до чисел на своём примере:

1. Опишите базовый план: трудоёмкость по работам, команда, срок, ставка, бюджет.
2. Назовите, какая вершина у вас расчётная, и обоснуйте это условиями проекта.
3. Смоделируйте одно возмущение (рост содержания или сжатие срока) и посчитайте две другие стороны по формулам выше.
4. Покажите резерв на качество и объясните, что произойдёт при его изъятии.
5. Свяжите вывод с календарным планом: длительность сжимается только по критическим работам, поэтому расчёт удобно продолжить через критический путь сетевого графика.

Частые ошибки

• Считать качество четвёртой независимой вершиной. В базовой модели оно свойство результата, а не ресурс, который можно «выделить»; иначе теряется смысл правила двух вершин.
• Линейно делить срок на численность. Расчёт «двое сделают вдвое быстрее» игнорирует потери на коммуникации и даёт заведомо недостижимый план.
• Путать содержание и объём работ. Содержание - перечень результатов, трудоёмкость - их цена в человеко-днях; одно и то же содержание при разной технологии стоит разной трудоёмкости.
• Сжимать проект целиком, а не критические работы. Ускорение задачи с резервом времени не сокращает срок проекта, но увеличивает бюджет.
• Забывать про накладные расходы при росте команды. Рабочие места, лицензии, управление растут вместе с $N$, поэтому реальный рост бюджета выше расчётного по прямым затратам.

FAQ

Проектный треугольник и тройственная ограниченность - это одно и то же? Да. «Тройственная ограниченность» - принятый в русскоязычном PMBOK перевод triple constraint, «проектный треугольник» и «железный треугольник» - обиходные названия той же модели. Расширенные версии добавляют риск и ресурсы, превращая треугольник в звезду или ромб, но базовая связь трёх вершин сохраняется.

Можно ли улучшить сразу все три стороны? Только сменой технологии или процесса, то есть за счёт роста эффективности $e$: автоматизация, переиспользование готовых решений, снятие простоев. Формула тогда меняет коэффициент, а не отменяется - треугольник просто становится больше по площади при тех же ограничениях.

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

Коротко

Проектный треугольник связывает содержание, срок и бюджет через трудоёмкость: $V = N\,T\,e$. Свободно задать можно только две вершины, третья вычисляется, а качество страдает первым, когда все три зажаты сверх меры. Рост содержания перекладывается на срок или бюджет, сжатие срока требует роста численности с потерями на коммуникации, поэтому бюджет растёт быстрее содержания. В учебной работе модель доводят до чисел: базовый план, названная расчётная вершина, одно возмущение с пересчётом и вывод про тип договора.