Что такое проектный треугольник

Проектный треугольник

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

Рисунок 1.1 – Проектный треугольник

Например, если вы решите изменить план проекта, укоротив расписание, то возрастёт стоимость проекта (если вы решите привлечь дополнительных работников) или уменьшится объём работ. Если же изменить план проекта с целью уменьшения его бюджета, то может возрасти длительность проекта и уменьшиться объём работ. Наконец, если вы увеличите объём работ, то проект будет длиться дольше и стоить дороже.

То, как изменения в плане влияют на другие стороны треугольника, зависит от обстоятельств и специфики проекта. В некоторых случаях уменьшение расписания увеличивает стоимость, а в других – уменьшает.

При создании плана вы можете столкнуться с тем, что план не удовлетворяет ожиданиям, например, проект заканчивается слишком поздно или его стоимость превышает допустимые пределы. В таком случае план нужно оптимизировать, чтобы привести его в соответствие ожиданиям.

Когда вы начинаете оптимизировать план, постоянно помните обо всех элементах треугольника и о том, что когда вы изменяете одну из сторон, это затрагивает две другие – позитивно или негативно, в зависимости от вашего проекта. И проверяйте два других элемента треугольника, чтобы быть уверенными, что изменения не делают план невыполнимым. Например, если вы изменили свой план с целью уменьшить расходы, проверьте, что дата окончания проекта все ещё находится в допустимых пределах.

Качество, четвертый элемент проектного треугольника, находится в его центре, и изменения, вносимые в любую из сторон треугольника, практически всегда влияют на качество. Качество не является стороной треугольника – это результат того, что вы делаете со временем, деньгами и объёмом работ.

Например, если вы нашли лишнее время в расписании, то можете увеличить объём работ, добавив задачи и увеличив длительность проекта. С этими дополнительными задачами и временем вы сможете добиться более высокого уровня качества в проекте и произведённом продукте или услуге.

Если же вы хотите понизить расходы, чтобы уложиться в бюджет, возможно, вам понадобится уменьшить объём работ, убрав некоторые из задач или уменьшив их длительность. С уменьшенным объёмом работ у проекта будет меньше шансов выйти на требуемый уровень качества, поэтому снижение расходов может привести к ухудшению качества проекта.

Планирование проекта в ms Project

Составление плана проекта в общем виде заключается в описании задач проекта, доступных ресурсов и определении взаимосвязей между ними с помощью назначений. Но при составлении плана проекта в MS Project количество операций несколько увеличивается.

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

Способ планирования и основные даты. Проект можно планировать двумя способами: от даты начала проекта или от даты окончания. Если у проекта нет жесткой даты окончания, то при планировании применяется первый способ: фиксируется дата, когда нужно начать проект, и во время составления плана определяется, когда проект может быть завершен.

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

Последовательность работ. Для создания уникального продукта или услуги (результата проекта) нужно осуществить некоторую последовательность работ. Задача планирования проекта заключается в том, чтобы достаточно точно оценить сроки исполнения и стоимость этих работ. Чем точнее дана оценка, тем выше качество плана проекта.

Чтобы дать точную оценку, нужно хорошо представлять состав работ проекта, то есть знать, какие именно работы нужно выполнить для получения его результата. Только после того, как составлен список проектных работ, оценивается длительность каждой из них и выделяются ресурсы, необходимые для их выполнения. И лишь затем можно оценить стоимость и сроки исполнения каждой задачи и, в результате сложения, общую стоимость и срок проекта. Вот почему определение состава работ является первым шагом при планировании проекта.

Определение состава проектных работ начинается с определения этапов (или фаз) проекта. Например, в проекте Издание номера журнала могут быть выделены фазы Планирование номера, Подготовка материалов, Верстка и Предпечатная подготовка.

После того как состав фаз и их результаты определены, нужно определить последовательность этих фаз относительно друг друга и крайние сроки их исполнения. Затем нужно определить, из каких работ состоят фазы, в какой последовательности исполняются эти работы и в какие крайние сроки нужно уложиться при их исполнении. То есть принципы планирования задач внутри фаз повторяют принципы планирования фаз внутри проекта.

Определять состав работ удобно в несколько шагов. Сначала создаётся скелет плана работ, состоящий из фаз, их результатов и нескольких основных задач. Потом в план добавляются остальные задачи, определяются их длительности и связи. Затем определяются ключевые даты проекта, устанавливающие крайние сроки достижения результатов проекта и другие ограничения по времени. Наконец, в план добавляется дополнительная информация о задачах.

Связь между двумя задачами определяет, каким образом время начала или завершения одной задачи влияет на время начала или завершения другой. Например, Окончательная сборка номера журнала может начаться только тогда, когда выполнена задача Обложка готова.

Задача, влияющая на другую, называется Предшественник, а задача, зависящая от другой, называется Последователь. Например, Обложка готова является предшествующей задачей, а Окончательная сборка – последующей.

Одна связь может объединять только две задачи, и при этом у одной задачи может быть несколько связей с другими задачами. Например, Окончательная сборка может начаться только после выполнения задач Обложка готова и Подготовка оглавления. Задача может иметь неограниченное число предшествующих и последующих задач.

