Проект «в мире треугольников»

Методологии управления проектами

1. Методология PMI, сформулированная в виде стандарта PMBOK, базируется на концепции управления проектами через группу стандартных процессов. Однако последняя версия стандарта PMBOK отражает существенную коррекцию методологии в сторону интерактивных методик.
2. Методология IW URM (Unique Reliable Method), разрабатывалась и оттачивалась с тем, чтобы в любом проекте был гарантирован успех — цели клиента достигнуты в оговоренный срок, в рамках определенного бюджета и с необходимым качеством. Для реализации разных типов проектов используется набор различных процедур, документов и технологий, наиболее подходящих для конкретного типа проекта.
3. Процесс управления проектами TenStep помогает менеджерам проектов успешно руководить проектами всех видов. TenStep предлагает пошаговый подход, начинающийся с простейших вещей и заканчивающийся настолько изощренными приемами, насколько это может потребоваться для конкретного проекта, включая шаблоны документов.
4. Методология P2M базируется в ориентированности не на продукт или процессы, а на улучшение организации в результате выполнения проектов. Иными словами, методология описывает, как использовать полученный в результате выполнения проектов опыт для развития компании.

«Выберите любые два»

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

• Проектируйте что-то быстро и к высокому стандарту, но тогда это не будет дешево.
• Проектируйте что-то быстро и дешево, но это не будет иметь высокого качества.
• Проектируйте что-то с высоким качеством и дешево, но будет относительно требоваться много времени.

Создание проекта

Новый проект можно
создать с помощью пункта меню File > New
(Файл > Создать).
Как правило, при запуске Microsoft Project эта
команда выполняется автоматически.

Проще всего при
создании проекта воспользоваться
консультантом. Окно консультанта
открывается в левой части экрана
(рисунок 2) при запуске Microsoft Project. Если
этого окна на экране нет, то открыть его
можно, нажав кнопку Tasks (Задачи) на панели
инструментов консультанта.

Рисунок 2 – Окно
Tasks (Задачи) консультанта

Для создания нового
проекта нужно щелкнуть на надписи Define
the project (Определение проекта) в окне
консультанта. После этого можно будет
вводить сведения о проекте. Все сведения
будут запрашиваться автоматически,
поэтому не придется запоминать, что еще
нужно ввести для полного и правильного
определения нового проекта.

В первую очередь
следует ввести дату начала проекта и
щелкнуть мышью на надписи Save and go to Step 2
(Сохранить и перейти к шагу 2) в нижней
части окна консультанта (рисунок 3).

Рисунок 3 – Ввод
даты начала проекта

Для задания и при
необходимости изменения основных
параметров проекта можно также
воспользоваться командой Project > Project
Information (Проект > Сведения о проекте). В
результате откроется одноименное окно
(рисунок 4).

В нем нужно указать
дату начала проекта в поле Start date (Дата
начала) или дату окончания проекта в
поле Finish date (Дата окончания). Указывать
следует только одну дату из двух, так
как в Microsoft Project проекты можно планировать
двумя способами: от даты начала или от
даты окончания. Первый способ применяется,
если у проекта нет жесткой даты окончания.
В этом случае дата завершения проекта
определяется во время планирования.
Метод планирования следует указать в
списке Schedule from (Планирование от).

Следующим шагом
будет определение того, планируется ли
совместная работа над проектом или нет.
Если предполагается работать над
небольшим проектом и планировать все
самостоятельно, то следует выбрать
вариант No (Нет). Если же необходимо
публиковать проект на сервере, чтобы
он был доступен другим сотрудникам, то
следует выбрать Yes (Да) и щелкнуть на
надписи Set connection information for the Project Server
(Ввести данные для подключения к серверу
Microsoft Project Server), после чего заполнить все
поля. Что именно указывать в этих полях,
необходимо узнать у администратора
сети организации.

Рисунок 4 – Окно
Project Information (Сведения о проекте)

Эту же операцию
можно выполнить, воспользовавшись
командой Tools > Options (Сервис > Параметры).
В открывшемся окне на вкладке Collaborate
(Совместная работа) указывают параметры
совместной работы.

Третьим шагом
будет сохранение проекта на диск. Для
этого нужно выбрать в меню File > Save (Файл
> Сохранить), задать имя проекта и
нажать кнопку Save (Сохранить). К примеру,
назовем проект Журнал. После сохранения
следует щелкнуть на надписи Save and Finish
(Сохранить и закончить работу) в нижней
части окна и перейти к этапу Define general
working times (Определение рабочего времени
проекта).

