Иногда лучшее решение — ничего не разрабатывать.
Бизнес приходит с запросом: «Нам нужно сделать новый функционал».
Для меня это не задача. Это только начало вопросов. Первый: какую проблему мы пытаемся решить?
На практике за «сделайте новую функцию» иногда стоит обычная хотелка — без четкой цели, цифр, исследования и понимания последствий.
Поэтому для сложных изменений я использую свой подход — Системную диагностику вносимых изменений.
1. Цель Понимаем, какую проблему решаем и зачем бизнесу это изменение.
2. Процесс Смотрим не только на будущую функцию, а на весь процесс, которого она касается. Что происходит до, во время и после изменения?
3. Люди Определяем, кто инициатор, кто владелец процесса, кто принимает решение и кто сможет валидировать результат.
4. Инструменты Изучаем текущий IT-ландшафт: какие системы уже используются, как они связаны и куда нужно встроить новое изменение.
5. Ограничения Проверяем технические, организационные, законодательные и другие ограничения, которые могут повлиять на решение.
6. Риски Что может пойти не так? Как это повлияет на бизнес, клиента и существующие процессы? Готов ли бизнес принять эти последствия?
7. Рекомендации И только после этого формируем варианты решения и определяем, что действительно стоит делать.
В моей практике был случай, когда такой анализ помог отказаться от интеграции с сервисом рассрочки. Условия были невыгодны для бизнеса, а сама интеграция усложняла путь клиента и увеличивала количество касаний при оформлении заказа. То есть ценность аналитика иногда заключается не в том, чтобы быстрее довести задачу до разработки, а в том, чтобы вовремя понять, что разрабатывать ее вообще не стоит.
А вы сталкивались с задачами, которые на старте казались хорошей идеей, а после анализа оказывались совсем не такими?