Почему одни и те же ошибки повторяются в проектах снова и снова?

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

Метод Lessons Learned — это систематический подход к извлечению, документированию и применению опыта, полученного в ходе project. По сути, это корпоративная версия старой мудрости «учись на своих ошибках», только более структурированная и без синяков на лбу.

Этот метод помогает решить ряд классических проблем:

• Повторение одних и тех же ошибок из проекта в проект (с вероятностью 90%, как показывает практика)
• Потеря ценных инсайтов и находок при переключении между project
• Отсутствие механизма передачи знаний между командами
• «Изобретение велосипеда» каждой новой командой

Давайте разберемся, как превратить болезненные факапы в ценный актив для будущих проектов.

Что такое Lessons Learned и почему это важно

Согласно Институту управления project (PMI), Lessons Learned — это процесс систематического сбора, оценки и документирования опыта, разработок, ошибок и рисков из проектов с целью их последующего применения. Если перевести с официального на человеческий: это способ не дать ценному опыту уйти в небытие после завершения project.

На практике это работает примерно так: вы наконец-то запустили тот многострадальный сервис для клиента (который, кстати, еще и в срок не уложился), выдохнули… и вместо того, чтобы сразу нырять в новый проект, останавливаетесь и задаете команде три волшебных вопроса: «Что прошло хорошо?», «Что пошло не так?» и «Что стоит улучшить в следующий раз?». И, что самое важное, — записываете ответы.

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

Впрочем, извлеченные уроки — это не только про ошибки, но и про победы. Например, ваша команда впервые провела предварительное тестирование фичи, что позволило сэкономить кучу времени на финальных этапах. Было бы глупо не сделать это стандартной практикой, верно?

Основные преимущества применения метода:

• Предотвращение повторения одних и тех же ошибок
• Снижение рисков в новых project
• Повышение качества и эффективности работы
• Укрепление командного духа через совместный анализ
• Создание базы знаний для новых сотрудников
• Сокращение времени и средств на «изобретение велосипеда»

Звучит как шаг к светлому корпоративному будущему? Безусловно. Но, как это обычно бывает с хорошими идеями, всё портит реализация. Поэтому давайте разберемся, какие уроки стоит извлекать в первую очередь.

Основные типы извлечённых уроков

Ошибки и причины их возникновения

Иронично, но самые ценные уроки мы извлекаем из наших самых эпичных факапов. Это как находка археолога — чем глубже копаешь, тем интереснее экспонаты. В случае с проектами важно не просто зафиксировать, что «всё пошло не так», а докопаться до первопричины.

Например, в одном из моих project мы обнаружили, что заказчик постоянно менял требования уже после приемки — и каждый раз это было как внезапное нападение диких ежей на пикник. В результате разбора полетов выяснилось, что мы просто не согласовали процесс внесения изменений на старте. Такая мелочь, а сколько нервных клеток спасла бы!

Удачные решения и лучшие практики

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

Предложения по улучшению

Эта категория включает те инсайты, которые приходят в голову уже после того, как вы набили все возможные шишки. «А что если бы мы…» — начинающиеся так фразы часто содержат зерно гениальности. Например, идея вносить правки дизайна отдельным этапом, а не вместе с исправлением багов. Такие предложения следует не только записать, но и протестировать в следующем project.

Неочевидные, но важные наблюдения

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

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

Когда и как внедрять Lessons Learned

Самое распространенное заблуждение о методе Lessons Learned — что это разовое мероприятие, которое проводится исключительно на поминках проекта (извините, я хотел сказать на «постпроектной ретроспективе»). В реальности же, чтобы извлекать максимум пользы, нужно встроить этот процесс в разные этапы жизненного цикла project.

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

Совет:

Не оставляйте Lessons Learned только на конец project. Для крупных проектов лучше проводить такой анализ регулярно, пока воспоминания ещё свежие, а синяки не успели посинеть еще сильнее.

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

Пошаговый процесс проведения Lessons Learned

Давайте разберём процесс так, чтобы даже начинающий менеджер project(или продвинутый кот в сапогах) мог его провести. Тут нет никакой магии — только систематический подход, который, впрочем, требует определённой дисциплины и умения не срываться на крик при словах «а мы же говорили, что так будет».

Подготовка команды и ожиданий

• Анонсируйте процесс заранее

В идеале — ещё на старте проекта упомяните, что сбор Lessons Learned будет проводиться. Это как предупреждение о фотографировании на американских горках — люди заранее готовятся выглядеть не слишком испуганными.

• Объясните цель и формат

Дайте понять команде, что это не поиск виноватых, а поиск возможностей для роста. И нет, это не про «оптимизацию персонала» — вы же не из HR-отдела. Это про то, как в следующий раз работать более эффективно.

• Назначьте фасилитатора

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

Сбор информации в течение проекта

• Создайте «бортовой журнал»

Звучит как из «Звёздного пути», но на практике это просто документ (таблица, Notion-страница, комментарии на полях распечатанного графика Ганта — неважно), где команда может фиксировать свои наблюдения по ходу проекта.

• Регулярно напоминайте о важности ведения журнала

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

