Философия agile. Что такое Agile? Эмпирическое исследование ключевых факторов успеха для IT проектов

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

• Введение
• 1. Анализ подходов к управлению проектами на основе классической и гибкой методологии
• 1.1 Введение в гибкие методологии управления проектами
• 1.2 Критика и проблемы гибкого управления проектами
• 1.3 История развития взглядов на гибкие методологии
• 1.4 Гибкие методологии в сравнении с традиционным подходом к управлению проектами
• 1.5 Ключевые факторы успеха IT проектов, использующих гибкие методологии
• 1.6 Ситуационный подход в управлении проектами в сфере информационных технологий
• 1.7 Общее описание ИТ проектов
• 1.8 Особенности управления проектами в разных странах
• 1.9 Этнокультурные особенности проектной деятельности в России
• 1.10 Переход на agile с традиционного подхода к управлению проектами
• Выводы по главе
• 2. Эмпирическое исследование КФУ для IT проектов
• 2.1 Методология исследования
• 2.2 Исследовательские гипотезы
• 2.3 Описание процесса проведения опроса
• 2.4 Анализ результатов
• 2.4.1 Демографические показатели респондентов
• 2.4.2 Тест надёжности переменных модели
• 2.4.3 Анализ корреляций независимых переменных с успешностью проекта
• 2.4.4 Построение модели множественной линейной регрессии
• 2.5 Интерпретация результатов
• Выводы по главе
• 3. Практические рекомендации
• 3.1 Советы по переходу на agile методологию
• 3.2 Рекомендации по проведению качественной ретроспективы
• 3.3 Саморегулируемая команда как способ ускорить процесс принятия решений
• 3.4 Ситуационный подход в практике управления проектами
• Рекомендации для будущих исследований
• Выводы по главе
• Заключение
• Список использованной литературы
• Список иллюстраций
• Приложение 1. Вопросник
• Приложение 2. Диаграммы остатков регрессии
• Приложение 3. Результаты опроса
• Приложение 4.Расшифровка для результатов опроса

Введение

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

Сейчас данная концепция значительно переросла рамки разработки ПО и стала, фактически, некоторой альтернативой традиционному подходу в управлении проектами во всех сферах. Но особенно она популярно всё же в сфере информационных технологий (IT), в силу динамичности этой области. Однако несмотря на растущую популярность и текущую скорость изменений в бизнес-среде, многие компании по-прежнему придерживаются традиционного подхода. Agile (гибкий) подход для них является, как правило, незнакомым, поэтому переход на новую методологию может вызывать сложности. В такой ситуации полезно иметь набор ключевых точек, на которые стоит обратить особое внимание. В литературе они называются ключевые факторы успеха (КФУ). В зарубежной литературе присутствует значительное число работ на эту тематику, однако в России данная область только начинает развиваться, поэтому работ на эту тему практически нет. В то время как социокультурные факторы, соответствующие разным странам, значительно влияют напроцесс управления. И стоит принимать это во внимание при работе с проектами.

Целью данной работы будет заполнить пробел в исследованиях: рассмотреть ключевые факторы успеха проектов в сфере IT, использующих agile методологии, в России и предоставить рекомендации по их практическому использованию

Для этого будет необходимо осуществить следующие задачи:

1. Идентифицировать вероятные КФУ с помощью анализа литературы.

2. Провести глубинные интервью с менеджерами для уточнения и дополнения КФУ.

3. Спроектировать и провести онлайн-анкетирование менеджеров проектов в IT, работающих с гибкими методологиями

4. Проанализировать результаты.

Объектом работы выступают ключевые факторы успеха проектов.

Предметом являются ключевые факторы успеха проекта в сфере IT, использующего гибкие методологии.

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

Методом для сбора является опрос менеджеров проектов в IT относительно их проекта, выполненного с использованием гибких методологий. Формирование опроса проходило в 3 этапа:

1. Формирование первичного перечня КФУ на основе имеющейся литературы

2. Уточнение КФУ в ходе неструктурированного интервью с 3 менеджерами проектов

3. Составление опросника и пилотажное тестирование

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

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

Структурно работа разделена на 3 большие главы. Первая - теоретическая, представляет собой анализ существующей литературы по данной теме в основном из зарубежных источников. Наибольшее внимание было уделено статьям из International Journal of Project Management и специализированным журналам, касающимся разработки ПО. Вторая глава представляет собой подробное описание методологии исследования, анализу и интерпретации полученных выборочных данных. Третья глава представляет собой набор рекомендаций для практиков, основанных на результатах исследования.

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

1. Анализ подходов к управлению проектами на основе классической и гибкой методологии

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

Методологии правления проектами в сфере ИТ можно глобально разделить на два подхода:

· Традиционный

· Гибкий (итеративный)

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

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

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

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

Практика использования методологий также подтверждает эти выводы: доля Agile проектов в общем массиве неуклонно растёт (с 2% в 2002 до 9% в 2010), в то время как традиционные подходы теряют популярность, что особенно заметно в области разработки приложений.

Управление проектами существует на различных уровнях иерархии. В представлении (Maylor, Brady, Cooke-Davies, & Hodgson, 2006) она выглядит следующим образом

Рисунок 1. Окружение проекта

Изначально данная схема была направлена на проекты по разработке программного обеспечения, однако примерно в таком же виде она существует и в других проектах в IT. При этом очевидно, что (Maylor, Brady, Cooke-Davies, & Hodgson, 2006) выделяют конкретные Agile методологии, как SCRUM и XP в качестве методологий уровня команды. Однако некоторые исследователи склонны смотреть на SCRUM как на более общую методологию, относящуюся и к уровню менеджера проекта в том числе (Barlow et al., 2011). Ряд исследователей также рассматривает Scrum в других сферах, отличных от IT. Данная методология демонстрирует неплохие результаты и в других областях, например, строительства (Owen, Koaskela, & Henrich, 2006).

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

Однако agile подход к управлению проектами имеют и определённые недостатки, отмеченные многими исследователями. В частности (Coplien & Harrison, 2004) отмечают, что многие менеджеры сегодня «словно лемминги» следуем за последними трендами, вместо того чтобы заботиться об использовании оптимального подхода. Кроме того (Coplien & Harrison, 2004) обеспокоены тем, что Agile отходит от принципов, заложенных в Manifesto. Всё чаще стремление направлено на сам факт применения agile подхода без осмысления лежащих в его основе принципов.