Связи могут объединять и фазы, поэтому все принципы организации связей между задачами применимы и к фазам. При этом связи могут объединять между собой и задачи, и фазы, например, фаза может начинаться по завершении задачи.

Типы связей задач. В MS Project есть четыре типа связей между задачами. Связь типа Окончание-начало (Finish—to—start), или сокращённо ОН (FS), – наиболее распространенный тип зависимости между задачами, при которой задача В не может начаться, пока не завершена задача А:

Связь типа Начало-начало (Start—to—start), или сокращённо НН (SS), обозначает зависимость, при которой задача В не может начаться до тех пор, пока не началась задача А. Например, Техническое редактирование не может начаться раньше, чем Редактирование материалов, но и для того, чтобы начать Техническое редактирование, не обязательно дожидаться окончания Редактирования материалов. С помощью такой связи обычно объединяются задачи, которые должны выполняться почти одновременно.

Связь типа Окончание-окончание (Finish—to—Finish), или сокращённо ОО (FF), обозначает зависимость, при которой задача В не может закончиться до тех пор, пока не закончилась задача А. Обычно такой связью объединяются задачи, которые должны выполняться почти одновременно, но при этом одна не может закончиться, пока не завершена другая. Например, сдача-приёмка программы идет одновременно с исправлением ошибок (найдённых в процессе сдачи-приёмки), и пока исправление ошибок не завершено, сдача-приёмка тоже не может завершиться.

Связь типа Начало-окончание (Start—to—Finish), или сокращённо НО (SF), обозначает зависимость, при которой задача В не может закончиться до тех пор, пока не началась задача А. Обычно такая связь используется в том случае, когда А является задачей с фиксированной датой начала, которую нельзя изменить. В таком случае дата начала последующей задачи не изменяется при увеличении длительности предшествующей.

Связь можно создавать перетаскиванием мыши с одного отрезка диаграммы Ганта на другой, при этом по умолчанию тип связи определяется как ОН (FS). Предшествующей задачей считается та, с которой началось перетаскивание, а последующей та, на которой перетаскивание закончилось (на последующую задачу указывает стрелка в конце связи). Для удаления связи или изменения её типа нужно дважды щёлкнуть на диаграмме и произвести соответствующие операции в открывшемся диалоговом окне.

Часто в жизни зависимости между задачами бывают немного более сложными, чем Окончание-начало (Finish-to-start). Например, между задачей «Покраска стен» и «Развешивание картин» должен пройти день, чтобы краска успела высохнуть. Для того чтобы описать такую зависимость между задачами, в MS Project используется параметр Запаздывание (Lag). Например, в случае с покраской стен запаздывание между задачами должно составить 1 день.

Запаздывание является свойством связи и может быть указано в диалоговом окне определения свойств связи. Запаздывание можно вводить как длительность (например, 1 день) или как процент от длительности предшествующей задачи. Например, если предшествующая задача продолжается 4 дня, то запаздывание в 25% будет равняться 1 дню.

Иногда для начала выполнения следующей задачи не нужно дожидаться полного окончания предыдущей. Например, можно начинать клеить обои, когда штукатурка положена хотя бы на некоторых стенах в доме. В таком случае следует использовать Опережение (Lead). Опережение вводится так же, как и запаздывание, но с отрицательным знаком, например опережение в 1 день указывается как -1д, а опережение в 50% (то есть следующая задача начинается, когда предыдущая выполнена наполовину) – как -50%.

Разработчик в треугольнике управления проектами

Излагаются два подхода, которые потенциально позволяют дать объективную оценку, на сколько работа разработчика на проекте удовлетворяет требованиям качества, сроков и бюджета.

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

Во многих случаях приходится искать баланс между ограничениями по времени, затратам и содержанием проекта. Очень наглядной иллюстрацией является проектный треугольник, (картинка поскольку три стороны треугольника связаны, и изменение одной стороны влияет, по крайней мере, на одну из двух других сторон, демонстрируя процесс балансировки ограничений).

В качестве примера можно рассмотреть ситуацию, когда требуется сократить срок сдачи проекта. Для этого может понадобиться увеличить бюджет и использовать больше ресурсов, с помощью которых тот же объем работы будет выполнен за меньшее время. Если же увеличение бюджета недопустимо, необходимо уменьшить содержание проекта, поскольку с наличными ресурсам нет возможности выполнить весь запланированный объем работ за меньшее время.

Создание, за отведённое время и в рамках заданного бюджета, качественного программного обеспечения, которое удовлетворяет реальным потребностям заказчика — это процесс, который можно и нужно описывать на языке управления проектами. Разработчик — одна из ключевых ролей в этом процессе. Мне кажется, принципиально возможно оценить профессионализм девелопера, если систематически оценивать результаты его работы с позиции того, насколько они соответствуют тройственной ограниченности.

В идеале каждая задача, которая поставлена разработчику, должна быть решена так, чтобы:

1. время работы не превышало времени предварительной оценки длительности этой работы,
2. качество кода удовлетворяло заранее определенным критериям и стандартам,
3. стоимость решения этой задачи не выходила за рамки выделенной для неё части бюджета.

