Работа с незапланированным временем в Project

Всегда хорошо предположить и установить буфер для каждого члена команды. Если «дополнительные» встречи известны и могут быть обоснованно предсказаны, то одним из вариантов является их представление в плане проекта (например, внепроектная встреча – 2 часа). Другой вариант — просто добавить буферное время (например, 10-15%) в задачи каждого члена команды, когда вы вводите их в план.

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

Вы также можете подумать о переходе на бережливое производство и спросить свою организацию: «Нужно ли нам так много совещаний?» Что мы можем сделать, чтобы сократить количество и время этих встреч? Что мы можем сделать, чтобы сократить время, которое Билли тратит на встречи?

Будьте осторожны с буферами, они почти всегда слишком малы :)

Это простые исправления с несколькими альтернативами в зависимости от того, что имеет смысл.

Первый вариант, вы можете уменьшить количество единиц на ресурс на странице ресурса. Итак, если у вас есть человек, который также выполняет работы, не связанные с проектом, на неопределенной основе, оцените, что осталось. Никто никогда не доступен на 100%. Таким образом, использование 60%, 70% или 80% уместно. Если вы сделали это таким образом, вам нужно установить все свои задачи как фиксированную единицу. Введите целевые часы, и проект рассчитает соответствующую продолжительность.

Второй вариант: если некоторые из этих совещаний, как запланированных, так и разовых, связаны с проектом даже самым отдаленным образом, то либо увеличьте свои оценки работы, чтобы включить эту работу, либо увеличьте продолжительность. Например, если у вас есть задача «постоянная работа», вы подключаете 8 часов, увеличиваете ее продолжительность до 1,5 или 2,0 дней, и проект рассчитает использование ресурсов до чего-то меньшего, чем 100%. Или установите фиксированную продолжительность задачи, вручную введите 1,5 или 2,0 дня, оставьте ресурсы на уровне 70 %, и проект рассчитает часы.

Я считаю, что использование фиксированной продолжительности является самым простым и сохранение ресурсов либо на уровне 50% для неполного рабочего дня, либо на 100% для полного рабочего дня. Я управляю продолжительностью так, чтобы у меня было достаточно времени для поворота гаечного ключа (полная производительность), а также для всех других вещей, которые всплывают. Недостатком этого способа является то, что вам нужно следить за использованием каждого человека, чтобы убедиться, что вы не перегружаете его / ее день. Требует некоторого выравнивания. Но MSProject причудлив, и это кажется лучшим способом преодолеть его ограничения.

РЕДАКТИРОВАТЬ: когда вы оцениваете время для задачи и вводите его в инструмент планирования, вы берете недетерминированную оценку и выбираете одно значение, детерминированное значение. Например, вы можете оценить от 3 до 8 дней для задачи с наиболее вероятным окончанием 5. Вы не можете запланировать диапазон, поэтому вы выбираете цель, которая представляет уровень вашей склонности к риску. Пять или шесть дней разумно, и это то, что вы планируете. Тем не менее, это по своей сути означает, что у вас есть некоторый риск превышения цели до 8 дней в этом примере из-за всевозможных прерываний, таких как специальные встречи, ваши люди отвлекаются на свои другие проекты, если они совместно используются, неожиданные проблемы и т. д. Это не делает расписание неправильным, это вызывает отклонения, с которыми вам приходится справляться.

Расписание не запускает вас; вы работаете по расписанию. Если ваше расписание говорит, что задача начинается сейчас, но вашего ресурса нет, это называется поздним началом. Вставьте его в свой инструмент в качестве фактической даты начала и продолжайте работу. Ваш график НЕ сбудется с нулевой дисперсией.

Встречи AdHoc — это убийцы планирования. Я бы сказал, что попытка адаптировать свое планирование к непредсказуемым условиям принесет вам только больше головной боли.

Пока у вас есть достаточно доказательств того, что эти встречи негативно сказываются на производительности вашей команды и/или управлении, нельзя ли проверить, действительно ли Билли нужно посещать все эти встречи? Если эти встречи проходят на уровне компании, возможно, менеджеры не знают, что эти встречи, хотя и полезные, могут привести к кошмарам, связанным с отслеживанием проектов. Эта тема уже широко обсуждалась?

Помимо следования предложениям буфера Дэвида и Атера, я не вижу особых дел.

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

Итак, я предлагаю вам задать себе вопрос: приносят ли все эти встречи какую-либо пользу работе Билли, чтобы окупить это изменение в планировании?

Я обнаружил, что невозможно угадать % накладных расходов, и я бы установил его изначально, но использую освоенный объем, чтобы лучше предсказать в рамках проекта, как различаются накладные расходы отдельных лиц. Я также старался использовать это как молоток, чтобы судить, был ли один человек на 90%, а другой на 50%. Мы обнаружили, что это дало нам ценные знания, чтобы увидеть, как разные люди использовались в проекте и вне его. В большинстве случаев средние накладные расходы каждого из освоенного объема были реалистичными для поддержания бизнеса и разработки новых функций.

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

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

Следите за этим, и это даст вам представление о потребностях команд во времени.

Кроме того, чтобы ответить на другой аспект вашего вопроса, я не знаю ни одного хорошего способа работы с MS Project, в котором вы не согласовывали бы часы команды, когда они их заказывают, и не корректировали план вручную. Если вы делаете это еженедельно (например, просите часы в пятницу, а затем перепланируете день пятницы/утро понедельника), это займет 1-3 часа, но вы будете очень хорошо чувствовать проект «в цифрах».

Я называю это «манией встреч». У вас есть много встреч, чтобы организовать себя и быть более эффективным и действенным в своих повседневных задачах; и у вас в конечном итоге остается меньше времени или совсем нет времени на их выполнение! Я не очень люблю встречи. Это заставляет меня засыпать большую часть времени; Предпочитаю неформальное общение в зале. Ваша ситуация выглядит для меня так, как будто нет босса, который мог бы принять решение или принять окончательное решение. Много консультаций; недостаточно быстрых решений. Рецепт выгорания членов команды. Кто-то должен быть ответственным за очистку этих неэффективных процессов.

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