В качестве одного из основных рисков agile проекта (Boehm & Turner, 2003) выделил возможные ошибки при разработке, так как усложняется контроль со стороны из-за отсутствия документации.

Существует точка зрения, что в силу того, что для agile проекта требуется более подготовленная в техническом плане и достаточно самостоятельная команда, успех проекта во многом обеспечен именно этим фактом, а не применением какой-либо методологии (Cohen, Lindvall, & Costa, 2004). В таком случае большинство исследований, касающихся эффективности подхода становятся необъективными.

1.3 История развития взглядов на гибкие методологии

Agile методологии - целый набор различных методик: SCRUM, Xtreme programming, Lean и другие, но объединяет их соответствие 4 базовым принципам, описанным в Agile Manifesto в 2001 году:

· Люди и взаимодействие важнее процессов и инструментов

· Работающий продукт важнее исчерпывающей документации

· Сотрудничество с заказчиком важнее согласования условий контракта

· Готовность к изменениям важнее следования первоначальному плану

Тем не менее, Agile не появился в 2001 году в головах нескольких человек, на самом деле история его развития насчитывает несколько десятков, и Manifesto явился лишь закреплением основ.

Несовершенство существующего подхода осознавалось задолго до 2001 года, и предпринимались попытки применения новых подходов. Уже в 1970-1980 годах применялись итеративные и инкрементные методологии, которые имели серьёзные преимущества в скорости реализации проектов и их эффективности. Например, EVO, RAD, DSDM- всё это методологии очень близкие к идеям гибкого управления проектами, они появились и использовались задолго до манифеста. Многие даже имели определённый успех: в 1988 году компания представила свою методологию Rapid Iterative Production Prototyping (RIPP), благодаря которой им удалось значительно сократить время разработки программного обеспечения. Компания гарантировала клиентам готовый продукт в течение 90 дней или возврат денег.

Наиболее интересной частью статьи выглядит таблица сравнения принципов из Agile Manifesto с методологиями предыдущих подходов. Сравнительно новые только 2 пункта из 12 , а все остальные - уже были отмечены или даже применены в упомянутых выше методологиях. Другими словами, большинство принципов agile - результат нескольких десятилетий развития альтернативных подходов к реализации проектов.

Отличный обзор эмпирических статей на тему Agile методологий представили (Dybе & Dingsшyr, 2008). Были обнаружены 1996 работ, 36 из которых оказались эмпирическими и были отобраны для анализа. В ходе детального обзора и систематизации, авторы пришли к выводу, что существует нехватка качественных эмпирических исследований на эту тему.

1.4 Гибкие методологии в сравнении с традиционным подходом к управлению проектами

Несмотря на достаточно долгий период успешного применения в различных проектах, многие менеджеры до сих пор относятся скептически к agile методологии и предпочитают традиционные методы. Такая позиция частично обоснована: все проекты уникальны и требуют различного полхода. Этот аспект хорошо описан в статье (Fernandez & Fernandez, 2008). Ответ на вопрос кроется в ситуации применения. Авторы выделают 4 типа начальных условий проекта:

1. Цель и путь её достижения определены

2. Определённая цель, без пути достижения

3. Определённый путь, без определённой цели

4. Неопределённая цель и путь

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

1.5 Ключевые факторы успеха IT проектов, использующих гибкие методологии

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

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

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

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

Первым концепцию ключевого фактора успеха предложил (Daniel, 1961) в своей статье в Harvard Business Review «Management Information Crisis». Более подробно термин раскрыл (Rockart, 1979):

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

Стоит отметить, что модель КФУ является сравнительно хорошей моделью, но она, как и любая другая модель, имеет некоторые недостатки и упрощения:

Однофакторность. Модель учитывает каждый фактор в отдельности, тогда как связь между факторами не менее важна (Nandhakumar, 1996)

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

Ключевые факторы успеха (КФУ) для управления проектами довольно хорошо освещены различными авторами. (Fortune & White, 2006) В своей статье проанализировали 63 публикации и выделили самые популярные КФУ. Оказалось, что у исследователей нет единогласия во мнениях: поддержка руководства, чёткие и реалистичные цели, детальный план - факторы, получившие наибольшее количество упоминаний, встречались все три вместе только в 17% работ.

В области IT проектов также есть определённый пласт работ по данной проблематике, однако и в данном случае консенсуса среди исследователей нет. (Misra, Kumar, & Kumar, 2009) В своей работе провели масштабное исследование ключевых факторов успеха в проектах, использующих гибкие методологии. Авторы акцентировали своё внимание на разработке программного обеспечения, но никаких существенных препятствий для распространения выводов на IT сферу в целом нет.

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

(Misra, Kumar, & Kumar, 2009) Выделили следующие факторы как наиболее существенные:

1. Ориентация на потребителя

2. Время принятия решений

3. Распределённость команды (географическая)

4. Размер команды

5. Корпоративная культура

6. Планирование и контроль

7. Компетентность

8. Личные характеристики

9. Коммуникация и переговоры

10. Социально-культурные особенности

11. Знания и обучение

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

Основные противоречия у исследователей возникают в отношении 3 факторов:

· Распределённость команды

· Размер команды

· Знания и обучение

Высказываются различные точки зрения - (Dybе & Dingsшyr, 2008) отмечают, что важно не просто расположить всю команду вместе, но и покупателя тоже, так как это позволяет детально обсуждать все рабочие моменты. В свою очередь (Misra, Kumar, & Kumar, 2009), несмотря на включение этого фактора в теоретическую модель, не нашли практического подтверждения значимости для успеха проекта. Такой же результат получил (Livermore, 2008) в своём исследовании. Таким образом, стоит отметить, что расположение команды проекта в одном месте - аспект требующий дальнейшего изучения.

(Misra, Kumar, & Kumar, 2009) Не обнаружили и серьёзной корреляции успешности проекта и размера команды, хотя в литературе главенствует точка зрения, что Agile методологии были разработаны и применимы к небольшим командам.

