С чем не хочешь сталкиваться в работе

Опыт и рефлексия: что я избегаю в работе

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

1. Неопределенность в фундаментальных аспектах проекта

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

• Отсутствие четкого бизнес-обоснования (Business Case):

  Проект: "Разработаем новую фичу для мобильного приложения".
  Проблема: Нет ответов на вопросы:
  - Какую бизнес-проблему решает эта фича? (Увеличение конверсии? Снижение отток клиентов?)
  - Какие метрики успеха? (Увеличение среднего времени в приложении на 15% через 3 месяца после релиза?)
  - Какова предполагаемая ROI?
  

    Работа в таких условиях превращается в бесконечный цикл переделок и субъективных оценок "хорошо/плохо".

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

2. Культура, не поддерживающая профессиональный менеджмент

Окружение, где роль PM воспринимается как бюрократическая или ненужная.

• Компании с сильной "технической анархией". Где решения принимаются исключительно на основе "авторитета самого умного архитектора", а процессы планирования, риск.MИТ, коммуникации считаются накладными расходомМ. В такой культуре PM не может выполнить свою ключевую функцию — синхронизацию и обеспечение прозрачности.

• Отсутствие базовых процессов. Например:

  # Ситуация: Нет инструментов или соглашений для...
  - Контроля версий и CI/CD (git, Jenkins)
  - Управления задачами (Jira, Asana, даже простой трекер)
  - Регламента встреч и принятия решений
  

    Попытка внедрить даже минимальную дисциплину в таких условиях — это борьба с системой, которая истощает ресурсы и не приносит ценности проекту.

3. Конфликты интересов и нездоровые политические игры

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

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

4. Неадекватное соотношение ответственности и полномочий

Знаменитый "ответственность без полномочий".

• Проекты, где PM формально отвечает за сроки и бюджет, но не имеет права:

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

5. Фиксированные условия в условиях высокой неопределенности

Жесткие фиксированные цены (Fixed Price) или жесткие сроки (Fixed Deadline) для проектов с высокоинновационными или исследовательскими компонентами.

# Аналогия: Контракт Fixed Price для исследовательской задачи
project_spec = {
    "type": "research_and_development",
    "goal": "create_algorithm_with_95%_accuracy",
    "contract": "fixed_price_and_fixed_deadline"
}
# Результат: неизбежное снижение качества, "урезание" функционала
# или бесконечные конфликты на стадии приемки.

В таких случаях я предпочитаю гибкие модели (Agile, Time & Materials с четкими контрольными точками), где ответственность за неопределенность разделяется между клиентом и исполнителем.

6. Нежелание инвестировать в планирование и риск-менеджмент

Краткосрочное мышление: "Мы не можем тратить две недели на планирование, начинайте кодисать сейчас!". Это прямая причина:

• Неконтролируемого роста технического долга.
• Критических перерасходов бюджета на поздних стадиях.
• Выгорания команды из-за постоянных "авралов".

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