Артефакты в управлении проектами, ч 2
Всем привет! Сегодня у нас с вами вторая часть разбора артефактов в управлении проектами. В первой части мы определили, что такое артефакт в контексте РМ, какие задачи решает, какие могут быть подходы для подбора артефактов на проект, а также разобрали артефакты, которые можно было бы использовать на этапах Инициации и Планирования проекта. Продолжаем, собственно, на очереди у нас обзор инструментов, документов, техник, которые могут быть применены на этапах Выполнения, Контроля и Завершения проекта.
Я женщина простая, продолжаю нумерацию с того на чем остановилась, поэтому:
3. Выполнение
Задачи на этапе выполнения проекта:
- выполнить проект
Не настолько просто, разумеется, но я не удержалась. На этапе выполнения у нас глобально есть задачи реализовать план, который мы наметили, то есть мы должны:
- выполнить намеченные задачи — есть управленческие, которые помогают достигнуть цели проекта, и содержательные задачи, которые нацелены на достижение намеченных результатов, то есть на освоение скоупа проекта, а так же на соблюдение требований проекта.
- исполнить бюджет — это директивный документ, значит он исполняется, здесь и фиксирование доходов, расходов, финансовых результатов, оценки стоимости различные.
- соблюсти сроки
- коммуницировать (с командой, со стейкхолдерами, с заказчиком, с внешним миром) и отчитываться о статусе выполнения проекта
- управлять изменениями — изменения неизбежны, в фокусе остается главная цель проекта, если меняется главная цель, то скорее всего, этот проект уже прекращает свое существование и будет инициирован новый, пусть и на базе старого.
- управлять рисками — здесь нас больше интересуют именно стратегии реагирования, по сути, наши последующие действия в случае наступления риска, который мы определили как возможный на стадии планирования, или который появился внезапно в процессе реализации проекта.
На то, как именно эти задачи выполняются больше всего влияет выбранная методология управления проектами (линейная или гибкая методологии, итеративный, спиральный, инкрементный подходы, и т.д.).
У нас есть, например, проект по разработке мобильного приложения, и вот этот проект как идея отдается двум разным командам, одна из которых работает по Waterfall, а вторая по Scrum.На этапе Планирования обе две эти команды определяют, какие цели будут у мобильного приложения, но одна команда делает это максимально детализированно и не переходит к выполнению конкретных работ до завершения работ над полной и исчерпывающей документацией, а также списка работ и задач на основании документации, а вторая ограничивается примерным перечнем фичей, общим описанием и всю детализацию закладывает в выполнение, итеративно отщипывая по кусочку от большой идеи проекта, декомпозируя и детализируя требования, определяя результат, и выдавая готовый инкремент в конце каждой такой итерации.
Поэтому на этапе выполнения набор артефактов в этих двух командах будет разным, глубина проработки этих артефактов тоже будет разной, как и частота их обновления.
Мне проще указать и расписать те артефакты, которые я знаю, использовала или видела в работе, чтобы не быть голословной, а вы можете привести примеры тех документов, материалов, инструментов или результатов, которые использовали в своей работе вы.
- 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 (Бэклог спринта), список задач или работ, которые должны быть выполнены в течение одного спринта. Бэклог спринта формируется на основе бэклога проекта.
Дополняйте, не стесняйтесь.
Важно отметить, что большая часть работы сейчас сконцентрирована в том или ином таск-трекере, то есть инструменте, где я могу вести и расписание, и бэклог, и формировать спринты, и давать требования по каждой задаче цикла разработки, и ставить управленческие задачи, и мониторить проект над которым работает несколько отделов, например, без выделенной команды. Поэтому на то, какие артефакты вы используете, также влияет и то, какой трекер задач у вас, есть у него инструменты встроенные или нет для этих артефактов.
4. Контроль
Задачи на этапе контроля проекта (который может идти параллельно Выполнению, а не последовательно) следующие:
- мониторить ход выполнения проекта (скоупа, сроков, бюджета, качество)
- отслеживать отклонения, их причины и последствия, и информировать о них
- решать конфликты (коммуникация между членами команды и вне, между документацией и реализацией)
С этапом Контроля все вроде как и проще, с одной стороны, а вроде как и сложнее. По сути, контроль нам нужен для того чтобы обеспечить качество (то, что находится в центре проектного треугольника и непременно потеряется, вытечет, если не соблюдать баланс между скоупом, сроками и бюджетом).
Когда мы контролируем, у нас есть:
- области контроля, это скоуп (продукт, по сути), бюджет (и иные ресурсы), сроки и само качество (соответствие тем или иным требованиям),
- отклонения (ожидания и реальность не совпадают по разным причинам),
- конфликты (интересов, людей, документации и продукта).
Лучше всего задачи контроля решают метрики. То есть конкретные показатели, коэффициенты, что-то измеримое, что можно отнести к конкретной области, что помогает увидеть отклонения и индентифицировать их причину, то что можно однозначно интерпретировать, чтобы избежать конфликта, потому что все в курсе, как именно это мониторится и считается.
Метрики могут быть продуктовыми, например, конверсии, вовлеченность, удержание пользователей, управленческими — эффективность затрат, возврат инвестиций, могут быть для разработки — скорость разработки, завершенность разработки, для тестирования — покрытие кода тестами, и так далее. Метрики могут быть также плановыми и фактическими, чаще всего их сравнивают в динамике (то есть во времени).
Поэтому к артефактам этапа Контроля проекта я бы отнесла только один:
- Дашборд метрик проекта
В зависимости от того, какой проект, какой контекст, какая методология, какие цели, какие инструменты (и для разработки, и для тестирования, и прочие), будут разные метрики, которые помогут вам понимать, насколько хорошо проект реализовывается.
Сейчас еще пример приведу, вам понравится. В практике менеджмента проектов есть рекомендация на этапе контроля мониторить Test Coverage Document, мол, это документ, который описывает объем и качество тестирования продукта или проекта. Он включает в себя информацию о тестовых сценариях, тестовых данных, методах тестирования и охвате тестирования различных аспектов продукта. Однако в современной разработке у большинства QA-команд есть системы управления тестами, которая помогает считать метрику Test Coverage, а тестовые сценарии и тестовые данные строятся из кода, потому что код как документация. И получается, что сам документ никто не пишет, это долго, сложно и излишне бюрократично. Реал-тайм метрики важнее и прозрачнее, чем документы.
Приводите аргументы свои за / против такой позиции, накидывайте примеры метрик, которые вы контролируете, на что вообще обращаете внимание. Или укажите, какие документы вам нужны, нельзя жить без них на этапе Контроля.
Смею предположить, что кто-то вспомнит про Requirements Traceability Matrix (Матрица соответствия требований, Матрица трассируемости). Это матрица, которая связывает требования к проекту с соответствующими тестовыми сценариями и проверками. Помогает убедиться, что все требования покрыты тестированием, ничего не упущено при разработке проекта, важно для продактов и аналитиков. Но этот документ собирается теми же системами управления тестами, при сборке покрытия тестами в связке код ⇄ тест, если при разработке разработчик указывал тегом, какую часть требования покрывает этот код (со ссылкой на требование).
5. Завершение
На этапе Завершения проекта есть задачи:
- оценить фактические результаты, сравнить с плановыми
- признать проект успешным / неуспешным на основе оценки
- подготовить проектную документацию, оформить в архив
- презентовать результаты, выводы и предложения по итогу проекта
- запланировать пост-проектное обслуживание и сопровождение, если применимо
Мое скромное мнение, что на этапе завершения у нас есть только Press Release (Пресс-релиз) или иной способ фокусированной коммуникации для информирования о результатах проекта, Слепок метрик на Дашборде проекта и выводы за период проекта и на момент завершения, сравнение этих метрик с плановыми, выводы и рекомендации.
То есть у меня есть документы, артефакты, которые я использовала с самого начала, я обновляю, актуализирую, закрываю и сдаю в архив. Готовлю оформленные результаты (отчет, презентация, справка, что угодно) и направляю заинтересованным сторонам. Все.
Отмечаю с командой, сама с собой отмечаю тоже, бью еще одну звездочку на боку в тату-салоне после завершения проекта, и на этом мои артефакты все.
Я там планировала в первой части флоу расписать, как можно двигаться по артефактам, но, видимо, это идея на другую статью. Ее пока не знаю, как и когда напишу, но напишу!
Надеюсь, вам было интересно, пишите, в чем согласны и несогласны, делитесь опытом, мнениями, я жду в нетерпении!
Залетайте на мой менеджерский огонек, задавайте мне вопросы в чате канала:
долго думала, как ответить, потому что комментарий вроде как не предполагает ответа, просто вырванная из контекста фраза, не относящаяся к статье и относящаяся скорее ко всей дисциплине менеджмента проектов, или ваше какое-то мнение вслух (но я не увидела аргументов, чтобы ответить более конструктивно)
давайте отвечу на примере.
пускай у нас проект - это прививка от опасной болезни, целью болезни будет - захватить организм, подчинить, размножить свои болезненные клетки, у болезни все очень хорошо с планированием, пришла - увидела - нашла брешь в защите организма - подчинила себе - победила. если же этой болезнью управляют, чтобы привить организм и не дать ему умереть, то планы болезни не имеют смысла, есть план того, кто ее направил, кто контролирует ее течение, кто может добавить организму ресурсов для борьбы или дать лекарство для полноценного исцеления.
проекты подвержены изменениям, и планы не спасут, нужно живое и своевременное реагирование на риски, запросы, конфликты, людей, поэтому управление - не про власть и могущество, а про контроль, мониторинг, реагирование (проактивное и реактивное), и поэтому нужны инструменты и методы, о которых я пишу на основе своего опыта.