Что входит в треугольник управления проектом кроме стоимости и сроков?

📐 Треугольник управления проектом (Iron Triangle / Triple Constraint)

В классическом понимании треугольник управления проектом состоит из трёх ключевых ограничений: Сроки (Time), Бюджет (Cost) и Содержание/Объём работ (Scope). Эти элементы взаимосвязаны и образуют вершины треугольника, в центре которого находится Качество (Quality). Изменение одного из параметров неизбежно влияет на остальные.

🎯 Третья вершина: Содержание/Объём работ (Scope)

Это основная цель проекта — продукт, услуга или результат, который должен быть достигнут. Scope определяет:

• Функциональность (функции, возможности).
• Требования (бизнес-требования, требования пользователей).
• Критерии приёмки (условия, при которых проект считается завершённым).
• Границы проекта (что входит, а что — нет).

Пример: В IT-проекте scope — это фичи приложения, технические спецификации, интеграции с другими системами.

⚖️ Центр треугольника: Качество (Quality)

Хотя традиционно в вершинах только три элемента, современные подходы (например, PMBOK) помещают Качество в центр треугольника как интегрирующий фактор. Качество — это степень соответствия результата проекта ожиданиям заказчика и установленным стандартам. Она напрямую зависит от баланса Scope, Time и Cost.

quadrantChart
    title "Взаимосвязь в Треугольнике Управления Проектом"
    x-axis "Низкая гибкость" --> "Высокая гибкость"
    y-axis "Низкое влияние" --> "Высокое влияние"
    "Scope (Объём)": [0.2, 0.8]
    "Time (Сроки)": [0.4, 0.7]
    "Cost (Бюджет)": [0.6, 0.6]
    "Quality (Качество)": [0.5, 0.9]

🔄 Динамика взаимосвязей

Изменение одного параметра при фиксированных двух приводит к компромиссу:

• Увеличение Scope → Рост Cost и/или Time, риск снижения Quality.
• Сокращение Time → Увеличение Cost (сверхурочные, больше команда) или сокращение Scope.
• Сокращение Cost → Увеличение Time или сокращение Scope.

Практический пример из IT:

Заказчик просит добавить в мобильное приложение новую фичу (Scope ↑) в рамках текущего бюджета и сроков. Project Manager должен предложить варианты:

• Вариант A (жёсткие сроки): Увеличить Budget (Cost ↑) для привлечения дополнительных разработчиков.
• Вариант B (жёсткий бюджет): Сдвинуть дедлайн (Time ↑), чтобы текущая команда успела.
• Вариант C (жёсткие сроки и бюджет): Урезать другую функциональность (Scope ↓) из бэклога или снизить Quality (например, выпустить MVP-версию фичи).

🏗️ Современные расширения модели

В Agile- и IT-среде классический треугольник часто дополняют другими критическими ограничениями, формируя "Шестигранник ограничений" (PMBOK 7):

1. Качество (Quality) — уже рассмотрено.
2. Ресурсы (Resources) — команда, оборудование, ПО.

   # Пример оценки загрузки ресурсов (команды)
   team_capacity_per_sprint = 120 человеко-часов
   feature_backlog_hours = 200
   # Дефицит ресурсов = 80 часов → влияет на Time или Scope
   

3. Риски (Risks) — неопределённости, которые могут повлиять на проект.
4. Удовлетворённость заказчика/пользователя — итоговый критерий успеха в Agile.

💡 Практическое применение для IT Project Manager

• Базовый инструмент коммуникации: Наглядно объясняю стейкхолдерам последствия их запросов.
• Основа для trade-off анализа: Приоритизация требований в бэклоге.
• Управление ожиданиями: Чёткое определение, что является фиксированным, а что — гибким параметром в проекте.
• Выбор методологии:

    *   **Жёсткий Scope** (водопад) → фокус на контроле Time и Cost.
    *   **Жёсткие Time и Cost** (Agile/Scrum) → фокус на гибком Scope и качестве.

Итог: Помимо стоимости (Cost) и сроков (Time), третьей вершиной классического треугольника является Содержание/Объём работ (Scope), а Качество (Quality) — его центральный элемент. Понимание и балансировка этих ограничений — ключевая компетенция Project Manager для успешной доставки проекта в рамках заданных условий. В динамичной IT-среде эта модель дополняется управлением ресурсами, рисками и фокусом на ценности для пользователя.