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

Почему возникло сопротивление

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

Анализ последствий упрощенного решения

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

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

Взаимодействие с технической командой

С техническим лидом и командой я провел отдельную встречу. Вместо того чтобы убеждать их в необходимости работы «во что бы то ни стало», мы вместе посмотрели на архитектурную диаграмму и определили зоны риска. Команда предложила компромисс: переработка ядра возможна, если мы разобьем изменения на два инкремента и уберем низкоприоритетные функции, не влияющие на основную ценность. Это позволило снизить объем первого релиза и уменьшить нагрузку на разработчиков.

Я учел их предложения и обновил требования, сохранив ключевую бизнес-логику, но адаптировав масштаб изменений.

Представление требований руководству

Когда я вышел с обновленными требованиями к руководству, я опирался на:

1. анализ бизнес-эффекта;
2. оценку технических рисков;
3. разбивку реализации на этапы;
4. дорожную карту, в которой был сохранен срок демонстрации пилотной версии.

Руководство увидело, что подход не только решает проблему, но и снижает риски. Аргументы были не эмоциональными, а основанными на данных: прогноз стоимости поддержки, влияние на NPS, оценка трудозатрат и прозрачная стратегия внедрения.

Результат и выводы

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

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