Естественно, что накладываемые ограничения должны быть адекватными, как с точки зрения общепринятых норм, так и относительно возможностей самого разработчика. (Но обсуждение этого вопроса выходит за рамки данной статьи, а по умолчанию мы считаем, что каждая задача, по решению которой оценивается профессионализм разработчика, является корректной поставленной и не имеющей чрезвычайно завышенных требований).

Зачем это нам нужно?

1. Повышение эффективности работы HR.
   Объективные, насколько это вообще возможно, критерии профессионализма разработчиков могли бы, к примеру, помочь HR-менеджеру, подобрать для конкретного проекта исполнителей, которые наилучшим образом соответствуют предъявляемым к данному проекту требованиям. Сами разработчики, имея возможность объективного сравнения своих способностей со способностями своих коллег, могли бы яснее осознавать те качества, над которыми им следует работать, чтобы увеличить спрос на свой труд, и повысить свой рейт.
2. Довольный заказчик.
   Кроме того, внедрение использования объективных критериев профессионализма выгодно и заказчику, поскольку с его точки зрения это повышает качество управления материальными и трудовыми ресурсами, повышая тем самым общее качество управления бизнесом.
3. Небольшие затраты, относительно ожидаемого эффекта.
   Цена, которую придётся заплатить, не слишком обременительна: повышение требования к дисциплине и аккуратный сбор и обработка данных.

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

В дополнение к стандартным методам QA, предполагается получать метрики качества кода с помощью статических анализаторов типа SonarQube. Думаю, что эти данные вполне можно соотнести с результатами работы каждого разработчика в проекте, а также оценивать любые части проекта и проект в целом. Возможно, что дополнительным параметром, оценивающим качество труда разработчика будет отношение времени потраченного на решение поставленной задачи к времени, потраченному на исправление относящихся к этой задачи багов.

Теперь о двух возможных подходах к деньгам и ко времени

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

• оценка задачи в часах того разработчика, который будет ей заниматься (предварительно согласованная с самим разработчиком);
• данные о том, сколько часов реально было потрачено на эту задачу (для этого необходим тайм-трекер);
• срок, due date, к которому задача должна быть готова.

Относительно бюджетных характеристик этот подход рассматривает три варианта проектов с точки зрения подхода к ценообразованию:

1. Fixed cost проект не предполагает отклонения от бюджетных характеристик в принципе.
2. Time and Material проект означает, что стоимость линейно связана с затраченными часами, из чего следует, что отклонению от бюджета тождественно отклонению от сроков. Таким образом, в этих вариантах фактически отсутствуют бюджетные метрики.
3. При нестрогом же fixed cost проекте, в котором есть возможность согласовывать изменения бюджета, потенциально не ясно, какую часть изменения в бюджете следует отнести к «заслуге» конкретного разработчика. В целом, этот подход означает, что в треугольнике управления проектом для отдельного разработчика показатели бюджета адекватно отобразить невозможно, и остаются лишь метрики качества/сроков.

В связи со всем изложенным выше, возникает несколько естественных вопросов:

Во-первых, какой из двух подходов, на ваш взгляд, лучше описывает профессионализм разработчика в контексте попадания в сроки/бюджет/качество? И какие варианты, кроме проектного треугольника, можно было бы использовать?

Во-вторых, хотелось бы понять, можно ли соотнести бюджеты в деньгах с эстимейтами и реально потраченными часами в задачах? Что такое сроки и относятся ли они к эстимейтам или же к Start date и Due Date?

Возможно ли учесть различия в проектах с точки зрения подхода к ценообразованию (fixed cost, time and material, другие варианты) при расчёте бюджетной метрики для конкретного разработчика, или для него имеет смысл только fixed cost подход?

В-третьих, интересно, насколько корректно использовать модель, которая иллюстрирует объективные ограничения, возникающие при управлении проектами, для количественного описания профессионализма разработчика?

Про управление проектами и продуктами

Проект, продукт, процесс — эти три “П” являются краеугольным камнем в вопросах управления целенаправленной деятельности людей. Недавно меня попросили прочитать вступительную лекцию к курсу по управлению проектами и … я согласился. Согласился потому, что у меня есть релевантный опыт работы над улучшением бизнес-процессов, работы над проектами, а теперь и над продуктами, которые и формируют вид экосистемы Tinkoff для конечных пользователей. Эта статья является расшифровкой данного выступления.

Краткое содержание

В рамках этой статьи мы

• Обсудим что является проектом, а что нет
• Рассмотрим разные подходы к управлению проектам (PMI, IMPA, …)
• Посмотрим на стандартный проект
• Сравним проекты, программы и портфели проектов
• Обсудим что делать будучи в проекте/продукте, чтобы достичь поставленных целей
• В конце будут ссылки на дополнительные ресурсы

Начнем с основ, а именно

Что является проектом, а что нет

Существует большое количество определений для термина “проект”, но общепринятым можно считать то, что приведено в PMBoK (Project Management Body of Knowledge) от Project Management Institute

