18.10.2021 | Автор: OleshkoV | 246 просмотров
Извлеченные уроки: что предлагает РМВОК?

Встретилась мне этим летом вот такая статья об управлении знаниями по РМВОК 6. В августе вышло седьмое издание РМВОК, поэтому теоретически есть возможность, что какая-то часть материала статьи уже устарела. Но на практике это вряд ли: если я правильно поняла, на уровне процессов и инструментов в новом издании никаких новшеств нет.

Если вы знакомы с РМВОК 6, то в курсе, что управлению знаниями там посвящено страниц 5-6, и они не сильно помогут вам наладить эти процессы, если вы не знакомы хоть немного с тем, что такое knowledge management в принципе. В качестве главного артефакта там рассматривается реестр извлеченных уроков, который по окончании проекта должен сохраняться в соответствующем репозитории. Есть упоминание одной строкой ряда инструментов вроде сообществ практиков, наставничества, дискуссионных форумов, конференций и т.п. И есть описание требований к процессу на самом высоком, а потому довольно абстрактном, уровне.

В своей статье Атул Гаур попытался внести хоть какую-то конкретику по работе с реестром извлеченных уроков. В частности, он потрудился свести все процессы управления проектом, в которых используется этот документ в качестве входа или выхода, в единую таблицу (она очень большая и предельно простая для понимания, поэтому переводить я ее не стала). И вторая его наработка – это перечень пунктов, которые желательно включить в реестр извлеченных уроков (буквально – содержание документа). Сразу оговорюсь, что по моему опыту, сохранять извлеченные уроки в длиннющем pdf-документе со всеми этими разделами, а потом сохранять такой документ в базе даже с очень хорошим поисковиком – нерабочая история. И это то, что у Ника Милтона называется первым уровнем зрелости в его модели зрелости извлеченных уроков. Но я вижу ценность в этой структуре как в своеобразном чек-листе, который команда проекта может использовать на ретроспективе, чтобы убедиться, что ничего не упущено. Автор совершенно правильно указывает, что заполнять реестр лучше по ходу всего проекта, а не на этапе закрытия, иначе вы рискуете утратить часть важных знаний. Однако структуру реестра я бы делала другой и уж точно не вела бы его в формате текстового документа. И на ретроспективе хорошо пройтись с командой еще раз по всему этому документу.

Итак, что Атул Гаур предлагает включить в содержание реестра:

  1. Проектная информация
    1. Данные о самом проекте
    2. Данные о команде проекта
  2. Достижения и успехи
    1. Основные достижения проекта
    2. Факторы, которые обусловили успех проекта
    3. Насколько полно проект соответствует установленным критериям успеха
  3. Вызовы и проблемы
    1. Основные вызовы проекта
    2. Шаги, предпринятые для того, чтобы справиться с этими вызовами
    3. Проблемы, с которыми пришлось столкнуться на разных этапах проекта
  4. Возможности
    1. Возможности, которые создал проект
    2. Точность экономического обоснования и финансового анализа
    3. Рекомендации для будущих проектов
  5. Управление границами проекта
    1. Отклонения в границах проекта
    2. Корректирующие и предупреждающие действия, которые команда предприняла для исправления этих отклонений
    3. Уроки, полученные относительно процесса сбора требований
  6. Управление расписанием проекта
    1. Отклонения в расписании проекта
    2. Корректирующие и предупреждающие действия, которые команда предприняла для исправления этих отклонений
    3. Уроки, полученные относительно точности и полноты списка задач, оценки их продолжительности и составления графика
  7. Управление затратами
    1. Отклонения бюджета
    2. Корректирующие и предупреждающие действия, которые команда предприняла для исправления этих отклонений
    3. Полученные знания об оценке затрат
    4. Шаги по улучшению точности оценки затрат в будущих проектах
  8. Управление качеством
    1. Отклонения в требованиях к качеству
    2. Корректирующие и предупреждающие действия, которые команда предприняла для исправления этих отклонений
    3. Знания, полученные при валидации результатов проекта
    4. Проблемы, с которыми пришлось столкнуться при выполнении корректирующих действий для обеспечения требований к качеству
  9. Управление ресурсами
    1. Уроки, полученные относительно привлечения и управления ресурсами проекта
  10. Управление коммуникациями
    1. Уроки, полученные благодаря вызовам, с которыми пришлось столкнуться в ходе коммуникаций по проекту, и методы решения этих проблем
  11. Управление рисками
    1. Риски, реализовавшиеся в проекте, и шаги, которые были предприняты для снижения проектных рисков
    2. Вызовы, с которыми пришлось столкнуться при реализации плана реагирования на риски
    3. Эффективность плана реагирования на риски
    4. Новые риски, которые не были изначально учтены при планировании
  12. Управление поставками
    1. Уроки, полученные относительно управления договорами
    2. Опыт, полученный при взаимодействии с поставщиками и вендорами, который нужно учесть в будущих поставках
  13. Управление стейкхолдерами
    1. Информация, относящаяся к вовлечению стейкхолдеров

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

Инструменты / 18.10.2021 | Просмотров: 246 | Добавил: OleshkoV | Всего комментариев: 0 / Теги: lessons learned, инструменты управления знаниями
ОБ АВТОРЕ
Виктория Олешко Олешко Виктория, бизнес-тренер, консультант, фасилитатор, главный редактор сайта SixSigmaOnline.ru.
Хотите узнать больше об управлении знаниями? Присоединяйтесь к группе на Facebook. Связаться с автором через Facebook или LinkedIn.

Поддержать автора на Patreon

ПОХОЖИЕ МАТЕРИАЛЫ


  Добавить комментарий
avatar
SixSigmaOnline.ru © 2009-2021            Хостинг от uWeb