(Livermore, 2008)Отметил, что Scrum, как одна из гибких методологий применим как к большим проектам (и, соответственно, командам), так и к крупным, в отличие от Extreme Programming и других.

Знаний и обучения команды также существуют противоречивые точки зрения: с одной стороны опытная команда показывает лучшие результаты (Wysocki, 2012), что довольно ожидаемо и подтверждается исследованиями. С другой стороны - обучение именно методологии не выглядит столь однозначно. (Livermore, 2008) обнаружил значительную корреляцию между успехом проектов и обучением, в то время как (Misra, Kumar, & Kumar, 2009) не нашли подтверждения этой позиции в своём эмпирическом исследовании. Стоит отметить, что выборки и в одном, и в другом случае были значимые статистически и обладали большим числом респондентов из разных областей (более 100 и более 200 соответственно)

1.6 Ситуационный подход в управлении проектами в сфере информационных технологий

С каждым годом увеличивается разнообразие проектов - по сферам бизнеса, масштабу и другим факторам. В ответ на это менеджеры разрабатывают новые методы управления этими проектами. Надёжный контроль возможен только тогда, когда управляющая система имеет разнообразие действий не ниже, чем разнообразие вероятных действий управляемой системы. Так звучит изложенный в более понятных терминах «Закон о необходимом разнообразии» сформулированный математиком Уильямом Эшби в книге «Введение в Кибернетику». В первоначальном варианте он был сформулирован для технических систем и звучал следующим образом: «Разнообразие исходов [ситуации], если оно минимально, может быть еще более уменьшено лишь за счет соответствующего увеличения разнообразия, которым располагает регулятор» (Эшби, 2015) в главе 11. Но этот же закон работает и для других систем, таких как организация или проект, впоследствии его даже стали называть «Первым законом управления». Таким образом, для эффективного управления необходимо увеличивать разнообразие возможных действий - использовать разные методологии и их комбинации.

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

(Howell et al., 2010) в своей работе на основе анализа литературы предложили модель, позволяющую соотнести особенности проекта и наиболее эффективную методологию.

Рисунок 3. График Неопределённость - последствия

По горизонтальной оси представлена степень неопределённости, по вертикальной - значимость последствий. В эти 2 измерения включены все факторы, выделенные авторами при анализе литературы:

· Степень неопределённости включает неопределённость, сложность и срочность проекта

· Значимость последствий - критичность последствий и ответственность команды.

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

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

Рассмотрением такого гибридного подхода занялись (Baird & Riggins, 2012) статьи «Planning and sprinting: Use of a hybrid project management methodology within a CIS capstone course». В качестве проектных команд у исследователей выступали группы студентов, выполнявших определённый проект. Этот факт, конечно, накладывает некоторые ограничения на применение результатов: переносить прямо в сферу бизнеса можно с трудом.

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

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

1.7 Общее описание ИТ проектов

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

IT, на сегодняшний день, - одна из наиболее динамично развивающихся сфер. Компании не могут обойтись без различных систем (системы безопасности, CRM, ERP систем) и серверов, поддерживающих бизнес, так и без сайтов и страничек в социальных сетях. На сегодняшний день значительное количество проектов в сфере IT завершаются с превышением бюджета, сроков, либо оборачиваются полной неудачей. Согласно отчёту CHAOS Summary 2010 (“CHAOS Summary 2010,”[Электронный ресурс] 2010) только 37% проектов завершаются успешно. Ещё 42% испытывают затруднения по сроках, бюджету или качеству, а оставшиеся 21% - считаются полностью проваленными. Хотя наблюдается определённая положительная тенденция, серьёзных улучшениях пока не приходится. 37% довольно малая часть от общего количества проектов. Данный отчёт в основном акцентируется на проектах по разработке программного обеспечения, однако похожая ситуация наблюдается и с другими проектами.

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

1.8 Особенности управления проектами в разных странах

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

Наиболее популярную типологию ценностей организации представил Г Хофштед: в его терминологии представлено 5 индексов, которые зависят от национальной культуры.

· Индивидуализм - коллективизм

· Дистанция власти

· Избегание неопределённости

· Феминность - маскулинность

· Ориентация на долгосрочную

Первоначально было выделено 4 измерения, последнее - Ориентация на долгосрочную перспективу, было добавлено в последующих работах. Данные для анализа культурных ценностей были получены авторов во многом случайно, когда он работал психологом в крупной межнациональной корпорации - IBM, и занимался там исследованием. За время проведения с 1967 по 1971 было проанализировано более 116000 сотрудников из множества стран.

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

Индивидуализм - коллективизм. В странах с преобладающей культурой индивидуализма общество даёт индивиду значительно больше свободы, меньше связывает его с окружающими: он заботится только о себе и, возможно, ближайших членах семьи. В более коллективистских странах люди ближе друг к другу и ощущают себя включёнными в группу. Они разделяют групповые интересы и мнения, а группа в некоторой степени защищает их, даёт поддержку в беде. Есть сильная зависимость между душевым ВВП и степенью индивидуализма: индивидуалистские страны, как правило, богаче. Управление проектами - идея появившаяся в индивидуалистских странах. В более коллективистских странах, гибкие структуры и временный характер проектов ставят людей в положение, когда они не привязаны к какой-то определённой группе и испытывают отчуждённость. Это непривычная для них ситуация. Для того чтобы избежать подобной ситуации (Hofstede, 1983) предлагает больше внимания уделять отношениям людей в проекте. Лучше использовать сложившиеся команды или формировать их из людей одной группы. Стоит также учитывать при планировании сроков время на установление отношений в команде.

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

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

По двум измерениям - Дистанции власти и Принятию неопределённости, страны были расположены в плоскости.

Рисунок 4. Распределение стран по кластерам, в зависимости от культурных особенностей

