Управление ИТ-проектами с использованием DSDM Agile Project Framework. Часть 1.

© Dynamic Systems Development Method Limited 2014

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

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

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

Сроки сдачи затягиваются, издержки растут, мотивация специалистов снижается, а в итоге страдает качество. Знакомая картина, не правда ли?

Поэтому стремление руководителей обучить персонал вполне объяснимо. И вот люди приходят на курс или тренинг по проектному управлению, а там им рассказывают про доставку пиццы и строительство мостов. А что делать, если на стадии 80% готовности проекта выясняется, что мост должен стоять на полкилометра ниже по течению и иметь не четыре полосы для движения, а восемь? И железнодорожную колею в придачу. Электрифицированную, разумеется. С мостами в реальной жизни так не бывает, а вот с продуктами информационных технологий – напротив – очень часто.

Авторов известных подходов понять можно, увлечение отраслевыми особенностями ведёт к потере универсальности. А именно она позиционируется как важнейшее преимущество PMBOK, PRINCE2®, P2M и ряда других, менее известных практик управления проектами. Отдельные тренеры даже берутся утверждать, что хорошему проектному менеджеру вообще всё равно, какими проектами управлять, главное – это знание методологии. Не будем спорить, вполне возможно, это так и есть, но вот где обитают эти самые fantastic beasts «хорошие проектные менеджеры», тренеры почему-то не рассказывают, поэтому управление ИТ-проектами очень часто приходится поручать именно ИТ-специалистам.

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

• Руководство на уровне организации в целом (governance).
• Собственно управление конкретным проектом (project management).
• Управление созданием продукта (solution delivery).

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

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

Особенности ИТ-проектов

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

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

Главная уязвимость такого подхода в том, что три уровня управления, о которых сказано выше, должны эффективно взаимодействовать и производить эскалацию только в случаях, когда это необходимо. В связке «project management – governance» обычно проблем не возникает, взаимодействие там проработано практически везде. Однако интеграция с техниками на уровне разработки продукта часто становится нетривиальной задачей. Причины этого в том, что многие техники разработки создавались в отрыве от более высоких уровней управления и не учитывают потребности менеджеров, которым, непонятны чисто технологические вопросы.

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

Универсальность vs специализация

Рассмотрим попытку такой синергии на примере интеграции структурированного подхода к управлению проектами PRINCE2® и метода DSDM Agile Project Framework . Известно, что чем больше функций может выполнять инструмент, тем он менее удобен по сравнению с отдельными инструментами, предназначенными именно для этих конкретных функций. Кто использовал швейцарский нож в качестве ножниц, а классический Leatherman вместо отвертки, тот поймет. Теоретически можно построить машину, способную одновременно летать, плавать и ездить по пересеченной местности (и такие попытки делались), но она будет делать всё это в отдельности заметно хуже, чем вертолет, катер и автомобиль-внедорожник, не говоря уже про несравнимые эксплуатационные расходы.

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

Преимущества и ограничения PRINCE2®

Структурированный подход Projects IN Controlled Environments (PRINCE2®) был разработан под эгидой правительства Великобритании для управления ИТ-проектами, но позже подвергся существенным изменениям в целях адаптации для других отраслей. Развитие PRINCE2® принесло ему мировое признание и сделало «de facto» стандартом управления проектами в Великобритании. Еврокомиссия рекомендует этот метод для спонсируемых ей проектов. Однако ради всего этого пришлось пожертвовать, в том числе, и первоначальной ИТ-специализацией.

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

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

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

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

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

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

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

Based on AXELOS PRINCE2® material. Reproduced under licence from AXELOS. All rights reserved.

ИТ-проекты и их продукты

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

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

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

Продолжение следует.

Автор статьи: Игорь Соглаев