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

Обозначить последствия

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

Предложить альтернативы

Если решение действительно несёт риски, важно не просто сказать «так нельзя», а предложить варианты. Например:

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

• использовать временное упрощение, но с чётко зафиксированным сроком технического долга;

• найти компромиссное техническое решение, которое даст выигрыш по времени, но не разрушит архитектуру.

Аргументировать через долгосрочные цели

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

Вести прозрачный диалог

Часто корень проблемы в том, что инженеры и бизнес говорят на разных языках. Моя роль как Engineering Manager — переводить технические ограничения на язык ценности. Если бизнес понимает, что отказ от качества сегодня может привести к падению репутации продукта или срыву важных интеграций завтра, вероятность пересмотра решения резко возрастает.

Определить точку компромисса

Если бизнес продолжает настаивать, моя задача — обозначить минимальные рамки качества, ниже которых команда опуститься не может. Это касается, например, безопасности, критической архитектуры или стабильности системы. Я готов искать компромисс в скорости или объёме фич, но не в фундаментальных принципах, без которых продукт станет неустойчивым.

Управление техническим долгом

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

Поддержка команды

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