Артефакты в управлении проектами, ч 2

Всем привет! Сегодня у нас с вами вторая часть разбора артефактов в управлении проектами. В первой части мы определили, что такое артефакт в контексте РМ, какие задачи решает, какие могут быть подходы для подбора артефактов на проект, а также разобрали артефакты, которые можно было бы использовать на этапах Инициации и Планирования проекта. Продолжаем, собственно, на очереди у нас обзор инструментов, документов, техник, которые могут быть применены на этапах Выполнения, Контроля и Завершения проекта.

Я женщина простая, продолжаю нумерацию с того на чем остановилась, поэтому:

Задачи на этапе выполнения проекта:

• выполнить проект

Не настолько просто, разумеется, но я не удержалась. На этапе выполнения у нас глобально есть задачи реализовать план, который мы наметили, то есть мы должны:

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

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

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

• Change Request (Запрос на изменение) — это документ, в котором оформляется запрос на внесение изменений в проект или его часть. Обычно возникает, когда появляются новые требования, изменяются условия или возникают проблемы, которые необходимо решить.
• Change Log (Журнал изменений) — документ, в котором фиксируются все изменения, вносимые в проект, обычно в формате таблицы. В нем указывается, кто запросил изменение, какие изменения были внесены, когда это произошло и какие последствия имеет каждое изменение.
• Impact Assessment (Оценка влияния) — это и инструмент, и процесс оценки потенциального влияния изменений на проект. Оценка проводится для определения того, как изменения могут повлиять на бюджет, сроки, ресурсы и другие аспекты проекта, чтобы принять обоснованное решение о том, следует ли внести эти изменения или нет. Там есть встречи, расчеты, поднятие архивной документации (а как раньше похожие изменения оценивались).
• Follow-Up Register (Реестр последующих действий) — документ, в котором фиксируются все события, которые мы определяем как рисковые, а также даты наступления и решения, ответственного, действия, которые нужны для того чтобы снизить влияние риска или развить влияние выявленной возможности, описание возможных последствий тоже там. Включает в себя и события, которые на этапе планирования определили, и возникшие непредвиденно по ходу выполнения проекта.
• Incident Priority (Классификация приоритетов для инцидентов) — классификация инцидентов по уровню их важности и срочности для бизнеса или проекта, его последствий для клиентов или бизнеса, а также времени, необходимого для его решения.
• Cause/Effect Diagram (Диаграмма причины и следствия) — инструмент, который помогает исследовать и понять причины возникновения проблемы или инцидента, а также их влияние на другие аспекты проекта или бизнеса. Диаграмма строится в виде древовидной структуры, где проблема (эффект) располагается в центре, а ее причины разбиваются на уровни, что помогает выявить основные и дополнительные причины проблемы. Удобно для разбора каких-то сложных многоуровневых рисков для работы над ошибками и более точным планированием последующих действий при создании стратегии реагирования на риск.
• Press Release (Пресс-релиз) — способ фокусированной коммуникации для информирования общественности, СМИ и заинтересованных сторон о новом продукте, услуге или достижениях. Я лично использовала такой способ для оповещения команды (не только команды проекта), а в целом всей команды, чтобы рассказать, как идут дела на проекте, как далеко мы продвинулись, какие планы и цели. То есть здесь в качестве заинтересованных сторон могут быть и другие сотрудники, и члены команды проекта, и стейкхолдеры, и заказчик, то есть все ключевые события донесены до всех ключевых персон.
• Release Notes (Релиз-ноутс) — способ фокусированной коммуникации для передачи информации о выпущенной версии продукта. В релиз-ноутс указываются новые функции, исправления ошибок, изменения в интерфейсе или производительности, а также инструкции по установке и использованию новой версии. При инкрементном подходе, например, регулярное составление релиз-ноутс это продуктовая, маркетинговая и проджектовая задачка.
• Project budget (Бюджет проекта) — это и документ, и инструмент, и само бюджетирование многоуровневый процесс, поэтому нельзя сказать, что бюджет появился только на этапе планирования, нет, при выполнении проекта я выполняю и бюджет, фиксируя по факту доходы и расходы, не выхожу за рамки, фиксирую изменения и отклонения.
• Project Schedule (Расписание проекта) — как следует из названия, это и график работ, и расписание задач и действий, необходимых для завершения проекта, по времени. Чаще всего расписание включает в себя Milestones (Вехи), то есть ключевые события в проекте, которые помогают оценить прогресс.
• Project Backlog (Бэклог проекта) — список всех задач, требований, функций или изменений, которые должны быть выполнены в рамках проекта. По сути, формируется после этапа Планирования за счет наполнения требованиями конкретных задач, нужных для достижения конкретных результатов, которые мы там запланировали при создании Карты результатов или WBS. В Scrum есть также Sprint Backlog (Бэклог спринта), список задач или работ, которые должны быть выполнены в течение одного спринта. Бэклог спринта формируется на основе бэклога проекта.

