Разработка расписания начинается с получения иерархической структуры работ (ИСР). Пока нет ИСР – о расписании говорить вообще не имеет смысла. Поэтому, если ИСР еще не создана – ее необходимо создать и только после этого приступать к планированию сроков.

Мне неоднократно приходилось видеть планирование сроков проекта без создания ИСР и эти сроки всегда срывались. Данный факт имеет простое объяснение – практически ни один человек не может удержать в голове свыше 9 единиц информации одновременно. Так, не глядя на ИСР, мы понимаем взаимосвязи между работами, но все их в голове удержать не можем.

Итак, как происходит процесс планирования сроков проекта?

Если идти по описанному в PMBOK пути – все получается достаточно хорошо. Есть ИСР, декомпозированная до отдельных работ. Далее мы эти прописываем взаимосвязи этих работ между собой, назначаем людей на эти работы и оцениваем время, за которое данные работы могут быть выполнены данными людьми (если ИСР существует в виде подобия ментальной карты, все вышеперечисленное удобнее делать прямо на этой ментальной карте). После чего увязываем все полученные результаты в логически непротиворечивый график проекта, который должен устроить всех его участников. Если этого не произошло – проводится следующая итерация графика, и так, пока все не будут согласны с получившимся графиком. После этого график подписывается всеми участниками, принимается в качестве базового и по нему ведется управление работами.

Как это происходит на самом деле?

Обычный вариант для российских компаний – посчитали содержание продукта, особо продвинутые посчитали содержание проекта, наложили стандартный процент рисков и выкатили сроки заказчику.

Какие типичные ошибки встречаются при таком подходе:

  1. Агрессивное расписание, т.е. несогласованность сроков работ с исполнителями этих работ. У исполнителей может быть свой взгляд на то, сколько времени займет данная работа. Причем, поскольку работают все-таки исполнители, задача займет столько времени - в лучшем случае - сколько скажут исполнители, а не сколько времени будет отпущено сверху.

  2. Не посмотрели на критический путь проекта. Здесь возможны самые разные варианты. Например, в одной из компаний, в которой я работал, человеческие ресурсы на проект до подписания контракта выделялись по остаточному принципу, а оплата соисполнителей была запрещена вообще. Такой подход хорошо работал с коммерческими компаниями, но когда его применили к оборонному заказу – все сразу встало. Дело в том, что военные подписывают контракт и платят по нему раз в год – в конце года. Предисполнение проекта стартовало в июле и, соответственно, кроме руководителя проекта по данному проекту полгода никто не работал, что сильно увеличило сроки.

  3. Непроработанность ТЗ, нечеткость его формулировок. Заказчик имеет в виду одно, исполнитель - другое. Поскольку продукт не может иметь двойственности и реализуется каким-то одним способом, часто обнаруживается, что проект надо дорабатывать, а время под это, естественно, не зарезервировано.

  4. Широкое использование оутсорсеров, с которыми ранее не работали. Конечно, вы не всеведущи и ваше время ограничено, поэтому необходимо использовать внешних разработчиков. Но какова их реальная производительность и на каком месте в их приоритетах стоит ваша компания? Без знания этих данных необходимо закладывать, по крайней мере, двойные риски по времени и стоимости, а также очень жестко контролировать сроки и качество работы.

  5. Сдача проекта – это тоже группа работ, которая занимает время. Постарайтесь учитывать это время, поскольку оно довольно продолжительное, особенно если будут проблемы с качеством продукта.

  6. Считать, что риски срыва сроков можно скорректировать работой в выходные дни – грубая ошибка. Во-первых, при этом сильно возрастают риски ухода работников, во-вторых, работа в выходные в течение последних двух месяцев не скомпенсирует сколь-нибудь большого отставания. 20% на риски в программном проекте - это очень мало. Также помните, что больше 10 часов в день человек продуктивно работать не может, даже если он находится на работе 14 часов. Включайте риски графика явно, обозначая их буферами.

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

  8. Участники проекта не все свое рабочее время работают в проектах – у них есть отпуска, пресейлы, обучение, работа по заполнению анкет для отдела кадров и т.п. Кроме того, они иногда болеют. Реальный коэффициент проектной загрузки редко превышает 60%. Однако, когда они оценивают свое время на выполнение задачи, они ориентируются на свою 100% загрузку. Помните об этом.

  9. Можно забыть про проект после подписания заказчиком акта сдачи-приемки, но, если есть такая возможность – выделите время на документирование реализовавшихся рисков и благоприятных событий – это очень поможет вам при оценке времени в следующем проекте.

  10. Создание графика работ с помощью Excel – очень привлекательно для новичков в проектном управлении. Большие проблемы возникнут позже , когда нужно будет его скорректировать в соответствии с изменившимися обстоятельствами. Потратьте несколько дней на изучение MS Project или подобных средств планирования и используйте их в дальнейшем. Затраченное на изучение время окупится после первого же серьезного изменения графика.