Необходимое примечание (disclaimer): я не имею ничего против управления проектами вообще и руководителей проектов в частности. Мне известна область применения проектного менеджмента, равно как и его ограничения. Я знаю менеджеров проектов, способных получить качественный результат в совершенно не располагающих к тому условиях; я также видел РП, польза от которых ограничивалась созданием протоколов встреч. Во многих проектах я сам был на роли менеджера, и хорошо знаю, в чём заключается эта работа. Ну и формальное обучение проходил, разумеется. Данная заметка не имеет цели поставить под вопрос пользу от дисциплины управления проектами в общем случае. Лишь в частном.

Теперь перейдём к теме.

В обычном, не таком уж гибком мире, управление проектами способно принести ИТ-подразделению неоценимую помощь, а именно: получить-таки требуемые результаты в ограниченные сроки и с ограниченным бюджетом. Но в современном, модном и гибком мире, особенно когда гибкость проявляют лишь одна-две команды, управление проектами большой ценности не несёт. Напротив, как мы уже многократно обсуждали на нашем портале и подробно рассматриваем на учебном курсе “Основы DevOps“, управление проектами – иная парадигма по отношению к управлению результатами, а потому в простых случаях а) не требуется, б) может принести вред.

Но простые случаи не очень интересны. Когда сотрудников десяток-другой, команд не больше пяти, продуктов пара, да и ИТ-систем немного, всё достаточно тривиально и скучно. Бери и делай, нечего рассуждать. Намного любопытнее так называемый “кровавый энтерпрайз” – сотни ИТ-систем, под тысячу и более сотрудников, про гибкие методы слышали не все, но повернуться в сторону DevOps заставляет время (или ИТ-директор, или зампред, или CIO [при наличии], или иной С-level Executive, курирующий информационные технологии). В таком случае комплексность ИТ-инфраструктуры и большое число взаимосвязей между сотрудниками и подразделениями создают организационные задачи, требующие продумывания, проектирования, инноваций. Вот тут интересно.

Собственно, интересно найти ответы на вопросы: какова роль руководителя проектов в среднем и крупном ИТ-подразделении, которое во всю стремится перейти на гибкие способы создания ценности? Есть ли вообще эта роль, и если есть, то в чём она заключается? Тема не так проста, как может показаться, и единого мнения среди экспертов пока не сложилось.

На одном конце диаметрально противоположных суждений можно расположить точку зрения PMI, Project Management Institute – ведущей организации, объединяющих профессионалов по управлению проектами, а также зарабатывающей приличные деньги на сертификации и пересертификации специалистов. В начале документа “The PM role in a lean and agile world” довольно разумно сказано, что основные гибкие методологии вроде Scrum и SAFe вообще не содержат роли руководителя проектов, распределяя все обязанности по другим ролям и команде. Однако уже в разделе “The Traditional PM versus the Agile PM Role” начинает свободно использоваться словосочетание “Гибкий руководитель проектами”, как будто такая штука есть в природе. А затем на полном серьёзе ведутся рассуждения, что, в целом, никуда от проектов не уйти, только нужно больше “agile” и ещё больше “lean”. Ну и не забывать про важность экзаменов. Такая точка зрения не отвечает на поставленные выше вопросы, но вполне объяснима, если учесть, что пик спроса на сертификацию PMP пришёлся на 2006-2008 годы, а с тех пор снизился примерно вдвое:

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

На другом полюсе можно расположить, к примеру, знакомого многим ИТ Скептика – признанного эксперта международного уровня, знакомого и с ITIL, и с управлением проектами, и даже с Agile/DevOps. В своей заметке “Overcoming the dysfunctions of IT project management” автор утверждает, что управление проектами – худшее, что когда-либо случалось с информационными технологиями. Далее следуют некие аргументы такой позиции, как минимум часть из которых может выглядеть весьма убедительно. Однако абсолютизм ИТ Скептика служит признаком того, что мы читаем рассуждения человека, как теперь принято говорить “укушенного эджайлом” – отрицающего прочие методы управления, считающего “новое знание” лекарством от всех болезней и светлым будущим для человечества. К сожалению, такой полюс также не способствует нахождению ответов на поставленные вопросы.

Так как эксперты помочь не готовы, придётся разбираться самостоятельно. Рассмотрим варианты ответа на вопрос “В чём может заключаться роль руководителя проектов в ИТ-подразделении из 500+ сотрудников, стремящемся освоить управление продуктами, а не проектами?“.

1. Управление работами команды

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

Эта роль, насколько известна, теперь отводится владельцу продукта, а не руководителю проекта. Пока мимо.

2. Построение работы команды

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

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

3. Управление проектом создания продукта

Такая работа если и возможна, то только на время, пока продукт полностью отсутствует, а перейти на новые практики гибкой и итеративной разработки быстро не получается. Как только будет получено что-то, хоть отдалённо напоминающее MVP, Minimal Viable Product, с такого рода проектом следует покончить, чтобы не сводить всё снова к привычной схеме “старт – планирование – выполнение и контроль – завершение”.

То есть роль руководителя проектов должна быть очень временной, а лучше – отсутствовать.

4. Управление результатами на более высоком уровне

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

Похоже, что не очень. Тот же SAFe вводит некую иерархию “Epic – Capability – Feature – Story“, для каждого уровня которой определены и назначение, и деятельность, и методы, и исполнители. Нигде не возникает потребность в руководителе проектов.

5. Построение взаимодействия между старым и новым мирами

Похоже, именно в этой области может очень пригодится менеджер проектов. Дело в том, что представить себе ИТ-организацию, которая 10-15 лет работала “традиционными” методами, а затем в разумный срок (скажем, за год-два) перестроилась и стала гибкой, не очень получается. Более того: есть мнение, что и не требуется в подавляющем большинстве случаев перестраивать всё ИТ-подразделение. Часть ИТ-систем и, соответственно, сотрудников, есть смысл, в том числе экономический, переводить на новые рельсы. А часть лучше оставить работать в привычной парадигме – с тщательным планированием, разделяемым ресурсом исполнителей, небольшим потоком изменений и так далее. Не зря же Gartner и Forrester рассказывают нам про бимодальные ИТ, а также про многоскоростные ИТ.

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

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

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

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

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

Что думаете?

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы