Выученные уроки по проекту (постмортем)

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

Постмортем или Выученные уроки — документ, в котором руководитель проекта (при участии команды) фиксирует приобретённый в ходе проекта полезный опыт.

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

Зачем это всё. На последнем месте работы я активно участвовал в пресейлах. И дважды прилетали пресейлы на крайне нетипичную услугу — аудит ПО. То есть, в ходе проекта нужно проанализировать программное обеспечение заказчика и дать по нему экспертные выводы. Какие недостатки, что можно улучшить. И заказчик для участия в тендере, просил предоставить кейсы. То есть, примеры реальных проектов, в ходе которых мы уже проводили аудит.

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

Подход к написанию постмортема

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

Будет здорово, если вы предоставите сотрудникам возможность тоже делать такие записи. Если доверия в команде нет — при помощи анонимной формы.

4.7.3.1 ОБНОВЛЕНИЯ ДОКУМЕНТОВ ПРОЕКТА
В результате закрытия проекта все документы проекта могут быть обновлены и помечены как окончательные версии.

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

PMBOK, версия 6

Вы можете завести в своей базе знаний что-то вроде «судового журнала» проекта и фиксировать в нём все эти вещи.

Типы выученных уроков

1. Неудачи и их причины: тут расписываем всё, что пошло не так. Команда расскажет подробности, вы же можете рассмотреть ситуацию в целом. Наверное, главное, что должно быть в постмортеме.
2. Лучшие практики, наоборот, что было хорошего. Мы, например, в прошлом проекте придумали, как проводить презентации требований так, чтобы заказчик смог начать отвечать на вопросы.
3. Предложения по изменению стандартных процессов для особых типов проектов. Это может быть необходимость планирования дополнительных проектных буферов, ввод нового уровня аппрува предлагаемых изменений в ходе реализации. В общем, что угодно, что могло бы упростить вам жизнь и решить проблемы до их появления.
4. Очевидные вещи, которые нигде не задокументированы. Лишнее напоминание до старта проекта проверить график отпусков исполнителей ещё никому не повредило.
5. То, что было задокументировано ранее, но находилось в неожиданном месте. Вы нашли в базе знаний полезный гайд, про который не было известно, потому что он лежал не в той папке? Отлично, дайте на него ссылку. И перенесите туда, где он должен находиться.

Структура постмортема

1. Цели проекта: какие критерии достижения ставились и как они выполнены, почему были отклонения?
2. Результаты проекта: что необходимо было сдать заказчику и что по факту сделано, когда сдано и почему были отклонения?
3. Информация о выполнении бюджета проекта (в деньгах или в человекочасах)
4. Хронология изменений в базовом плане. Позволяет оценить, сколько раз руководитель проекта «обнулял счетчик» проекта.
5. Опыт для последующих команд.
6. Чек-лист передачи проекта на поддержку.

Очень важно, чтобы вся информация имела конкретный характер, идеально — если она будет со ссылками на проектные документы.

Примеры записей

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

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

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

Из-за отсутствия у заказчика видения проекта и склонности затягивать решения, итерации комплектовались задачами не в полном объёме, некоторые специалисты простаивали. Из-за этого количество итераций выросло с 5 до 9 и срок проекта съехал с середины марта на середину июня.

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

В целом, это всё, что вам нужно знать о постмортемах.