Собственники, заказчики, менеджеры среднего звена разумеется любят, когда классная идея реализуется в максимально короткие сроки. Задача аналитика в компании не потакать желанию, а объяснить, почему любые изменения в процессе должны пройти цикл разработки.

Возьмем простую задачку из моей практики: Причины отказа “отказ от общения” и “сброс” выглядят одинаково. Давайте объединим и напишем “отказ от общения/сброс”. Сделайте сегодня.

Если заняться задачей сразу: 1. Вы поменяете причину отказа и теперь, внутри CRM будет агрегированное поле; 2. Триггер, который реагировал на причины отказа, перестанет отрабатывать и часть клиентов не получат, допустим, сообщения в мессенджер; 3. Дашборд с аналитикой начнет показывать неверные цифры; 4. В чат поддержки, от продавцов, полетят вопросы “а он сбросил, вот эту причину выбрать?”. Поверьте, этот вопрос зададут сотни раз. И вы на него ответите.

Таким образом, решив задачу быстро, вы создадите себе работу на месяц вперед и будете вынуждены тушить мелкие пожары.

Когда заказчик говорит: «Сделайте сегодня», правильный ответ, увы, не «нет». Правильный ответ: «Давайте я покажу, что получится»

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

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

Именно для этого и нужен цикл разработки. Не как бюрократическая процедура, а как инструмент для переговоров. И защиты, если честно.