Горизонтальная ось - индекс дистанции власти, вертикальная ось - индекс принятия неопределённости. Страны разбились на несколько кластеров. Правый верхний угол соответствует модели «семьи» - высокая дистанция власти, низкий индекс принятия неопределённости. Правый нижний угол - модель «пирамиды» высокий индекс дистанции власти и принятия неопределённости. Левый нижний- «хорошо смазанная машина», низкий индекс дистанции власти и высокий принятия неопределённости. Левый верхний угол - «деревенский рынок», низкие индексы дистанции власти и принятия неопределённости. Управление проектами предполагает модель «деревенского рынка», когда иерархия не столь важна (их может быть две - проектная и функциональная), важно не бояться неопределённости и уметь решать конфликты с помощью переговоров (Hofstede, 1983). Для других типов культур необходимо приспосабливать управление для достижения лучшего результата.

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

В этих терминах Российской культуре соответствует:

· Индивидуализм

· Высокая дистанция власти

· Высокая степень избегания неопределённости

· Феминность

· Ориентация на краткосрочную перспективу

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

В Своде Знаний по управлению проектами PMBoK: PMI культура отмечена как один из важных факторов среды организации. «В свете глобализации понимание влияния культур критически важно» Культура становится критическим фактором в определении успеха проекта». PMBOK. Некоторые исследователи также отмечают, что одно из предположений PMBOK: в управлении проектами существует неизменная часть и вариативная часть, на которую факторы национальной культуры оказывают прямое влияние. Особенно это актуально для проектов, в которые вовлечена мультикультурная команда, либо географически распределённая по разным местам. В Российских условиях - самая большая в мире и мультинациональная страна, это довольно часто встречающаяся ситуация, поэтому эта тема особенно актуальная для российских менеджеров проектов.

1.9 Этнокультурные особенности проектной деятельности в России

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

Сегодня огромное количество данных собирается о людях из разных стран, в том числе достаточно данных об этнокультурных характеристиках. В частности The World Values Survey (www.worldvaluessurvey.org) - глобальная сеть учёных-социологов, занимающаяся изучением изменения в ценностных установках, а также их влиянием на социальную, политическую и другие сферы жизни. На основе данных с этого портала построена, а также собственного исследования менеджеров, (Кожевникова, 2013) была составлена таблица ценностных ориентиров россиян по сравнению с американцами.

Таблица 1Сравнение россиян с жителями США.

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

Пункты «Формализм и требования», «Инициатива и достижения», «Доверие и толерантность» представляют непосредственный интерес для практиков гибких методологий управления проектами в IT и других сферах. Тот факт, что россияне «признают менее формальный подход», является позитивным моментом, так как Agile практики основаны на менее формальной и более личной (не стоит воспринимать абсолютно) коммуникации, предпочитая неформальные планы и непосредственное общение между членами команды. Напротив, относительно низкий уровень доверия и толерантности, а также низкое желание проявлять инициативу и слабая ориентация на достижение являются негативными факторами. Основой практически каждой гибкой методологии управления проектами является слаженная команда, обладающая должной степенью самостоятельности. Вполне очевидно, что низкая степень доверия и желания проявлять инициативу негативным образом сказываются на способностях команды.

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

1.10 Переход на agile с традиционного подхода к управлению проектами

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

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

Сложность перехода на новую методологию варьируется от организации к организации и зависит от множества факторов. Менеджер должен уделить особенное внимание обучению команды новым методикам, донесению ценности новой методологии до команды, ресурсной поддержке внедрения, апробации нового подхода (Fernandes, Ward, & Araъjo, 2015).

Важным аспектом при внедрении являются также способности персонала. (Cockburn, 2002) отмечал, что различия людей делают их более или менее приспособленными для определённого типа работы. (Boehm & Turner, 2003) развили классифицию, выделив 5 типов сотрудников:

3 - способны к переосмыслению метода, нарушению его правил для успешного применения в совершенно новой, непредсказуемой ситуации

2 - Способны к приспособлению метода к текущей ситуации

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

1 В - После обучения способны выполнять стандартные процедуры

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

Для успешного внедрения гибких методологий необходимо достаточноеколичество сотрудников 2 и 3 типа. Если в организации значительная доля негибких сотрудников 1В, внедрение agile подхода рискованно. Стоит рассмотреть плановый, либо гибридный подход, который предполагает более основательное и формализованное планирование. Стоит также отметить, что данный подход даже более соответствует российской организационной культуре (Кожевникова, 2013).

Выводы по главе .

Гибкие методологии являются одной из главных альтернатив традиционному подходу к управлению проектами. Особенно эффективны они в условиях постоянно меняющихся условий среды, а значит - и требований к продукту. Подобная ситуация особенно характерна для сферы IT. Модель КФУ является хорошим способом показать факторы, которым менеджеру стоит уделить наибольшее внимание. В зарубежной литературе на данную тему нет единогласия: исследователи выделяют разные факторы в качестве ключевых для успех проекта. В России же подобных исследований практически нет. В то время как между странами существуют объективные различия в социокультурных факторах. Они не позволяют с большой долей вероятности проецировать выводы зарубежных исследований на российские компании.

2. Эмпирическое исследование ключевых факторов успеха для IT проектов

2.1 Методология исследования

Гибкие методологии управления проектами, базирующиеся на создании бизнес-ценности для заказчика в процессе постепенной итеративной разработки продукта прочно вошли в проекты в сфере IT. Они доказали свою эффективность в условиях неопределённости, которая сопровождает бизнес нашего времени. Однако вопрос применения agile на практике до сих пор вызывает споры среди теоретиков и практиков. В англоязычной литературе достаточно статей относительно ключевых факторов успеха agile проекта, но сложно сказать, что они единогласно выделяют какие-либо показатели (Fortune & White, 2006). Более того, в этих работах исследуются респонденты из разных стран, в то время как каждая страна имеет свои особенности в управлении проектами (Hofstede, 1983). Подобных работ о российских проектах крайне мало. Закрыть этот пробел - основная цель исследования.

Проведённое исследование можно разбить на 4 этапа:

· Подготовительный этап

· Этап сбора информации

· Этап анализа полученной информации

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

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

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

2.2 Исследовательские гипотезы

На основе результатов предыдущих исследований были выдвинуты следующие гипотезы:

Таблица 2. Исследовательские гипотезы

2.3 Описание процесса проведения опроса

Опрос - основной метод сбора информации в исследовании. Основой для вопросника послужила методика, применённая в статье (Misra, Kumar, & Kumar, 2009). Оригинальный опросник был переведён на русский язык и впоследствии модифицирован. После анализа предварительных интервью с менеджерами были добавлены несколько вопросов:

