Тут, как это уже случалось, всё тот же Паша сподвиг меня написать серию статей про управление проектом. И заодно систематизировать / актуализировать мои знания и опыт в этой области. Раз уж я сделал N проектов, это кому-нибудь нужно. (C) Пока планирую примерно такой набор записей:

• Первые дни: собственно эта статья
• Старт проекта
• Статусы и другие коммуникации на проекте
• Управление планом-графиком
• Управление изменениями
• Управление проблемами
• Закрытие проекта

Что же нужно для начала работы? Как мне кажется, нужно обратить внимание на три основных области:

• Люди
• Процесс
• Проект

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

Люди

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

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

Относительно этих участников нужно провести набор действий, для начала:

1. Определить заказчика проекта. Никаких "если" здесь быть не может, это один конкретный человек, слово или подпись которого означает принятие результатов проекта или недостижение каких-то заявленных целей.
2. Определить спонсоров проекта со стороны заказчика и со стороны исполнителя; убедиться, что они понимают свою роль и готовы в случае возникновения проектных изменений работать с ними, а также рассматривать эскалированные на них вопросы.
3. В идеале – прособеседовать участников проекта и определить, что движет каждым: например, разработчик может считать, что он строит красивую систему в вакууме, а бизнес-аналитик может считать, что получает неоценимый опыт. Понимание этой мотивации и управление ожиданиями участников проекта может снизить риски их внезапного ухода. Но это только начало, дальше нужно продолжать держать с каждым тесный контакт, чтобы не было сюрпризов.
4. Понять зависимости с другими проектами, целями компании, личными целями топ-менеджеров: в идеале при личной встрече, но из достоверных источников тоже подойдёт.

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

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

Процесс

Под проектом я имею в виду несколько вещей:

• Уровень зрелости проектного управления
• Принятая модель работы
• Формат взаимодействия

Насчёт уровня зрелости проектного управления есть масса моделей, и я обязательно когда-нибудь выложу в общий доступ свою. Лично я предпочитаю модели с фиксированным набором уровней, где 1 – это начальный, а 5-6 – максимально развитый. Также лично я предпочитаю оценивать зрелость по следующим компонентам: люди и компетенции, процессы, системы, организация.

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

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

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

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

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

Под принятой моделью работы понимаю следующие варианты:

• waterfall
• agile
• hybrid

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

Под форматом взаимодействия имею в виду очень простую вещь: а как вообще люди взаимодействуют? И взаимодействие включает очень много вопросов:

• Как принято ставить задачи?
• Как принято контролировать выполнение?
• Как принято спрашивать сроки?
• Насколько принято выполнять обещания?
• Насколько принято съезжать с договорённостей?

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

Проект

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

• Паспорт проекта
• План-график проекта для waterfall
• Статусы проекта

Отсутствие этих документов однозначно указывает на отсутствие общего понимания следующих компонент:

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

И раз уж это всё отсутствует первое (и совершенно естественное), что потребуется сделать – это их создать. Но это потребуется делать одновременно с запуском задач на критическом пути.