Project is a temporary endeavor undertaken to create a unique product, service or result.

Из этого определения сразу видны ключевые характеристики проекта, а именно:

• Уникальность продукта или сервиса (функциональность)
• Ограничение по времени (сроки)
• Ограничение по ресурсам, которые так или иначе конвертируются в деньги (стоимость)

Эти ключевые характеристики можно изобразить графически в виде треугольника ограничений.

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

Product

Для продукта такого канонического определения нет, но мне понравилось описание, которое приведено в статье What’s the difference between a product and a project?

A product is designed to continually create value for customers by solving their problems. Products have more permanence, are living entities which we deliver quickly, iterate constantly, and are not something that we just walk away from.

В итоге, ключевыми характеристиками продукта являются следующие

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

Продуктовое мышление применяет эти принципы широко и не ограничивается только продуктами, которые продаются конечным пользователям.

Сравнение проектов и продуктов приведено ниже

Для проектов мы рисовали треугольник ограничений. Для современной продуктовой разработки он тоже существует, но он перевернут. Суть в том, что в обычном проектном подходе фиксируется функционал и зачастую сроки — это приводит к тому, что плывет бюджет. В продуктовой разработке зафиксированы сроки, например, размером спринта и стоимость, например, размером команды — это приводит к тому, что варьируется объем функционала, который поставляется этой командой за время спринта

Теперь перейдем к сравнению проектов с операционной деятельностью.

Operations

Операционную деятельность или процессную можно определить так

Operations are the ongoing execution of activities and they follow an organization’s procedures to produce the same result or a repetitive service. Operations are permanent in nature.

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

Сравнение Product, Project, Operations

Сравнить продукты, проекты и операционную деятельность можно, построив матрицу 2×2, которую очень любят консультанты. По горизонтали у нас уровень управляемости, а по вертикали уровень повторяемости. Итоговая картинка представлена ниже. Причем пошаговая деятельность здесь — это про продуктовую разработку на основе гипотез и экспериментов.

Чем-то эта модель напоминает классический Кеневин фреймворк (Cynefin framework), представленный ниже. Здесь тоже четыре основные области, которые имеют следующие соответствия

Obvious

Причем движение по этим доменам идет по часовой стрелке от Chaotic к Complex, потом Complicated и Obvious. И чем ближе мы к Obvious тем большее commodity наши подходы и результаты.

Итого, мы сравнили проекты, продукты и процессы (операционную деятельность) и поняли в чем их отличия. Давайте теперь перейдем собственно к проектам, к управлению которыми существуют разные подходы.

Разные подходы к управлению проектами

Среди подходов, достойных упоминания я бы выделил следующее трио:

• PMI (Project Management Institute)
  Институт управления проектами — всемирная некоммерческая профессиональная организация по управлению проектами, основанная в 1969 году. Выпускает монументальную книгу PMBoK (Project Management Body of Knowledge), которая пережила уже шесть изданий и используется для проведения сертификаций на позицию PMP (Project Management Professional).
• IPMA (International Project Management Association)
  Международная Ассоциация Управления Проектами — некоммерческая профессиональная ассоциация, созданная в 1965 году в Цюрихе и призванная объединить специалистов в области управления проектами из разных частей мира. От России в эту ассоциацию входит Национальная Ассоциация Управления Проектами “Совнет”. Здесь базовой книгой для сертификации является “Основы профессиональных знаний и Национальные требования к компетентности (НТК) специалистов по управлению проектами. Версия 3.1”
• PRINCE2 (PRojects IN Controlled Environments)
  структурированный метод управления проектами, созданный в 1989 году, одобренный правительством Великобритании в качестве стандарта управления проектами в социальной сфере. Методология PRINCE2 включает в себя подходы к менеджменту, контролю и организации проектов.

Из трех этих подходов я трогал только два:

• PMBoK я основательно зубрил в рамках подготовки к успешной сертификации на позицию PMP — на самом деле полезнее была книга “PMP Exam Prep, Eighth Edition” от Rita Mulcahy
• С подходом СОВНЕТ я знакомился 12 лет назад в рамках курса по управлению проектами в магистратуре МФТИ. Подход интересный, но является локальным изобретением в отличие от PMBoK

Можем попробовать их сравнить.

С точки зрения практических инструментов обе модели почти ничем
не отличаются. В обеих моделях есть WBS (иерархическая структура работ), методы сетевого планирования и так далее. Различия касаются системного подхода в построении моделей.

В обеих моделях применяется различная терминология для системного описания. В IPMA используется пара “процесс-функция”, в PMI — “процесс-область знаний”. Перечень функций управления внешне напоминает перечень областей знаний. Но не смотря на сходство названий, имеется существенное различие по
существу групп процессов:

• в IPMA группы процессов эквиваленты календарным стадиям управления по всему проекту
• в PMBOK группы процессов повторяются на каждой фазе жизненного цикла

Дальше поговорим про проекты, причем скорее с точки зрения PMI.

Проект и из чего он состоит