Дополняйте, не стесняйтесь.

Важно отметить, что большая часть работы сейчас сконцентрирована в том или ином таск-трекере, то есть инструменте, где я могу вести и расписание, и бэклог, и формировать спринты, и давать требования по каждой задаче цикла разработки, и ставить управленческие задачи, и мониторить проект над которым работает несколько отделов, например, без выделенной команды. Поэтому на то, какие артефакты вы используете, также влияет и то, какой трекер задач у вас, есть у него инструменты встроенные или нет для этих артефактов.

Задачи на этапе контроля проекта (который может идти параллельно Выполнению, а не последовательно) следующие:

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

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

Когда мы контролируем, у нас есть:

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

Лучше всего задачи контроля решают метрики. То есть конкретные показатели, коэффициенты, что-то измеримое, что можно отнести к конкретной области, что помогает увидеть отклонения и индентифицировать их причину, то что можно однозначно интерпретировать, чтобы избежать конфликта, потому что все в курсе, как именно это мониторится и считается.

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

Поэтому к артефактам этапа Контроля проекта я бы отнесла только один:

• Дашборд метрик проекта

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

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

Смею предположить, что кто-то вспомнит про Requirements Traceability Matrix (Матрица соответствия требований, Матрица трассируемости). Это матрица, которая связывает требования к проекту с соответствующими тестовыми сценариями и проверками. Помогает убедиться, что все требования покрыты тестированием, ничего не упущено при разработке проекта, важно для продактов и аналитиков. Но этот документ собирается теми же системами управления тестами, при сборке покрытия тестами в связке код ⇄ тест, если при разработке разработчик указывал тегом, какую часть требования покрывает этот код (со ссылкой на требование).

На этапе Завершения проекта есть задачи:

• оценить фактические результаты, сравнить с плановыми
• признать проект успешным / неуспешным на основе оценки
• подготовить проектную документацию, оформить в архив
• презентовать результаты, выводы и предложения по итогу проекта
• запланировать пост-проектное обслуживание и сопровождение, если применимо

Мое скромное мнение, что на этапе завершения у нас есть только Press Release (Пресс-релиз) или иной способ фокусированной коммуникации для информирования о результатах проекта, Слепок метрик на Дашборде проекта и выводы за период проекта и на момент завершения, сравнение этих метрик с плановыми, выводы и рекомендации.

То есть у меня есть документы, артефакты, которые я использовала с самого начала, я обновляю, актуализирую, закрываю и сдаю в архив. Готовлю оформленные результаты (отчет, презентация, справка, что угодно) и направляю заинтересованным сторонам. Все.

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

Я там планировала в первой части флоу расписать, как можно двигаться по артефактам, но, видимо, это идея на другую статью. Ее пока не знаю, как и когда напишу, но напишу!

Надеюсь, вам было интересно, пишите, в чем согласны и несогласны, делитесь опытом, мнениями, я жду в нетерпении!

Залетайте на мой менеджерский огонек, задавайте мне вопросы в чате канала:

#projectmanagement #projectpixie