💮💎👆👆🧡🌸💎🌷 Утром прилетает задача: «Нужно сделать понятный и быстрый онбординг с удалённой идентификацией, чтобы пользователь мог открыть счёт и заказать карту без похода в отделение». Проблема Сейчас у некоего банка есть анкета в приложении, отдельная анкета на сайте и офлайн‑процесс в отделении. Требования комплаенса и безопасности растут, а пользователи хотят открыть карту «за 5 минут и без лишних шагов». Часть заявок зависает: где‑то не хватает документов, где‑то система долго ждёт ответы от внешних проверок. Как проходит день системного аналитика в таком кейсе 1. Встреча с бизнесом и другими заинтересованными сторонами (комплаенсом и безопасностью) На первой встрече собираем разный взгляд на одну и ту же проблему: - бизнес хочет короткий и понятный путь в приложении; - комплаенс следит за соблюдением требований KYC/AML и регулятора; - безопасность отвечает за риск мошенничества и подставных лиц. Формулируем общую цель: единый онбординг, который укладывается в требования регулятора, при этом остаётся удобным для клиента. 2. Обсуждение архитектуры и интеграций с разработкой и смежными командами Следующий шаг — встреча с разработчиками и ответственными за интеграции с внешними сервисами (проверка паспорта, бюро кредитных историй, проверки по чёрным спискам). Выясняется, что: - мобильное приложение и веб используют разные API для подачи заявки; - статусы заявок хранятся в нескольких системах, из‑за чего поддержка не всегда видит общую картину. Задача аналитика — собрать сквозной путь заявки: от первого экрана анкеты до выпуска карты, с указанием всех точек принятия решения. 3. Проработка решения и план внедрения На рабочей встрече с заинтересованными командами аналитик договаривается: - объединить анкеты в один набор данных - создать единый сервис с API для подачи заявки; - добавить в приложение экран «Статус заявки», где клиент видит, что сейчас происходит: «документы проверяются», «ожидаем фото паспорта» и т.п. - «раскатить» функциональность сначала только на часть реальных пользователей, чтобы отследить возможные недочеты в процессе и зафиксировать метрики. 4. Формулирование требований к процессу Сначала аналитик описывает сценарии: - «Как новый клиент я хочу заполнить данные один раз и видеть понятные шаги до выпуска карты». - «Как сотрудник поддержки я хочу видеть текущий статус заявки и причину задержки, чтобы корректно ответить клиенту». Дальше раскладывает это на более детальные требования: - единый процесс онбординга для мобильного приложения и веба, с общей моделью статусов (черновик, на проверке, требуются документы, одобрено, отказано); - отдельный сервис статусов заявки, чтобы любой канал бэкофиса банка мог получить актуальную информацию; - понятные правила: на каком шаге какие проверки выполняются, и в каких случаях можно попросить у клиента дополнительные документы прямо в приложении. Затем аналитик прорабатывает технические детали: форматы и состав данных, схемы таблиц в БД и архитектуру решения, описывает интеграции и иные требования. Если вам интересны такие задачи и вы хотите узнать, как проходить полный путь от сбора требований до подготовки технического решения и научиться говорить на одном языке и с бизнесом и с разработкой, то в начале марта будет открыт набор на очередной поток моего лайв-обучения «Системный аналитик с 0 до Middle”. Никаких предзаписанных уроков, только онлайн-занятия, выполнение домашних заданий с проверкой, итоговый кейс, адаптированный под бэкграунд-чек и поддержка при трудоустройстве. Все интересующие вопросы можно смело задавать мне в личные сообщения @matteroftrust Самостоятельное же погружение в профессию можно начинать с моего бесплатного и популярного на Хабре гайда из 5 частей по профессии системного аналитика.