У проекта обычно есть инициатор проекта, который часто является его спонсором. Спонсор проекта — это человек, который поддерживает проект на всех стадиях жизненного цикла, особенно на начальном этапе. Обычно, у этих людей есть какие-то планы, реализация которых выходит за границы операционной деятельности. В этом случае на помощь приходит проектный подход, который позволяет стартовать проект с определенными вводными и некоторыми фазами, например

• Определение проекта
• Проектирование
• Разработка
• Развертывание
• Завершение проекта

Внутри этих фаз работа идет в рамках процессов, поделенных на группы и области знаний. Среди групп выделяют:

• Процессы инициации
• Процессы планирования
• Процессы выполнения
• Процессы мониторинга и контроля
• Процессы закрытия

Работа процессов внутри фаз происходит итеративно, как показано на рисунке ниже. Между фазами обычно есть контрольные точки, прохождение которых связано с демонстрацией определенных результатов и принятием решения продолжать ли проект дальше. На выходе проекта мы имеем результаты проекта, которые поставляются конечным пользователям, а также документацию, которая становится активом для улучшения процессов выполнения проектов.

Распределение активностей групп процессов по фазам проекта обычно имеет вид, похожий на представленный ниже. На этом рисунке пунктирной линией выделена общая активность по проекту.

Области знаний

PMBoK выделяет следующие 10 областей знаний:

— Integration
— Scope
— Cost
— Quality
— Resource
— Communications
— Risk
— Procurement
— Stakeholder

Они вместе с группами процессов формируют табличку, в которую попадают все процессы, рассмотренные в PMBoK и приведенные на рисунке ниже. В рамках PMBoK подробно рассматривается каждый процесс, его входы и выходы, а также активность внутри самого процесса.

Теперь, когда мы кратко рассмотрели модель проекта в версии от PMI, давайте пойдем дальше и попробуем посмотреть на более крупные образования относительно проектов

Проекты, программы и портфели проектов

Если кратко, то эти три П (проект, программа, портфолио) относятся к друг другу как указано на рисунке ниже

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

• анализ производительности операционной деятельности влияет на стратегию
• оценка влияния проектов и программ на бизнес помогает проводить ревью и корректировки портфолио

Подводим итоги

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

— Есть ли временные рамки? Четкая дата старта и финиша?
— Как сформирована команда? На время или на постоянку?
— Как выглядит планирование? Итеративное или up-front?
— Поставка функционала единоразовая или инкрементальная?
— Источник требований зафиксирован или адаптируется по мере получения информации?
— Фокусируемся на поставке обещанных заранее результатов или повышении общей эффективности решения?

Если это проект, то важно понять

• Как выглядит проектный треугольник (сроки, стоимость, функционал)
• Кто спонсор и стейкхолдеры и их ожидания
• Какова ваша роль и ожидания от нее
  — Если вы не project manager, то это можно обсудить с ним
  — Если вы project manager, то теория по project management вам в помощь

Если это продукт, то вам стоит изучить вопросы зрелости процессов, например, KMM (Kanban Maturity Model). Или любую другую, которая поможет вам увеличить уровень зрелости команд и повысить эффективность процессов разработки продукта.

Что такое проектный треугольник

Что такое треугольник управления проектом, и как он может помочь вашему коллективу?

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

Ни один из трёх элементов проектного треугольника нельзя изменить без последствий для двух других его вершин. Задача менеджера проекта состоит в том, чтобы сбалансировать все три аспекта таким образом, чтобы уложиться в бюджет и сроки, выполнив при этом проект в установленном объёме.

Чуть позже мы выполним разбивку треугольника управления проектом на три части, проанализируем их взаимосвязь и посмотрим, как менеджеры проектов могут поддерживать их баланс, чтобы обеспечить успех проекта.

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

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

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

Задача менеджера проекта заключается в том, чтобы сбалансировать три вершины треугольника и обеспечить максимально высокое качество при соблюдении бюджета, сроков и требований проекта.

Взаимосвязь объёма, стоимости и времени

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

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

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

Тройственная ограниченность треугольника

Для того чтобы контролировать все три элемента, менеджер проекта должен иметь чёткое представление о каждой отдельной переменной и возможность гибко реагировать на изменения в рамках всего проекта.

Объём

Объём — это размер проекта с точки зрения качества, детализации и величины его ожидаемых результатов. Чем больше проект, тем, естественно, больше потребуется времени и средств на его реализацию.

К элементам объема проекта можно отнести:

Количество готовой продукции

Качество готовой продукции

Прочность (например, количество пользователей, которые могут одновременно использовать приложение)

Количество и сложность компонентов

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

Стоимость

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

К стоимости можно отнести:

Бюджет в финансовом выражении

Количество участников группы

Оборудование и технические средства

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

Время

При корректировке времени следует учитывать, что количество времени так же важно, как и тип измеряемого времени. Среди последствий корректировки времени может быть продление сроков выполнения, внесение изменений в программное обеспечение для ведения календарей, необходимость исключения стадий планирования и многое другое.

Ко времени можно отнести:

Общую хронологию проекта

Количество часов, отработанных в рамках проекта

Внутренние календари и ориентиры

Время на планирование и выработку стратегии

Количество этапов проекта

