Распределение ресурсов между менеджерами
Вопрос
В реальных проектах, если разработчики задействованы больше чем в одном проекте, как мы переводим их оценки в план?
Ответ
Подобная ситуация в компания заказной разработки может быть. Причины этого я описывал в статье про то, как работает аутсорс. Теперь посмотрим на практике, как это происходит.
Этап планирования (долгосрочный)
Как правило, на этапе планирования вы не знаете, что будет через полгода, поэтому закладываете 100% вовлечение разработчика в ваш проект. Это случай, когда вы планируете на 3-6-12 месяцев вперед.
Возможно, в компании заранее будут существовать практики, что каждый разработчик дополнительно должен выделять 30% своего времени на поддержку проектов из прошлого. Если это так - это известная цифра, которую вы применяете при планировании. То есть, трудозатраты разработчика у вас уменьшаться на 30%, и это будет 4 часа (при эффективных 6 часах).
Оперативный уровень (краткосрочный)
На практике, может случиться такое, что есть незапланированные работы, доработки по проектам из прошлого. Еще бывает, что проект из прошлого вел другой менеджер проекта. Поэтому тут появляется конфликт - ресурс один, а он нужен двум менеджерам :)
В подобных случаях дефицита ресурса проводят “ресурсное планирование”. Условно, еженедельно собираются менеджеры и обсуждают кто и на какой период времени будет привлечен для работы над проектом (например, на этой неделе Разработчик Василий 100% процентов времени потратит на проект А, на следующей неделе - на проект Б). Формулы могут быть разные. Возможно, формула деления будет по принципу: “кто громче кричит, тому и достанется разработчик Василий”. Но это нюансы.
Для вас же, как менеджера - на планировании это никак не отразится. Вы учитываете это в вашем плане и прогнозируете отклонение от дедлайна. Также думаете, как об этом сообщить заказчику :)
Заключение
Это плохая практика, когда в один день разработчик (да или любой другой специалист) работает над 2 и более проектами. Это приводит к потере контекста. На восстановление контекста (знания о проекте, построить в голове модель всех связей) - требуется энергия и время (как минимум 15 минут каждый раз). Постоянное переключение между разными вопросами / проектами - приводит к банальной усталости в течение дня. Вы вроде и вагоны не разгружали, а чувствуете себя также.
Поэтому, если вы столкнулись с дефицитом ресурсов - старайтесь зафиксировать максимально длительные периоды вовлечение разработчика / аналитика / тестировщика в работе над одной задачей.
Дополнительный материал
Как всегда, подробнее об этом можно почитать в статье. В статье в деталях рассмотрен процесс планирования (долгосрочный, среднесрочный, краткосрочный) и практики, которые применяются на каждом из этапов. Я описал лишь Краткосрочный и Долгосрочный.
Все посты написаны мной. Если вам интересно узнать больше, подписывайтесь на мою рассылку о менеджменте. Один-два раза в месяц я пишу статьи о разных аспектах проектного управления или менеджмента в целом. Или вы можете просто написать мне :)