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