Сокращение бюджета или увеличение объёма работ придётся как-то компенсировать за счёт ослабления одного или нескольких ограничений по времени реализации проекта, например, путём продления сроков, увеличения рабочего времени или внесения других изменений в график.

Вероятностный фактор: инновации

Когда кто-нибудь находит новый способ выполнения работы, позволяющий делать это быстрее или экономичнее, такая корректировка может быть произведена без изменения других элементов треугольника управления проектом.

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

Кроме того, применение современных производственных процессов, помогающих стандартизировать последовательность операций и сократить время на принятие решений, позволит команде работать эффективнее без ущерба качеству. Инвестирование в такие инструменты управления, как шаблоны для продаж или программное обеспечение для управления проектами, сократит трату времени и средств без ущерба качеству и масштабу проекта.

Стратегии управления проектным треугольником

Теперь, когда вы понимаете, что такое проектный треугольник, вот вам несколько советов, как эффективно использовать его в повседневной работе. Неплохо бы также вспомнить про пять этапов управления проектами, чтобы определить, где возникают накладки.

Выбор приоритетов

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

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

Чёткая формулировка ожиданий

Определив границы и приоритеты проекта, сообщите о них клиенту и всем заинтересованным сторонам, чтобы потом не было неоправданных ожиданий или неудовлетворённых заказчиков.

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

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

Список вероятных факторов, способствующих отставанию от графика (погодные условия, стихийные бедствия, локальные события и т. д.)

Список часто используемых планов действий на случай отставания с указанием оценочных значений стоимости и времени, которые нужно будет добавить при возникновении непредвиденных обстоятельств

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

Частота актуализации

Разработав и согласовав план действий, предусматривающий возможные изменения стоимости, графика и объёма работ с учётом различных вероятных обстоятельств, обеспечьте регулярное информирование всех заинтересованных сторон о каких бы то ни было изменениях и прогнозах в рамках проекта.

Если поставщик сообщит вам, что у него нет необходимых ресурсов, оповестите клиента и ответственного за проект о вероятной задержке. Даже если у вас закончатся какие-либо ресурсы, заинтересованные стороны будут в курсе происходящего и будут готовы к корректировкам, которые вам придётся внести. Если же ресурсы у вас не закончатся, вы и ваш клиент будете более уверены в том, что вы подготовлены к самым разным ситуациям.

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

Существует множество подходов к управлению проектами, в которых приоритет отдаётся тем или иным параметрам проекта, в результате чего треугольники получаются разными. Ниже мы рассмотрим семь самых распространённых методов управления проектами, в которых приоритет отдаётся низкой стоимости и экономии времени.

Методы реализации проектов с упором на ресурсосбережение

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

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

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

Свод знаний по управлению проектами (каскад с PMBOK®): вариант традиционного каскада с последовательным выполнением, в рамках которого для повышения эффективности процесса применяются стандарты, предусмотренные «Сводом знаний по управлению проектами», разработанным Институтом управления проектами.

Методы реализации проектов с упором на экономию времени

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

Agile: приоритет отдаётся гибким процессам, позволяющим быстро адаптироваться к изменениям при минимальных затратах времени и средств; в рамках этого подхода часто используется специализированное программное обеспечение для agile-управления.

Scrum: вид agile-управления проектами, который чаще всего применяется при разработке программного обеспечения, когда используются элементы Scrum-методологии, такие как спринты и ежедневные летучки, позволяющие свести к минимуму потери времени на этапе выполнения работ.

Kanban: применяются непрерывные и прозрачные процессы коллективной работы для выполнения работ в минимальные сроки; в рамках этого подхода часто используется специализированное программное обеспечение.

Scrumban: в этом методе коллективные и непрерывные канбан-процессы сочетаются с ежедневным групповым обсуждением по методу Scrum, что помогает эффективнее минимизировать время на выполнение работ.

Безусловно, цель каждого из методов состоит в том, чтобы найти оптимальный баланс между низкой стоимостью, темпами реализации и высоким качеством. Но поскольку в треугольнике управления проектом как минимум одна переменная должна иметь приоритет, все эти методы имеют перекос в сторону той переменной, которая принята в качестве базовой.

Как использовать принцип тройственной ограниченности себе на пользу

На первый взгляд может показаться, что железный треугольник и его система тройственной ограниченности не даёт никакой свободы. Однако, научившись применять их в своём процессе управления проектами предприятия, вы отметите, что эти средства позволяют обеспечить более эффективное выполнение проектов. Если заранее хорошо разобраться в имеющихся ограничениях и возможностях, можно будет избежать многих дорогостоящих проблем.

Кроме того, железный треугольник помогает выбрать программное обеспечение для управления проектами, создать процессы и настроить производство таким образом, чтобы ваша команда могла оперативно приступить к работе. После этого вы будете способны на любые свершения.

Проектный треугольник

«Вы можете иметь это хорошее, быстрое или дешевые. Выберите два».

Инженеры много лет говорят об этом руководителям проектов.

В разных терминах каждый проект имеет «треугольник» времени,денег и области охвата. Изменить один из них, не затроня хотя бы один из других, невозможно. Задача руководителя проекта — следить за тем, чтобы треугольник не распался.

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

