Какой метод управления проектами выбрать

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

Во время одного из семинаров PMI в Быдгоще меня очень заинтересовала реакция одного из авторов книг по гибкому управлению проектами - г-на Кристиана Качора [1] когда во время обсуждения один из выступавших убедил всех, что даже мост можно построить с использованием методологии Agile. К сожалению, я не записал именно те слова, которые были написаны, но я надеюсь, что фраза «можно, но зачем?» Прекрасно отражает высказывание г-на Кристиана. Стоит осознать, что методология - это инструмент, который мы используем в конкретном случае. В конце концов, если г-н Анджей купил компьютер для автомобильной мастерской, это не значит, что он выбросит все остальные инструменты. Я не вижу большого смысла стучать по клавиатуре с помощью колпака сплиттера, когда достаточно использовать обычную отвертку. Мы живем во время, когда все происходит быстро, и для непрофессионала, который не знает точно предположений о методологиях, использование гибкой методологии кажется очевидным, потому что все должно быть быстрым, современным, гибким, без лишних документов, потому что это такая подгонка! Я не собираюсь вступать в полемику, потому что она, вероятно, закончилась бы соображениями, подобными тем, которые были изложены в его программах Яном Тадеушем Станиславским - «О превосходстве праздника Пасхи над Рождеством», мне интересно, как помочь в выборе правильной методологии.

В сентябре 2017 года Институт управления проектами опубликовал шестой выпуск сборника передовых методов управления проектами - PMBOK [2] , Важно объединить два отдельных учебника в одно редактируемое целое, поэтому на первой странице моей электронной копии документа я могу прочитать: «Вместе впервые - Руководство PMBOK - Шестое издание + Руководство по гибкой практике» [3] ». Что это значит? Только профессионалы видят необходимость использовать оба этих инструмента, и никто не хочет оценивать их через призму «современности». Кстати, я не совсем согласен с тезисом, что гибкие методологии - это «глоток свежести». Этот ветер дует уже около 20 лет, что является очень длительным периодом перед лицом внезапных перемен в бизнесе. Я думаю, что только настоящий автолюбитель осмелится назвать себя современным 20-летним автомобилем, и технологии, очевидно, стареют медленнее, чем идея.

В таком случае, что мне выбрать?

Мистер Роберт Высоцкий в своей книге [4] довольно широко описывает различия между методологиями. Настолько подробно, что я решил спросить его об алгоритме решения. Что ж, если вы можете описать выбор алгоритма, достаточно предоставить данные и их можно рассчитать. Я уже видел программу, в которую выбрасывается информация, она грохочет, и методология появится автоматически. Вау, как просто. К сожалению, моя радость была довольно короткой и продолжалась до тех пор, пока в первом предложении ответа я не прочитал «... автоматизированный инструмент, я не думаю, что это будет слишком практично ». В следующей части сообщения есть список книг, которые стоит прочитать по этой теме. Избавившись от разочарования и размышлений, я согласился с ним. В конце концов, каждый проект - это конкретная задача, выполняемая в конкретной среде. Количество переменных огромно и практически уникально, поэтому решение о выборе методологии нельзя доверить автомату. Это во много раз компетенции менеджеров, вытекающие из их знаний, опыта и интуиции.

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

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

Категория: Организационная культура - есть ли Agile поддерживающая среда в организации?

1. Утверждение подхода: понимают ли руководство и спонсоры использование гибкой методологии в этом проекте?

1 - ДА
5 - частично
10 - НЕТ

2. Доверие к команде: уверены ли заинтересованные стороны, что команда поймет их видение и потребности?

1 - ДА
5 - вероятно
10 - маловероятно

3. Принятие решений: может ли команда получить автономию и полномочия принимать решения о своей работе?

1 - ДА
5 - вероятный
10 - маловероятно

Категория: Команда - у нас есть правильная команда?

1. Размер команды: каков размер команды проекта?

1 - от 1 до 9
2 - с 10 до 20
3 - с 21 до 30
4 - с 31 до 45
5 - от 46 до 60
6 - от 61 до 80
7 - от 81 до 110
8 - от 111 до 150
9 - от 151 до 200
10 - более 201

2. Уровень опыта: каков уровень опыта членов проектной команды?

1 - большой
5 - средний
10 - отсутствует

3. Доступность для клиентов. Имеет ли команда легкий доступ к бизнес-клиентам?

1 - легко
5 - средний
10 - отсутствует

Категория: Проект - ожидаются ли изменения? Можно ли использовать итеративный подход?

1. Вероятность изменения: какой процент требований, вероятно, изменится в течение месяца?

1 - 50%
5 - 25%
10 - 5%

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

1 - время
5 - деньги
10 человек

3. Инкремент продукта: может ли продукт доставляться итерациями?

1- ДА
5 - возможно
10 - НЕТ

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

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

В Приложении 13, PMBOK, 6-е издание, есть 2 примера (тематические исследования). Первый - это проект интернет-аптеки, реализованный Agile. В рамках проекта была создана интернет-аптека для продажи более дешевых канадских рецептурных лекарств, главным образом, американским клиентам Продажа лекарств является предметом споров как в Канаде, так и в США, и эта отрасль характеризуется быстрым изменением правил и жесткой конкуренцией. Проект встретил крайне нестабильные требования, с серьезными изменениями в течение недели. Он использовал очень короткие итерации (2 дня) и еженедельные версии программного обеспечения, чтобы столкнуться с высокой скоростью изменений.

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

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

В этом случае «гибкий» подход не был принят во внимание. Доверие к поставщикам (команде) было неоднозначным. Принятие решений осуществлялось не локально, а в рамках обязательств, касающихся архитектуры решения и требований, описанных ранее. Элементы конструкции можно было постепенно тестировать в лаборатории, но их нельзя было собрать, и можно было продемонстрировать функциональность. В случае неудачи проекта многие люди были потенциально подвержены риску, поэтому критичность была очень высокой. Изменения были заблокированы, поскольку они затронули многие организации и субподрядчиков. Проект был крупным, и в компании одного поставщика работало более 300 человек. Многие из сотрудников являются специалистами высокого класса, опытными практиками. Доступ к клиенту был невозможен, хотя контрактные аналитики смогли задать вопросы о спецификациях. К сожалению, общение было очень медленным - каждый вопрос и ответ занимает около 10 дней. На основе анализа проекта было установлено, что эту часть (особенно исследование) можно выделить и провести как гибкий проект, но основная часть проекта должна была быть выполнена классическим способом.

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

[1] Я рекомендую: Krystian Kaczor, SCRUM и не только, теория и практика гибких методов, PWN Warsaw 2014

[2] Руководство к Своду знаний по управлению проектами, PMBOK GUIDE, шестое издание, Институт управления проектами, Пенсильвания, 2017

[3] Руководство по гибкой практике, Институт управления проектами, Пенсильвания, 2017

[4] Роберт Высоцкий, Эффективное управление проектами, традиционный, agile extreme, шестое издание, Helion, Gliwice 2013 (Примечание - выпуск 7 в объявлениях)

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