В дата-департаменте банка многое держится на точности требований и понятных интеграциях. Тут нельзя «договориться на словах» — нужны схемы, спецификации и единые форматы обмена. Иначе процессы ломаются, очереди на доработки растут, а тестирование превращается в угадайку.
Компания iStaff-it предоставила выделенного аналитика «в аренду», по договору аутстаффинга. Эксперт подключился к задачам внутреннего ПО в контуре управления данными. Он фиксировал требования, проектировал решения, готовил документацию и сопровождал тестирование. Общий объем работ составил 467 часов.
Что нужно было сделать в банковском контуре данных
Команда развивала внутренние сервисы и интеграции. Много стыков: пользователи, разработка, тестирование, смежные системы. Аналитика подключили, чтобы собрать ожидания, снять разночтения и разложить работу на артефакты, от постановок до критериев приемки.
С самого начала эксперт выстроил прозрачный контур работы: фиксация решений, единый бэклог и регулярные синхронизации. Документацию и материалы специалист вел в Confluence, задачи и согласования — в Jira. Работали итеративно, в Scrum/Kanban.
Ключевые опоры процесса:
- единая база требований и решений в Confluence;
- бэклог задач, статусы и согласования в Jira;
- короткие циклы уточнения требований по мере разработки.
Использованные технологии и практики: SQL, UML, BPMN, REST API, SOAP, JSON/XML, Scrum, Kanban, JIRA, Confluence.
Требования без двойных трактовок
Ключевая задача аналитика — собрать требования к продукту и описать их так, чтобы разработчики и тестировщики понимали одно и то же. В банковском контуре это особенно важно, ведь тут много ролей, много согласующих и высока цена ошибки.
В работе аналитик закрывал полный цикл требований, от сбора до поддержания их актуальности по мере изменений. Отдельное внимание уделялось формулировкам, функционалу и критериям приемки. Это помогало сокращать возвраты на уточнение и ускоряло подготовку к тестированию.
Что делал наш системный IT-архитектор:
- собирал требования от пользователей и владельцев процессов;
- анализировал входные данные и уточнял противоречия;
- документировал функциональные требования к ПО;
- формулировал критерии приемки и ограничения;
- согласовывал изменения и фиксировал решения в базе знаний.
После фиксации требований аналитик связывал их с задачами в бэклоге. Так, команда видела, что именно должно быть реализовано в спринте и как это будет приниматься.
Проектирование решений и описание интеграций
Внутренние дата-сервисы редко живут в вакууме. Они постоянно меняются данными с другими системами. Поэтому часть работы — создание решений: как именно происходит взаимодействие, какие методы вызываются, что передается в запросах, где возможны ошибки.
Аналитик iStaff-it проектировал решения на уровне спецификаций и диаграмм. Для процессов применялись BPMN-схемы, для структуры и взаимодействий — UML. Для интеграций описывались контракты: REST API и SOAP, форматы JSON, правила валидации и обработки ошибок.
В рамках проработки техрешений архитектор IT-решений:
- декомпозировал требования на компоненты и сценарии;
- описывал пользовательские и системные сценарии;
- оформлял диаграммы процессов и взаимодействий (BPMN/UML);
- готовил спецификации по API-интеграциям (REST/SOAP);
- фиксировал форматы и поля обмена (JSON/XML);
- уточнял источники данных и проверял логику выборок через SQL.
Перед списком артефактов всегда важно пояснить: задача аналитика — не «написать документ ради документа». Цель — дать разработке и тестированию точную опору, чтобы изменения можно было реализовать и проверить без лишних кругов согласований.
Артефакты, которые готовил ИТ-инженер:
- описание бизнес-контекста и терминов (единый словарь);
- функциональные требования и постановки на доработки;
- BPMN-диаграммы процессов и ролей;
- UML-диаграммы для компонентов и взаимодействий;
- спецификации интеграций (REST/SOAP);
- описание форматов сообщений (JSON/XML) и правил валидации;
- критерии приемки и чек-листы для проверки.
После подготовки артефактов аналитик iStaff-it поддерживал их актуальность. Если менялась логика или формат обмена, изменения отражались в документации и в задачах, чтобы команда не работала по устаревшей версии.
Передача в тестирование и проверка результата
Чтобы тестирование шло быстро, аналитик готовил материалы так, чтобы их можно было использовать как основу для тест-кейсов. С понятными сценариями, входными данными, ожидаемыми результатами и условиями ошибок. Дальше — сопровождение передачи и контроль, что команда проверяет именно то, что было согласовано.
Отдельным блоком шла проверка реализованного функционала на соответствие требованиям. Это не «второе тестирование», а аналитическая валидация, представляющая собой сверку с постановками, выявлением расхождений и фиксацией корректировок.
Что входило в эту часть работ:
- подготовка пакетов материалов для тестирования и ответы на вопросы QA;
- уточнение сценариев и пограничных случаев по ходу проведения тестов;
- участие в разборе дефектов и спорных трактовок, возникающих по ходу реализации;
- проверка реализованного функционала по требованиям и критериям приемки;
- фиксация правок в документации и бэклоге, если вдруг менялась логика.
Важно, что эта работа снимает «серую зону» между аналитикой и разработкой. Команде проще закрывать задачи, а качество требований растет от итерации к итерации.
Итоги
За 467 часов выделенный бизнес-аналитик усилил команду дата-департамента банка на ключевых процессах: от сбора требований и проектирования решений до документации и сопровождения тестирования. В результате у команды были четкие спецификации, описанные интеграции и ясные критерии приемки — без лишних трактовок и возвратов.
Если вам нужен аналитик под банковский контур, интеграции REST/SOAP и работу с требованиями в Jira/Confluence, обращайтесь в iStaff-it. Мы подберем выделенного специалиста на аутстаффинге под ваши контуры, стеки и процессы.
