Треугольник проекта (Iron Triangle)

Назначение: наглядная модель trade-off для переговоров со стейкхолдерами.

Аудитория: PM, спонсоры, заказчики.

Статус: устоявшийся (Barnes, 1969; PMBOK).

Не путать с: Scope Creep (частный случай неконтролируемого изменения содержания; отдельной статьи в БЗ пока нет), уставом проекта (Project Charter — документ, фиксирующий те же ограничения), Pick-Any-Two (популярная формулировка той же идеи).

Общее #

Треугольник проекта (англ. Project Management Triangle, Iron Triangle, Triple Constraint — «тройное ограничение») — модель, связывающая три ключевых параметра проекта: содержание (scope), сроки (time) и стоимость (cost). Суть модели: три параметра взаимозависимы — нельзя изменить один из них, не затронув хотя бы один из остальных. Увеличение содержания при фиксированном сроке требует роста стоимости; сокращение срока при фиксированном бюджете требует урезания содержания; урезание бюджета при том же содержании удлиняет срок.

                         Scope
                      (содержание)
                          /\
                         /  \
                        /    \
                       /      \
                      /        \
                     / качество \
                    / (quality)  \
                   /              \
                  +----------------+
              Time                Cost
            (сроки)            (стоимость)

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

Как читать модель #

Термины «сторона» и «вершина» в литературе взаимозаменяемы: треугольник изображают и с параметрами в вершинах (scope, time, cost по углам), и с параметрами на сторонах — смысл не меняется. Важно другое: модель описывает не «три цифры в плане», а три взаимных зависимости:

• Scope → Time, Cost. Содержание определяет объём работ; объём работ — при данной производительности команды — определяет срок, а при данных ставках — стоимость. Это направление считается «физикой» проекта: оценка без определённого содержания невозможна.
• Time → Cost, Scope. Сжатие срока при том же содержании требует больше параллельной работы и людей, а значит — денег; если денег нет, «платит» содержание (часть работ не успевает) или качество.
• Cost → Scope, Time. Урезание бюджета при том же содержании удлиняет срок (меньше людей — медленнее); при несдвигаемом сроке — сокращает содержание или качество.

Условный числовой пример. Проект: 10 функций, 6 месяцев, команда из 5 человек. Заказчик просит «сделайте за 4 месяца, функциональность и бюджет не трогаем». Арифметика треугольника: объём работ не изменился, доступное время сократилось на треть — значит, нужна либо команда ~8 человек (рост стоимости, причём нелинейный: коммуникационные издержки), либо сокращение содержания до ~7 функций, либо «сжатие» качества, которое выставится счётом позже. Четвёртого исхода модель не предусматривает — и практика её в этом подтверждает.

Происхождение #

Идею тройного ограничения сформулировал британский исследователь проектного управления Мартин Барнс (Martin Barnes) в работе Time and Motion in Project Management (1969). Барнс описал связь «время — стоимость — результат» и показал, что управление проектом — это всегда балансировка между ними, а не максимизация каждого параметра по отдельности. Название Iron Triangle («железный треугольник») подчёркивает жёсткость связей: вершины нельзя «растянуть» усилием воли, как нельзя растянуть железный каркас.

Популярности модели способствовало её использование в консалтинге и позже — в стандартах PMI: описывая «управляющие переменные проекта», PMBOK фактически канонизировал тройное ограничение, а затем и расширил его (см. следующий раздел темы — «Шесть ограничений PMBOK»).

Модель развивалась в двух направлениях. Во-первых, появились расширения списка ограничений: пятое издание PMBOK Guide (2013) говорит уже о шести взаимозависимых ограничениях (см. раздел «Шесть ограничений PMBOK»). Во-вторых, «качество» из неявного следствия стало явным элементом модели — сначала «в центре треугольника», затем и вовсе четвёртой вершиной в ромбических моделях (см. раздел «Расширенные модели trade-off»).

Несмотря на критику (см. соответствующий раздел), треугольник проекта остаётся самым узнаваемым образом проектного управления: он объясняет суть trade-off заказчику за одну минуту и без специальной подготовки. Общее место модели среди базовых концепций проектного управления — во введении в управление проектом.

Три классические вершины #

Краткая сводка того, что происходит при «сдвиге» каждой вершины (при прочих равных):

Scope (содержание) #

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

