Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 23)
Результат. Согласованные с разработчиками, стейкхолдерами и поставщиками реальные ресурсы. То есть не обещание выделить энное число миллионов, а сами миллионы (в виде субсчета, кредитной линии, сумки с наличными), не обещание выделить офис, а ключи/пропуска, не «эту фичу мы, наверное, сделаем за три дня», а три дня в сетевом графике и запись чата/совещания с согласованием этих трех дней. Результат фиксируется в окончательном варианте графа зависимостей.
В ходе аллокации ресурсов вполне возможно возникновение конфликтных ситуаций. Их отработка осуществляется исходя из общего принципа субординации. Конфликт между стейкхолдерами только обозначается (путем информирования одних стейкхолдеров о позиции других), решения они должны принимать самостоятельно. Конфликты между разработчиками, напротив, эскалируются и модерируются – вплоть до расширенных совещаний с привлечением других разработчиков (в составе участников обязательно нужно иметь хотя бы одного «технаря»). Разница в подходах вытекает из «принципа одной лодки»: правильное разрешение любого конфликта внутри команды – то, что повышает ее сплоченность и работоспособность. Правильным является решение, соответствующее общему видению лучшего будущего (успех проекта, повышение статуса или безопасности разработчиков и т. д.). Такое видение ПМ может сформировать у разработчиков (так или иначе находящихся в зависимом от него положении), но не в состоянии сформировать у стейкхолдеров (за некоторыми исключениями, ориентироваться на которые было бы неправильно). Поэтому ПМ может (и должен) разрешать конфликтные ситуации только внутри команды.
После аллокации задачи приобретают конкретную стоимость (точнее, две – денежную и временнýю в виде срока выполнения). Денежное выражение графы зависимостей становится сметой проекта, складывающейся в его полный бюджет. Однако для непосредственного управления проектом более важной является временнáя стоимость задач, складывающаяся в срок выполнения проекта.
Следует заметить, что проекты далеко не всегда требуется делать к определенному сроку. Гибкие методологии (например, SCRUM) предполагают другой режим работы – сделать максимум возможного в очередной итерации, после чего принять решение: делать или не делать следующую. В большинстве реальных проектов первоначальные сроки не выдерживаются, и это не становится поводом для их прекращения.
Однако если у проекта существует какой-то установленный срок и он является значимым для стейкхолдеров, неисполнение проекта к этому сроку может повлечь за собой непредсказуемые последствия, а следовательно, является критическим риском. Для минимизации этого риска в DaShe предусмотрен набор методов, направленных на решение единственной задачи: оценка текущего риска не уложиться в срок и снижение этого риска путем перераспределения ресурсов.
Наилучшим инструментом контроля за
Таким образом, диаграмма Ганта позволяет контролировать не только состояние текущих задач, но и последствия их более раннего или более позднего исполнения.
1. Из графа зависимостей в программу для визуализации переносятся все задачи, их плановая продолжительность и связи между ними. С помощью программы визуализируется критический путь.
2. Производится балансировка ресурсов. Начинать все задачи одновременно невозможно – на них просто не хватит разработчиков. Поэтому даты начала и завершения задач сдвигаются таким образом, чтобы объем одновременно задействованных ресурсов (прежде всего рабочего времени исполнителей, но также и нагрузки на оборудование, и других параметров) не превышал существующих ограничений. Приоритет имеют задачи, относящиеся к более значимым позициям бэклога (элементам продукта). В результате балансировки критический путь может измениться.
3. В дополнение к задачам на диаграмме расставляются вехи (контрольные точки, майлстоуны). Вехи необходимы для более гибкого контроля за ходом проекта: задач в проекте много, контролировать каждую слишком трудоемко, какие-то обязательно будут пропущены и по закону подлости окажутся критичными. Поэтому контроль за ходом проекта осуществляется не по задачам, а по вехам, количество которых не превышает возможности ПМ. Вехами «обставляются» задачи, лежащие на критическом пути или близкие к нему, а также задачи, выполнение которых вызывает сомнение (с проблемными исполнителями, технологиями или ограниченными ресурсами).
4. Исходя из сопоставленной стоимости каждой задачи заполняются показатели для метода освоенного объема. В первой итерации определяются плановые объемы: сумма плановых расходов на выполненные задачи к каждому майлстоуну (
Показатели освоенного объема предоставляют ПМ целую «приборную доску» для оценки хода проекта. Есть ли перерасход бюджета: EV – AC. Есть ли задержка по времени выполнения: EV – PV. На сколько процентов выполнен проект: EV/TPV. Какова текущая скорость выполнения по отношению к плановой: EV/PV.
5. Диаграмма Ганта обновляется всякий раз, когда в проекте происходят какие-то изменения (производятся расходы, выполняются или не выполняются в срок задачи, подтверждаются или не подтверждаются вехи, меняется оценка сроков или стоимости отдельных задач). В случае если длина критического пути проекта превышает установленный срок, производится перепланирование задач: сжатие или параллелизм.
Результат. Сбалансированная по ресурсам и сжатая для обеспечения срока диаграмма Ганта, содержащая вехи, расставленные в действительно важных точках проекта.
Как и в случае всех остальных визуализаций, конкретная программа, обеспечивающая отрисовку диаграммы Ганта, выбирается ПМ исходя из личных предпочтений. DaShe предъявляет к диаграмме единственное требование: она должна удобно модифицироваться по мере возникновения изменений в любом из запланированных действий.
Действия из графа зависимостей ранжируются по их критичности в зависимости от близости к критическому пути. Более критичным действиям уделяется больше внимания (резервирование дополнительных ресурсов), менее критичные действия сразу же имеют некие резервы по длительности. Обычными методами управления по критическому пути являются переброс ресурсов с менее критичных на более критичные действия и начало более критичных действий параллельно с окончанием предыдущих.
Построение диаграммы Ганта и определение критического пути позволяет сделать выбор между альтернативными вариантами обеспечения задач инфраструктурными ресурсами. Такие альтернативы существуют для большинства реальных задач; даже простейший ресурс – помещение для команды проекта – на этом этапе может быть выделен в виде бюджета аренды, и какой именно офис арендовать (грубо говоря,
Оценить ресурс – значит сопоставить ему некую метрику его полезности по сравнению с альтернативами.
Например, если известно, что производительность программистов в
1.
Поскольку одни и те же ресурсы (очевидный пример – офис) могут использоваться более чем в одной задаче, каждый ресурс включается в список только один раз. Для каждой позиции списка выполняются следующие шаги.