Руководителю проекта приходится удерживать вместе три вещи: объем работ, срок и бюджет. Стоит заказчику добавить функцию или попросить закончить раньше, и под вопросом оказываются остальные стороны.
Ниже: что такое проектный треугольник, как стороны влияют друг на друга, где в нем качество, как построить его на примере и как модель работает в Waterfall, Agile, Scrum и Kanban.
.jpg)
- Что такое проектный треугольник
- Преимущества и недостатки проектного треугольника
- Как работает проектный треугольник
- Построение проектного треугольника и примеры использования
- Как управлять проектным треугольником
- Проектный треугольник в разных методологиях
- FAQ по проектному треугольнику
- Коротко о главном
Что такое проектный треугольник
Проектный треугольник — это модель управления проектами, которая показывает, как связаны между собой объем работ (содержание), время и бюджет (стоимость). Проектный треугольник простыми словами — это связь между содержанием, сроком и ресурсами проекта.
Модель называют также железным треугольником и тройственной ограниченностью проекта. Набор сторон в источниках описывают по-разному. Ассоциация по управлению проектами (APM) определяет тройное ограничение как баланс между временем, стоимостью и качеством при поставке содержания проекта, а в докладе Wei Lee на конгрессе PMI 2010 года отмечено, что менеджеры проектов обычно говорят о тройном ограничении объема, времени и стоимости. Базовый вариант модели строится на трех сторонах, которые показаны на схеме ниже.
- Объем работ. Объем определяет, что именно должно быть выполнено в рамках проекта, то есть содержание проекта. Увеличение объема работ без соответствующего увеличения ресурсов и бюджета может привести к задержкам или недостаточному качеству выполнения работ.
- Время. Сроки завершения проекта определяются как ожидаемым временем выполнения работ, так и желанием заказчика получить результат в срок. Сокращение временных рамок может привести к увеличению затрат на ресурсы или снижению качества работ из-за нехватки времени на их выполнение.
- Бюджет. Это стоимость проекта и ресурсы, на которые он рассчитан. Недостаточный бюджет ограничивает доступ к необходимым ресурсам, услугам или технологиям, а это отражается на качестве проекта или его сроках. Резкое снижение бюджета без уменьшения объема работ или времени может поставить под угрозу завершение проекта.
Какое место в треугольнике занимает качество
В этом докладе объем, время и стоимость названы тройным ограничением, а качество проекта зависит от баланса этих трех факторов. В определении APM качество входит в само ограничение вместе со временем и стоимостью. Авторы обзора научных публикаций 1970–2015 годов (Pollack, Helm, Adler, 2018) отмечают, что статус качества в этой модели остается спорным. На схеме качество показано в центре как результат баланса сторон.
Автор доклада называет высококачественным проект, который дает нужный продукт, услугу или результат в рамках объема, в срок и в пределах бюджета. При такой трактовке качество не вынесено в отдельную сторону, а каким должен быть нужный результат, модель не говорит.
Качество не показано отдельной стороной треугольника, поэтому критерии приемки согласуйте вместе со сторонами до старта работ.
Преимущества и недостатки проектного треугольника
По мнению Пола Нейбора, автора блога APM, проектный треугольник чаще всего используют, чтобы договариваться с заинтересованными сторонами о важнейших целях проекта. В этом его основная польза.
- Четкие ограничения. Модель помогает согласовать ожидания всех заинтересованных сторон относительно объема работ, времени и бюджета проекта.
- Управление изменениями. Понимание связи между объемом, временем и бюджетом помогает оценить, как изменение одного элемента повлияет на другие, и принять обоснованное решение.
- Реалистичное планирование. Три стороны задают рамки, в которые укладывают план проекта: перечень работ, график и бюджет.
Недостатки модели связаны с ее простотой.
- Упрощенность. Проектный треугольник представляет собой упрощенную модель, которая не всегда учитывает все сложности и аспекты проекта. Реальные проекты часто имеют гораздо более сложную структуру и могут содержать дополнительные факторы, которые не укладываются в рамки треугольника.
- Жесткость. В проектном треугольнике оговариваются три основных параметра — объем работ, время и бюджет. В ходе выполнения проекта они могут меняться под влиянием различных факторов и изменений внешних условий, и тогда жесткость модели затрудняет адаптацию проекта к новым требованиям.
- Качество не показано отдельной стороной. Модель из трех сторон не измеряет качество отдельно, поэтому его критерии приходится задавать дополнительно.
- Перекос без договоренности. Если команда держит один параметр проектного треугольника за счет других, не согласовав это с заказчиком, результат может не устроить его по остальным сторонам.
Поэтому модель применяют с учетом контекста проекта и не принимают безоговорочно.
Как работает проектный треугольник
Проектный треугольник работает как набор взаимосвязей: если изменяется любая из сторон, хотя бы одна из двух других, скорее всего, тоже изменится. Повод для изменения нередко дает заказчик или клиент, когда просит добавить функции, ускорить запуск или уложиться в меньшую сумму. Менеджеру проекта остается определить, какая сторона уступит, и обсудить этот выбор до начала работ над правкой. В таблице показано, как обычно распределяются последствия.
| Что меняется | Что происходит с другими сторонами | Как это решают на практике |
|---|---|---|
| Объем работ растет | Срок увеличивается или бюджет растет | Переносят срок, увеличивают бюджет или откладывают часть работ на следующий этап |
| Срок сокращается | Растет стоимость или уменьшается объем | Привлекают дополнительные ресурсы за деньги либо сокращают состав работ |
| Бюджет уменьшается | Уменьшается объем или сдвигается срок | Убирают часть функций или растягивают график |
Компромисс — это соглашение между сторонами, в котором каждая из них от чего-то отказывается, чтобы результат устроил всех.
Trade-off — это баланс между двумя противоположными целями, при котором выигрыш в одной достигается за счет другой.
В управлении проектами компромисс возникает, например, когда заказчик требует увеличить объем работ, но не готов увеличить бюджет, и приходится искать решение, устраивающее обе стороны. Trade-off хорошо виден на сроках: чтобы сократить срок без сокращения объема, проект часто выполняют с привлечением дополнительных ресурсов, и стоимость растет. Выбор срока за счет бюджета и есть trade-off.
Любая просьба изменить одну сторону требует решения, какая из двух других сдвинется. Назовите этот выбор заказчику сразу, не дожидаясь срыва.
Построение проектного треугольника и примеры использования
Для примера взят проект по разработке мобильного приложения для доставки продуктов. Срок и бюджет в нем условные и нужны только для иллюстрации.
1. Описываем объем работ
Сначала перечисляют все работы, которые входят в проект.
- Определить требования к функциональности приложения: авторизация, просмотр каталога товаров, оформление заказа и оплата.
- Разработать дизайн интерфейса.
- Написать и протестировать программный код.
- Сделать интеграцию с платежными системами.
- Протестировать приложение на различных устройствах.
- Подготовить документацию и инструкции для пользователей.
- Выпустить приложение в RuStore и других магазинах приложений.
Оплату продуктов такое приложение принимает через подключенные платежные системы, а не через биллинг магазина: по правилам Google Play его биллинг нельзя использовать для оплаты физических товаров, в том числе продуктов, и доставки еды. Ограничения магазинов касаются платных приложений и цифровых покупок: в RuStore монетизацию могут подключить только индивидуальные предприниматели и юридические лица, а Google Play с 26 декабря 2024 года приостановил платные покупки и подписки для разработчиков с расчетным счетом в России.
2. Назначаем временные рамки
Для каждой задачи оценивают реалистичный срок, а затем строят диаграмму Ганта или PERT-диаграмму. Диаграмма Ганта показывает работы во времени, а ее полосы отмечают даты начала и окончания и зависимости между задачами. PERT-диаграмма — это сетевая модель, в которой для работ берут три оценки длительности: оптимистичную, наиболее вероятную и пессимистичную. На обеих диаграммах находят критический путь, то есть самую длинную цепочку зависимых задач, которая определяет общую длительность проекта.
Например, планируемый срок разработки приложения — 6 месяцев. В него заранее закладывают время на обучение сотрудников, подготовку ресурсов и исправление ошибок. Ключевые сроки сдачи этапов разработки определяют с учетом критического пути и зависимостей между задачами.
3. Рассчитываем бюджет
Стоимость оценивают по каждой задаче из списка работ, а затем складывают оценки задач в общий бюджет проекта. Для приложения в оценку затрат входят три основные статьи.
- оплата заработной платы разработчиков, дизайнеров, тестировщиков;
- аренда оборудования и программного обеспечения;
- маркетинговые расходы и другие издержки.
Планируемый бюджет проекта — например, 1 200 000 рублей. В него закладывают резерв на непредвиденное, то есть дополнительные деньги или время на случай, если риски наступят.
Как управлять проектным треугольником
Применение проектного треугольника сводится к двум действиям: определить приоритеты и провести каждое изменение через оценку и согласование с заказчиком. Приоритет не всегда у срока. В проекте с жестким дедлайном, как при подготовке Олимпийских игр, фиксируют время, а в проекте, где главное качество и безопасность, при необходимости подстраивают срок и стоимость. Обычно этим занимается менеджер проекта.
Что делать, когда заказчик просит ускорить проект
Допустим, клиент просит выпустить приложение для доставки продуктов раньше срока. Менеджер сначала оценивает влияние на две другие стороны: сокращение срока без сокращения объема часто ведет к росту стоимости, поэтому одной договоренностью о дате вопрос не закрыть. Затем клиенту предлагают два-три варианта на выбор: сократить объем первого релиза, увеличить бюджет на дополнительные ресурсы или перенести часть работ на следующий этап. Запрос на изменение после оценки утверждают, отклоняют или откладывают.
Роль менеджера и заинтересованных сторон
Менеджер проекта отвечает за успешную поставку проекта. Он собирает оценки по объему, времени и бюджету, показывает заказчику последствия изменений и следит за отклонениями от плана. Приоритеты согласуют с заказчиком и другими заинтересованными сторонами, то есть с лицами и группами, у которых есть интерес или роль в проекте либо на которых проект влияет. Спонсор, то есть инициатор проекта, отвечает за то, чтобы работа эффективно управлялась и достигала поставленных целей. Распределить эти роли помогает матрица ответственности.
%201.png)
Где фиксировать срок, объем и бюджет
Инструменты управления проектами для фиксации разные, а основа одна: каждую сторону записывают там, где с ней потом сверяются при изменениях. Устав проекта — это документ, который официально разрешает проект и дает менеджеру право использовать ресурсы организации; по описанию PMI, в нем указывают высокоуровневый объем, допущения и ограничения по бюджету, времени и ресурсам. Остальные документы проекта уточняют отдельные стороны.
| Сторона | Что фиксируем | Где фиксируем |
|---|---|---|
| Объем и содержание | Состав работ и высокоуровневый объем | Устав проекта и документы с требованиями |
| Время | Этапы, сроки и зависимости задач | Диаграмма Ганта |
| Бюджет и стоимость | Статьи затрат и резерв на непредвиденное | Расчет бюджета проекта |
| Качество | Критерии приемки результата | Документы с требованиями к результату |
Проектный треугольник в разных методологиях
В методологиях управления проектами проектный треугольник применяют по-разному: методология определяет, какая сторона остается жесткой, а какая гибкой. Ниже это показано на примере Waterfall, Agile, Scrum и Kanban.
Водопадный подход или Waterfall
В водопадном или каскадном подходе проектный треугольник чаще всего рассматривается как статическая модель, где объем работ, время и бюджет фиксированы на начальном этапе проекта. Изменения проходят формальное рассмотрение и согласование, а изменение объема может привести к пересмотру сроков выполнения работ или бюджета проекта.
Чтобы выполнить проект в заданные сроки и уложиться в согласованный бюджет, изменения объема после начала разработки стараются свести к минимуму.
Гибкие подходы к управлению проектами
В гибких подходах к управлению проектами проектный треугольник в Agile рассматривается как динамическая модель. Чаще всего срок и бюджет фиксируют, а объем подстраивают под доступные ресурсы. Джим Хайсмит предложил для Agile отдельную модель, Agile Triangle, где вершины — ценность, качество и ограничения (традиционные объем, сроки и стоимость).
Изменение начальных требований считается нормой, но изменение объема не бесплатно: оно меняет состав релиза, и команда решает, какие функции войдут в него, а какие уйдут позже. Для этого важно постоянно коммуницировать с заказчиком и обсуждать приоритеты задач, чтобы влиять на объем работ при зафиксированных сроках и бюджете.
Прежде чем начинать релиз, согласуйте с заказчиком, какую функцию команда готова перенести.
Scrum и Kanban
В Scrum спринт — это событие фиксированной длины не более месяца. По Scrum Guide 2020, внутри спринта качество не снижается, а объем можно уточнять и пересогласовывать с владельцем продукта по мере появления новых знаний. Поэтому в Scrum срок спринта задан заранее, а гибким остается состав работ внутри него.
В Kanban участники явно ограничивают число рабочих элементов в процессе (WIP) и берут новую работу, когда есть сигнал о свободной емкости. По Kanban Guide, цель подхода — помочь понимать trade-off и управлять риском. При этом руководство не связывает метод с проектным треугольником и не фиксирует ни срок, ни бюджет: ограничение WIP управляет потоком работ.
FAQ по проектному треугольнику
Чем дополнить или заменить проектный треугольник?
Треугольник можно дополнить целями, которых в нем нет. В методе управления проектами PRINCE2 7, по сообщению PeopleCert, цели проекта включают время, стоимость, риск, выгоды, содержание, качество и устойчивость. Такой набор позволяет оценивать проект шире трех базовых сторон и видеть, например, риски и выгоды.
Что такое scope change и change freeze?
В глоссарии APM scope change — это любое изменение содержания проекта, которое требует изменить стоимость или срок. Момент, после которого новые изменения объема больше не рассматриваются, называют change freeze, или заморозкой изменений.
Почему модель называют треугольником Барнса?
По сообщению APM, классический треугольник время, стоимость и качество придумал Мартин Барнс, поэтому его называют треугольником Барнса или железным треугольником.
Коротко о главном
- Проектный треугольник связывает объем работ, время и бюджет: при изменении любой стороны хотя бы одна из двух других, скорее всего, тоже изменится.
- В базовой модели качество не вынесено в отдельную сторону и зависит от баланса трех, поэтому критерии приемки согласуют заранее и отдельно.
- Управлять треугольником значит выбрать гибкую сторону, провести изменения через согласование с заказчиком и записать решение.
- В Waterfall стороны фиксируют на старте, в Agile и Scrum чаще гибким остается объем, а Kanban ограничивает число задач в работе.
- Модель упрощает проект, поэтому ее дополняют рисками, критериями качества и ценностью для бизнеса.
.png)
.png)
Комментарии (1)
Оставить комментарий