Треугольник ограничений проекта

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

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

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

Подходы к управлению жизненным циклом проекта/продукта

Существует множество подходов к управлению жизненным циклом проекта/продукта в зависимости от типа проекта:

• Предположение о неизменности требований, низких рисках, критичности сроков завершения. В этом случае применяется водопадный жизненный цикл. Для планирования и контроля хорошо применимы методы PERT, метод критического пути, метод освоенного объема, диаграмма Ганта. Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Подход применим к строительным и инженерным проектам, в которых содержание проекта остаётся практически неизменным в течение всего проекта .
• Предположение о критичности качества, при этом требования к сроку и ресурсам достаточно гибки (под качеством здесь понимается полнота удовлетворения потребностей, как известных, так и неизвестных заранее, часто создаваемых выходом нового продукта). В этом случае применяются спиральный жизненный цикл, гибкая методология разработки продукта, минимизация администрирования и неформальный подход к управлению проектом. К преимуществам относят гибкость и адаптивность под изменения требований. В качестве недостатков отмечают что гибкость может приводить к потере фокуса, усложнению внесения непредвиденных изменений .
• Предположение о высоких неопределенностях и рисках проекта (для инновационных проектов и стартапов). В этом случае применяются подходы управления бережливый стартап, Phase–gate model, Benefits realisation management.

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

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

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

Любой проект проходит стадии инициации, планирования, выполнения и закрытия.

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

• 31.05.16 10:19

•
Andrey_Smitenko
•
#302266
•
Хабрахабр

•

•

2600

Управление разработкой, Управление проектами

Излагаются два подхода, которые потенциально позволяют дать объективную оценку, на сколько работа разработчика на проекте удовлетворяет требованиям качества, сроков и бюджета.Управление проектом — это организация процесса по успешному, т. е. за отведённое время и без превышения выделенного бюджета, достижению поставленной цели. Конечный продукт при этом должен обладать заданными изначально свойствами и быть приемлемого качества.
Во многих случаях приходится искать баланс между ограничениями по времени, затратам и содержанием проекта. Очень наглядной иллюстрацией является проектный треугольник, (картинка поскольку три стороны треугольника связаны, и изменение одной стороны влияет, по крайней мере, на одну из двух других сторон, демонстрируя процесс балансировки ограничений).
В качестве примера можно рассмотреть ситуацию, когда требуется сократить срок сдачи проекта. Для этого может понадобиться увеличить бюджет и использовать больше ресурсов, с помощью которых тот же объем работы будет выполнен за меньшее время. Если же увеличение бюджета недопустимо, необходимо уменьшить содержание проекта, поскольку с наличными ресурсам нет возможности выполнить весь запланированный объем работ за меньшее время.
Создание, за отведённое время и в рамках заданного бюджета, качественного программного обеспечения, которое удовлетворяет реальным потребностям заказчика — это процесс, который можно и нужно описывать на языке управления проектами. Разработчик — одна из ключевых ролей в этом процессе. Мне кажется, принципиально возможно оценить профессионализм девелопера, если систематически оценивать результаты его работы с позиции того, насколько они соответствуют тройственной ограниченности.В идеале каждая задача, которая поставлена разработчику, должна быть решена так, чтобы:

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

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

Обзор

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

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

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

В качестве графического средства управления проектом треугольник может отображать время, ресурсы и техническую цель в виде сторон треугольника, а не углов. Джон Сторк, бывший преподаватель курса «Базовое управление проектами» Американской ассоциации менеджмента, использовал пару треугольников, называемых внешним треугольником и внутренним треугольником, чтобы представить концепцию, согласно которой проект должен быть завершен в установленное время или раньше. , в рамках бюджета или ниже его, и соответствовать или превышать требуемый объем. Расстояние между внутренним и внешним треугольниками иллюстрирует изгородь или непредвиденные обстоятельства для каждого из трех элементов. Смещение можно было показать по расстоянию. Его примером проекта с сильным уклоном во времени был трубопровод на Аляске, который, по сути, должен был быть выполнен вовремя, независимо от затрат. После нескольких лет разработки нефть вытекла из конца трубы в течение четырех минут по графику . На этой иллюстрации временная сторона внутреннего треугольника была фактически на вершине внешней линии треугольника. Это относилось и к линии технических целей. Линия затрат внутреннего треугольника, однако, была внешней, поскольку проект значительно превышал бюджет.

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

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

Преодоление проблем с ограничениями проекта

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

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

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

