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

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

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

Решения обсуждали с бизнесом, владельцами систем, архитекторами, разработчиками и юристами. Нужно было учесть и требования финансового регулирования.

Во время обсуждений я выяснила, что одна из страховых компаний группы уже использует собственный продукт. Часть обменов, которые мы планировали для неё, оказалась не нужна.

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

В результате сократили объём запланированных интеграционных работ. Стало меньше зависимостей между командами и вопросов для согласования. Появилась более понятная основа для планирования.

Для меня это пример того, зачем РП разбираться в логике решения. По стрелке на схеме легко поставить задачу. Однако сначала стоит выяснить, кто ждёт эти данные и для чего.

Даже подробную архитектурную схему полезно сверять с актуальными процессами и потребностями участников. Иногда самый полезный вопрос на встрече: «А это нам точно нужно делать?»

Перед тем как включать интеграцию в план, полезно ответить на три вопроса: • Кто будет использовать данные? • Для какой задачи они нужны? • Что уже решено другими средствами?

Собрала их на карточке.