Управление содержанием опирается на два инструмента. Иерархическая структура работ (Work Breakdown Structure, WBS) декомпозирует результат проекта до измеримых пакетов работ — отдельных статей в БЗ пока нет. Scope Creep («расползание содержания») — неконтролируемый рост требований после старта — классический пример того, как одна вершина «тихо» меняется, разрушая баланс всего треугольника: содержание растёт, а сроки и бюджет остаются прежними, и разницу оплачивает качество.

Признаки того, что вершина Scope теряет управление: требования «уточняются» в переписке, а не через change request; в план добавляются «маленькие» задачи, не прошедшие оценку; команда не может назвать полный список того, что входит в релиз. Каждое из этих событий — точечный сдвиг вершины без компенсации на двух других, то есть скрытый займ у качества.

Time (сроки) #

Сроки — календарное время до завершения проекта или его контрольной точки. Вершина складывается из последовательности и длительности задач, зависимостей между ними и доступности ресурсов. Планирование сроков опирается на диаграмму Ганта (полосы задач на шкале времени) и метод критического пути (Critical Path Method) — самую длинную цепочку зависимых задач, определяющую минимальную длительность проекта; подробнее — в статье «Критический путь».

Особенность вершины Time: срок — единственный параметр, который невозможно увеличить задним числом. Денег иногда можно найти больше, содержание — пересмотреть, а пропущенный дедлайн уже наступил. Кроме того, сжатие сроков подчиняется закону убывающей отдачи: сокращение срока вдвое почти никогда не сокращает работу вдвое, зато почти всегда взвинчивает стоимость и риск (больше параллельной работы, больше переработок, больше ошибок).

Сигналы неблагополучия вершины: план собран из «лучших случаев» (оценки без резервов на риски), критический путь не выделяется — все задачи «одинаково важны», а каждый статус-отчёт сдвигает прогноз завершения вправо. Стабильный прогноз даты — признак того, что вершина Time действительно управляется, а не декларируется.

Cost (стоимость) #

Стоимость — все ресурсы, необходимые для выполнения содержания в срок: зарплаты команды, подрядчики, лицензии, оборудование, инфраструктура. Вершина Cost связана с бюджетом проекта и его контролем. Основной инструмент контроля — управление освоенным объёмом (Earned Value Management, EVM), сопоставляющее плановую, фактическую и «заработанную» стоимость работ, — отдельной статьи в БЗ пока нет.

Тонкость вершины Cost: «стоимость» и «бюджет» — не одно и то же. Бюджет — согласованный предел, а стоимость — реальная цена получения результата. Возможность «сэкономить» почти всегда означает либо сокращение содержания, либо накопление долга (технического, квалификационного, репутационного), который придётся выплачивать позже и с процентами.

Типовая ловушка вершины Cost — «оптимистический бюджет»: оценка по лучшему случаю, в которой нет резервов на риски и переделки. Такой бюджет не снижает стоимость проекта — он лишь переносит её признание на позднюю фазу, когда переговорная позиция PM уже слаба. Зрелое управление стоимостью резервы делает явными (contingency reserve на известные риски, management reserve на неизвестные) и отделяет их от целевого бюджета.

Качество (Quality) — в центре #

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

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

Качество здесь понимается двояко: и как соответствие результата требованиям (fitness for purpose), и как качество процесса (меньше дефектов, меньше переделок). Важно, что деградация качества проявляется не сразу — момент «треугольник сошёлся» выглядит успехом, а счёт приходит позже: инцидентами в эксплуатации, техдолгом, поддержкой. Именно поэтому качество «в центре», а не «четвёртая точка, которую можно выбрать»: им жертвуют неявно, когда явно жертвовать уже нечем.

«Pick Any Two»: быстро — дёшево — качественно #

Популярная формулировка треугольника — афоризм «быстро, дёшево, качественно — выбери любые два» (англ. pick any two, «fast — good — cheap»). В прикладной литературе по клиентской работе эту формулировку популяризовал, в частности, Мартинес-Кодинак (Martinez-Codinach, 2013), но сама идея старше и восходит к «тройному ограничению» Барнса. Смысл афоризма: из трёх желаемых свойств результата устойчиво достигаются только два — третье неизбежно приносится в жертву.

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

Типовой микродиалог, в котором афоризм экономляет недели:

— Сделайте этот модуль за две недели, силами текущей команды и в рамках текущего бюджета. — Две недели, та же команда, тот же бюджет — то есть «быстро и дёшево». Зафиксируем это? — Да. Но качество не должно упасть. — «Быстро, дёшево и качественно» одновременно не получается — выбираем два из трёх. Либо четвёртая неделя, либо один специалист на месяц, либо упрощаем сам модуль. Что фиксируем?

