Управление ИТ-проектом

       

шестой. Создаем расписание


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

Задаем точку старта

В уставе зафиксированы даты начала и окончания проекта. Используя специализированное ПО, мы задаем точку старта проекта и видим предполагаемую дату окончания. Укладывается ли результат в сроки, указанные в уставе? Возможно.


увеличить

В этот момент нам удобно ввести понятие «вех».

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

Добавим в наше расписание значимые для нас вехи. Допустим, в уставе прописано, что до 10 сентября необходимо согласовать с заказчиком макет, а весь проект завершить не позже 15-го. Укажем в перечне задач соответствующие вехи.


увеличить

Вехи будут помогать нам удобнее организовать расписание и, в то же время, могут выступать ограничениями проекта. Также «график вех» – одна из разновидностей отчета, который очень удобно использовать для коммуникаций с заказчиком.

Сетевой анализ расписания

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

Сетевой анализ включает в себя:

  • анализ и выравнивание ресурсов
  • анализ критического пути
  • сжатие расписания (crashing и fast track)
  • анализ Монте-Карло

Анализ и выравнивание ресурсов начинается с анализа диаграммы использования ресурсов (доступна в любом специализированном ПО). Нет ли перегрузки – не получается ли, что один и тот же разработчик должен несколько месяцев решать одновременно множество задач, работая за троих? Если да, то используйте «выравнивание ресурсов» (также стандартная опция в специализированном ПО – вот почему я так настойчиво рекомендую вам его использовать).

Посмотрите, как программа предложит вам поменять расписание проекта (какие-то работы сдвинуть во времени, чтобы дать возможность нашим сотрудникам закончить другие дела и приступить к другим).

Укладываемся ли мы в ограничения сроков из устава теперь? Возможно. Но с огромной вероятностью – нет (такова природа проектов вообще и ИТ-проектов в частности). Будем работать над расписанием дальше.

Критический путь отражает самый длинный путь в нашей сетевой диаграмме и самое короткое время, за которое можно выполнить проект. Это одно из фундаментальных понятий в проектном управлении.

Работы на критическом пути нельзя делать параллельно (они строго последовательны).

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

Задержка любой работы на критическом пути автоматически задерживает весь проект. Пока дизайнер не закончит – разработчик не может быть полезен на проекте.

Сжатие расписания всегда имеет целью ускорить выполнение работ по проекту.

Один из методов сжатия – crashing (добавление ресурсов). В нашем примере: задавшись целью ускорить работы, например, дизайнера, мы нанимаем дополнительных людей в команду. Это ускоряет выполнение работ, но повышает стоимость. Практическое использование данного метода состоит в корректировке списка ресурсов, а затем (на его основе) и расписания проекта (добавили нового дизайнера – назначьте ему часть работ и посмотрите, сократился ли критический путь).

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

Используйте методы сжатия расписания, осознавайте риски, которые за ними стоят.

Анализ Монте-Карло – термин из теории игр. Этот вид анализа основан на задании исходных условий и дальнейшем моделировании возможных ситуаций. Осуществляется с использованием особого ПО (наше, «проектное» для этих целей не подходит, иногда пользуются электронными таблицами excel с преднастроенной логикой). В настоящей книге мы не будем останавливаться на нем подробно.

Урезание расписания


Сетевой анализ расписания иногда противопоставляют «урезанию» содержания работ (cutting scope). Порой, соблазн ПМ состоит в том, чтобы «выкинуть» некоторые работы из проекта, дабы получить более удобное расписание. Удержитесь от того, чтобы сделать это «тайком».
Помните, что проект всегда реализуется в интересах клиента. Если сетевой анализ не позволяет вам добиться реалистичного расписания к искомой дате без ущерба к конечному продукту – обсудите эту проблему со спонсором, предложите ему увеличить сроки проекта или позволить вам «выкинуть» определенные работы (по сути, вы просите переписать устав). Возможно, вам придется признать свою ошибку при грубом (ROM) планировании в фазе инициации. Не бойтесь этого. Не бойтесь поступать этично.
Итоговое расписание.
Результатом наших усилий должно стать реалистичное расписание. Такое, которое не противоречит уставу, обеспечено ресурсами, и по которому команда проекта действительно готова выполнить работы в соответствие с графиком.
Помните, расписание должно быть доступно заинтересованным лицам. Команде необходимо иметь доступ к подробной иерархии работ, спонсору же достаточно видеть основные вехи. Позаботьтесь о том, чтобы результаты планирования не остались у вас на компьютере – обеспечьте актуальной информацией всех, кто в ней нуждается любым приемлемым способом (письма, распечатки, и проч.).

Содержание раздела