· Команда проекта и руководство компании регулярно обмениваются информацией о ходе реализации проекта

· Мы используем специальное ПО для удобства управления и коммуникации внутри команды

· У команды и руководства имелось чёткое видение, какого результата проект должен достичь

· Каждый член команды хорошо осознаёт свою роль и функции внутри проекта

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

Часть вопросов, была исключена из методики после обсуждения в ходе интервью с менеджерами и в ходе пилотажа исследования силами студентов НИУ ВШЭ. В частности переменная «Социокультурные факторы» не имеет смысла в контексте данного исследования, так как исследование проводится в рамках одной страны - России, поэтому факторы предопределены. В исследовании (Misra, Kumar, & Kumar, 2009) данная переменная отвечает за различия между странами, в которых осуществляют деятельность респонденты, что в данном случае некорректно.

После окончательной проверки опрос был размещён на сервисе Google Docs, а затем опубликован на тематических форумах и группах в социальных сетях:

· http://www.cyberforum.ru/

· http://programmersforum.ru/

· http://www.pmprofy.ru/

· http://www.microsoftproject.ru/

· http://www.pmi.ru/forum/

· https://www.facebook.com/

· https://www.linkedin.com/

Всего получено 17 ответов. Достаточное разнообразие было достигнуто как по опыту респондентов, так и по размерам организации.

Выдвижение исследовательских гипотез

2.4 Анализ результатов

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

2.4.1 Демографические показатели респондентов

В ходе исследования также была собрана дополнительная информация о респондентах. Большинство респондентов представляют компании в отраслях, связанных с компьютерами (software, hardware и т.п.) (76%), остальные отрасли представляют по 1 респонденту (6%) - телекоммуникации, консалтинг, продажи и финансы.

Значительно большее разнообразие имеется по размерам представленных организаций:

Таблица 3. Описательная статистика - количество работников в организации

Можно сказать, что представлены как совсем небольшие организации в 10-20 человек, так и средние и крупные компании.

Большинство респондентов представляют команды в 5-10 человек (41,2%) или 11-20 человек (41,2%), остальные размеры команды представлены небольшим количеством респондентов (по 5,9%). Стоит отметить довольно ровную выборку: примерно 50% респондентов представляют маленькие команды (до 10 человек) и 50% команды более 10 человек.

Самый важный момент в демографической части опроса - опыт работы с Agile методологиями:

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

Выборка довольно ровная: присутствуют респонденты с различным опытом работы с agile методологиями. Некоторое преобладание респондентов с опытом до 3 лёт, вероятно, обуславливается тем фактом, что agile подход в России только начинает набирать популярность.

2.4.2 Тест надёжности переменных модели

Анализ валидности был проведён для переменных, составленных из нескольких показателей. В качестве способа определения был выбран коэффициент Альфа Кронбаха. Данный показатель оценивает внутреннюю согласованность переменных и измеряется в значениях от 0 до 1, где 0 - полностью не согласованы, 1 - полностью согласованы. Таким образом, чем выше значение, тем лучше для исследования. Существуют различные точки зрения на порог отсечения, но наиболее популярное пороговое значение - 0,7.В таблице представлены результаты для составных переменных:

Таблица 5. Анализ валидности переменных

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

2.4.3 Анализ корреляций независимых переменных с успешностью проекта

Основная концепция исследования - анализ взаимосвязи между 15 независимыми переменными (представляющими критические факторы успеха) и 1 зависимой - успешностью проекта. Одним из основных инструментов является коэффициент корреляции Пирсона. Для данного исследования уровень значимости - 95%. Результаты проведённого анализа представлены в таблице.

Таблица 6. Корреляция переменных

По результатам анализа, только 3 независимые переменные обнаружили статистически значимую связь с успешностью проекта: Ориентация на удовлетворённость потребителя, Время на принятие решений, Контроль. Данные результаты согласуются с выводами исследования (Misra, Kumar, & Kumar, 2009). Самую сильную взаимосвязь с успешностью проекта.

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

2.4.4 Построение модели множественной линейной регрессии

Подобные документы

Сущность и функции корпоративной системы управления проектами (КСУП), ее элементы и предъявляемые к ней требования. Базовые методологии и процессы управления проектами. Характеристика основных ролей в контексте КСУП, этапы ее разработки и внедрения.

контрольная работа , добавлен 13.06.2013


Сущность понятия "проект". Связь методологии управления проектами с другими управленческими дисциплинами. Разница между менеджером и владельцем. Источники успеха руководителя. Рычаги управления проектами. Жизненный цикл и фазы инвестиционного проекта.

презентация , добавлен 21.11.2011


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

курсовая работа , добавлен 07.07.2015


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

курсовая работа , добавлен 14.01.2014


Характеристика этапов развития управления проектами в России. Понятие, роль и актуальность проектного управления. Основные формы планирования и контроля текущей деятельности фирмы. Особенности управления проектами в фирмах-партнерах "1С:Франчайзи".

курсовая работа , добавлен 23.10.2015


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

практическая работа , добавлен 07.04.2015


Управление проектами в рыночных условиях, особенности управления ими в России. Управление эффективностью, рентабельностью и продолжительностью работы проекта. Деятельность людей в проектах. Факторы и правила достижения успеха в управлении проектами.

курсовая работа , добавлен 25.03.2008


Понятие, состав и виды проектов. Этапы управления проектами на предприятии. Организационно-экономическая характеристика ТОО "Казцинктех". Анализ экономических показателей работы предприятия. Основные проблемы в управления проектами и пути их решения.

дипломная работа , добавлен 22.05.2012


Проект и его характеристика. Управление проектом как одна из самых сложных и трудоемких задач управленческой деятельности. Виды организационных структур управления проектами. Анализ организационной структуры управления проектами в ООО "Ай-Ти Сервис".

дипломная работа , добавлен 18.02.2013


Понятие и структура корпоративной системы управления проектами. Основные методы диагностики уровня зрелости управления проектами. Инициация и планирование, финансирование проектов. Управление программами, рисками, коммуникациями и портфелем предприятия.