Суть приёма: афоризм не отвергает запрос, а возвращает выбор тому, кто его делает. Ответственность за trade-off остаётся у заказчика — PM лишь делает цену решения видимой до, а не после.

Шесть ограничений PMBOK #

Классический треугольник — модель одного взгляда: PM, оценивающего проект «сверху». Стандарт PMI расширил картину. Уже четвёртое издание PMBOK Guide отмечало, что проекты ограничены не только временем, стоимостью и содержанием, а пятое издание (2013) зафиксировало шесть взаимозависимых ограничений:

• Scope — содержание: что входит в результат проекта;
• Quality — качество: требования к свойствам результата;
• Schedule — расписание: сроки и последовательность работ;
• Budget — бюджет: денежное выражение ресурсов;
• Resources — ресурсы: люди, оборудование, материалы;
• Risk — риск: неопределённость, способная отклонить проект от цели.

Смысл расширения: изменение любого из шести параметров затрагивает остальные. Добавление функциональности меняет содержание; рост требований к качеству удлиняет расписание; жёсткий бюджет ограничивает ресурсы; нехватка ресурсов увеличивает риск — и так по кругу. Формально это уже не «треугольник», а сеть зависимостей (иногда модель называют «гексагональной» — hexagonal constraints).

Соответствие классической и расширенной моделей:

Когда какую модель использовать:

• Треугольник (3) — для коммуникации: объяснение trade-off заказчику, переговоры о приоритетах, разбор «а почему нельзя добавить фичу бесплатно». Простота — достоинство: три вершины держатся в голове и умещаются на салфетке.
• Шесть ограничений — для планирования и контроля: здесь видно, что ресурсы и риск — самостоятельные рычаги, а не «производные» от денег и сроков. Например, снять ограничение по срокам иногда дешевле не деньгами, а перераспределением людей; а рост риска — самостоятельная цена сжатия сроков, которую треугольник не показывает.

Показательно, что седьмое издание PMBOK Guide (2021) вообще отказалось от списка ограничений как от каркаса изложения: стандарт перешёл от процессной модели к набору принципов и доменов исполнения. Это не «отмена» треугольника, а признание: ограничения — отправная точка разговора о проекте, а не его организующий принцип.

Расширенные модели trade-off #

Модель Коэна (Cohen’s Diamond) #

Модель, ассоциируемая с именем Алана Коэна, превращает треугольник в ромб (diamond), добавляя качество четвёртой вершиной: содержание — сроки — стоимость — качество. Тем самым качество перестаёт быть «пассивным центром» и становится явной стороной переговоров: им можно управлять и жертвовать так же осознанно, как сроком или бюджетом. Это честнее классической схемы: на практике «качество» далеко не всегда неприкосновенно — заказчик нередко сознательно выбирает «работает как-нибудь, но вчера».

Diamond Model Фернандеса #

Братья Дэвид и Давид Фернандес в работе The Project Management Triangle (PMI, 2008) предложили близкую ромбическую модель: cost — time — scope — quality, где качество — четвёртое измерение, связанное с содержанием, но не сводящееся к нему. Их ключевой аргумент: в классическом треугольнике качество «молчит», из-за чего решения о trade-off принимаются так, будто качество бесплатно. Явная вершина качества заставляет задать вопрос: «какое качество и для кого» — требования к качеству флагманского продукта и внутреннего инструмента измеряются по-разному и стоят разных денег.

Pick-2, Pick-3, Pick-N #

«Pick any two» формализуется как правило выбора фиксированных вершин: из N ограничений одновременно зафиксировать можно не все — остальные становятся переменными.

• Pick-2 — классика: фиксированы два параметра, третий варьируется («fixed scope & time → cost floating»).
• Pick-3 — расширение на большее число ограничений: в шестипараметрической модели PMBOK фиксируют три (например, scope, schedule, budget), а качеством, ресурсами и риском управляют.
• Pick-N — предельный случай: попытка зафиксировать всё. Она возможна лишь формально — на бумаге; реальная степень свободы всё равно найдётся, только неуправляемая: она проявится качеством, риском или выгоранием команды.

Правило переводит интуицию «всё сразу не бывает» в рабочий инструмент: сколько и какие именно вершины мы фиксируем — записано явно.

Теория ограничений Голдратта #

