Александр Белков
SA / BA в банковской и страховой сферах
Хабр привет! Меня зовут Александр Белков, я занимаюсь внедрением и разработкой банковских и страховых систем, а также бизнес и системным анализом.
Две роли в одном лице — это не редкость. Но когда совмещаешь бизнес- и системный анализ, легко запутаться, где чья ответственность. Если не разделять задачи, начинаются недопонимание и стресс. Расскажу, как оставаться эффективным, если на вас смотрят и бизнес, и команда разработки.
Где вы сейчас: бизнес-аналитик или системный?
Чтобы понять, в какой роли вы работаете в проекте, задайте себе два вопроса.
Со сколькими системами я работаю ежедневно?
Со сколькими заказчиками или ключевыми внутренними клиентами я взаимодействую?
Ответы покажут вашу позицию.
Один заказчик + одна система — вы системный аналитик. Процессы устоялись, терминология единая, вы погружены в одну систему.
Два и более заказчиков + две и более системы — вы бизнес-аналитик. Даже близкие команды могут называть одни и те же вещи по-разному, а системы могут иметь разную архитектуру. У вас никогда не будет время на проработку деталей.
«Красные зоны» — сложные случаи:
Один заказчик + несколько систем.
Несколько заказчиков + одна система.
Если вы в «красной зоне», значит, придется совмещать обе роли. Это требует особой осторожности.
Разница в подходе: «зачем» против «как»
Суть — в точке старта и фокусе.
Критерий | Системный аналитик | Бизнес-аналитик |
Начало работы | Когда в системе что-то происходит. Пример: менеджер открыл форму создания заявки. | Когда у бизнеса появляется потребность. Пример: клиент зашел в отделение банка. |
Критерий успеха | Система отработала по сценарию. Пример: система корректно вынесла отказ по кредиту. | Бизнес достиг своей цели. Пример: клиент получил нужный продукт, компания увеличила доход. |
Основная задача, ожидания по мнению коллег (согласно BABOK) | Сбор, интерпретация требований и создание технических решений. | Выявление, анализ и управление требованиями для достижения целей проекта. |
Основной вопрос | КАК это будет работать в системе? | ЗАЧЕМ это нужно бизнесу? |
Фокус в общении | С командой разработки, тестировщиками. | С заказчиком, бизнес-пользователями. |
Бизнес-аналитик ищет ответ на вопрос «зачем», системный — на вопрос «как». Когда вы совмещаете роли, важно не смешивать эти вопросы в один поток.
Главная ловушка совмещения: вы — «единая точка контакта»
Вы общаетесь с бизнесом («зачем?») и с разработчиками («как?»). Естественно, бизнес ждет от вас ответа на вопрос «когда?».
Вот главные риски:
Конфликт интересов. Если вы начинаете обещать сроки, вы попадаете под давление. Вы можете подтолкнуть команду к не оптимальному решению, лишь бы успеть. Или потеряете авторитет, если команда вас не послушает.
Выгорание. Вы оказываетесь между молотом бизнеса и наковальней технических ограничений.
Решение: Избегайте ситуации, когда вы в одном лице отвечаете за «что/как» и за «когда». Договоритесь, что сроки озвучивает проектный менеджер или руководитель. Если это невозможно — осознайте этот конфликт как основной источник стресса и будьте готовы к нему.
Как упростить согласование требований
Типичная ошибка — один «универсальный» документ для заказчика и разработчиков. Он получается большим, его долго согласовывать, и из-за объема трудно получить от команды реалистичную оценку сроков.
Вместо этого — разделяйте документацию по этапам и аудитории.
Бизнес-требования. Документ для заказчика. Описывает, ЧТО нужно сделать и ЗАЧЕМ. Язык — бизнес-термины. Фокус на цели и процессы.
Пример: «Клиент хочет оформить страховку. Менеджер должен предложить ему несколько вариантов с разным покрытием».Системные (технические) требования. Документ для разработчиков и тестировщиков. Описывает, КАК система должна это сделать. Язык — технический. Фокус строго на поведение системы: данные, логика, результат.
Пример: «В форме создания заявки добавить выпадающий список «Тип полиса». При выборе типа автоматически рассчитывать и показывать сумму премии».Приёмочные тесты. Четкие сценарии для проверки, что система работает как надо.
Преимущества:
Каждая сторона согласовывает то, что понимает.
Ускоряется процесс согласования.
Снижается сопротивление команды разработки.
Главный риск — искажение требований при превращении бизнес-задачи в техническую. Контролировать это — ваша ответственность.
Как управлять требованиями
Один экран. Если описание задачи не умещается на одном экране без прокрутки, его будут читать невнимательн��. Выносите детали в прикрепленные файлы.
Разделяйте постановки. Бизнес-постановка (Epic, RFC) — для заказчика. Системная постановка (Task, Bug) — для тестировщиков и разработчиков.
Делите большие задачи. Если задача логически распадается на независимые части — разделите их.
Создавайте «маппинг требований». Простая таблица, где слева — формулировка для заказчика, а справа — список связанных технических задач. Так вы мгновенно ответите на вопрос о статусе.
Проверяйте полноту. Перед передачей задачи спросите себя: хватит ли этой информации разработчику или тестировщику, чтобы начать работу? Все ли ссылки есть?
Пример бизнес-постановки:
Я как страховой менеджер хочу предложить клиенту более дорогую программу страхования автомобиля КАСКО, для этого уточняю детали автомобиля. Если автомобиль иностранного производства и год изготовления менее 3х лет, то предлагаю рассмотреть вариант страхования с дополнительным пакетом страховых покрытий ЛЮКС и ЛЮКС+ если клиент категорически против, то выполняю расчет страхования СТАНДАРТ с дополнительным покрытием “сколы и царапины”. Для отечественного автомобиля возрастом менее 3х лет делаю предварительный расчет по страховой программе СТАНДАРТ с опцией “страхование имущества в салоне”. Если автомобиль иностранного производства возраста от 3х до 5 лет, то опция ЛЮКС+ не предлагается, только если клиент запрашивает отдельно. Для автомобилей иностранного производства старше 5 лет опции ЛЮКС и ЛЮКС+ не должны предлагаться. Для отечественных автомобилей старше 5 лет по умолчанию предлагается страховка с расширением страховых рисков “парковка во дворе” по льготному тарифу и предлагается дополнительный сервис “помощь на дороге”.
После получения расчета от системы менеджер сообщает клиенту расчет страховой премии по запрошенному тарифу и более дорогому с более высокой страховой стоимостью при годовой оплате. Так же менеджер сообщает клиенту о возможности заключения контракта с поквартальной оплатой.
Пример системной постановки:
Менеджер вводит страну и год выпуска автомобиля.
Система возвращает доступные программы страхования
Менеджер выбирает программу страхования
Система выполняет расчет запрошенного страхового тарифа. Возвращает расчет страховой премии:
Согласно запрошенной страховой суммы
Запрошенная страховая сумма + 50 000
Запрошенная страхования сумма + все необязательные риски.
В случае наличия признака “любимый клиент” система выполняет расчет согласно тарифу с дисконтом 10%.
Пример UAT тестов:
Описание.
Предварительные условия:
Настроенный продукт кредитной линии, где
правило активации выплаты полностью активировано;
комиссия за выплату составляет процент от суммы выплаты;
тип начисления комиссии капитализируется к основному остатку.
Вариант использования:
Клиент запрашивает 40000, тогда
сумма выплаты составляет 40 000;
комиссия за выплату составляет 2 000 (5%);
основная сумма договора составляет 42 000.
Например, на следующий день клиент запрашивает дополнительно 10 000, тогда
сумма выплаты составляет 10 000;
комиссия за выплату составляет 500;
Основной баланс составляет 42 000 + 10 000 + 500 = 52 500.
Как не делать чужую работу и обозначить границы
Команда привыкает, что вы делаете всё сами. Важно четко обозначить пределы вашей ответственности.
Говорите прямо. «Входные данные готовы, но для проработки технических деталей нужна помощь системного аналитика из команды Х».
Не создавайте «магию». Не пишите в задачах расплывчатых формулировок вроде «происходит расчет». Это введет разработчика в заблуждение. Лучше явно указать: «Требуется проработка алгоритма расчета коэффициента».
Объясняйте изменения. Если в прошлый раз вы сделали всё сами из-за срочности, предупредите команду, что в следующий раз это не повторится.
Пример, как можно показать, что требования не проработаны:
Ожидаемый сценарий
Запрос на выплату с новой суммой и условиями контракта.
Происходит волшебство.
Создается новая версия контракта с:
новым графиком;
новым лимитом;
новой суммой выплаты;
новой комиссией.
Главные правила
Диагностируйте роль. Два вопроса (системы/заказчики) помогут понять, на чем нужно сосредоточиться.
Разделяйте требования. Говорите с бизнесом на языке бизнеса, с разработчиками — на техническом. Пишите разные документы.
Не отвечайте за сроки. Ваша задача — «что» и «как». «Когда» — зона ответственности PM.
Держите фокус на нужном документе. Для каждого этапа — своя документация.
Прямо формулируйте границы. Не бойтесь просить помощи и явно указывать, чье участие требуется.
Совмещение ролей — это вызов. Но с разделением обязанностей и фокуса внутри себя вы становитесь не узким специалистом, а ключевым звеном, которое ускоряет коммуникацию и повышает шансы проекта на успех.
Больше полезного по системному анализу — в нашем ИТ-сообществе. Мы делимся экспертизой через бесплатные вебинары, организуем конференции, проводим опросы и создаем среду для профессионального общения. Подписывайтесь, чтобы быть в курсе всех событий и не упустить ничего важного. До встречи внутри!