Однажды в Россию на завод по сбору автомобилей знаменитой корпорации Тойота приехал топ-менеджер.

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

В основе всего лежала agile методология. Но то что он увидел на совещании повергло его в шок…

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

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

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

Так прошло минут 15. И тут директор с криком “Демократия кончилась, теперь снова диктатура!” начал раздавать распоряжения, который подчиненные стали усердно записывать в свои ежедневники.

Гость из Японии от увиденного смог вымолвить всего одну фразу: “Но это же не agile управление проектами.

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

Я уж не говорю про идеи на планерках…”. На что генеральный ответил: “Да, это не принципы аджайл! В России такие гибкие методы не работают!”.

Ну не работают они…

Скорей всего у Вас тоже в голове сейчас крутится вопрос: “Что же это за загадочная такая фраза?”.

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

Виноваты программисты

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

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

1. Идея;
2. Техническое задание;
3. Создание дизайна;
4. Программирование;
5. Тестирование;
6. Запуск итоговой версии.

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

В результате при создании дизайна или программировании, новые идеи просто приходилось игнорировать.

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

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

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

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

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

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

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

Именно это собрание в горной деревушке Сноубёрд в феврале 2001 года и считается зарождением методологии agile (кто-то даже называет это философией).

Поскольку в большинстве своем эти люди были программисты, то результатом собрания был выпуск “Манифеста гибкой методологии разработки программного обеспечения” (по английски Agile Manifesto) и принципов Аджайла.

В связи с тем, что у программистов с применением данной философии и принципов начали появляться весьма отличные результаты, то и многие организации стали переходить на применение этих подходов.

Коротко и по делу

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

1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.

Принципы, упоминающиеся в манифесте Agile. Просто прочтите, поймёте чуть дальше.

• Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
• Частая поставка рабочего программного обеспечения (каждый месяц или неделю, или ещё чаще);
• И много еще подобных.

“Что за чушь я только что прочитал? Ни слова не понял!”. Думаю у Вас такие сейчас мысли.

Скажу честно, что такое Agile как методология (а также что написано в манифесте) я сам понял далеко не сразу, книги и статьи давали поверхностное описание, пока я не увидел всё это на практике.

Поэтому я сэкономлю Вам огромное количество времени и расскажу коротко и по делу.

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

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

На примере всё ясно

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

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

Обычный хлебзавод в России

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

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

После исследований технолог разработает хлеб на свой вкус и приносит его директору.

Он пробует новый продукт и решает - наградить технолога словами “Молодец. Держи бублик” или сказать “Нет. Переделывай”.

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

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

Agile-хлебзавод в России

Генеральному директору приходит идея разработать новый сорт хлеба. И вот здесь начинаются чудеса.

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

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

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

ВНЕДРЯТЬ ИЛИ ПОСЛАТЬ

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

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

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

Но это в корне не верно. В России эту методологию активно использует:

• Банк “Альфа-банк”;
• Сеть пиццерий “Додо пицца”;
• Бухгалтерский сервис “Кнопка”.

И если с “Альфа-банком” все понятно, большая компания, у них есть ресурсы и люди для внедрения инноваций в свою систему.

То с “Додо пицца” и “Кнопка” всё намного интереснее, ведь компании небольшие. И по моему мнению именно одним из факторов их успеха стал этот подход.

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

1. Благодаря применению “гибких” подходов возрастает качество получаемых результатов;
2. Результаты получаются гораздо быстрее и эффективнее за счет чего экономится время и затраты;
3. Компания лучше адаптирована к изменениям (даже непредвиденным) и конкуренции;
4. Создание проектов происходит более планируемо и контролируемо;
5. Компания может создавать продукты, которые будут ждать и покупать их потребители.

Внутренняя работа

Единственный вопрос, на который я долго искал ответ, как же тогда происходит работа в agile-компании.

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

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

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

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

3. Тестирование. Все идеи и знания суммируются в тестовый рецепт. Данный рецепт выпекается небольшой пробной партией для получения по нему обратной связи на закрытой дегустации среди обычных покупателей (!!!).
4. Сбор обратной связи. Покупатели едят хлеб и высказывают свои пожелания. На основании этого в тестовый рецепт вносятся изменения и доработки. Финал.

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

Хочу себе

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

И Вы думаете, что agile это то, что Вам так нужно. Ведь так можно создать что-то новое, поистине инновационный продукт.

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

Это топ-5 вопросов, которые задают себе все собственники, когда видят эту методологию.

Подходит малому бизнесу? Если Вы не выпускаете постоянно новые продукты или не реализуете постоянно новые проекты, а работаете на “старом”, то с большей долей вероятности НЕТ.

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

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

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

А это означает исключительно работу в команде и более широкий кругозор.

Кто должен быть начальником? Прозвучит непривычно, но в agile-компаниях нет начальников.

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

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

НАС УЖЕ БОЛЕЕ 29 000 чел.
ВКЛЮЧАЙТЕСЬ

Подводные камни

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

Их осознают компании только после внедрения. Поэтому заранее “Пожалуйста” за то, что спас Вас от потери денег и времени.

Аджайл - не инструмент

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

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

Сюда включается или Скрам (инструменты управления). О каждом инструменте в дальнейшем мы конечно же напишем статьи, но Вы должны понять, что аджайл это прежде всего философия, принятая в компании.

Команда

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

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

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

Чужой нос

Личного пространства в компании больше нет. Из серии - я к тебе не лезу и ты ко мне не лезь. Этого больше нет.

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

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

Оплата

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

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

Текучка

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

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

Коротко о главном

Для кого все таки подойдут методы управления проектами agile? Для больших компаний или для маленьких? На самом деле и для тех, и для других.

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

Ведь Вы перестаете работать по-старинке, а Ваши сотрудники перестают думать (и работать) как большинство Ваших конкурентов.

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

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

Казалось бы, актуальность на лицо. Я же предлагаю Вам пойти другим путем. Не рубить с плеча.

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

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

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

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

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

Scrum

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

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

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

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

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

Extreme Programming

Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.

Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.

Концепция строится на основании двенадцати приёмов:

Канбан

