В ИТ-проектах часто возникают ситуации, в которых участники команды не могут уделять 100% своего рабочего времени на проект. Особенно ярко это проявляется в организациях с линейно-функциональной или слабой матричной структурой. В них проектная деятельность носит нерегулярный характер, а потому ресурсы выделяются по остаточному принципу.
Как правило, в таких случаях менеджер проекта вынужден договаривается с заказчиком проекта и с руководителями функциональных подразделений о том, на какую часть времени от основной работы будут доступны участники.
Возникает вопрос: как менеджеру проекта рационально распорядиться отведенным временем участников для достижения результатов в срок?
Предположим, вы как менеджер проекта договорились, что участники должны выделять фиксированное время – один час в день. В этом случае чистое время по каждому участнику составит: в неделю – 5 часов (чуть более половины рабочего дня); в месяц – 20 часов (2,5 рабочих дня).
Есть, как минимум, три подхода «договориться» с участниками проекта:
Первый: Подойти формально, определен час, будь любезен посвятить его проекту
Второй: Участники выделяют в неделю полдня «с хвостиком» для работы на проекте
Третий: Раз в месяц два с половиной дня участники занимаются только делами проекта
Давайте рассмотрим ключевые преимущества и недостатки каждого подходов.
Первый: «По чуть-чуть, но каждый день»
Преимущества:
– позволяет быть «в тонусе» проекта (держать «в уме» текущую ситуацию по работам на сегодня);
– выполнять конкретные (заранее «нарезанные») задачи в отведенное время;
– оперативный обмен информацией между участниками проекта по взаимосвязанным задачам
Недостатки:
– остаточный принцип предполагает, что могут «дернуть» по основной (вне проектной) работе. Это приводит к тому что несколько отрывов сводит на нет работоспособность по задачам проекта в отведенный час (см. рис. 1). Как следствие, – участник будет вынужден этот час отработать вечером после основной работы. Знакомая ситуация, согласны?!
– но, здесь его ждет другая ловушка – работоспособность к вечеру резко падает (см. рис. 2), что приводит к снижению качества и увеличению длительности выполняемой работы в этот день;
– это приводит либо к тому, что допоздна «дожимается» работа, либо – откладывается на следующий день (с формулировкой для менеджера проекта: «Вчера было много работы – не успел. Доделаю завтра»).
Второй: «Недельный спринт»
Преимущества:
– оставаться «в тонусе» проекта (неделя в текущей деятельности «пролетает» быстро);
– появляется возможность коллегам по основной работе сказать, что в такой-то день я до / после обеда недоступен (вполне рабочая ситуация, когда мы на полдня куда-то уезжаем по делам);
– высокая вероятность выполнить задачи недельного «спринта» в отведенное время рабочего дня (с низкой вероятностью «дожимать» работу – вне рабочего времени)
Недостатки:
– эти полдня в неделю для каждого сотрудника могут быть свои (кому-то удобнее отработать с утра во вторник до обеда, кому-то, – в пятницу после), что требует дополнительной координации участников менеджером проекта;
– при большой динамике текущей работы, участники могут потерять мотив качественно выполнять задачи по проекту, перенося часть задач недельных спринтов на следующую неделю.
Третий: «Не уходим, пока не сделаем»
Преимущества:
– полное погружение в задачи проекта в отведенные дни;
Недостатки:
– вероятность крайне мала, что эти дни совпадут у всех участников проекта;
– как следствие первого, – отсутствие какой-либо информации будет означать простой по проекту (с формулировкой: «У меня отсутствовало то-то и то-то, поэтому я успел сделать это и это»);
– существенное увеличение сроков выполнения работ по проекту;
– высокая вероятность, что всех «выгонят» работать в выходные дни (чтобы «необходимая информация» была наконец-то представлена).
Учитывая работоспособность сотрудников в течение дня и последствия перерывов в работе (см. рис. 1 и рис. 2), а также особенности каждого из подходов, рассмотренных выше, можно рекомендовать гибкий подход к распределению времени участников проекта.
Рекомендации:
- Берем за основу «Недельный спринт».
- Договариваемся с участниками о дне недели и времени (до / после обеда). Самый идеальный вариант – такой день и время сделать единым для всех (если есть возможность, еще и закрепить регламентом по проекту такой «момент»). Здесь стоит отметить что преимущество работать до обеда в том, что работаем «на свежую голову», а после – приступим, когда всю «текучку раскидаем».
- Оставшийся час из пяти (четыре мы отвели на до / после обеда) определяем:
– в случае если все работают, как поется в той песне «… на том же месте в тот же час»): часовое недельное совещания накануне дня проведения работ;
– в случае, если каждый работает по своему графику: ежедневные 10-15 мин. stand-up meeting («живые» или виртуальные через IRC-инструментарий) для координации работ на текущий день.
- Применяем подход «Не уходим, пока не сделаем» в крайнем случае, если проект начинает «гореть». Используем, при необходимости, как напоминание в качестве «бича» – при срыве сроков «выходим» в выходные.
Такой подход дает ряд преимуществ:
– участники находятся «в тонусе» проекта;
– работа над задачами проекта происходит в рабочее время;
– позволяет менеджеру проекта проще осуществлять контроль над ходом проекта.
Среди недостатков подхода – требуется опыт в науке и искусстве проектного управления.
В ходе управления ИТ-проектами, помимо описываемых выше, возникает масса «вариаций на тему». К примеру, что делать, если среди участников проекта – функциональные руководители со своим «непредсказуемым» графиком? Или, как поступать, если «отведенное» время участников на проект меньше часа в день? Или как быть, если работы, распределенные на участников проекта сильно зависят друг от друга (например, написать код – протестировать, найти ошибки – отдать на доработку)? И другие «всплывающие нюансы».
Буду рад узнать про ваш опыт проектного выделения времени участников.
Как и с чем вы подходите «к снаряду»? Что для вас является важной составляющей рационального использования времени на проектных работах?
“Среди недостатков подхода – требуется опыт в науке и искусстве проектного управления.”
Мило…
Т.е. в других вариантах можно проскочить и без опыта проектного управления?…