В этой статье

Time + money + scope = quality

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

Вот некоторые примеры того, как это работает:

Чтобы привлечь дата окончания (времени), вы можете потратить больше ресурсов (денег), чтобы быстрее завершить работу или урезать функции (область), чтобы меньше работы необходимо сделать до нового крайнего срока.

Чтобы завершить проект в рамках бюджета (затрат), можно избавиться от сверхурочных и завершить проект позднее (время) или срезать компонентов (область действия).

Чтобы добавить функции в продукт (область), вы можете продлить крайний срок, чтобы уложить время на новую работу (время) или добавить людей для ее более быстрого выполнения (затраты). Вы также можете сделать и то, и другое!

Качество — это четвертая часть треугольника проекта. Оно расположено в центре, где любое изменение любой стороны влияет на его.

Например, если вы опережаете расписание, вы можете заменить функции вырезания или дать больше времени существующим задачам. Благодаря этому дополнительному времени и области результат может быть лучше.

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

В предыдущем примере можно было просто завершить работу с продуктом раньше с большим количеством функций, чтобы он был раньше конкурентов. Это может быть определение качества для этого проекта в вашей компании.

Что нельзя изменить

В большинстве проектов по крайней мере одна сторона треугольника фиксирована. Изменить его нельзя.

Возможно, бюджет не подлежит обсуждению. (Похоже, вы знакомы?) Или, возможно, продукт должен выйти в продажу к определенной дате. Возможно, и то, и другое верно.

Часто фиксированные элементы проекта продиктуются руководителем проекта, но не всегда. Иногда решение о том, какой элемент является самым важным для успеха проекта, зависит от вашего плеча. И вам нужно быть понятным, если возникают проблемы (и они всегда возникают).

Когда проблема возникает на стороне исправлений, действовать не всегда достаточно. Например, если вы обнаружите, что разработка функции программного обеспечения займет больше времени, чем прогнозировался, и вы подписали контракт, в который будет добавлена эта функция (область), необходимо либо перенести дату окончания, либо добавить ресурсы, чтобы завершить ее вовремя.

Если стороны с исправлением и проблемойразные, не сдайте их. В этом и есть прелесть треугольника проекта. всегда есть место для внесения изменений. Например, если проект должен завершиться вовремя и он получил масштаб, вы все равно можете скорректировать затраты, добавив ресурсы.

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

Оптимизация расписания

Тем не менее вы столкнулись с проектом, который настроен на превышение крайнего срока.

Чтобы сократить расписание, можно сократить критический путь задачи, последняя задача которой завершается в дату окончания проекта. Изменение других задач может не сократить календарный план, но изменение задач критического пути будет выполняться. Чтобы сократить критический путь, вы можете:

Сократите длительность задачи (уменьшите область действия или добавьте ресурсы).

«Быстрое отслеживание» расписания: перекрытие задач, чтобы люди могли работать над ними одновременно (добавить ресурсы). Эту прием лучше использовать ближе к началу проекта.

«Аварийное выполнение» расписания: добавление ресурсов для ускорения выполнения задач (деньги).

Удаление задач (сокращение области действия).

Конечно, такое исправление расписания может существенно сказаться на бюджете, области и качестве проекта.

Оптимизация бюджета

В большинстве проектов наибольший фрагмент бюджета состоит из затрат на ресурсы: затраты на ресурсы с учетом ставок и фиксированные затраты на людей, оборудование и материалы. Для работы с бюджетом может потребоваться очень сложное решение.

Сократите область проекта, чтобы сократить количество задач, для выполнения которые требуются ресурсы.

Убедитесь, что подходят тарифы, сборы и сверхурочные.

Убедитесь, что ресурсы лучше всего подходят для работы.

Замените дорогой ресурс на более дорогой.

Контроль над затратами может привести к отключению крайнего срока или необходимости сократить масштаб проекта. Например, если для задач не разрешается сверхурочные работы, дата окончания может быть позже на месяц. Если же вы обрезали область, дата окончания может фактически переместиться в нее.

Оптимизация области

Можно ли сэкономить деньги, сделав мост на несколько футов короче его реки? Конечно, нет. Иногда область проекта не может измениться, поэтому вам придется принять другие меры:

Добавьте ресурсы, чтобы убедиться, что все задачи завершены (затраты).

Вырезание задач, которые не находятся на критическом пути (при их стоимости).

Добавление задач или добавление длительности к задачам (затратам).

Продлите крайний срок, чтобы разрешить время для всех задач с текущим уровнем ресурсов (времени).

Что нужно сделать до старта проекта. Часть 3

Что важно предусмотреть и учесть до начала проекта, чтобы он прошел успешно, продолжает рассказывать наш эксперт Максим Якубович.

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

Чтобы перейти к подписанию документов, официально утверждающих проект, нужно сделать еще один важный шаг – сформулировать ограничения по проекту. Расскажу об этом подробнее.

В управлении проектами используется термин «проектный треугольник» (употребляют еще понятие «тройное ограничение проекта»). Проектный треугольник описывает взаимодействие ключевых ограничений:

