Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 33)
2) С дружественными стейкхолдерами проводятся переговоры, исходя из их текущей мотивации, относительно помощи, которую они могут оказать в решении вопроса; результатом переговоров должна стать осознанная мотивация стейкхолдеров «решить этот вопрос в моих интересах».
3) Один из дружественных стейкхолдеров инициирует обсуждение вопроса на совещании и, если он подготовлен (см. п. 2), добивается полезного для проекта решения.
4. В случае если коалиция противников проекта сильнее коалиции сторонников, ПМ активизирует работу по замене одного или нескольких стейкхолдеров.
Результат. ПМ выбирает наиболее эффективный способ воздействия на стейкхолдеров.
Неизменный состав стейкхолдеров бывает только в очень маленьких или в очень везучих проектах. Любой реальный стартап – это история постоянной смены ключевых игроков и их представителей. Поэтому ПМ должен спокойно относиться к замене стейкхолдеров и уметь управлять этим процессом.
1. Независимо от текущего положения дел в проекте, ПМ регулярно ищет альтернативных стейкхолдеров (инвесторов, партнеров, потребителей и т. д.). Для этого используются те же методы, что и для поиска прочих людей: регулярный опрос всех знакомых и участие в профильных мероприятиях (тусовках). Каждый потенциальный стейкхолдер включается в список аффилянтов проекта. ПМ проводит с ним переговоры о потенциальном интересе к проекту и, если такой интерес проявлен, включает возможного стейкхолдера в свой перечень контактов по проекту (см. «Управление репутацией»).
NB. Сферы деятельности, в которых чаще встречаются потенциальные стейкхолдеры: финансы, наука, производство, юридические услуги, государственные органы и общественные организации.
2. Если возникает ситуация, требующая или благоприятствующая замене одного из стейкхолдеров, ПМ проводит переговоры с дружественными стейкхолдерами и начинает процесс, выпуская официальный документ.
Результат. ПМ располагает опцией «замена стейкхолдера» в случае возникновения критических проблем в проекте.
3.6. Управление стоимостью
Цель проекта – создание качественного продукта в рамках заданных ограничений: сроков и бюджета. Выдерживание сроков обеспечивается путем управления процессом (см. п. 3.2). Чтобы уложиться в бюджет, требуется точно так же управлять другим компонентом проекта: его стоимостью.
Для выполнения проекта в рамках бюджета ПМ регулярно (по итогам каждого этапа) осуществляет три действия: 1) распределяет произведенные расходы по выполненным задачам (фиксация отгрузок); 2) прогнозирует будущие расходы, исходя из достигнутого уровня производительности (метод освоенного объема); 3) изменяет расписание проекта, если появляются риски превышения бюджета. Управление стоимостью – всего лишь регулярное выполнение этих трех методов.
Бюджет проекта расходуется непрерывно, каждый месяц платится зарплата, аренда, периодически оплачиваются услуги подрядчиков. Для понимания, насколько все эти расходы приближают создание продукта, необходимо соотносить произведенные затраты с полученными результатами – выполненными заданиями, решенными задачами и созданными элементами. Для этого используется метод «Отгрузки», в рамках которого выполнение каждого задания (причем неважно, подрядчиком или разработчиком) оформляется как отгрузка – товар или услуга, имеющая конкретную стоимость.
1. ПМ фиксирует все производимые в рамках проекта расходы, разделяя их на оплату подрядчикам и собственные расходы на разработку.
2. После завершения очередного этапа рассчитывается стоимость выполнения каждого из активных в этот период заданий, она складывается:
из платежей подрядчикам, отнесенным на задание (если оплата производится за несколько заданий, доля каждого рассчитывается, исходя из предоставленной подрядчиком оценки трудоемкости);
долей в зарплатах разработчиков, работавших над заданием:
долей в произведенных собственных затратах:
3. Производится контроль: сумма стоимостей заданий должна быть равна расходам за период.
4. Окончательная (появившаяся только после завершения платежного периода) стоимость завершенного задания включается в расписание проекта. С этого момента задание становится отгрузкой.
Результат. Все уже выполненные в ходе проекта задания, решенные задачи и созданные элементы имеют конкретную стоимость, которой можно оперировать в ходе дальнейшего управления.
Если за семь месяцев проекта, рассчитанного на год, реализовано четыре из десяти запланированных элементов продукта, то хорошо идут дела или плохо? Чтобы точно ответить на этот вопрос, необходимо знать соотношение стоимостей уже сделанных и еще не сделанных работ. По завершенным элементам известна и плановая (см. первоначальную диаграмму Ганта), и фактическая (сумма отгрузок) стоимость, по оставшимся – только плановая. Для их сопоставления необходимо определить прогнозируемую фактическую стоимость оставшихся работ. Для этого используется метод анализа освоенного объема.
1. В ходе составления расписания была определена плановая стоимость каждой из запланированных задач (
2. После завершения первой задачи (а также каждой последующей) ПМ рассчитывает текущие характеристики. Во-первых, освоенный объем (
3. После этого рассчитывается индекс исполнения стоимости (
4. Если индекс меньше единицы, производится оценка суммы возможного перерасхода бюджета. Для этого строится линейная регрессия по значениям CPI за всю историю проекта, вычисляется его прогнозное значение на момент завершения проекта, CPI’. Отсюда находится текущая оценка суммы перерасхода:
5. В случае нарастающей тенденции к перерасходу бюджета и/или чрезмерно высокой (выше запланированных резервов) ECV производится анализ каждой задачи с целью выявить наиболее проблемные по производительности участки.
Результат. В каждый момент времени в проекте у ПМ есть достаточно объективная оценка текущей производительности, позволяющая оценить прогнозируемую стоимость проекта в целом и оперативно принять меры, если она выходит за пределы бюджета.
Весь смысл управления стоимостью заключается в том, чтобы не дожидаться фактического превышения бюджета, а заблаговременно принять какие-то меры по исправлению ситуации. Если после очередного спринта оценка перерасхода превышает некий «порог чувствительности», ПМ незамедлительно производит коррекцию расписания.
1. На основе анализа освоенного объема по каждой задаче ПМ определяет узкие места – задачи с наименьшей достигнутой производительностью. Выясняются причины несоответствия плановой и фактической производительности (недостаточная квалификация разработчиков, проблемы с коммуникацией, мотивацией, неудачные технические решения, ошибки в оценке стоимости и т. д.).
2. Если устранение причин возможно силами самого ПМ, он их устраняет (перераспределяет работы, налаживает коммуникации, мотивирует разработчиков, обеспечивает принятие лучших технических решений).
3. Если устранение причин требует эскалирования, ПМ незамедлительно к нему прибегает: составляет обстоятельную докладную записку и дает ей ход с учетом политических раскладов.
Результат. Если возникают риски перерасхода бюджета, ПМ своевременно корректирует расписание.
3.7. Управление качеством
Цель проекта – создание не какого получится, а
Ожидания, не вошедшие в бэклог, существуют всегда и по двум причинам. Во-первых, универсальное требование «продукт должен нормально работать» на деле означает «продукт не должен раздражать аффилянта непонятным или неприятным поведением» – но выяснить, какое именно поведение продукта является непонятным или неприятным, можно только после создания соответствующей функциональности. В бэклоге записано, что продукт должен делать; записать все, чего он