Проджект менеджмент [основные методы управления проектами]

 

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

 

Содержание

 

• Метод «Водопад»
• Метод критического пути
• Метод управления критическими цепочками
• Гибкий метод управления проектами
• Agile и Scrum
• Agile и Kanban
• Agile и экстремальное программирование
• Agile и Adaptive Project Framework
• Скоростная разработка приложений
• Запуск нового продукта
• Packaged Enabled Reengineering
• PRINCE2
• Метод шести сигм
• Метод маркировки результатов
• Институт управления проектами

 

1. Метод «Водопад» (Waterfall)

 

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

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

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

1. Детализация потребительских требований;
2. Концепция, дизайн и планирование;
3. Создание материального продукта (строительство, написание кода и т. д.);
4. Интеграция в существующие системы;
5. Валидация (тестирование, отладка и т. д.);
6. Сборка продукта;
7. Постоянное техническое обслуживание.

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

 

2. Метод критического пути (Critical Path Method)

 

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

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

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

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

 

3. Метод управления критическими цепочками

 

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

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

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

 

4. Гибкий метод управления проектами (Agile)

 

Группа экспертов по разработке программного обеспечения разработала основы Agile System чуть более 15 лет назад. Они создали новый способ создания пользы для потребителей и взаимодействия с ними. Этот способ характеризовался четырьмя ключевыми аспектами:

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

За короткое время эксперты проджект менеджмента расширили эти концепции до отдельных фреймворков:

• «Скрам»;
• «Канбан»;
• Экстремальное программирование;
• Адаптивное управление проектами.

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

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

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

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

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

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

 

5. Agile и Scrum

 

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

Команды Scrum встречаются для ежемесячных сессий, на которых они разбивают свои проекты и результаты на 15- или 30-дневные части, называемые «спринтами». Работая над этими небольшими объемами, команды избегают перегрузок в производстве, типичных для других методологий управления проектами. Перераспределяя приоритеты своих усилий каждый месяц, для удовлетворения потребительского спроса, они могут оставаться гибкими и мотивированными — повышая производительность и удовлетворенность клиентов.

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

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

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

 

Скрам мастер

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

 

Владелец продукта

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

 

Участник команды

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

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

Scrum работает особенно хорошо, когда команды получают существенную поддержку от высшего руководства в виде открытых финансовых и временных бюджетов.

 

6. Agile и Kanban

 

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

Многие руководители проектов используют концепции Канбан в сочетании с Agile методами. Гениальность Канбан в том, что производство происходит по требованию, при котором заказчик «протягивает» изделия через производственную базу.

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

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

• In Queue (британский термин, означающий «в очереди»);
• В процессе;
• Недавно завершено.

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

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

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

 

7. Agile и экстремальное программирование

 

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

• Коммуникация;
• Простота;
• Обратная связь;
• Уважение;
• Смелость.

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

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

 

8. Agile и Adaptive Project Framework

 

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

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

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

 

Сходство между Agile методами

Независимо от выбранного типа Agile метода, все они имеют определенные общие характеристики. Agile команды:

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

 

9. Скоростная разработка приложений

 

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

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

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

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

 

10. Запуск нового продукта (New Product Introduction)

 

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

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

 

11. Packaged Enabled Reengineering

 

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

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

 

12. PRINCE2

 

PRINCE2 — это комплексная методология управления проектами, которую не следует путать с PMBOK (the Project Management Institute’s Project Management Body of Knowledge).

PRINCE2 используется правительством Соединенного Королевства, многими организациями частного сектора по всему миру  иможет многое предложить американским организациям:

• Усиление контроля над ресурсами;
• Повышение эффективности управления проектными рисками;
• Четкое распределение ответственности между структурами;
• Акцентирование на конечных пользователях «Кто, когда и почему»;
• Последовательное, организованное планирование и исполнение;
• Регулярное, обоснованное рассмотрение рабочих циклов.

 

13. Метод шести сигм

 

Компания Motorola изначально разработала высокопрофессиональную систему «Шесть сигм» для устранения недостатков. Они хотели, чтобы их продукты и услуги полностью соответствовали их первоначальным требованиям на протяжении всего процесса проектирования, производства и доставки.

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

“Шесть сигм”-менеджеры  используют 5 технологических этапов, которые вместе называются DMAIC-S (define, measure, analyze, improve, synergize):

• Определи потребности клиентов. Менеджеры могут определить масштаб и цель проекта, определив и составив профиль идеальных клиентов и поняв, как им обслуживать их.
• Измерь производительность процесса. Создав соответствующие метрики для сбора данных о производительности, менеджеры могут определить, насколько хорошо система удовлетворяет потребности потребителей.
• Проанализируй общие проблемы. Менеджеры “Шести сигм” изучают проблемы производительности, чтобы определить их коренные причины и подкрепить свои наблюдения достоверными данными.
• Усовершенствуй систему. Руководители проектируют, тестируют и запускают новые системы для устранения основных причин системных проблем. Они опираются на данные, оценивая эти решения (и реализуя свои корректирующие меры).
• Объедини эти результаты по всей компании.

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

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

 

14. Метод маркировки результатов

 

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

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

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

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

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

 

15. Институт управления проектами (PMI)

 

Некоторые менеджеры считают PMI’s Guide to the Project Management Body of Knowledge (PMBOK) самостоятельной методологией управления проектами. Другие считают его скорее справочником. Но, безусловно, этот сборник предоставляет необходимый набор условных обозначений и стандартизирует профессиональные термины, используемые менеджерами проектов.

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

1. Инициирование.
2. Планирование.
3. Выполнение.
4. Контроль.
5. Завершение.

 

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

 

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

• Многопользовательский потенциал (т. е. может ли вся твоя команда использовать его одновременно?).
• Функции управления проектами, которые хорошо сочетаются с выбранным методом.
• Отзывы от руководителей проектов, которые разделяют твою корпоративную философию.
• Максимальная емкость базы данных.
• Надежность и простота использования.
• Необходимые сроки обучения / перехода на новое место работы.
• Информация основанная на данных vs. визуальных интерфейсов.
• Инструменты для создания диаграмм и отслеживания рабочих процессов

Компании, которые разработали твою программную платформу управления проектами, вероятно, сформировали её в соответствии с конкретной стратегией. Например, метод скоростной разработки приложений хорошо синхронизируется с объектно-ориентированными языками программирования, такими как Java и C++. Такие сервисы, как MeisterTask и Trello предлагают интерактивные «доски», которые идеально сочетаются с корпоративными Kanban структурами.

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

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