Проект под угрозой? Как Project Manager’у избежать фейла

Смотреть детальнее

Представьте ситуацию: вы ведете IT-проект, дедлайны согласованы, команда работает слаженно… И вдруг все «ломается». Новые требования от стейкхолдеров задерживают процесс, а технический долг угрожает производительности. Бизнес требует одно, разработчики строят другое, а пользователям нужно третье.

Знакомо? Это классическая ситуация, с которой сталкивается каждый Project Manager, особенно если у него еще нет лет отточенного опыта в IT. Однако ключевой вопрос: можно ли это предусмотреть?

Ответ — да. И не только предусмотреть, но и избежать части проблем.

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

3 кейса, когда ваш IТ-проект может быть под угрозой

Рассмотрим реальные кейсы, где проекты едва не сорвались, и практические советы, как предотвращать такие проблемы.

1. Постоянные изменения требований во время разработки

В стартапе разрабатывали мобильное приложение для доставки еды. Первоначально концепция была четкой: минимализм, быстрый заказ, удобный треккинг. Но уже через три месяца появились новые must-have фичи: чат с курьером, возможность оплаты криптовалютой, интеграция с TikTok для рекламы.

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

✅ Что делать в таком случае: создайте Change Management Board. Простое правило: каждое новое изменение проходит оценку по трем параметрам — влияние на бюджет, сроки, техническую сложность. Используйте Jira Confluence или Notion для ведения списка изменений. Кроме того, внедрите формализованный процесс оценки изменений: impact assessment + голосование команды + утверждение стейкхолдерами.

Инструменты:

• Jira Roadmap → визуализация влияния изменений на сроки
• Confluence/Notion → страница Change Requests

Дополнительный совет. При общении со стейкхолдерами используйте трюк What’s in it for you — показывайте бизнесу не только затраты, но и риски. Например: «Если добавить чат с курьером, релиз отложится на шесть недель. Готовы ли вы к потере потенциальных 15% прибыли за это время?» Такая аргументация поможет принимать обоснованные решения, а не превращать проект в бесконечный эксперимент.

2. Технический долг

В компании Х, разрабатывающей SaaS-решения, релизы выпускаются ежемесячно. Чтобы не тормозить процесс, команда жертвовала чистотой кода, создавая временные решения (без времени заменить их на длительные).

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

✅ Что делать в таком случае:

• Заложите «технический долг» в спринты. 10–15% спринта выделяйте на рефакторинг и оптимизацию кода. Если CTO/Tech Lead говорит, что долг критический — это не игнорируется.
• Работайте с долгом как с бюджетом. Внедрите систему технического долга (Tech Debt Register), где долг разбит на: критический (bloker) — останавливает работу (аварийное исправление); средний (мешает скорости) — замедляет разработку (legacy-код), низкий (не критично) — можно отложить, но лучше исправить.
• Убедите бизнес, что рефакторинг — это о деньгах. К примеру, тестовая автоматизация может сэкономить 40% времени в будущих спринтах.

Инструменты:

• Jira Technical Debt tickets
• SonarQube → анализ кода и выявление технического долга
• Sentry/NewRelic → отслеживание ошибок в продакшене

3. Несоответствие между бизнес-ожиданиями и результатом

Команда работала над CRM-системой для малого бизнеса. Когда пришло время демо-презентации для менеджмента, выяснилось, что функционал, на который они рассчитывали, не соответствует ожиданиям. Бизнес ожидал автоматическую рассылку email «как в HubSpot», а разработчики реализовали простой SMTP-сервис.

✅ Что делать в таком случае:

• Используйте прототипы и Customer Feedback на промежуточных этапах. Перед созданием новых функций используйте Figma, Miro или Whimsical для создания макетов. Важно не только согласовывать их с менеджментом, но привлекать будущих пользователей для тестирования концепции.
• Введите общий backlog с бизнесом. Внедрите Jira-доску для бизнеса и разработчиков, где менеджмент может отслеживать ход работы. Также пригодится Slack-канал или Notion-страница, где кратко объясняется статус фичи.
• Переводите с бизнес-языка на технический. Когда бизнес говорит «Сделайте e-mail рассылку, как у HubSpot», ваша обязанность — расспросить детали. То есть: сколько писем ожидается, как сегментируется база, нужно ли заложить функцию A/B-тестирования?

Инструменты:

• Figma / Miro → прототипы
• Notion / Confluence → страница «Бизнес-потребности в технических терминах»
• Jira Custom Workflows → задачи для разных уровней (бизнес → разработка)

Почему техническая экспертиза — это must-have для Project Manager в IT

Роль Project Manager давно вышла за рамки классического управления дедлайнами и коммуникациями. В IT PM без технического бэкграунда рискует:

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

Важно! Техническая осведомленность не означает, что PM должен писать код. Но базовые знания об архитектуре приложений, API, базах данных и CI/CD позволят более эффективно работать с командой и принимать обоснованные решения.

Хороший Project Manager в IT — это не просто координатор, а стратег, помогающий команде находить баланс между бизнес-требованиями и технологиями. Подходите к каждому кейсу индивидуально, но обращайте внимание на то, как вы могли бы избежать подобного в будущем.