Роль руководителя проекта развивается вокруг ответственности. Менеджер проекта должен контролировать и контролировать проект с самого начала и до закрытия.

Следующие факторы будут определять роль менеджера проекта:

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

• Менеджер проекта должен установить цели, необходимые для проекта, и работать над достижением этих целей.

• Наиболее важным видом деятельности менеджера проекта является информирование заинтересованных сторон о ходе реализации проекта.

• Менеджер проекта должен оценивать и тщательно отслеживать риски проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

Цель управления проектом и успешность проекта

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

Группы оценок успешности:

• Ориентированные на контракт с жесткой фиксацией требований и минимизацией изменений в ходе проекта, например традиционные методологии, в том числе PMBOK: «проект успешен, если выполнен согласно утвержденным критериям: объёму, сроку, качеству». То есть проект успешен, если исполнен и закрыт договор между Заказчиком и Исполнителем (вне зависимости от того, являлся ли он юридическим документом в случае внешних проектов или определялся как-то иначе в случае внутренних проектов). При этом оценка успешности единая как для заказчика так и для исполнителя.
• Ориентированные на удовлетворенность заказчика с гибким управлением требованиями, например гибкие методологии SCRUM: «проект успешен, если заказчик удовлетворен»
• Ориентированные на длительное взаимодействие с Заказчиком: управление программами, направленное на длительное взаимодействие, а не на один проект/контракт. Здесь делается акцент на продолжение сотрудничества Исполнителя с Заказчиком в рамках последующих проектов и иного взаимодействия.
• Сбалансированные, например PRINCE2: «проект успешен при сбалансированности по крайней мере по трем категориям — бизнеса, ориентации на пользователя и технологической зрелости». Здесь делается акцент на финансовой успешности проекта, удовлетворенности пользователей и развитии технологий. Оценка успешности может различаться с точки зрения бизнеса, пользователя и исполнителя. Такие методики оценки чаще используются для внутренних проектов, когда заказчик и исполнитель находятся в одной организации.

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

В целом можно определить цель управления проектами следующим образом:

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

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

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

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

Как того требует любое начинание, проект должен протекать и достигать финала с учетом определенных ограничений. Классически эти ограничения определены как содержание проекта, время и стоимость. Они также относятся к Треугольнику Управления проектами, где каждая его сторона представляет ограничение. Изменение одной стороны треугольника влияет на другие стороны. Дальнейшее уточнение ограничений выделило из содержания качество и действие, превратив качество в четвертое ограничение.Ограниченность времени определяется количеством доступного времени для завершения проекта.
Ограниченность стоимости определяется бюджетом, выделенным для осуществления проекта.
Ограниченность содержания определяется набором действий, необходимых для достижения конечного результата проекта.
Эти три ограниченности часто соперничают между собой. Изменение содержания проекта обычно приводит к изменению сроков (времени) и стоимости. Сжатые сроки (время) могут вызвать увеличение стоимости и уменьшение содержания. Небольшой бюджет (стоимость) может вызвать увеличение сроков (времени) и уменьшение содержания.Управление проектами является наукой о применении инструментов и технологий, которые дают возможность команде (не только управляющему проектом) организовать работу с учетом этих ограничений.

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

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

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

Любой проект проходит стадии инициации, планирования, выполнения и закрытия.

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

Национальные стандарты управление проектами:

• NASA Project Management (США)
• BSI BS 6079 (Великобритания)
• APM Body of Knowledge (Великобритания)
• OSCEng (Великобритания)
• DIN 69901 (Германия)
• V-Modell (Германия)
• VZPM (Швейцария)
• AFITEP (Франция)
• Hermes method (Швейцария)
• ANCSPM (Австралия)
• CAN/CSA-ISO 10006-98 (Канада)
• P2M (Япония)
• C-PMBOK (Китай)
• South African NQF4 (ЮАР)
• CEPM (Индия)
• PROMAT (Южная Корея)

Стандарты с расширенной географией применения:

• ISO 10006:2003, Quality management systems — Guidelines for quality management in projects
• A Guide to the Project Management Body of Knowledge (PMBOK Guide)
• PRINCE2 (PRojects IN a Controlled Environment)
• ISEB Project Management Syllabus
• Microsoft Solutions Framework (MSF)
• Oracle Application Implementation Method {AIM}

Стандарты оценки компетенции менеджера проекта:

• ICB IPMA Competence Baseline (IPMA)
• PMCDF (США)
• NCB UA (National Competence Baseline, Version 3.0) (Украина)
• НТК (Российская Федерация)