Однако сегодня многие команды рассматривают иные варианты и обращают внимание на другие методологии. Одной из них стал канбан. CTO ConvertKit Грант Аммонс (Grant Ammons) говорит , что компании сперва адаптируют Scrum, который учит их необходимым дисциплинам для разработки ПО, а затем ищут более удобную альтернативу и обращаются к канбану.

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

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

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

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

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

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

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

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

Три объёма значения Agile

В первом, более узком значении, этот термин стал с начала 2000-х использоваться в сфере разработки программного обеспечения, когда в американском штате Юта, на горном курорте, собрались отраслевые специалисты, чтобы обсудить методики и практики создания программных продуктов, востребованных конечным потребителем. Результатом той встречи стал Манифест (Agile Manifesto) разработки программных продуктов, с 12-ю принципами, которые, в первую очередь, касались узкой сферы деятельности авторов, но потенциально могли быть распространены и на некоторые другие бизнес-проекты.

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

1. Работа над проектом ведётся итерациями – короткими циклами (спринтами). (В случае с разработкой программного обеспечения продолжительность этих циклов составляет от 1 недели до 1 месяца).
2. По завершении каждого цикла выходит продукт, который уже можно применять в бизнесе. Для программного обеспечения таким продуктом может стать приложение или только его часть, однако даже «сырой» софт уже можно и нужно пробовать в деле.
3. Продукт проверяется заказчиком или пользователями, которые поддерживают с разработчиками постоянную обратную связь. Клиентоориентированный подход применяется в течение всего проекта (всех итераций).
4. Любые замечания быстро включаются в доработку, а изменения, позволившие сразу по ходу подправить разработку продукта, – приветствуются, поскольку это позволяет не накапливать глобальные ошибки системы.

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

Быструю обратную связь в настройке конечного формата производства на заводах «Toyota» обеспечивал любой рабочий, который мог стать инициатором остановки конвейера и автором корректировок по донастройке производственного цикла. В масштабах всего производства Agile-трансформация может повлечь за собой переналадку производственной деятельности в целом, если продукт становится результатом живого отклика на текущие потребности клиента. Так, если фабрика выпускала пластиковые тазы, а обратная связь с клиентом демонстрирует потребность в вёдрах, то быстрая адаптация с параллельной корректировкой нюансов (формы ручки, величины, цвета) будет как раз в стиле Agile management (если соблюдены и остальные принципы).

Принципы Agile-управления

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

1. Решающее значение для настройки продукта имеет потребитель и степень его вовлеченности в создание результата.
2. Для принятия решения команды должны быть высокоэффективными и сплочёнными.
3. Поэтапная и цикличная работа становится основой процесса. Проект делится на мелкие части, которые завершаются к определённому сроку до завершения проекта в целом.
4. Фокус оценки результативности направлен на частые представления промежуточных состояний проекта.
5. В работе коллектив опирается на закон Парето, по которому 20% усилий дают 80% эффективности, что позволяет не доводить каждый отдельный цикл до совершенства перед представлением результата потребителю. Продукт совершенствуется естественным образом с каждой новой итерацией.
6. Предполагается обязательное завершение одного этапа перед переходом к следующему.

«Гибкий» подход стал базовым для целого ряда методологических практик, которые отличаются между собой, но включают идеи Agile: Scrum, Kanban, Lean, Crystal и др. Методология Scrum, например, практически всегда рассматриваются в связке с Agile как единая система управления проектами по разработке программного обеспечения.

Метод Scrum демонстрирует, как «гибкий подход» может быть применён на практике в конкретных операциях. Так, например, работа с требованиями по проекту реализуется с помощью четырёх «артефактов»:

• Product backlog предполагает формирование списка требований, созданного по единому шаблону (User Story) и отсортированного по приоритетам. Если требований нет, проект завершается.
• Sprint backlog – это требования ближайшего спринта (этапа), разделённые на задачи без возможности добавлять новые требования в течение спринта. Обязательство на ближайший этап, взятые командой с типом управления Agile, записываются на доске (т. н. Kanban).
• Sprint Goal – общая цель спринта – ориентир при принятии альтернативных решений.
• Sprint Burndown Chart – «диаграмма сгорания». Она показывает насколько продвинулась команда в течение этапа.

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

Характерные ошибки внедрения Agile и недостатки подхода

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

К распространённым ошибкам внедрения относятся следующие:

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

«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было наверно самой сложной задачей»

— Роджер Лаунис, историк НАСА

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

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

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

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

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

В этой статье мы рассмотрим:

• Классический проектный менеджмент
• Agile
• Scrum
• Lean
• Kanban
• Six Sigma
• PRINCE2

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

Почему «управление проектами»?

Имена Нила Армстронга и Базза Олдрина навсегда войдут в историю как символы одного из величайших достижений человечества – высадке человека на Луну. Однако основной вклад в это событие внесли 400 000 сотрудников НАСА и 20 000 компаний и университетов, работавших вместе над миссией «Аполлон».

В 1961 году Джон Кеннеди поставил задачу высадить человека на спутнике Земли и вернуть его обратно – при том, что на тот момент НАСА отправляли человека в космос лишь на 15 минут. Такая амбициозная цель потребовала невероятного количества ресурсов, кооперации, инноваций и планирования.

Как говорится в книге НАСА «Managing the Moon Program», основная проблема состояла не в том, «что делать?» , а в том, «как сделать столько за такой короткий срок?». По словам доктора Макса Фагета (Dr. Max Faget), главы инжиниринга в Космическом центра имени Линдона Джонсона (The Lyndon B. Johnson Space Center, JSC) , тогда в НАСА не представляли, как уложить все необходимые действия в 10 лет. А потому первым шагом стало «разбить проект на управляемые этапы».

Затем важно было ускорить выполнение каждой отдельной фазы и удостовериться, что команды и компании, работающие на каждой фазе, эффективно взаимодействуют друг с другом и вовремя поставляют результаты. Эта задача была возложена на доктора Джорджа Мюллера (George E. Muller), управлявшего каждой частью проекта «Аполлон», от Белого Дома до поставщика самой мелкой детали. Чтобы контролировать проект было легче, он решил разбить проект на 5 областей: «Контроль Программы», «Системная Инженерия», «Тестирование», «Надёжность и Качество» и «Лётная эксплуатация». Схема управления программой Аполлон представлена на Рисунке 1 .