• Проводите промежуточные опросы

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

Проведение встречи Lessons Learned

• Подготовьте повестку

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

• Установите правила

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

• Начните с эмоций

Парадоксально, но я обнаружил, что начать с «как вы себя чувствовали во время проекта» — отличный способ сбросить напряжение и перейти к конструктивному разговору. Используйте смайлики или шкалу от 1 до 10 для визуализации.

• Обсуждайте темы последовательно

Для каждой темы задавайте три ключевых вопроса: Как это произошло? Какие были последствия? Что можно сделать по-другому в будущем? Это как формула расследования в детективе, только без трупов (опять же, обычно).

Документирование и распространение результатов

• Создайте документ

После встречи оформите результаты в структурированный отчёт. Хорошая структура: тип урока (проблема/лучшая практика), описание ситуации, рекомендации на будущее.

• Сделайте результаты доступными

Разместите документ там, где его легко найдёт любой член команды — SharePoint, Confluence, Google Drive. Ключевые инсайты можно даже оформить как плакаты на стене офиса — если, конечно, у вас ещё остался физический офис после пандемии.

• Донесите информацию до заинтересованных сторон

Создайте разные версии отчёта для разных аудиторий. Руководству, вероятно, интересны будут финансовые и стратегические уроки, а не то, что «Джон постоянно забывал писать комментарии к коду».

Внедрение изменений в будущих проектах

• Включите извлечённые уроки в стандартные процессы

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

• Предусмотрите время на изучение прошлых уроков

В начале каждого нового проекта выделите время на изучение соответствующих Lessons Learned из прошлых проектов. Это должно быть в чек-листе запуска, рядом с «создать канал в Slack» и «заказать пиццу на первую встречу».

• Отслеживайте внедрение

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

Как организовать встречу Lessons Learned

Встреча Lessons Learned — это кульминация всего процесса, эдакий финал сезона вашего сериала о проекте. И как в любом хорошем финале, здесь должны быть и откровения, и катарсис, и намеки на следующий сезон. Давайте разберемся, как избежать превращения этой встречи в формальность или, еще хуже, в очередную серию «Игры престолов».

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

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

Что касается времени и места — для полноценного воркшопа выделите минимум 2-3 часа без отвлечений. Да, это много, но помните, что вы анализируете работу, которая могла занимать месяцы или даже годы. И проводите встречу в специально выделенном помещении — не в опенспейсе, где коллеги из соседнего отдела будут сверлить вас взглядами, когда вы начнете обсуждать «тот самый провальный спринт».

Структура встречи Lessons Learned:

• 10 мин:

Приветствие и объяснение формата

• 15 мин:

Представление участников и их роли в проекте

• 20 мин:

Разминка — эмоциональная оценка проекта (можно использовать смайлики, цветные стикеры)

• 40 мин:

Обсуждение проблемных моментов с фокусом на причины и решения

• 40 мин:

Обсуждение успешных практик и возможностей для масштабирования

• 20 мин:

Формулирование конкретных рекомендаций для будущих проектов

• 15 мин:

Согласование дальнейших шагов и ответственных

• 10 мин:

Обратная связь по самой встрече

Особое внимание уделите созданию безопасной атмосферы. Люди будут откровенны только в том случае, если не будут опасаться последствий своей честности. Я однажды был на встрече, где руководитель отдела начал сессию со слов: «Ну что, кто виноват в том, что мы запоздали на месяц?» — можете представить, насколько продуктивным было дальнейшее обсуждение.

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

Инструменты и шаблоны для Lessons Learned

В мире айтишника есть одна фундаментальная истина: правильный инструмент может превратить невыполнимую задачу в тривиальную. То же самое касается и процесса Lessons Learned — с подходящими инструментами он перестаёт быть тягостной обязанностью и становится чем-то вроде археологических раскопок, только вместо древних артефактов вы находите полезные инсайты (и иногда скелеты в шкафу).

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

Из личного опыта, для команд до 10 человек отлично работает связка Notion (для создания структурированной базы знаний) + Miro (для проведения самих сессий). Для корпоративных гигантов с сотней проектов, вероятно, нужно что-то более масштабируемое типа Confluence или специализированных решений.

Как сделать Lessons Learned частью культуры команды

За годы работы в IT я осознал одну непреложную истину: самый крутой процесс не принесет никакой пользы, если команда следует ему с энтузиазмом гимназиста, идущего на урок физики в понедельник утром. Особенно это касается Lessons Learned — процесса, который легко превращается в ритуальное мероприятие «для галочки», где все усердно кивают, а затем с облегчением забывают все сказанное, едва закрывается дверь переговорной.

Чтобы превратить Lessons Learned из формальности в ценный элемент корпоративной ДНК, нужно работать над тремя ключевыми аспектами:

Прозрачность

• Делайте результаты видимыми

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

• Отмечайте улучшения

Когда проблема из прошлого проекта успешно решена в текущем — обязательно публично отметьте это. «Помните, как мы мучились с API-интеграцией в прошлом году? В этот раз, благодаря документированному уроку, мы сделали это на две недели быстрее!»

• Будьте честны в оценках

