Как вы проводите анализ после завершения проекта?

Мой подход к постпроектному анализу (Post-Mortem или Retrospective)

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

Подготовительный этап: Сбор объективных данных

Перед самой встречей я обеспечиваю сбор количественных и качественных метрик, чтобы анализ строился не на эмоциях, а на фактах.

• Сбор метрик:

  # Пример метрик, которые мы готовим (в псевдокоде/списке):
  project_metrics = {
      "budget": {"planned": 500000, "actual": 487500, "variance": +2.5%},
      "timeline": {"planned_days": 90, "actual_days": 102, "variance": -13.3%},
      "scope": {"planned_features": 15, "delivered_features": 14, "change_requests": 3},
      "quality": {"critical_bugs_post_release": 2, "customer_satisfaction_score": 4.2/5},
      "team_health": {"overtime_hours": 120, "voluntary_attrition_post_project": 0}
  }
  

• Анкетирование участников: Рассылаю анонимную форму с вопросами:

    *   Что, по вашему мнению, прошло особенно хорошо?
    *   С какими основными трудностями мы столкнулись?
    *   Что бы вы сделали иначе в следующем проекте?

• Анализ артефактов: Пересматриваю backlog, протоколы совещаний, отчеты о рисках, переписку по критическим инцидентам.

Проведение ретроспективной встречи

Сама встреча проводится в интерактивном формате (часто с использованием онлайн-досок, типа Miro или MURAL) и длится 1.5-2 часа. Я строго модерирую процесс, чтобы он оставался конструктивным.

Формат встречи:

1. Вступление и правила: Напоминаю, что цель — улучшение процессов, а не поиск виноватых. Вводим правило «мобильные телефоны на столе» (полное внимание).
2. Факты и цифры: Кратко представляю собранные метрики. Это задает объективный тон.
3. «Что прошло хорошо?» (Keep): Начинаем с позитива. Это повышает моральный дух и позволяет зафиксировать успешные практики.

    *   Пример: "Эффективная коммуникация между Dev и QA после внедрения ежедневных 15-минутных стендапов".

1. «Что можно улучшить?» (Problem): Фокусируемся на процессах, инструментах, коммуникациях, а не на личностях.

    *   Пример: "Процесс согласования макетов с заказчиком занимал в среднем 5 рабочих дней, создавая простои для frontend-разработчиков".

1. Глубинный анализ причин (Root Cause Analysis): По ключевым проблемам мы используем технику «5 почему».

   Проблема: Срыв дедлайна на этапе интеграции.
   Почему 1? → Модули от разных команд не стыковались.
   Почему 2? → Команды использовали разные версии API-контрактов.
   Почему 3? → Не было единого репозитория или строгого процесса обновления контрактов.
   Почему 4? → Ответственность за это не была четко закреплена в RACI-матрице.
   Коренная причина: Отсутствие централизованного управления контрактами API и четкой роли "владельца интеграции".
   

2. Генерация идей (Action Items): Преобразуем выводы в конкретные, измеримые, назначенные и срочные задачи по улучшению.

    *   **НЕПРАВИЛЬНО:** "Лучше коммуницировать".
    *   **ПРАВИЛЬНО:** "Внедрить использование Swagger Hub для ведения контрактов API к 01.06. Ответственный: тимлид бэкенда Иван. KPI: сокращение времени на интеграцию на 30% в следующем спринте".

Пост-обработка и архивация

После встречи я формализую результаты в Отчет о завершении проекта, который включает:

• Краткое описание проекта и достигнутых целей.
• Сводку метрик (бюджет, сроки, качество).
• Ключевые выводы (сильные стороны и области для улучшения).
• План действий (Action Plan) с владельцами и сроками.

  ## План улучшений (Next Sprint)
  | Действие | Владелец | Срок | Ожидаемый результат |
  | :--- | :--- | :--- | :--- |
  | Внедрить регламент Code Review для критических модулей | Lead Dev | 2 недели | Снижение bugs в prod на 15% |
  | Провести workshop по настройке Jira для PM | Я (PM) | 1 месяц | Унификация процессов отчетности |
  

Этот отчет рассылается команде, стейкхолдерам и архивируется в корпоративной wiki (например, Confluence) в разделе "Уроки проекта", чтобы к нему можно было обратиться при планировании аналогичных инициатив.

Ключевые принципы, которых я придерживаюсь:

• Инклюзивность: Приглашаю всех ключевых участников — разработчиков, тестировщиков, аналитиков, даже представителей заказчика, если это уместно.
• Фокус на процесс: Мы обсуждаем "что" и "как" пошло не так в процессах, а не "кто" виноват.
• Закрытие петли обратной связи: Самый важный этап — контроль выполнения плана улучшений. Я включаю эти action items в agenda следующих регулярных встреч команды, чтобы убедиться, что уроки действительно интегрируются в нашу работу.

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