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