Если что-то не работает в текущем процессе Lessons Learned — признайте это и измените. Мета-анализ собственных инструментов — признак здоровой культуры.

Безопасность

• Создавайте пространство без обвинений

Ключевой момент — команда должна чувствовать, что можно признавать ошибки без страха последствий. Как говорили в одной компании, где я работал: «У нас не бывает ошибок, бывают только возможности для улучшения» (звучит как корпоративный BS, но на удивление работает).

• Начинайте с себя

Руководители проектов должны первыми признавать свои промахи. «Я недостаточно ясно коммуницировал требования, поэтому команда потратила неделю на ненужную функциональность».

• Хвалите за конструктивную критику

Когда кто-то указывает на реальную проблему, это должно вызывать благодарность, а не раздражение — даже если слышать это неприятно.

Регулярность

• Встройте Lessons Learned в существующие ритуалы

Сделайте это частью спринт-ретро, если работаете в Agile, или регулярных статус-митингов в водопадной модели.

• Выделите время в календаре

Буквально — блокируйте слоты в календаре для сбора и анализа извлеченных уроков, иначе «более важные» задачи всегда будут вытеснять этот процесс.

• Циклически возвращайтесь к прошлым урокам

Раз в квартал проводите обзор ранее зафиксированных инсайтов — это предотвращает эффект «открытия Америки заново».

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

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

Ошибки при проведении Lessons Learned (и как их избежать)

За годы работы в проектном управлении я наблюдал множество ways to fail в процессе сбора и применения извлеченных уроков. Это почти как коллекционирование марок, только вместо марок — креативные способы выстрелить себе в ногу. Вот самые распространенные ошибки, которые совершают даже опытные менеджеры:

Формальность ради галочки

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

Решение:

Показывайте конкретную пользу от предыдущих уроков. «Помните, как мы внедрили промежуточное тестирование после прошлогоднего факапа? Так вот, оно только что спасло нас от срыва сроков в текущем проекте».

Поиск виноватых

Встреча превращается в подобие средневекового суда с охотой на ведьм. «Кто залил эту неоптимизированную функцию в прод?» — такой подход гарантированно закрывает людям рты на всех будущих обсуждениях.

Решение:

Фокусируйтесь на системных проблемах, а не на личностях. Вместо «Маша сделала X неправильно» используйте «В нашем процессе нет проверки X, что привело к проблеме».

Игнорирование положительного опыта

Часто встречи Lessons Learned превращаются в сеансы групповой терапии, где все жалуются. Но успешные практики не менее важны для будущих проектов.

Решение:

Установите правило обсуждать как минимум столько же успехов, сколько и неудач. Используйте формат «Что сработало отлично и как мы можем делать это чаще?»

Отсутствие конкретных действий

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

Решение:

Каждый зафиксированный урок должен иметь связанное с ним действие, ответственное лицо и срок. «До конца месяца Алексей обновит шаблон технического задания, добавив раздел о требованиях к масштабированию».

Перегруз информацией

50-страничный документ с мельчайшими деталями, который никто никогда не откроет после его создания. Это как страховой полис — знаешь, что он существует, но читаешь только когда случилось что-то плохое.

Решение:

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

«Амнезия организации»

Уроки извлекаются, документируются… и благополучно забываются к началу следующего проекта. Через полгода команда повторяет те же ошибки, словно фильм «День сурка».

Решение:

Внедрите обязательный процесс ознакомления с релевантными уроками при запуске нового проекта. Можно даже включить кратный опросник: «Какие основные риски были выявлены в проекте X и как мы планируем их избежать?»

Отсутствие анонимности

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

Решение:

Предусмотрите возможность анонимного сбора обратной связи перед встречей. Используйте анонимные опросы или ящик для предложений (цифровой или физический).

Низкое качество фасилитации

Дискуссия уходит в сторону, самые громкие голоса доминируют, ключевые моменты не фиксируются. Встреча заканчивается ощущением потраченного времени.

Решение:

Инвестируйте в хорошего фасилитатора. Это может быть специально обученный человек из вашей организации или внешний специалист. Хороший фасилитатор стоит каждой копейки.

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

Заключение: почему Lessons Learned — не бюрократия, а конкурентное преимущество

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

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

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

Главное понимать: Lessons Learned — это не просто документ, который нужно заполнить в конце проекта. Это образ мышления, при котором каждый опыт — неважно, положительный или отрицательный — становится стимулом для развития. В Кремниевой долине есть даже компании, которые отмечают самые грандиозные провалы, превращая их в источник важных уроков для всей организации.

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

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

Освоение методологии Lessons Learned — это важный шаг на пути профессионального развития любого проектного менеджера. Чтобы углубить свои знания в управлении проектами и изучить не только этот, но и другие эффективные подходы, стоит обратить внимание на специализированные курсы. На странице лучших курсов по управлению проектами вы найдете подборку образовательных программ, которые помогут систематизировать имеющиеся знания и освоить новые инструменты в этой области. Инвестиции в профессиональное обучение обычно окупаются очень быстро — за счет предотвращения тех самых ошибок, о которых мы говорим.