Наиболее фундаментальное обоснование треугольника даёт теория ограничений (Theory of Constraints) Элияху Голдратта — книга The Goal (1984), применение к проектам — Critical Chain (1997). Ключевой тезис: любая система в каждый момент ограничена одним слабейшим звеном, и производительность всей системы определяется именно им, а не суммой усилий на «сильных» участках.

Отсюда следствия, прямо относящиеся к треугольнику. Во-первых, «улучшать» можно только ограничивающий параметр — ускорение неузкого места на срок и стоимость проекта не влияет вовсе. Во-вторых, попытка давить на все вершины одновременно распыляет ресурсы: единственное, что имеет значение, — где сейчас слабейшее звено (и оно перемещается: устранил одно ограничение — ограничением становится следующее). Связь теории ограничений с ограничением незавершённой работы в команде разобрана в статье о WIP-лимитах.

Применение в работе PM #

На старте: что зафиксировано, а что варьируется #

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

• Fixed scope / flexible time & cost — «содержание свято». Классика контрактной и инженерной разработки: сначала полный список требований, затем оценка. Цена: любое изменение требований — формальная процедура с пересчётом сроков и бюджета (change request).
• Fixed time & cost / flexible scope — «дата свята». К жёсткой дате (выставка, регуляторный срок, релиз конкурента) делают максимум ценного из возможного, а состав — предмет приоритизации. Это конфигурация Agile.
• Fixed cost / flexible scope & time — «бюджет свято». Типично для внутренних и исследовательских проектов: выделяется энная сумма, под неё подбирается разумный объём работ.

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

Чек-лист соглашения о степенях свободы на старте:

• Какая вершина жёсткая безусловно (регуляторный срок? фиксированный контракт? обязательный состав результата)?
• Какая вершина гибкая, и кто уполномочен менять её в рамках проекта (приоритизация бэклога — чья зона ответственности)?
• Какова процедура сдвига жёсткой вершины (change request, эскалация) и сколько она стоит?
• Как измеряется «качество», чтобы жертвы им были видимыми (Definition of Done, метрики дефектов)?
• Записано ли соглашение (устав проекта, контракт) и подтверждено ли всеми ключевыми сторонами?

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

В переговорах: треугольник как аргумент #

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

1. Признать запрос легитимным и по существу: «да, фича полезна».
2. Назвать цену через модель: «она добавляет работу; при фиксированных сроке и бюджете возрастёт только нагрузка — за счёт качества, которое сегодня не входит в сделку».
3. Предложить выбор: убрать что-то равноценное из содержания / сдвинуть срок / увеличить бюджет — одну из трёх вершин двигаем, но не бесплатно.

Такая схема переводит разговор из «PM отказывает» в «PM показывает счёт». Опытные PM считают этот паттерн главной практической ценностью модели: она даёт нейтральный язык, в котором рост содержания — не каприз исполнителя, а арифметика.

Антипаттерны #

На практике треугольник чаще всего «ломается» не из-за внешних обстоятельств, а из-за типовых ошибок его применения:

• «Зафиксировано всё». Срок, бюджет и содержание заявлены жёсткими одновременно. Степень свободы не исчезает — она уходит в неуправляемую плоскость: переработки команды, скрытые дефекты, тихое «доопределение» требований по ходу дела. Итог предсказуем: последняя треть проекта превращается в кризис.
• Качество как невидимый буфер. Формально стороны не меняются, фактически разница оплачивается пропущенным тестированием и ревью. Антидот — сделать качество измеримым (Definition of Done, метрики дефектов), тогда «заимствование у центра» станет видимым в отчётах.
• Треугольник как угроза. Модель используется не для выбора, а для отказа: «треугольник запрещает». Это извращает её назначение: модель предлагает варианты («что двигаем?»), а не закрывает разговор.
• Один треугольник на все уровни. Вершины проекта в целом и вершины отдельного эпика — разные масштабы; фиксация «scope жёсткий» на уровне проекта не означает той же фиксации внутри двухнедельной итерации. У каждого уровня планирования — своё соглашение о степенях свободы.

В Agile: fixed time & cost, variable scope #

Agile-подходы можно описать через треугольник целиком: спринт — это мини-проект с фиксированными сроком и стоимостью. Длина спринта не меняется (fixed time), состав команды стабилен (fixed cost), а содержание спринта — величина переменная: команда берёт в спринт ровно столько задач из приоритизированного бэклога, сколько способна сделать (variable scope).