Эта система из 5 этапов – названных «Этапами GEM» в честь инициалов доктора Мюллера – была разработаны «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать», как отмечает сам Мюллер. «Контроль Программы» определял, что нужно сделать, управлял бюджетом и требованиями, а также управлял взаимосвязями элементов программы. Область «Системная инженерия» отвечала за разработку новых устройств и узлов, «Тестирование» за то, что эти новые элементы работают, «Надёжность и Качество» проверяли разработанные элементы на соответствие требованиям и стандартам, а «Лётная эксплуатация» отвечала за то, что эти узлы будут работать во время полёта.

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

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

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

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

Однако, если Вы – шеф-повар, и готовите не одно блюдо, а несколько, например, салат (приготовление которого состоит из 3 этапов) и десерт (который нужно только подать), то Вам потребуется инструмент, позволяющий отслеживать временные затраты на каждый из элементов и время, когда они должны быть готовы. И тут на помощь приходит один из первых современных инструментов проектного управления: Диаграмма Гантта, представленная на Рисунке 2 .

Изобретённая независимо Ко ролем Адамеки (Korol Adamecki) и Генри Л. Ганттом (Genry L. Gantt) в начале XX в., диаграмма Гантта показывает расписание проекта основываясь на датах окончания и завершения задач. В неё вносятся задачи, их длительности и взаимосвязи, а затем высчитывается критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта. Взаимосвязи между началом и окончанием разных задач очень важны – вы же не можете подать гостям суп, пока вы его не сварили, не так ли?

Так вот, типовой проект очень похож на проект приготовления и подачи ужина, только в нём гораздо больше задач, взаимосвязей, дедлайнов и видов ресурсов. Проектам с жёсткими дедлайнами диаграмма Гантта помогает решить, когда лучше начинать те или иные задачи, чтобы сократить время реализации. А для проектов с сильными ресурсными ограничениями, диаграмма Гантта предоставляет возможность построить схему в форме событийной цепочки процессов (event-driven process chain) для планирования ресурсов.

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

Для таких проектов лучше подходят гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

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

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

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

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

Agile: Гибкий итеративно-инкрементальный подход к управлению проектами и продуктами, ориентированный на динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует множество методов, базирующихся на идеях Agile, самые популярные из которых – Scrum и Kanban.

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

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

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

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

Менеджер проекта (руководитель проекта, project manager, PM): Руководитель команды проекта, ответственный за управление проектом (планирование, реализацию и закрытие проекта).

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

Спринт (Sprint): Итерация (рабочий цикл) в Scrum, длящаяся от недели до месяца, в ходе которой создаётся рабочая версия продукта или его элемент, представляющий ценность для заказчика.

«Классическое» или «традиционное» проектное управление: Наиболее широко распространённый метод управления проектами, основанный на так называемом «водопадном» (Waterfall) или каскадном цикле, при котором задача передаётся последовательно по этапам, напоминающим поток.

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

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

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

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

5 этапов традиционного менеджмента:

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

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

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения. Например в ИТ-проектах на данном этапе выбирается язык программирования. (В отечественной практике данная фаза обычно не выделяется, а термин «разработка» не используется — прим. пер.)

Этап 4. Реализация и тестирование. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.

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

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

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования. Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

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

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

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

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

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на Рисунке 5 .

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова (об истории появления Agile можно прочесть – прим.пер.). Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto) , закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

Сильные стороны Agile

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

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

Вотчина Agile – разработка новых, инновационных продуктов. В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно– нет информации для планирования.

Слабые стороны Agile

В отличие от PRINCE2 и PMBOK Agile – не является ни методологией, ни стандартом. Agile — это набор принципов и ценностей. Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу.

Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. К счастью, существуют готовые наборы практик, которые облегчают Agile-трансформацию организации. К таким наборам относятся фреймворк Scrum, метод Kanban и многие другие – Crystal, LeSS, SAFe, Nexus.

Scrum

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

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

Как уже говорилось, Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены.

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

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

Сильные стороны Scrum

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

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

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

Слабые стороны Scrum

Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга.

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

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

Lean

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

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

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

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

Сильные стороны Lean

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

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

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

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

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

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

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

Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile. Но у Kanban есть 4 столпа, на которых держится вся система:

1. Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
2. Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
3. Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
4. Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban

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

6 сигм (Six Sigma)

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Bill Smith создал концепцию 6 сигм в 1986 году. Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDI:

• Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
• Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
• Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
• Разработка (Develop): На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
• Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

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

Сильные стороны 6 сигм

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

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

Слабые стороны 6 сигм

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

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

PRINCE2

НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PR ojects IN C ontrolled E nvironments version 2 », что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBOK не содержит:

• Специализированных аспектов управления проектом, например, отраслевых;
• Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т.п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

• 7 принципов определяют общие правила управления проектами по PRINCE2, определяют базу методологии;
• 7 процессов определяют шаги продвижения по проектному циклу;
• 7 тем – аспекты, по которым проводится контроль для достижения успеха проекта.

В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

• Бизнес-аспект (Принесёт ли этот проект выгоду?)
• Потребительский аспект (Какой нужен продукт, что мы будем делать?)
• Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

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

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

• Начало проекта (Start ing up a project ): В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
• Инициация проекта (Initiation a project ): В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
• Руководство проектом (Directi ng a project ): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
• Контроль стадии (Control ling a stage ): При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
• Управление созданием продукта (Managing Product Delivery): Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
• Управление границами стадии (Manag ing a stage boundary ): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
• Завершение проекта (Closing a project ): Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.

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

Сильные стороны PRINCE2

• Адаптируемость к особенностям организации;
• Наличие чёткого описания ролей и распределения ответственности;
• Акцент на продуктах проекта;
• Определённые уровни управления;
• Фокус на экономической целесообразности;
• Последовательность проектной работы;
• Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2

• Отсутствие отраслевых практик;
• Отсутствие конкретных инструментов для работы в проекте.

Лучшая система управления проектами … для Вас!

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

Как получить международный сертификат по Agile

Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат ICAgile Certified Professional — наш тренинг