Метод Lessons Learned: как менеджеру не повторять ошибок в проекте

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

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

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

Если в компании есть проектный или продуктовый офис, то сбор извлечённых уроков — это его функция. Если такого процесса ещё нет — инициируйте его самостоятельно.

Что такое Lessons Learned

Это процесс обмена информацией внутри проектного/продуктового офиса (если он есть) или внутри вашей команды в целом. Для него необходимо:

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

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

Обмен извлечёнными уроками между командами — отличный способ предотвратить повторение одних и тех же ошибок.

Какими уроками можно делиться

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

Как собирать и использовать уроки

1. Проанализируйте проект и попросите команду сделать то же самое. Для этого можно подготовить опросник, можно попросить оставить фидбек в свободной форме. Для крупных проектов лучше проводить такой анализ регулярно, пока воспоминания ещё свежие.
2. Запланируйте встречу для обсуждения, выберите фасилитатора. Фасилитатором не обязательно должны быть вы. Иногда рекомендуют, чтобы это был не менеджер проекта/продукта, чтобы не давить на команду. Ко встрече должно быть готово общее пространство, где все члены команды смогут ознакомиться с уже собранными уроками.
3. Проведите встречу. Она может быть в формате ретроспективы. Вам нужно ответить на три вопроса: Что было хорошо? Что пошло не так? Что стоит улучшить?
4. По итогам встречи оформите документ, которым можно поделиться со всеми. В документе должно быть краткое изложение выводов, к которым вы пришли во время встречи, список Lessons Learned и подробные рекомендации.
5. Используйте этот документ для следующих этапов проекта.
6. Выберите общее пространство, где будете хранить документ. Его должно быть легко найти любому члену проекта, к нему не нужно настраивать дополнительные доступы. Если требуется, внесите изменения в уже существующую документацию, чтобы при ознакомлении с ними можно было прочитать и ваши выводы и советы.
7. При запуске нового проекта обратитесь к базе знаний и найдите подобный документ по аналогичному проекту.

Пример документа Lessons Learned

Вот как можно оформить документ:

Разбивайте Lessons Learned по типам и обязательно пишите следующие шаги, чтобы внедрить изменения и улучшить процессы в компании.