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

Блог Александра Кондуфорова

об информационных технологиях, программировании, путешествиях и фотографии

Sunday, July 25, 2010

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

В последнее время на собеседованиях сталкиваюсь с тем, что не все люди, претендующие на роль team/dev lead, знают про железный треугольник. Хочется немного осветить этот вопрос. Сразу скажу, что опытные PM’ы не найдут для себя ничего нового в этой заметке, она ориентирована на тех, кто еще только начинает изучать проектный менеджмент.

Итак, железный треугольник (iron triangle, project management triangle) – это абстракция, описывающая взаимодействие основных атрибутов или характеристик проекта: объема работ, сроков и ресурсов (команды, а следовательно и бюджета). Выглядит он обычно так:

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

Смысл этого треугольника в том, что ограничения на объем работ (scope), сроки (time/schedule) и бюджет (cost/budget) должны быть разумными, и любой менеджер проекта должен уметь ими управлять. В противном случае проект рискует стать провальным.

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

Как же бороться с железным треугольником? Так же, как и с deadlock’ами – стараться не создавать предпосылок для его появления 🙂

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

1. Клиент более важно иметь продукт готовым полностью (ограничен объем работы), и у есть бюджет лишь на определенную команду. В таком случае сроки выполнения работ выбираются нами (отталкиваясь от оценки, а также размера и качества команды) или вообще делаются варьируемыми, если это возможно. Здесь нужно понимать, что этот вариант возможен лишь когда у клиента ограничен месячный или квартальный бюджет, если не хватает бюджета на весь проект, то нужно искать уже пути удешевления производства: покупка или использование сторонних разработок, использование более “дешевой” рабочей силы (аутсорсинг), экономия на качестве. Варьирование сроков здесь никого не спасает.
2. Клиент хочет иметь продукт готовым полностью в указанные сроки. Единственный разумный (!) вариант здесь – увеличение команды. Не очень разумные варианты вроде сверхурочные работы тоже имеют право на жизнь, но их нужно использовать ОЧЕНЬ аккуратно. С увеличением команды тоже есть один нюанс: оно не всегда приводит к желаемому результату. Во-первых, новым людям нужно время на вливание в проект (если он уже идет). Во-вторых, не все задачи хорошо параллелятся – часто задача Б может быть сделана лишь только после завершения задачи А, поэтому добавлять людей для выполнения задачи Б нет смысла. В-третьих, большее количество людей в команде ведет к увеличению времени на их координацию и общение между собой, что увеличивает оценку объема работ и, следовательно, бюджет. То есть, опять же, клиент платит больше. Все это ведет к тому, о чем говорил еще дядюшка Брукс (перефразируя): 9 женщин не родят ребенка за 1 месяц.
3. Клиент хочет иметь продукт в указанные сроки, но у него нет бюджета на увеличение команды. В этом случае единственная наша возможность – это варьирование объема работы, т.е. приоритезация задач проекта и договор сделать лишь те, что мы успеем, с учетом приоритетов. Менее важные задачи рискуют оказаться за границами продукта к дате релиза.

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

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

Прежде всего, не паниковать 🙂 Не вы первые, не вы и последние – по разной статистике в IT около 20-25% заваленных проектов, и еще около 45-50% – вышедших за рамки запланированных бюджетов, сроков, либо выпущенных не полностью готовыми (не вся функциональность либо плохое качество).

А вот дальше нужно сесть и хорошо подумать, причем желательно вместе с вашим клиентом. Возможно, вы сможете найти компромисс и освободить одну из вершин, а даже если и нет – клиенту лучше быть в курсе происходящего как можно раньше, а не за неделю перед релизом, чтобы успеть подстелить соломку, где это возможно. Оптимизация процесса работы и коммуникаций, более строгий контроль за выполнением работ, строгий change requests management, оплаченные сверхурочные, дополнительная мотивация сотрудников премиальными – все это может помочь не потерять лицо в глазах клиентов и избежать штрафов за срывы сроков. Но все-таки наилучшая рекомендация для менеджера проекта – постоянно держать в голове этот самый треугольник и отталкиваться от него, дабы свести возможность срабатывания этого риска к минимуму. Ну, и не забывать управлять остальными рисками, конечно же 🙂

Правила эффективного управления сроками проектов

1 марта Академия бизнеса «Эрнст энд Янг» провела мастер-класс , посвященный теме управления сроками проектов. Ведущая Анна Григораш рассказала присутствующим о том, что нужно делать, чтобы успевать с проектами в срок. Подробнее — в репортаже нашего журналиста Ирины Грабовской.

Не важно, чтобы каждое отдельное задание было выполнено в срок. Важно, чтобы в срок был завершен весь проект
Элия Голдратт

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

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

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

Итак, проект предполагает:

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

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

1) нарушение изначальных сроков,

2) частые изменения содержания проекта,

3) необходимость повторного выполнения некоторых работ,

4) отсутствие необходимых ресурсов, когда они были обещаны,

5) борьба за приоритеты между проектами,

6) превышение бюджета.

Успех управления проектом во многом определяется контролем «железного треугольника» — задания, срока и бюджета. Геометрический феномен данного треугольника заключается в том, что нельзя увеличить или уменьшить одну сторону, не затронув две других.

Успех управления проектом во многом определяется контролем «железного треугольника» — задания, срока, бюджета

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

Управление сроками проектов

«Если в вашем проекте ключевой фактор — сроки, будьте готовы к тому, что придется жертвовать либо качеством конечного продукта, либо бюджетом, выделенным на реализацию проекта», — говорит Анна Григораш.

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

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

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

Методы сокращения длительности операций

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

