Как не похоронить проект: вредные привычки ИТ-менеджера и пути их преодоления

Как не похоронить проект: вредные привычки ИТ-менеджера и пути их преодоления

В сентябре в Оренбурге прошла одна из ведущих ИТ-конференций Merge 2025 + IT Fest Oren, собравшая специалистов из диджитал компаний со всей России. Наш проектный менеджер Александр Гушев выступил с докладом на секции «Управление проектами», его тема «Вредные привычки проектного менеджера» оказалась близкой многим: вместо теоретических рекомендаций Александр предложил рассмотреть типичные управленческие ошибки, с которыми сталкиваются менеджеры в работе, особенно в условиях неопределенности и нехватки времени.

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

«Очень часто проекты стартуют в условиях высокой неопределенности: заказчику “нужно еще вчера”, документация отсутствует, требования размыты, а ожидания — завышены. В такие моменты особенно легко пойти по пути наименьшего сопротивления и отказаться от формальностей. Мой доклад — это сборник таких решений, которые выглядят “удобными” в моменте, но почти всегда приводят к провалу»,— отметил Александр.

1. Игнорирование формальностей на старте проекта

Вредная практика: начать работу до подписания договора или согласования условий. Часто заказчик настаивает на немедленном старте и обещает «закрыть формальности позже».

Почему это опасно: риск юридической и финансовой неопределенности. Без документального подтверждения договоренностей может быть невозможно доказать объем работ, стоимость или даже факт сотрудничества.

Что делать:

  • Не приступать к разработке без минимального набора документов: договора, спецификации, утвержденного техзадания
  • Если работа действительно срочная, стоит зафиксировать обязательства в письме, согласованном с юристами или руководством
  • Всегда согласовывайте начало проекта внутри компании

2. Отсутствие полноценного онбординга и информации о проекте

Вредная практика: запуск новых сотрудников в проект без введения в контекст: без предоставления доступов, без представления команды, без понятных ожиданий.

К чему приводит: низкая эффективность, рост ошибок, потеря времени и ухудшение коммуникации в команде.

Рекомендации:

  • У каждого участника должен быть четкий онбординг: цели проекта, зоны ответственности, ключевые контакты
  • Запуск проекта невозможен без базовой организационной структуры. Инвестируйте 1–2 дня в правильный старт, это поможет сэкономить недели исправлений

3. Отказ от детализации содержания проекта

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

Проблема: формулировки типа «качество на высоте, бесплатно и в срок» нереальны. Отсутствие согласованного объема работ приводит к росту требований и конфликтам.

Правильный подход:

  • Подписывать четкие условия: объем, сроки, бюджет, критерии приемки
  • Не начинать работу без понимания целей проекта. Менеджер — это не просто координатор, а проводник между задачами и бизнес-результатами

4. Микроменеджмент и запрет на обратную связь

Вредная практика: тотальный контроль за временем команды, навязчивый трекинг задач и подавление инициативы.

Риски: выгорание, снижение вовлеченности, утрата доверия в команде.

Эффективная альтернатива:

  • Контролируйте не время, а результат
  • Стимулируйте вопросы «зачем мы это делаем?», осознанность команды напрямую влияет на качество реализации
  • Делегируйте ответственность и оставляйте команде пространство для принятия решений

5. Избегание эскалации проблем

Вредная практика: откладывание сложных вопросов и надежда, что они «рассосутся сами».

Реальность: промедление с эскалацией приводит к накоплению рисков, затягиванию сроков и потере контроля над проектом.

Совет:

  • Эскалация — это не признание слабости, а инструмент управления
  • Если обозначить проблему вовремя, повысятся шансы на ее решение
  • Обязательно фиксируйте моменты, требующие привлечения внимания руководства или заказчика

6. Сокращение проектной цепочки: минус аналитики, QA и тестовые среды

Вредная практика: передавать правки напрямую разработчику, выкладывать на продакшн без QA.

Что может пойти не так: все. От ошибок в логике до критичных багов на проде.

Что делать:

  • Используйте все этапы проекта: аналитика, разработка, QA, ревью
  • Даже под давлением сроков не отказывайтесь от тестовых окружений
  • Пренебрежение процессами почти всегда обходится дороже сэкономленного времени

7. Ограничение информации между участниками проекта

Вредная практика: пересылать задачи без объяснения контекста. Не разбираться в сути, а просто быть передатчиком между заказчиком и командой.

Чем это опасно: недопонимание, ошибки, повторная работа, разочарование обеих сторон.

Антидот:

  • Менеджер должен разбираться в сути задач и объяснять их команде
  • Обеспечьте единое понимание целей, требований и приоритетов
  • Повышение прозрачности внутри команды снижает количество ошибок

8. Отказ от ведения проектной документации

Вредная практика: не вести документацию, не фиксировать изменения, не обновлять финансовые показатели.

Последствия: отсутствие контекста, невозможность оценить эффективность, проблемы при переходе проекта или аудите.

Что важно:

  • Поддерживайте описание проекта в Confluence, карточки в Bitrix24 или другом инструменте
  • Включайте в отчетность: цели, изменения, команду, метрики
  • Документация - это не бюрократия, а управленческий инструмент

9. Игнорирование риск-менеджмента

Вредная практика: отсутствие анализа рисков и планов реагирования. Движение вслепую, без подготовки к отклонениям.

К чему приводит: срыв сроков, перерасход бюджета, обострение конфликтов.

Решение:

  • Составьте реестр рисков в начале проекта: вероятность, последствия, стратегия
  • Пересматривайте риски регулярно
  • План B должен быть не только в голове, но и в документах

Зрелое управление — это осознанный выбор

«ИТ-проекты - это огромный потенциал роста для бизнеса. Управлять проектом означает создавать условия, в которых команда может работать предсказуемо и эффективно. Все начинается с отказа от вредных привычек, даже если они кажутся удобными», - подытожил Александр Гушев.

Начать дискуссию