Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 22)

1. Содержание.

2. Процесс.

3. Персонал.

4. Стейкхолдеры.

5. Коммуникации.

6. Закупки.

7. Стоимость.

8. Качество.

Разумеется, это выделение достаточно условно и служит исключительно для удобства поиска тех или иных методов в ситуации, когда у ПМ возникает проблема в какой-то конкретной области. На практике применение всех методов, описанных в данном разделе, требуется от ПМ постоянно, каждый день и не по одному разу. Пример: сетевой график (диаграмма Ганта, PERT, «критический путь») необходимо пересчитывать каждый раз, когда изменяется оценка продолжительности хотя бы одной задачи проекта (а такие изменения происходят чуть ли не ежечасно). Иначе получится как у Джеффа Сазерленда («Революционный метод управления проектами»): «Сколько проектов шло по диаграмме Ганта?» – «Ни одного».

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

3.1. Управление содержанием

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

Управление содержанием – это определение перечня и порядка действий, которые действительно нужны для успеха проекта, выбор между альтернативными вариантами их ресурсного обеспечения и создание необходимых резервов (буферов) на основе оценки рисков каждого действия. Действие, включенное в содержание проекта, называется задачей и может, в свою очередь, состоять из отдельных подзадач любой степени вложенности.

3.1.1. Анализ зависимостей

Бэклог содержит ранжированный перечень элементов продукта с примерной оценкой затрат на их реализацию. Однако на этапе проектирования затраты оцениваются очень приблизительно (методом покер-планирования, а не составлением подробной сметы). Для управления содержанием требуется куда большая детализация и точность в оценке затрат. Детализация содержания, связанного с разработкой каждого элемента, называется анализом зависимостей: успешная реализация элемента зависит как от внешних (наличие электроэнергии в офисе), так и от внутренних (стыковочные размеры соседней детали) факторов. Цель этапа – максимально полно учесть все зависимости по каждому из элементов бэклога, зафиксировав их в виде списков задач по обеспечению всех необходимых составляющих для реализации элемента. В ходе анализа зависимостей происходит детализация бэклога (ранжированного списка элементов) в полный граф, где узлами являются задачи, а связями – зависимости (выполнение предшествующих задач – необходимое условие для начала выполнения следующих).

1. Для каждого из элементов назначается эксперт (как правило, главный исполнитель работ), который персонально отвечает за успешность реализации этого элемента. Эксперты составляют списки зависимостей: без чего элемент не будет работать. Например, кнопка быстрой регистрации не работает без дизайна (один день работы дизайнера), верстки в составе сайта (один день работы фронт-программиста), уже готовой процедуры регистрации (внутренняя зависимость), автономной отладки (один день тестировщика) и отладки в составе сайта (еще одна внутренняя зависимость). Если при этом дизайн делает сторонняя организация, возникает внешняя зависимость (от наличия договора на этот самый дизайн).

2. Для исключения пропуска наиболее очевидных и потому чаще всего забывающихся зависимостей используется чек-лист.

• Деньги

• Помещение

• Логистика

• Коммуникационные системы (мессенджеры, хранилища файлов, пространство для совместной работы)

• Туалет

• Еда

• Вода

• Тепло

• Поддержка семьи

• Законность

• Качество воздуха

• Стулья, столы, интерьер

• Возможность спокойно работать (то есть отсутствие информационного шума и постоянных прерываний)

3. Особое внимание уделяется внутренней зависимости – когда разные элементы зависят друг от друга или предъявляют противоречивые требования. Эти конфликты разрешает ПМ с участием экспертов по каждому вовлеченному элементу.

Результат. Граф зависимостей, содержащий детализацию бэклога в виде задач и связей между ними. Задачи включают в себя требования к общей инфраструктуре, ресурсному обеспечению каждого элемента, внешним и внутренним работам по реализации элементов. Зависимости представляют собой связи между отдельными задачами типа «завершение А необходимо для начала Б».

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

3.1.2. Аллокация ресурсов

Выявленные на предыдущем шаге зависимости позволяют произвести распределение реальных ресурсов. Карта доступа к ресурсам (из раздела 1) и граф зависимостей (из предыдущего пункта) объединяются для получения списка выделяемых ресурсов, который согласуется со стейкхолдерами и внешними партнерами. Как правило, такое согласование проходит скорее в режиме защиты бюджетов, нежели в режиме «сколько попросишь, столько и дали», поэтому требует специального метода.

Карта доступа к ресурсам может и должна содержать значительно больше позиций, чем будет реально востребовано в проекте. Большинство реальных задач можно решить разными способами, с использованием того или иного набора ресурсов. На этапе аллокации ресурсов выбирать конкретные варианты еще рано: пока неизвестен критический путь проекта, невозможно оценить уровень требований к отдельным задачам, а следовательно, и к количеству ресурсов, требующихся для их решения. Поэтому обеспечение задачи ресурсами (аллокация) производится по максимуму, исходя из самого дорогого по стоимости варианта. Выбор конкретных вариантов инфраструктурных ресурсов производится позднее, для чего задействуется специальный метод.

1. Составляется развернутый граф зависимостей с визуализацией объемов требуемых ресурсов. В карточки задач вписываются требуемые объемы ресурсов и варианты их получения (если они есть, см. карту доступа к ресурсам) с указанием стоимости. В качестве суммарных характеристик задач определяются ожидаемое время выполнения и совокупная стоимость, равная сумме стоимостей наиболее дорогих вариантов обеспечения ресурсами. Полученные оценки визуализируются (например, длиной и высотой прямоугольников на графе). В результате получается реальная раскладка требуемых ресурсов, из которой понятно, для каких задач они нужны и что без них не получится.

2. Развернутый граф обсуждается с разработчиками. Решается задача подтверждения с их стороны достаточности запланированных ресурсов для реализации отдельных задач. Обеспечивается обратная связь (устного разговора недостаточно, желателен сохраненный чат в мессенджере, переписка, протокол совещания). Если какого-то ресурса недостаточно, проводится совещание (групповой чат) со всеми имеющими отношение к проекту разработчиками, и по результатам граф корректируется.

3. Уточненный граф обсуждается со стейкхолдерами. Решаются две задачи:

1) дополнительный поиск более дешевых ресурсов (обычно в последний момент лучше вспоминается, что «вот это можно взять там-то»);

2) обоснование полной стоимости проекта, которая без графа зависимостей может показаться взятой со слишком большим запасом.

Обеспечивается обратная связь (протокол совещания, решение совещания, имейлы от ключевых стейкхолдеров), подтверждающая конечный вариант распределения ресурсов.

4. В случае если такая возможность есть, и ключевой стейкхолдер одобряет, уточненный граф оформляется как некий проект в установленном формате и направляется в государственные или частные организации, специализирующиеся на поддержке подобных разработок. Решается задача привлечения дополнительных ресурсов. Обеспечивается обратная связь (письма с отказом или с согласием на выделение дополнительных ресурсов). Разумеется, учитывается соотношение «затраты – потенциальный результат», его оценку проводит ключевой стейкхолдер.