Как без лишнего стресса и лишних трудозатрат поддерживать план-график проекта в актуальном состоянии

Каждый раз показывая кому-либо планы проектов/задач, которые я накидываю в MS Project, я получаю множество, на мой взгляд, необоснованных восторгов и вопросов «как?» и «что?», при том что ничего сложного или требующего получения отдельного высшего образования я не использую.

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

Вместо вступления

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

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

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

«Проваливая подготовку, вы готовитесь к провалу», – говорил Бенджамин Франклин; «Если вам не удалось составить план, значит, вы запланировали неудачу», – вторил ему Уинстон Черчилль, как будто эти двое работали со мной на одних проектах.

Как я планирую

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

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

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

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

Мои правила планирования

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

1. Люди не роботы и никогда не будут работать 100% рабочего времени, даже если они занимаются только одной задачей, поэтому Правило №1 – не планировать больше 80% на человека.

2. Всем задачам я по умолчанию ставлю тип "С фиксированными трудозатраты", потому что отдаю планирование дат MS Project, и только по одиночным задачам я меняю тип и выставляю конкретные даты (те самые задачи, на которые мы не можем влиять).

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

• Анализ и проектирование
• Разработка
• Стабилизация (тестирование и багфиксинг)
• Приемка
• GoLive

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

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

tip: сдвигать уровни задач удобно через выделение + ctrl+shift+->

6. Отпуска должны быть учтены в календаре – для каждого ресурса в MS Project есть свой календарь, зайдя в который, вы сможете запланировать отпуска, а также работу в выходные и праздничные дни – если в вашем проекте что-то пойдет не так, и нужно будет догонять график.

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

7. Если мы планируем от трудозатрат и с ограничениями типа ASAP, мы не можем задавать конкретные даты, и если мы это делаем (а MS Project это позволяет), то MS Project «сходит с ума» и не может автоматически пересчитывать даты и планы, поэтому:

• Никогда не меняйте дату завершения у задач с типов ограничения отличным от `Окончание не ранее (ОНР)`, `Окончание не позднее (ОНП)` или `Фиксированное окончание (ФО)` – это ломает логику планирования в MS Project.
• Никогда не меняйте дату начала у задач с типов ограничения отличным от `Начало не ранее (ННР)`, `Начало не позднее (ННП)` или `Фиксированное начало (ФН)` – это ломает логику планирования в MS Project.
• Если на задаче указан процент выполнения, MS Project не даст вам поменять дату окончания, точнее даст, но не учтет и не перестроит план.

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

Немного теории

Прежде чем начать планирование непосредственно в MS Project, немного теории о том, какие атрибуты есть у задач в MS Project:

1. «Тип планирования» (Task mode) - автоматическое или ручное планирование
2. «Тип задачи» (Task type) - с фиксированным объемом ресурсов, с фиксированными трудозатратами или с фиксированной длительностью
3. «Тип ограничения» (Constraint type) - Как можно раньше, Не раньше чем, Фиксированное начало и другие
4. «Приоритет» (Priority) - собственно приоритет выполнения задачи, относительно других задач в этом и других проектах. Задается в целых числах от 0 (самый низкий приоритет) до 1000 (самый высокий приоритет).
5. «Предшественники» (Predecessors и dependency types) - зависимости от других задач, не обязательно от завершения, могут быть как «Конец-Начало», так и «Начало-Начало» и в любом случае можно задать сдвиг как вперед от даты, так и назад - например: начинать за два дня до завершения другой задачи
6. «Ресурсы» (Resource Names) – в нашем случае это специалисты, которые будут выполнять задачу

Перед началом работы с планом, необходимо выполнить подготовку проекта в MS Project:

1. Установить следующие настройки проекта:

В разделе Дополнительно (Advanced):

• Показывать суммарную задачу проекта (Show project summary task) – просто для удобства – дает возможность смотреть суммарные показатели проекта

В разделе Расписание (Schedule):

• Установить автоматическое планирование (Auto Scheduled)
• Задать Тип задачи (Task type) по умолчанию - Фиксированные трудозатраты (Fixed Work)

В параметрах выравнивания ресурсов (Leveling Options) на вкладке «Ресурсы» (Resource):

• Выставить «Выполнять автоматически» (Automatic).
• Установить «по часам (Hour by Hour)» в настройке поиск превышений доступности (Look for overallocations on a).
• Выставить «По приоритетам, стандартный (Priority, Standard)» в настройке Порядок выравнивания (Leveling order).

2. В таблице задач добавить следующие столбцы:

• Приоритет (Priority).
• Трудозатраты (Work).
• Процент выполнения (% Complete).
• Тип задачи (Type) – потребуется для быстрого изменения типа задачи, на которые мы не можем влиять (например, внешние для компании зависимости, задачи, выполняемые заказчиком, смежными подразделениями и т.п.), от которых зависят задачи, на которые мы влиять можем.
• Тип ограничения (Constraint Type).

3. Настроить дату начала проекта - дату, в которую необходимо начать работу над первой задачей в проекте.

4. Настроить производственный календарь - тут надо учесть государственные праздники и общие для компании выходные.

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

5. На диаграмме Ганта включить выделение задач на критическом пути

6. Настроить отображение задач на диаграмме Ганта:

• Суммарные задачи - название справа

• Задачи - название слева, ресурс справа

• Задачи на критическом пути - название слева, ресурс справа

• Вехи - название слева

Создание план-графика

Когда все предварительные шаги и настройки выполнены, пора приступить к планированию.

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

1. Копируем шаблон план-графика:

2. Вместе с командой детализируем каждую задачу до уровня «одна задача – один исполнитель», сразу проставляя зависимости между задачами, конкретных исполнителей для каждой задачи и определяя приоритеты задач (в примере мы хотим выпустить версию для iOS раньше, чем для Android, поэтому поставили задачам на iOS приоритет выше, чем для задач на Android)

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

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

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

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

И отобразив его на таймлайне:

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

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

Александр Головков

Дата публикации: 15 ноября 2021 г.