Это не совпадение, а осознанный отказ от самой рискованной конфигурации. Жёсткая фиксация содержания (fixed scope) — источник главных провалов проектов: требования всегда меняются быстрее, чем их удаётся «заморозить», и каскадная модель либо ломается, либо платит качеством. Agile разворачивает конфигурацию: фиксируется то, что предсказуемо (время и команда), а варьируется то, что непредсказуемо (состав). Отсюда же роль приоритизации бэклога — это механизм управления гибкой вершиной.

Сопоставление конфигураций двух миров:

Понимание этой связи полезно в обе стороны: waterfall-проекты осмысленно описывать в терминах треугольника («что мы зафиксировали?»), а Agile-команды — в терминах степеней свободы («что у нас переменное и как мы этим управляем?»).

Критика модели #

Популярность треугольника породила и обоснованную критику. Основные претензии:

• Ценность (value) не входит в модель. Треугольник отвечает на вопрос «уложимся ли мы в срок/бюджет/содержание», но не на главный вопрос бизнеса: «стоит ли результат своих затрат». Проект может идеально «сидеть» во всех трёх вершинах и при этом быть бесполезным — и наоборот, проект с превышением бюджета способен создать кратно больше ценности. В конкурентных средах ограничением является не «железо треугольника», а поставка ценности раньше и дешевле, чем у альтернатив (позиция Agile/Lean: true constraint is value delivery).
• Риск — не параметр, а среда. В классической схеме риск нигде не живёт, хотя каждое «сжатие» треугольника в реальности оплачивается именно риском. PMBOK частично ответил, включив риск в шесть ограничений; систематическая работа с рисками разобрана в отдельной статье «Управление рисками проекта».
• «Качество в центре» упрощает. Качество — не однородная величина: есть функциональное соответствие, надёжность, безопасность, удобство — и «жертвуют» ими по-разному. Кроме того, качество не всегда «жертва»: инвестиция в качество (автотесты, ревью, рефакторинг) сокращает совокупные срок и стоимость, а не удлиняет их, — это противоречит прямой логике треугольника.
• Модель статична. Треугольник изображает фиксированный момент, но реальные ограничения меняются: то, что вчера было гибким, сегодня стало жёстким (закончилось терпение спонсора) — и наоборот.

Современный взгляд пытается дополнить модель, а не отбросить её: в центре обсуждения — соотношение ценности и стоимости (value vs cost): решения о trade-off принимаются по критерию максимума ценности на единицу ограничения, а не по формальному «удержанию вершин». Развиваются и данные о проектах (Project Data Analytics): вместо интуитивных оценок «сколько будет стоить сжатие сроков» — статистика похожих проектов организации. Треугольник при этом не отменяется: он остаётся базовым языком, на котором эти более тонкие рассуждения излагаются.

См. также #

• Введение в управление проектом — место треугольника среди базовых концепций проектного управления.
• Agile — подход, реализующий конфигурацию «fixed time & cost, variable scope».
• WIP-лимит — практическое применение теории ограничений Голдратта к потоку задач.
• Критический путь — как устроена вершина Time изнутри: цепочка задач, определяющая срок проекта.
• Управление рисками проекта — риск как самостоятельное ограничение в расширении PMBOK.

Заключение #

Треугольник проекта — старейшая и самая узнаваемая модель проектного управления: три вершины — содержание, сроки, стоимость — и качество, принимающее на себя дисбаланс. Её сила в простоте: за минуту она объясняет заказчику, почему «всё сразу и бесплатно» не бывает, и превращает спор в выбор.

Практические выводы для PM:

1. Аксиома переговоров: нельзя изменить одну вершину, не затронув остальные, — каждое «добавим немножко» имеет цену, и её следует называть явно.
2. Главное правило: на старте зафиксировать две вершины и согласовать, какая остаётся гибкой; стихийная «фиксация всего» означает, что жертвовать придётся качеством.
3. Agile — это тоже треугольник: спринт фиксирует время и стоимость, варьируя содержание; приоритизация бэклога — механизм управления гибкой вершиной.
4. Модель неполна: она не учитывает ценность и риск, поэтому служит языком для разговора о trade-off, но не критерием решения — решение принимается по максимуму ценности.

Критики справедливо указывают, что реальное управление — это не «удержание треугольника», а поставка ценности в условиях ограничений. Но именно поэтому модель живёт: любой разговор о приоритетах, любой change request и любой выбор «что режем» — это разговор в терминах треугольника проекта, независимо от того, знают ли его участники его название.