Иногда лучшее решение — ничего не разрабатывать.

Бизнес приходит с запросом: «Нам нужно сделать новый функционал».

Для меня это не задача. Это только начало вопросов. Первый: какую проблему мы пытаемся решить?

На практике за «сделайте новую функцию» иногда стоит обычная хотелка — без четкой цели, цифр, исследования и понимания последствий.

Поэтому для сложных изменений я использую свой подход — Системную диагностику вносимых изменений.

1. Цель Понимаем, какую проблему решаем и зачем бизнесу это изменение.

2. Процесс Смотрим не только на будущую функцию, а на весь процесс, которого она касается. Что происходит до, во время и после изменения?

3. Люди Определяем, кто инициатор, кто владелец процесса, кто принимает решение и кто сможет валидировать результат.

4. Инструменты Изучаем текущий IT-ландшафт: какие системы уже используются, как они связаны и куда нужно встроить новое изменение.

5. Ограничения Проверяем технические, организационные, законодательные и другие ограничения, которые могут повлиять на решение.

6. Риски Что может пойти не так? Как это повлияет на бизнес, клиента и существующие процессы? Готов ли бизнес принять эти последствия?

7. Рекомендации И только после этого формируем варианты решения и определяем, что действительно стоит делать.

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

А вы сталкивались с задачами, которые на старте казались хорошей идеей, а после анализа оказывались совсем не такими?

Иногда лучшее решение — ничего не разрабатывать. | Сетка — социальная сеть от hh.ru