1. Содержание проекта. В простейшем случае оно может выглядеть как список работ по проекту, которые нужно реализовать, чтобы достигнуть целей и получить запланированные результаты. Для некоторых проектов содержание описывают в виде совокупности документов, например:

• Видение проекта.
• Техническое задание на проект (или на каждый его результат).
• ИСР проекта и т.д.

Чем точнее описано содержание проекта, тем проще спрогнозировать сроки и бюджет проекта.

2. Время реализации. Это ограничения по продолжительности проекта, включающие дату, к которой нужно получить ожидаемые результаты

3. Бюджет. Ограничение по стоимости проекта.

4. Качество. Ограничение, связанное с тем, в какой степени выполняются требования к результатам. Например, заказчика может устроить, что будут реализованы лишь самые важные требования проекта.

Самую большую сложность представляет интерпретация ограничения по качеству. Качество чего имеется в виду? Можно рассуждать о качестве и самого проекта и его результатов. Определение качества, которое использую я, следующее:

Качество – это степень соответствия результата и требованиям к нему. Качество результатов можно проверить, сравнив то, что получилось – с тем, что требовалось получить. Грубо говоря, сравнив итоговый продукт проекта с требованиями к нему.

Таким образом, качество проекта тесно связано с его содержанием. В нем и описаны требования к этим результатам.

Логика формирования ограничений по проекту следующая:

1. Уточнить содержание проекта, определив цели. Понимая это, можно определить результаты и требования к ним.

2. Понимая требования к результатам проекта, определить список работ по проекту.

3. Понимая список работ по проекту, определить сроки и бюджет.

4. Зафиксировать договоренности о содержании, сроках, бюджете и качестве проекта как ограничения проекта.

Как работает проектный треугольник

Так как неопределенность в проекте велика, то и наши расчеты имеют некоторую степень достоверности. Если не учтены важные требования во время их сбора – это приведет к появлению новых работ в содержании проекта. Сторона треугольника «Содержание» станет длиннее. Сбалансировать ее можно, либо увеличив сторону треугольника «Бюджет», либо увеличив сторону «Срок». Либо увеличив обе.

Таким образом, если меняется одна из сторон треугольника, руководителю проекта и заказчику приходится балансировать две другие. Понимая, как работает проектный треугольник, руководитель проекта и заказчик могут договориться, что важнее для проекта – срок, содержание, качество или бюджет?

Многие из вас уже видели похожие картинки, которые помогают расставить приоритеты.

Если заказчик настаивает, что должны быть реализованы все цели проекта и при этом выполнены все требования к результатам – желательно, чтобы к моменту старта эти требования уже были собраны и утверждены. Тогда руководитель проекта под эти требования может просчитать бюджет и срок.

При этом заказчик проекта должен отдавать себе отчет в том, что если по ходу проекта он захочет изменить или добавить требования – срок и/или бюджет проекта придется изменять.

Если заказчик пытается на старте проекта зафиксировать все три параметра проектного треугольника – это значит, он пытается передать руководителю проекта все риски, связанные с изменениями. Как реагирует на такое поведение заказчика мудрый руководитель проекта? Он закладывает резервы времени и денег на изменения (иногда резервы могут быть очень существенными, например равными 100% от расчетных значений сроков или бюджета).

Какие еще типы ограничений могут быть

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

Ограничения по ресурсам оказывают самое сильное влияние на сроки выполнения работ, но могут повлиять и на бюджет проекта.

Какова логика встраивания рисков в ограничения? В Своде знаний по управлению проектами PMBOK есть следующее объяснение: «Изменение требований к проекту или целей проекта может вызвать дополнительные риски». Они в свою очередь могут повлиять на содержание проекта, сроки или бюджет.

Стоит ли использовать шесть типов ограничений или достаточно определить три (содержание, срок и бюджет) – решать руководителю проекта. Я в большинстве проектов оперирую только тремя самыми важными ограничениями, которые описываю в документе Устав проекта.

Успешность проекта

Об успехе проекта судят по его выполнению в рамках ограничений.

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

Итак, типовые критерии успешности проекта обычно следующие.

Проект реализовал все запланированные результаты, причем был выполнен в срок и в бюджет.

Шаги по подготовке проекта к старту выглядят так:

1. Согласовать цели проекта с заказчиком.

2. Описать результаты проекта.

3. Согласовать требования к результатам проекта.

4. Определить допущения проекта.

5. Определить ограничения проекта и критерии успешности проекта.

После того, как эти шаги выполнены, руководителю проекта стоит оформить Устав проекта (иногда документ называют Паспорт проекта) и согласовать его с заказчиком.

Этот документ становится гарантом, что руководитель проекта и заказчик одинаково понимают все важные аспекты.
Содержание Устава проекта может быть разным в различных компаниях. Но важность этого документа нельзя недооценивать.

Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».

Опыт работы в сфере управления проектами – более 10 лет.

20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.

Опыт преподавания – 8 лет. Около 2000 студентов, прошедших обучение на его семинарах.

Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий блога по управлению проектами.