Кто виноват если проект завален?

📊 Анализ причин провала проекта: Системный взгляд

В IT-проектах провал редко является результатом ошибки одного человека. Это почти всегда системный сбой, где вина распределяется между несколькими уровнями и участниками. Как опытный Project Manager, я рассматриваю это через призму процессов, коммуникаций и принятия решений.

🔍 Ключевые стороны ответственности

1. Project Manager (и управленческая вертикаль)

• Неверная оценка сроков, бюджета, рисков.
• Слабая коммуникация между командами, заказчиком, стейкхолдерами.
• Отсутствие контроля за критическими точками (milestones) и качеством.
• Неумение эскалировать проблемы вовремя и на правильный уровень.
• Пример плохой практики PM (что НЕ делать):

  # Метафорический "код" плохого управления
  def manage_project():
      ignore_risks()          # Игнорирование идентифицированных рисков
      micromanage_team()      # Точечный контроль вместо trust & verify
      delay_decisions()       # Постоянное откладывание решений
      hide_bad_news()         # Сокрытие проблем от стейкхолдеров
      change_scope_without_process() # Хаотичное управление изменениями
      return project_failure
  

2. Команда проекта (Developers, QA, Analysts)

• Несообщение о проблемах на ранних стадиях ("молчаливые риски").
• Недостаточная квалификация или нежелание обучаться новым технологиям проекта.
• Низкое качество работы из-за выгорания, плохой мотивации или процессов.
• Сопротивление процессам (например, отказ от code review, тестирования).

3. Заказчик / Product Owner

• Нечеткие или постоянно меняющиеся требования (scope creep).
• Нереалистичные ожидания при ограниченных ресурсах.
• Несвоевременное вовлечение в приемку и предоставление фидбэка.
• Политические решения, игнорирующие технические рекомендации команды.

4. Высшее руководство (Steering Committee)

• Недостаточное финансирование или ресурсное обеспечение.
• Некорректные стратегические приоритеты.
• Давление с целью сокращения сроков без учета реалий.
• Отсутствие поддержки в разрешении организационных конфликтов.

5. Процессы и методология

• Несоответствие методологии (Waterfall vs Agile) типу проекта.
• Отсутствие четких процессов для управления изменениями, рисками, качеством.
• Некорректно настроенные инструменты (Jira, Confluence), которые мешают, а не помогают.

🛠️ Проактивный подход: как распределить ответственность конструктивно

Вместо поиска "крайнего" я применяю процедуру пост-мортема (retrospective) без поиска виноватых, но с анализом системных причин:

1. Сбор данных: что произошло, хронология, метрики.
2. Анализ корневых причин (5 Why, диаграмма Ишикавы).
3. Формулировка уроков и конкретных action items.
4. Внедрение изменений в процессы на уровне портфеля проектов.

Пример структуры отчета о провале (фокус на решения, а не обвинения):

## Project Alpha: Анализ закрытия
### Основные причины (системные):
1.  **Риск-менеджмент**: Не эскалирован ключевой риск зависимости от внешнего вендора.
2.  **Коммуникации**: Требования менялись еженедельно без формального change request.
3.  **Ресурсы**: Два ключевых разработчика ушли в середине спринта без knowledge transfer.

### Рекомендации на будущее:
- Внедрить обязательный регулярный risk review со стейкхолдерами.
- Утвердить жесткий процесс Change Control Board для всех изменений scope.
- Создать программу кросс-обучения в команде (bus factor > 2).

🎯 Вывод: Кто действительно "виноват"?

Культура обвинений (blame culture) — главный враг организационного обучения. В современном проектном менеджменте "виновата" прежде всего система управления, которая:

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

Итоговый ответ: Если проект "завален", формальная ответственность лежит на Project Manager'е и спонсоре проекта, так как они не обеспечили успешную delivery. Однако реальные причины почти всегда распределены между несовершенством процессов, коммуникационными разрывами и коллективными решениями (или их отсутствием). Задача профессионального PM — не найти виноватого, а создать систему, где такие сбои будут предупреждаться, а не разбираться постфактум.