Метод сжатия:

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

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

Метод быстрого прохода:

• — параллельное выделение операций, которые обычно выполняются последовательно.

• — возрастают риски дополнительных доработок.

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

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

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

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

4. Можно сделать некоторые работы иначе, если это сокращает срок их выполнения (инновации).

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

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

Метод критической цепи

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

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

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

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

Для поиска «узкого горлышка» проекта ведущая предложила использовать такие вопросы:

• — Где вероятнее всего проекты «застрянут» на самое длинное время?
• — Где вероятнее всего будет наиболее сильное перепрыгивание от задания к заданию?
• — Где наиболее важно максимально задействовать ресурс?

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

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

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

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

Елена Калибаба,
внешний консультант по обучению

Сейчас у меня период перемен: я ушла из благотворительной сферы, в которой проработала 10 лет, и перешла в бизнес. Поэтому для меня тема мастер-класса особенно актуальна. Дело в том, что когда я работала в благотворительности, у нас проекты были весьма специфические: была конкретная задача и конкретная сумма, поэтому превышения бюджета более чем на 20% никогда не было.

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

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

Что касается сроков в управлении проектами, то это всегда актуальный фактор. Но мне кажется, что здесь от одного человека ничего не зависит. Я все-таки верю, что любого человека можно мотивировать, и если мы работаем в команде над проектом, и сроки горят, то нужно обратиться ко всем участникам проекта. Не знаю, насколько это работает в бизнесе, еще не успела попробовать, но в общественной деятельности это работает на 100 процентов!

Ирина Андреева,
начальник отдела подбора персонала, К. А. Н. Девелопмент

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

Занимаясь подбором персонала, я понимаю, что формирование команды — это тоже проект, имеющий свои сроки, свой бюджет и определенные параметры качества.

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

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

Александр Макаревич,
начальник лаборатории психодиагностики

Очень понравился стиль ведения мастер-класса . Видно, что ведущая хорошо подготовлена. Удачно была подана технология управления сроками проекта. Внимание участников было акцентировано на необходимых моментах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Структура принятия решения

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

Давление графика

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

Давление возможностей

• Насколько критичны для вас бизнес-ограничения?
• Можно ли приостановить проект и пересмотреть бизнес-ограничения?
• Можно ли объединить два параллельных проекта и добиться поставленных целей?
• Можно ли переместить некоторые цели в список желаний и достичь их позже?

Давление бюджета

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

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

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

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

Проектный менеджмент: «водопад» или Agile?

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

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

Железный треугольник проектного менеджмента

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

Железный треугольник Easy Project

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

Каскадное управление — «водопад»

Каскадная модель лучше всего подходит для проектов с чётко определёнными границами, то есть когда содержание является ключевым элементом проекта. Примеры: строительство дома, планирование конференции, внедрение Easy Project.

Методика: Задаём границы проекта, то есть определяем содержание — оно будет неизменным. Это означает, что нельзя изменить число окон в доме, место проведения или тему конференции. Далее, время проекта является ограничивающим фактором — мы ограничены полностью (конференция) или почти полностью (внедрение EP). Когда содержание проекта неизменно, главная задача проектного или портфельного менеджера заключается в том, чтобы спланировать, как будут использоваться и расходоваться ресурсы с учётом времени и последовательности реализации проекта.

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

Гибкое управление — Agile

Agile-методы следует использовать для управления проектами, в которых время реализации является неизменным, ресурсы служат определяющим фактором, а содержание предстоит спланировать (то есть расставить приоритеты).

Примеры: разработка ПО (спринты); издательство (дата выпуска журнала, газеты); контент-маркетинг (рекламная кампания).

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

Железный треугольник Easy Project

Как это можно использовать

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

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

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

Управление проектами по методике Agile. Расстановка приоритетов, как правило, не вызывает проблем — на помощь приходят всевозможные инструменты. Сложности возникают с выделением ресурсов под конкретный журнал пожеланий. Здесь не обойтись без составления точного плана. Разработчик, к примеру, может быть задействован в нескольких журналах (устранение ошибок и запросы функций, язык один и тот же). Если не решить проблему количественного распределения ресурсов по журналам пожеланий, то расставить приоритеты не получится, и скрам-мастер столкнётся с несоответствием между ожиданиями и результатами. В дальнейшем это приведёт к нарушению сроков выпуска обновлений, поскольку такие задачи, как исправление ошибок и обработка запросов на новые функции, «сжирают» ресурсы стратегической разработки.

Профессиональный план Easy Project всего за 49 € в месяц

Как сочетать две методологии

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

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

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

»Сделаем хорошо, быстро, дешево. Выберите из этих трех условий два».

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

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

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

В этой статье

Время + деньги + область охвата = качество

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

Вот пара примеров того, как это работает.

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

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

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

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

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

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

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

Знайте, что невозможно изменить

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

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

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

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

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

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

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

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

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

Сократите длительность задач (сократить область охвата проекта или добавить ресурсы).

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

обогнать расписание: добавить ресурсы, чтобы быстрее выполнить задачи (деньги);

удалить задачи (сократить область охвата проекта).

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

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

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

сузить область охвата проекта, чтобы было меньше задач, требующих ресурсов, или чтобы такие задачи были короче;

проверить адекватность ставок, расценок и сверхурочных;

убедиться в том, что ресурсы являются оптимальными для данной работы;

заменить дорогие ресурсы более дешевыми.

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

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

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

добавить ресурсы, чтобы обеспечить выполнение всех задач (затраты);

пожертвовать задачами, которые не находятся на критическом пути (затраты);

добавить задачи или увеличить их длительность (затраты);

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