Рабочее время – это один из основных ресурсов проекта, от эффективного управления которыми зависят результаты проекта.
Процесс управления временем имеет несколько аспектов: с одной стороны, он неразрывно связан с процессом бюджетирования и составлением графика проекта, с другой стороны – с контролем сроков исполнения проектных задач, оценкой возможных рисков, и наконец, с управлением личным временем каждого сотрудника.
В контексте данной статьи под управлением временем будем понимать процесс, при помощи которого руководитель проекта может контролировать сроки исполнения проектных задач, оценивать результаты и риски. В качестве базовых будем рассматривать детерминированные модели сетевого планирования, где связи между отдельными задачами проекта жестко заданы.
Как уже отмечалось выше, одним из наиболее популярных методов составления графика проекта в данном случае является метод критического пути. Критический путь - максимальный по продолжительности полный путь в сетевом графике. Именно длительность кpитического пути опpеделяет наименьшую общую пpодолжительность pабот по пpоекту в целом. Увеличение продолжительности критических работ приводит к соответствующему увеличению общей продолжительности проекта, в то время как некритические работы обладают некоторыми резервами времени, с помощью которых можно управлять проектом. При необходимости менеджер проекта может задержать работу на этот резерв времени без влияния на общую продолжительность проекта и связанных задач. Работы, лежащие на критическом пути, имеют временной резерв, равный нулю. Поэтому одним из способов снижения риска является пристальный контроль именно тех задач, из которых состоит критический путь выполнения проекта.
Для контроля процесса выполнения проекта и оценки рисков в детерминированной модели используются milestones - контрольные отметки, или, как их по-другому называют, контрольные точки, т.е. вехи, отмечающие окончание очередного этапа работ. В качестве таких контрольных точек обычно используются короткие информативные документы, срок исполнения которых фиксируется в графике проекта. При этом очень важен сбалансированный подход к расстановке контрольных точек, чтобы не тратить ресурсы на вспомогательную работу. Например, вместо документа может выступать конкретное задание, выданное сотруднику на определенный срок, результат исполнения которого проверяется менеджером проекта. Задание может быть выдано в виде предписания, талона или в какой-то другой форме, при этом фиксируется время выдачи задания, срок исполнения, ответственный исполнитель и проверяющий, который должен поставить свою отметку после проверки задания.
По существу, здесь задача контроля плотно соприкасается собственно с самим процессом планирования, так как оптимальным является разбиение проекта на такие элементарные задачи, на которые бы приходилось ровно по одной контрольной точке, и выполнение которых легко проверить.
Инструментом, позволяющим руководителю проекта получить оптимальное разбиение проекта на задачи и иметь четкую картину конечного и промежуточных результатов проекта, является WBS - Структура Декомпозиции Работ (Work Breakdown Structure). Данный подход позволяет с заданным уровнем точности описать содержание работ по проекту, провести декомпозицию проекта на пакеты, субпакеты и пр., т.е. представить список работ по проекту в виде иерархической структуры, где каждая элементарная работа имеет объективный или измеримый результат.
В целом, WBS – это итерационный процесс. Каждый следующий уровень декомпозиции обеспечивает более глубокую детализацию проекта. На нижних уровнях иерархии пакетам соответствуют меньшие объемы работ. Это упрощает контроль выполнения проекта и дает возможность более четко определять действия, необходимые для достижения цели проекта. Таким образом, формируется основа для определения измеримых показателей проекта в терминах затрат того или иного ресурса, например, трудоемкости, стоимости и пр.
Следует помнить, что WBS – это инструмент, позволяющий провести декомпозицию до уровня, необходимого и достаточного для определения сущности работ проекта. Чрезмерная детализация WBS требует излишнего уровня поддержки и отчетности. Но недостаточное внимание к разработке WBS и переход непосредственно к формированию сетевого графика и расчету критического пути может привести к потере важных для проекта работ, а следовательно к задержкам проекта на поздних стадиях его реализации после выявления упущений.
В общем случае, количество итерационных шагов WBS зависит от выбранного подхода к управлению проектом. Если целью выполняемого проекта является разработка программной системы, в качестве примера можно рассмотреть три наиболее распространенных подхода к управлению проектом: классическое водопадное, или каскадное программирование (Waterfall), RUP (Rational Unified Process) как пример классического итеративного подхода, а также экстремальное программирование как пример гибкого подхода к проектированию.
Классический водопадный подход включает стандартные этапы: анализа требований, проектирования, разработки, сборки и тестирования, выполняемые последовательно, где контрольными точками являются точки завершения этапов. Необходимость внесения изменений обнаруживается обычно к концу разработки. Такой подход хорош для маленьких проектов и в тех случаях, когда требования к разрабатываемому продукту строго определены и гарантированно не будут изменяться.
RUP предлагает итеративный подход, основанный на спиральном жизненном цикле проекта. Он делится на четыре фазы – вхождение в проект (исследование), развитие (уточнение плана), конструирование и развертывание. Каждая фаза складывается из последовательности итераций, число которых может быть любым. В каждой итерации перечисленные выше технологические процессы последовательно применяются к разработке небольшой части ПС. Контрольные точки в конце фаз позволяют оценить, насколько успешной была предыдущая фаза и насколько успешен весь проект в целом. При этом допустимо предъявление результата заказчику. Он имеет возможность оценить выполненную реализацию, выдать свои замечания, которые могут привести к изменению и уточнению требований к ПС. Следующая итерация предполагает расширение уже разработанной части путем реализации и интеграции очередной порции требований. Постоянно выполняемые оценки состояния проекта являются основой для решения разных проблем и управления рисками проекта. Если команда разработчиков выявила проблему, назначается сотрудник, ответственный за ее разрешение, и определяется дата, когда проблема должна быть разрешена.
В случае экстремального программирования вместо планирования как детерминированного процесса используется игра в планирование, в ходе которой разработчики и заказчики в процессе обсуждения определяют, что можно реализовать в ближайшей версии системы. Таким образом, контрольными точками проекта являются моменты внедрения очередной версии. В период, когда еще невозможно предоставить систему пользователям, в качестве элементарных задач проекта используются эксперименты с целью определения наилучшей архитектуры системы. Контрольными точками являются результаты экспериментов.
На практике часто используются не чистые методологии, а их комбинации. При этом учитывается опыт, приобретенный в ранее выполненных проектах (лучшие критические практики, или critical best practices).
Успех проекта в целом зависит от того, как каждый исполнитель проекта укладывается в сроки, выделяет время на приоритетные задачи, грамотно управляет рабочей нагрузкой.
В некоторых компаниях для этого проводятся специальные тренинги по тайм-менеджменту, главная мысль которых заключается в том, чтобы каждый сотрудник постоянно фиксировал ход мыслей, положение дел, чтобы в каждый момент времени знать, что было сделано, что предстоит сделать. Это, во-первых, уменьшает вероятность запутаться в задачах и отклониться от основной цели, во-вторых, позволяет не забыть про задачи с менее высоким приоритетом, отложенные "на потом". Такие записи будут впоследствии полезны при работе над документацией, при подключении к проекту новых людей, анализе сделанных ошибок и т.д.
Еще один способ классифицировать дела по важности следует из закона Парето. Если применить этот закон к тайм-менеджменту, он будет звучать так: 20% всех дел дают 80% результатов; 80% дел дают 20% результатов. Это позволяет при рассмотрении списка дел выделить те 20%, которые дают максимальный результат и поэтому требуют особого внимания.
Другим способом отделения важного от неважного является качественного скачка и количественных улучшений Питера Друкера. Неважными считаются дела, не создающие качественных скачков в развитии задачи, вносящие лишь незначительные «количественные» улучшения.
При расстановке приоритетов стоит обратить внимание также на необратимость некоторых вещей. Если сегодня есть возможность сделать что-то, а завтра ее уже не будет, приоритет данного дела повышается.