что такое проектный треугольник
Разработчик в треугольнике управления проектами
Излагаются два подхода, которые потенциально позволяют дать объективную оценку, на сколько работа разработчика на проекте удовлетворяет требованиям качества, сроков и бюджета.
Управление проектом — это организация процесса по успешному, т. е. за отведённое время и без превышения выделенного бюджета, достижению поставленной цели. Конечный продукт при этом должен обладать заданными изначально свойствами и быть приемлемого качества.
Во многих случаях приходится искать баланс между ограничениями по времени, затратам и содержанием проекта. Очень наглядной иллюстрацией является проектный треугольник, (картинка поскольку три стороны треугольника связаны, и изменение одной стороны влияет, по крайней мере, на одну из двух других сторон, демонстрируя процесс балансировки ограничений).
В качестве примера можно рассмотреть ситуацию, когда требуется сократить срок сдачи проекта. Для этого может понадобиться увеличить бюджет и использовать больше ресурсов, с помощью которых тот же объем работы будет выполнен за меньшее время. Если же увеличение бюджета недопустимо, необходимо уменьшить содержание проекта, поскольку с наличными ресурсам нет возможности выполнить весь запланированный объем работ за меньшее время.
Создание, за отведённое время и в рамках заданного бюджета, качественного программного обеспечения, которое удовлетворяет реальным потребностям заказчика — это процесс, который можно и нужно описывать на языке управления проектами. Разработчик — одна из ключевых ролей в этом процессе. Мне кажется, принципиально возможно оценить профессионализм девелопера, если систематически оценивать результаты его работы с позиции того, насколько они соответствуют тройственной ограниченности.
В идеале каждая задача, которая поставлена разработчику, должна быть решена так, чтобы:
Естественно, что накладываемые ограничения должны быть адекватными, как с точки зрения общепринятых норм, так и относительно возможностей самого разработчика. (Но обсуждение этого вопроса выходит за рамки данной статьи, а по умолчанию мы считаем, что каждая задача, по решению которой оценивается профессионализм разработчика, является корректной поставленной и не имеющей чрезвычайно завышенных требований).
Зачем это нам нужно?
Но формирование таких критериев требует сильной формализации в описании процесса разработки. К текущему моменту у нас намечается два пути. Они различаются в подходах к двум из трёх сторон треугольника управления проектом: срокам и бюджету. Прежде чем перейти к этим различиям, очень кратко опишем идею нашего подхода к оценке качества.
В дополнение к стандартным методам QA, предполагается получать метрики качества кода с помощью статических анализаторов типа SonarQube. Думаю, что эти данные вполне можно соотнести с результатами работы каждого разработчика в проекте, а также оценивать любые части проекта и проект в целом. Возможно, что дополнительным параметром, оценивающим качество труда разработчика будет отношение времени потраченного на решение поставленной задачи к времени, потраченному на исправление относящихся к этой задачи багов.
Теперь о двух возможных подходах к деньгам и ко времени
Первый взгляд на эту проблему исходит из того, что далеко не в каждом случае можно рассчитывать на наличие всех исходных данных. В целом для расчёта показателей, относящихся к попаданию в сроки, необходимы:
Относительно бюджетных характеристик этот подход рассматривает три варианта проектов с точки зрения подхода к ценообразованию:
В связи со всем изложенным выше, возникает несколько естественных вопросов:
Во-первых, какой из двух подходов, на ваш взгляд, лучше описывает профессионализм разработчика в контексте попадания в сроки/бюджет/качество? И какие варианты, кроме проектного треугольника, можно было бы использовать?
Во-вторых, хотелось бы понять, можно ли соотнести бюджеты в деньгах с эстимейтами и реально потраченными часами в задачах? Что такое сроки и относятся ли они к эстимейтам или же к Start date и Due Date?
Возможно ли учесть различия в проектах с точки зрения подхода к ценообразованию (fixed cost, time and material, другие варианты) при расчёте бюджетной метрики для конкретного разработчика, или для него имеет смысл только fixed cost подход?
В-третьих, интересно, насколько корректно использовать модель, которая иллюстрирует объективные ограничения, возникающие при управлении проектами, для количественного описания профессионализма разработчика?
Буду рад услышать ваше мнение на этот счет!
Что нужно сделать до старта проекта? Часть 3. Ограничения проекта
В первой статье этого цикла речь шла о формулировании целей проекта, результатов проекта и сбору требований к ним, как необходимому шагу для снижения неопределенности проекта. Вторая статья цикла посвящена формулированию допущений по проекту и переходу от допущений к рискам, которые надо будет учесть при планировании сроков и бюджета проекта.
Для того чтобы перейти к подписанию документов, подтверждающих официальное признание проекта, нужно сделать еще один важный шаг – сформулировать ограничения по проекту.
В управлении проектами используется термин «проектный треугольник», для которого используют также название «тройное ограничение проекта». Проектный треугольник описывает взаимодействие ключевых ограничений проекта:
Самую большую сложность представляет интерпретация ограничения по качеству. Качество чего имеется в вид у?
Применительно к проекту можно рассуждать о качестве проекта и о качестве результатов проекта. Определение качества, которое использую я, следующее:
Качество – это степень соответствия результата требованиям к нему.
Когда мы говорим о качестве результатов проекта, то его можно проверить, сравнив то, что получилось сделать по результатам проекта, с тем, что требовалось получить (грубо говоря, сравнив продукт проекта с требованиями к нему).
Таким образом, качество результатов проекта тесно связано с содержанием проекта, в котором описаны требования к результатам.
Логика формирования ограничений по проекту следующая:
Как работает проектный треугольник?
Так как неопределенность в проекте велика, то и наши расчеты имеют некоторую степень достоверности. Если мы при сборе требований не учли важные требования – это приведет к появлению новых работ в содержании проекта, сторона треугольника «Содержание» станет длиннее. Сбалансировать ее можно, либо увеличив сторону треугольника «бюджет», либо увеличив сторону «срок», либо увеличив обе эти стороны треугольника.
Таким образом, если меняется одна из сторон треугольника, руководителю проекта и заказчику приходится балансировать две другие стороны треугольника.
Понимая, как работает проектный треугольник, руководитель проекта и заказчик могут договориться о приоритетах: что важнее для проекта – срок, содержание, качество или бюджет.
Многие из вас уже видели похожие картинки:
Если заказчик настаивает на том, что должны быть реализованы все цели проекта и при этом выполнены все требования к результатам, то желательно, чтобы к моменту старта проекта эти требования уже были собраны и утверждены заказчиком. Тогда руководитель проекта под требования может просчитать бюджет и срок. При этом заказчик проекта должен отдавать себе отчет в том, что если по ходу проекта он захочет изменить или добавить требования, то срок или бюджет проекта придется изменять (а может быть, и то, и другое).
Если заказчик пытается на старте проекта зафиксировать все три параметра проектного треугольника, то он пытается передать руководителю проекта все риски, связанные с изменениями в проекте. Как реагирует на такое поведение заказчика мудрый руководитель проекта? Он закладывает резервы времени и денег на изменения (иногда резервы могут быть очень существенными, например, равными 100% от расчетных значений сроков или бюджета).
Какие еще типы ограничений могут быть?
В PMBOK содержится мнение, что к четырем ограничениям, описанным в проектном треугольнике, нужно еще добавлять ограничения по ресурсам и рискам. В результате получается шестигранник ограничений:
Какова логика встраивания рисков в ограничения? В PMBOK дается следующее объяснение: «Изменение требований к проекту или целей проекта может вызвать дополнительные риски». Риски, в свою очередь, могут повлиять на содержание проекта, сроки или бюджет проекта.
Ограничения по ресурсам оказывают самое сильное влияние на сроки выполнения работ, но могут повлиять и на бюджет проекта.
Стоит ли использовать подход PMBOK к ограничениям, определяя шесть типов ограничений, или достаточно определить три типа ограничений (содержание, срок и бюджет) – решать руководителю проекта. Я в большинстве проектов оперирую только тремя самыми важными ограничениями, которые описываю в документе Устав проекта.
Успешность проекта
По выполнению проекта в рамках его ограничений судят об успехе проекта.
Например, при достижении всех целей проекта в срок и в бюджет проект будет признан успешным. В PMBOK считается, что «успех проекта должен связываться с последними базовыми планами, одобренными уполномоченными заинтересованными сторонами». Это значит, что если базовые сроки или бюджет несколько раз по ходу проекта пересматривались и согласовывались заказчиком проекта, то измерение успешности проекта будет делаться относительно последнего согласованного заказчиком срока и бюджета.
Итак, критерием успешности проекта является реализация всех запланированных результатов проекта, причем в срок и в бюджет.
Шаги по подготовке проекта к старту следующие:
Если у вас есть вопросы и комментарии по теме ограничений проекта, давайте обсуждать. И удачи вам в реализации проектов!
Проектный треугольник
«Вы можете иметь это хорошее, быстрое или дешевые. Выберите два».
Инженеры много лет говорят об этом руководителям проектов.
В разных терминах каждый проект имеет «треугольник» времени,денег и области охвата. Изменить один из них, не затроня хотя бы один из других, невозможно. Задача руководителя проекта — следить за тем, чтобы треугольник не распался.
Процедура Во-первых, когда возникает проблема, найдите ее в треугольнике проекта: имеет ли он время (расписание), деньги (бюджет) или область? Затем выясните, какие стороны треугольника можно изменить, а какие — фиксированные. В-третьих, устраив проблему и оптимизируйте проект. В-четвертых, завершите проект и отпразднуйте его!
В этой статье
Time + money + scope = quality
Треугольник проекта также называется «утюговом треугольником» и (менее широкое название — тройной ограничением). Это одно и то же: невозможно изменить бюджет, расписание или область проекта, не влияя на хотя бы одну из других частей.
Вот некоторые примеры того, как это работает:
Чтобы привлечь дата окончания (времени), вы можете потратить больше ресурсов (денег), чтобы быстрее завершить работу или урезать функции (область), чтобы меньше работы необходимо сделать до нового крайнего срока.
Чтобы завершить проект в рамках бюджета (затрат), можно избавиться от сверхурочных и завершить проект позднее (время) или срезать компонентов (область действия).
Чтобы добавить функции в продукт (область), вы можете продлить крайний срок, чтобы уложить время на новую работу (время) или добавить людей для ее более быстрого выполнения (затраты). Вы также можете сделать и то, и другое!
Качество — это четвертая часть треугольника проекта. Оно расположено в центре, где любое изменение любой стороны влияет на его.
Например, если вы опережаете расписание, вы можете заменить функции вырезания или дать больше времени существующим задачам. Благодаря этому дополнительному времени и области результат может быть лучше.
Один из ключевых моментов: универсальный стандарт качества не существует. Для любого проекта качество определяется в самом проекте. Для некоторых компаний самой важной мерой качества является сохранение проекта в бюджете. Для других людей выход на рынок вовремя имеет больше значения. Руководитель проекта должен знать, как определяется качество для организации и конкретного проекта.
В предыдущем примере можно было просто завершить работу с продуктом раньше с большим количеством функций, чтобы он был раньше конкурентов. Это может быть определение качества для этого проекта в вашей компании.
Что нельзя изменить
В большинстве проектов по крайней мере одна сторона треугольника фиксирована. Изменить его нельзя.
Возможно, бюджет не подлежит обсуждению. (Похоже, вы знакомы?) Или, возможно, продукт должен выйти в продажу к определенной дате. Возможно, и то, и другое верно.
Часто фиксированные элементы проекта продиктуются руководителем проекта, но не всегда. Иногда решение о том, какой элемент является самым важным для успеха проекта, зависит от вашего плеча. И вам нужно быть понятным, если возникают проблемы (и они всегда возникают).
Когда проблема возникает на стороне исправлений, действовать не всегда достаточно. Например, если вы обнаружите, что разработка функции программного обеспечения займет больше времени, чем прогнозировался, и вы подписали контракт, в который будет добавлена эта функция (область), необходимо либо перенести дату окончания, либо добавить ресурсы, чтобы завершить ее вовремя.
Если стороны с исправлением и проблемойразные, не сдайте их. В этом и есть прелесть треугольника проекта. всегда есть место для внесения изменений. Например, если проект должен завершиться вовремя и он получил масштаб, вы все равно можете скорректировать затраты, добавив ресурсы.
Если все три стороны треугольниказависли, не стоит волнуйтесь. Возможно, у проекта возникли проблемы, но вы знаете, что у вас возникли проблемы, и у вас есть хорошая отправная точка для пересмотра целей проекта или стандартов качества.
Оптимизация расписания
Тем не менее вы столкнулись с проектом, который настроен на превышение крайнего срока.
Чтобы сократить расписание, можно сократить критический путь задачи, последняя задача которой завершается в дату окончания проекта. Изменение других задач может не сократить календарный план, но изменение задач критического пути будет выполняться. Чтобы сократить критический путь, вы можете:
Сократите длительность задачи (уменьшите область действия или добавьте ресурсы).
«Быстрое отслеживание» расписания: перекрытие задач, чтобы люди могли работать над ними одновременно (добавить ресурсы). Эту прием лучше использовать ближе к началу проекта.
«Аварийное выполнение» расписания: добавление ресурсов для ускорения выполнения задач (деньги).
Удаление задач (сокращение области действия).
Конечно, такое исправление расписания может существенно сказаться на бюджете, области и качестве проекта.
Оптимизация бюджета
В большинстве проектов наибольший фрагмент бюджета состоит из затрат на ресурсы: затраты на ресурсы с учетом ставок и фиксированные затраты на людей, оборудование и материалы. Для работы с бюджетом может потребоваться очень сложное решение.
Сократите область проекта, чтобы сократить количество задач, для выполнения которые требуются ресурсы.
Убедитесь, что подходят тарифы, сборы и сверхурочные.
Убедитесь, что ресурсы лучше всего подходят для работы.
Замените дорогой ресурс на более дорогой.
Контроль над затратами может привести к отключению крайнего срока или необходимости сократить масштаб проекта. Например, если для задач не разрешается сверхурочные работы, дата окончания может быть позже на месяц. Если же вы обрезали область, дата окончания может фактически переместиться в нее.
Оптимизация области
Можно ли сэкономить деньги, сделав мост на несколько футов короче его реки? Конечно, нет. Иногда область проекта не может измениться, поэтому вам придется принять другие меры:
Добавьте ресурсы, чтобы убедиться, что все задачи завершены (затраты).
Вырезание задач, которые не находятся на критическом пути (при их стоимости).
Добавление задач или добавление длительности к задачам (затратам).
Продлите крайний срок, чтобы разрешить время для всех задач с текущим уровнем ресурсов (времени).
Например, проект можно завершить быстрее за счет увеличения бюджета или сокращения объема работ. Точно так же увеличение объема может потребовать эквивалентного увеличения бюджета и графика. Сокращение бюджета без корректировки графика или объема приведет к снижению качества.
«Хорошо, быстро, дешево. Выбери два». и аналогичные операторы часто используются для краткой инкапсуляции ограничений треугольника.
Однако на практике торговля между ограничениями не всегда возможна. Например, вложение денег (и людей) в полностью укомплектованный проект может замедлить его. Более того, в плохо выполняемых проектах часто невозможно улучшить бюджет, график или объем без ущерба для качества.
Треугольник управления проектами используется для анализа проектов. Его часто неправильно используют для определения успеха как выполнения требуемого объема работ с разумным качеством в рамках установленного бюджета и графика. Треугольник управления проектом считается недостаточным в качестве модели успеха проекта, поскольку он не учитывает важнейшие аспекты успеха, включая влияние на заинтересованные стороны, обучение и удовлетворенность пользователей.
СОДЕРЖАНИЕ
Обзор
Ограничение по времени относится к количеству времени, доступному для завершения проекта. Ограничение по стоимости относится к бюджетной сумме, доступной для проекта. Ограничение объема относится к тому, что должно быть сделано для достижения конечного результата проекта. Эти три ограничения часто являются конкурирующими: увеличение объема обычно означает увеличение времени и затрат, жесткое ограничение по времени может означать увеличение затрат и сокращение объема, а ограниченный бюджет может означать увеличение времени и сокращение объема.
Дисциплина управления проектами заключается в предоставлении инструментов и методов, которые позволяют команде проекта (а не только менеджеру проекта ) организовать свою работу в соответствии с этими ограничениями.
Джеймс П. Льюис предполагает, что объем проекта представляет собой площадь треугольника и может быть выбран в качестве переменной для достижения успеха проекта. Он называет эту взаимосвязь PCTS (производительность, стоимость, время, объем) и предлагает проекту выбрать любые три.
Модель STR
Объем = Время × Ресурсы
Объем относится к сложности (что также может означать качество). Ресурсы включают людей (рабочих), финансовые и физические. Обратите внимание, что эти значения не считаются неограниченными. Например, если один пекарь может испечь буханку хлеба за час в духовке, это не значит, что десять пекарей могут испечь десять буханок за один час в одной и той же духовке (из-за ее вместимости). Девять женщин не могут родить за один месяц.
Темы треугольника управления проектами
Время
Задачи также распределяются по приоритетам, определяются зависимости между задачами, и эта информация документируется в расписании проекта. Зависимости между задачами могут повлиять на продолжительность всего проекта (с ограничениями по зависимостям), как и на доступность ресурсов (с ограничениями по ресурсам). Время отличается от всех других ресурсов и категорий затрат.
Использование фактической стоимости предыдущих аналогичных проектов в качестве основы для оценки стоимости текущего проекта.
Согласно Своду знаний по управлению проектами (PMBOK), процессы управления сроками проекта включают в себя:
Определить действия
Последовательность действий
Оценка ресурса деятельности
Оценка продолжительности деятельности
График разработки
Контроль расписания
Из-за сложного характера группы процессов «Время» были созданы учетные данные для управления проектами PMI Scheduling Professional (PMI-SP).
Расходы
Области затратного процесса
Инструменты оценки затрат на управление проектом
Программное обеспечение для управления проектами можно использовать для расчета отклонений стоимости проекта.
Сфера
Требования, указанные для достижения конечного результата. Общее определение того, что должен выполнить проект, и конкретное описание того, каким должен быть конечный результат. Основным компонентом объема работ является качество конечного продукта. Количество времени, затраченного на выполнение отдельных задач, определяет общее качество проекта. Некоторые задачи могут потребовать определенного количества времени для адекватного завершения, но большее время может быть выполнено в исключительных случаях. В ходе большого проекта качество может существенно повлиять на время и стоимость (или наоборот).
Вместе эти три ограничения породили фразу «вовремя, по спецификации, по бюджету». В этом случае термин «область действия» заменяется на «спецификацию».
Эволюция модели ограничений проекта
Традиционно модель ограничений проекта признавала три ключевых ограничения; «Стоимость», «Время» и «Объем». Эти ограничения образуют треугольник с геометрическими пропорциями, иллюстрирующий сильную взаимозависимую связь между этими факторами. Если есть требование изменить какой-либо из этих факторов, то по крайней мере, один из других факторов также должен быть изменен.
Такое широкое использование вариаций подразумевает уровень двусмысленности, связанный с нюансом третьего ограничивающего члена, и, конечно же, уровень ценности гибкости модели треугольника. Эта неоднозначность позволяет размыть фокус между результатами проекта и процессом проекта, при этом приведенные выше примеры терминов имеют потенциально разный импульс в двух контекстах. И «Стоимость», и «Время» / «Доставка» представляют собой затраты проекта верхнего уровня.
Модель «Project Diamond» порождает этот размытый фокус за счет включения «объема» и «качества» отдельно в качестве «третьего» ограничения. Несмотря на то, что добавление «качества» в качестве ключевого сдерживающего фактора, признавая растущую зрелость управления проектами, имеет свои достоинства, этой модели все еще не хватает ясности между результатами и процессом. Однако алмазная модель не отражает аналогию с сильной взаимосвязью между точками треугольников.
PMBOK 4.0 предлагает усовершенствованную модель, основанную на тройном ограничении, с 6 факторами, которые необходимо отслеживать и управлять. Это проиллюстрировано в виде шестиконечной звезды, которая поддерживает силу аналогии с треугольником (два наложенных треугольника), и в то же время представляет разделение и взаимосвязь между факторами входов / выходов проекта в одном треугольнике и факторами процессов проекта в другом. Звездные переменные:
При рассмотрении двусмысленности третьего ограничения и предложений «Проекта Бриллиант»; Вместо этого можно рассматривать цель или продукт проекта как третье ограничение, состоящее из подфакторов «Объем» и «Качество». Что касается результатов проекта, то и «Объем», и «Качество» могут быть скорректированы, что приведет к общему изменению цели / продукта. Эта интерпретация включает четыре ключевых фактора в исходной треугольной форме входов / выходов. Это может быть даже включено в PMBOK Star, демонстрируя, что «Качество», в частности, может контролироваться отдельно с точки зрения результатов проекта и процесса. В дополнение к этому предложению, использование термина «Цель» может лучше всего отражать результаты инициативы по изменению, в то время как «Продукт» может лучше всего представлять более ощутимые результаты.