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



«Среди недостатков подхода – требуется опыт в науке и искусстве проектного управления.»
Мило…
Т.е. в других вариантах можно проскочить и без опыта проектного управления?…