Клиент — продуктовая IT-компания с собственной CRM-системой, в которую планировалась масштабная доработка: нужно было внедрить новый модуль для учёта подписок, синхронизировать его с биллингом и API колл-центра, а также навести порядок в связках между клиентами, тарифами и внутренними справочниками.
На старте задача казалась простой: «Нарисовать схемы и описать бизнес-процессы». Но очень быстро выяснилось, что документации по старой архитектуре не существует, требования формулируются ситуативно, а бизнес-логика построена на догадках, а не на правилах.
В команду заказчика вошёл наш системный аналитик уровня middle+. Первую неделю он провёл в интервью с внутренними пользователями: менеджерами, службой поддержки, инженерами. Вместо того чтобы просто фиксировать «как есть», он задавал неудобные вопросы: «Зачем вы так делаете?», «Что происходит, если...», «А что, если клиент в двух тарифах одновременно?». Эти «если» быстро вскрыли противоречия в логике системы.
Через 2 недели у клиента появился не только набор схем BPMN, но и:
единый глоссарий понятий, которым раньше пользовались по-разному;
предложения по переиспользованию логики существующих сервисов;
спецификация по REST-интеграции с биллингом, включая граничные кейсы;
roadmap по декомпозиции задач для команды разработки.
Клиент отдельно отметил, что аналитик «разруливал споры между бизнесом и девелоперами, потому что понимал и тех, и других». Ему не нужно было объяснять, что такое idempotency или как работает очередность webhook-запросов — он сам это закладывал в логику.
Проект продолжается, но уже на этапе подготовки стало понятно: без этого уровня системного мышления заказчик бы погряз в хаосе фичей. Вместо этого — структурированная архитектура и точное понимание, куда двигается продукт.