Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 24)
2.
Для выделения используется чек-лист абстрактных свойств:
• «+» доступность («−» риск дефицита);
• «+» понятность, быстрота результата («−» риск затягивания освоения);
• «+» производительность («−» риск затягивания работы);
• «+» гибкость, богатство возможностей («−» риск срыва работ из-за отсутствия ключевой функции);
• «+» надежность, отработанность («−» риск отказа в критический момент).
3.
Одинаковые свойства отбрасываются, остальным выставляются оценки в диапазоне от 0 до 1. Агрегация оценок не производится, так как в зависимости от задач при выборе ресурсов будут использоваться разные метрики.
Результат. Оценки инфраструктурных ресурсов. На основе оценок инфраструктурных ресурсов производится их выбор под конкретные задачи проекта.
1.
Плановая продолжительность проекта – Запас
2.
Для надежности 0,8–1 – доступность, понятность, отработанность. Для надежности 0,4–0,8 – производительность. Для надежности 0–0,4 – богатство возможностей, потенциал роста.
Результат. Выбранные ресурсы под каждую задачу.
Напомним, что под инфраструктурными ресурсами в DaShe понимается очень многое – не только серверы, кабели, кофемашины, стулья и столы, но и языки программирования, стандарты документации, средства коммуникации, технологические платформы и стандарты, закупаемые на стороне услуги и компоненты. Все они должны выбираться сознательно, через оценку и анализ рисков, а не «возьмем первый попавшийся вариант».
Трудоемкость в ходе аллокации ресурсов оценивали эксперты, исходя из предположения о «нормальном» ходе работы, без конкретизации инфраструктурных ресурсов и требований к надежности задач. После составления диаграммы Ганта и выбора конкретных ресурсов можно оценить вероятность срыва выполнения каждой из имеющихся задач. Такая оценка производится с целью добавления буферов – запасов бюджетов и сроков, способных компенсировать непредвиденные обстоятельства.
Все компоненты задачи (характер самой задачи, разработчики, субподрядчики, инфраструктурные ресурсы) содержат в себе риск невыполнения этой задачи в срок. Поэтому оцениваются на риск в первую очередь ресурсы, а уже в самом конце – собственно задачи.
1. К бюджету проекта добавляется общий резерв на непредвиденные ситуации, исходя из новизны проекта, квалификации команды, стека технологий и т. д., но в любом случае не менее 20 %.
2. Методом опроса экспертов (разработчиков и стейкхолдеров, поскольку у них разный опыт и разное видение проблем) оцениваются:
1) инфраструктурные риски (вероятность «несрабатывания» конкретного ресурса);
2) персональные риски (вероятность, что конкретный разработчик «не потянет» или внезапно покинет проект);
3) риски конкретной задачи (вероятность, что в силу ее сложности или новизны возникнут непредвиденные проблемы).
После этого для каждой задачи рассчитывается агрегированный риск: как произведение (1 − риск) всех составляющих рисков.
3. Опросом тех же экспертов оценивается критичность каждой задачи: вероятность, что ее невыполнение приведет к срыву всего проекта. Например, при разработке нового косметического крема решение задачи «крем не должен убивать пользователей» имеет критичность 1, а задачи «крем должен быть фиалкового цвета» – 0,01 (однако если главный стейкхолдер любит именно фиалковый цвет, критичность может также вырасти до 1).
4. По всем задачам пересчитывается плановая стоимость:
Производится повторное согласование бюджета со стейкхолдерами: выбор между риском или созданием стоимостного буфера. В случае отсутствия буфера риски компенсируются из общего резерва проекта либо принимаются на себя стейкхолдерами. Пересчитанная плановая стоимость всех задач плюс общий резерв составляют пересчитанный бюджет проекта. На первой итерации метода он утверждается и далее используется в качестве цели управления.
5. В случае если какая-либо задача имеет риск, который невозможно компенсировать в рамках бюджета, план ее исполнения пересматривается: ищется возможность закупки готового и отработанного решения (то есть несущего значительно меньшие риски) на стороне.
6. Для задач со стопроцентной критичностью (1 ровно) закупка на стороне недопустима, поскольку даже у самых отработанных решений существует риск отказа. Если в бюджет не вписывается критическая задача – проект нереализуем. В этом случае может быть применен метод снижения уровня готовности (вместо массового продукта – опытный образец), что влечет за собой возврат к этапу 2 – разработке продукта.
7. Поскольку скорость освоения дополнительных средств не бесконечна, увеличение бюджета не всегда означает выполнение большего объема работ в тот же срок, а обычно увеличивает и продолжительность работ. Поэтому продолжительность задач, находящихся на критическом пути проекта (и только на нем!), пересматривается. Учитывается момент возможного возникновения непредвиденной ситуации, возможность закупки сторонних решений и добавляется временной буфер, равный максимальному времени, требующемуся на освоение денежного буфера. В результате критический путь проекта увеличивается, тем самым увеличивая временны´ е резервы и всех остальных задач (поэтому они и не пересматривались на данном шаге).
8. При каждом изменении в ходе проекта (завершении каких-то задач, расходовании средств, возникновении непредусмотренных ситуаций) буферы пересчитываются заново и проверяются на соответствие скорректированному бюджету проекта.
Результат. Диаграмма Ганта с временны´ ми буферами на критическом пути и пересчитанной плановой стоимостью каждой задачи.
Стоимостные буферы, выделенные под задачи, должны быть подкреплены и натуральными ресурсами. Для этого используется карта доступа к ресурсам (в которой, напомним, были отмечены все возможные, а не только отобранные для проекта ресурсы) и материалы собеседований при найме разработчиков (при чрезвычайных обстоятельствах в проекте привлечение уже оцененных кадров предпочтительнее, мотивация в этом случае может быть и чисто материальной).
В предыдущих разделах были учтены ресурсы и риски, связанные с каждой задачей проекта. Однако существует ресурс, который часто недооценивается или вовсе не учитывается при управлении содержанием: отношение стейкхолдеров. К процессу решения одной и той же задачи стейкхолдеры могут относиться совершенно по-разному, в зависимости от представленного им описания задачи, хода работ, момента предоставления отчета о выполнении/невыполнении задач и многих других факторов. Заинтересованное и благожелательное отношение стейкхолдеров в целом облегчает выполнение задач, а безразличное или негативное – создает критические риски. Поэтому для оценки влияния стейкхолдеров в DaShe предусматривается отдельный метод.
1. Из архива проекта извлекаются и помещаются на видное место перед глазами ПМ:
• карточки стейкхолдеров (с личными ценностями и предпочтениями);
• ограничения по элементам продукта со стороны стейкхолдеров.
2. В ходе проекта ПМ осуществляет регулярные контакты со всеми стейкхолдерами (даже если все идет идеально и никакой помощи от них не требуется). Любые события в проекте, комплементарные ценностям конкретного стейкхолдера, сообщаются при первой же личной встрече. Отслеживаются все события (случившиеся или ожидаемые), которые могут повлиять на позицию стейкхолдера по отношению к проекту в целом или к отдельным задачам, и вносятся в план разговора. Поскольку доступ к стейкхолдерам, как правило, не свободный, ПМ должен заранее составлять расписание встреч и строго его выдерживать.
3. Формулировки и продолжительность задач модифицируются с учетом ценностей и ограничений заинтересованных в них стейкхолдеров. Например, если стейкхолдер убежден, что основная проблема программирования – это написание кода, а отладка – всего лишь формальность («хороший программист сразу пишет правильный код»), разбивка задач на подзадачи должна производиться с бóльшим временем на кодирование (включающим резерв на отладку) и меньшим – на отладку. Если стейкхолдер полагает, что результат – это подпись заказчика на акте, следует выделять отдельные подзадачи для получения такой подписи. Если стейкхолдер считает, что красивые презентации – напрасная трата времени, а то и целенаправленный обман аудитории, о результатах ему нужно докладывать устно, максимум рисуя несколько чисел на бумажке и обводя их кружочком.