Как быть одновременно бизнес-аналитиком и системным аналитиком и не сгореть

Александр Белков

SA / BA в банковской и страховой сферах

Хабр привет! Меня зовут Александр Белков, я занимаюсь внедрением и разработкой банковских и страховых систем, а также бизнес и системным анализом.

Две роли в одном лице — это не редкость. Но когда совмещаешь бизнес- и системный анализ, легко запутаться, где чья ответственность. Если не разделять задачи, начинаются недопонимание и стресс. Расскажу, как оставаться эффективным, если на вас смотрят и бизнес, и команда разработки.

Где вы сейчас: бизнес-аналитик или системный?

Чтобы понять, в какой роли вы работаете в проекте, задайте себе два вопроса.

1. Со сколькими системами я работаю ежедневно?

2. Со сколькими заказчиками или ключевыми внутренними клиентами я взаимодействую?

Ответы покажут вашу позицию.

• Один заказчик + одна система — вы системный аналитик. Процессы устоялись, терминология единая, вы погружены в одну систему.

• Два и более заказчиков + две и более системы — вы бизнес-аналитик. Даже близкие команды могут называть одни и те же вещи по-разному, а системы могут иметь разную архитектуру. У вас никогда не будет время на проработку деталей.

• «Красные зоны» — сложные случаи:

  • Один заказчик + несколько систем.

  • Несколько заказчиков + одна система.

Если вы в «красной зоне», значит, придется совмещать обе роли. Это требует особой осторожности.

Разница в подходе: «зачем» против «как»

Суть — в точке старта и фокусе.

Бизнес-аналитик ищет ответ на вопрос «зачем», системный — на вопрос «как». Когда вы совмещаете роли, важно не смешивать эти вопросы в один поток.

Главная ловушка совмещения: вы — «единая точка контакта»

Вы общаетесь с бизнесом («зачем?») и с разработчиками («как?»). Естественно, бизнес ждет от вас ответа на вопрос «когда?».

Вот главные риски:

1. Конфликт интересов. Если вы начинаете обещать сроки, вы попадаете под давление. Вы можете подтолкнуть команду к не оптимальному решению, лишь бы успеть. Или потеряете авторитет, если команда вас не послушает.

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

Решение: Избегайте ситуации, когда вы в одном лице отвечаете за «что/как» и за «когда». Договоритесь, что сроки озвучивает проектный менеджер или руководитель. Если это невозможно — осознайте этот конфликт как основной источник стресса и будьте готовы к нему.

Как упростить согласование требований

Типичная ошибка — один «универсальный» документ для заказчика и разработчиков. Он получается большим, его долго согласовывать, и из-за объема трудно получить от команды реалистичную оценку сроков.

Вместо этого — разделяйте документацию по этапам и аудитории.

1. Бизнес-требования. Документ для заказчика. Описывает, ЧТО нужно сделать и ЗАЧЕМ. Язык — бизнес-термины. Фокус на цели и процессы.
   Пример: «Клиент хочет оформить страховку. Менеджер должен предложить ему несколько вариантов с разным покрытием».

2. Системные (технические) требования. Документ для разработчиков и тестировщиков. Описывает, КАК система должна это сделать. Язык — технический. Фокус строго на поведение системы: данные, логика, результат.
   Пример: «В форме создания заявки добавить выпадающий список «Тип полиса». При выборе типа автоматически рассчитывать и показывать сумму премии».

3. Приёмочные тесты. Четкие сценарии для проверки, что система работает как надо.

Преимущества:

• Каждая сторона согласовывает то, что понимает.

• Ускоряется процесс согласования.

• Снижается сопротивление команды разработки.

Главный риск — искажение требований при превращении бизнес-задачи в техническую. Контролировать это — ваша ответственность.

Как управлять требованиями

• Один экран. Если описание задачи не умещается на одном экране без прокрутки, его будут читать невнимательно. Выносите детали в прикрепленные файлы.

• Разделяйте постановки. Бизнес-постановка (Epic, RFC) — для заказчика. Системная постановка (Task, Bug) — для тестировщиков и разработчиков.

• Делите большие задачи. Если задача логически распадается на независимые части — разделите их.

• Создавайте «маппинг требований». Простая таблица, где слева — формулировка для заказчика, а справа — список связанных технических задач. Так вы мгновенно ответите на вопрос о статусе.

• Проверяйте полноту. Перед передачей задачи спросите себя: хватит ли этой информации разработчику или тестировщику, чтобы начать работу? Все ли ссылки есть?

Пример бизнес-постановки:

Я как страховой менеджер хочу предложить клиенту более дорогую программу страхования автомобиля КАСКО, для этого уточняю детали автомобиля. Если автомобиль иностранного производства и год изготовления менее 3х лет, то предлагаю рассмотреть вариант страхования с дополнительным пакетом страховых покрытий ЛЮКС и ЛЮКС+ если клиент категорически против, то выполняю расчет страхования СТАНДАРТ с дополнительным покрытием “сколы и царапины”. Для отечественного автомобиля возрастом менее 3х лет делаю предварительный расчет по страховой программе СТАНДАРТ с опцией “страхование имущества в салоне”. Если автомобиль иностранного производства возраста от 3х до 5 лет, то опция ЛЮКС+ не предлагается, только если клиент запрашивает отдельно. Для автомобилей иностранного производства старше 5 лет опции ЛЮКС и ЛЮКС+ не должны предлагаться. Для отечественных автомобилей старше 5 лет по умолчанию предлагается страховка с расширением страховых рисков “парковка во дворе” по льготному тарифу и предлагается дополнительный сервис “помощь на дороге”.

После получения расчета от системы менеджер сообщает клиенту расчет страховой премии по запрошенному тарифу и более дорогому с более высокой страховой стоимостью при годовой оплате. Так же менеджер сообщает клиенту о возможности заключения контракта с поквартальной оплатой.

Пример системной постановки:

Менеджер вводит страну и год выпуска автомобиля.

Система возвращает доступные программы страхования

Менеджер выбирает программу страхования

Система выполняет расчет запрошенного страхового тарифа. Возвращает расчет страховой премии:

• Согласно запрошенной страховой суммы

• Запрошенная страховая сумма + 50 000

• Запрошенная страхования сумма + все необязательные риски.

В случае наличия признака “любимый клиент” система выполняет расчет согласно тарифу с дисконтом 10%.

Пример UAT тестов:

Описание.

Предварительные условия:

Настроенный продукт кредитной линии, где

• правило активации выплаты полностью активировано;

• комиссия за выплату составляет процент от суммы выплаты;

• тип начисления комиссии капитализируется к основному остатку.

Вариант использования:

1. Клиент запрашивает 40000, тогда

   1. сумма выплаты составляет 40 000;

   2. комиссия за выплату составляет 2 000 (5%);

   3. основная сумма договора составляет 42 000.

2. Например, на следующий день клиент запрашивает дополнительно 10 000, тогда

   1. сумма выплаты составляет 10 000;

   2. комиссия за выплату составляет 500;

   3. Основной баланс составляет 42 000 + 10 000 + 500 = 52 500.

Как не делать чужую работу и обозначить границы

Команда привыкает, что вы делаете всё сами. Важно четко обозначить пределы вашей ответственности.

• Говорите прямо. «Входные данные готовы, но для проработки технических деталей нужна помощь системного аналитика из команды Х».

• Не создавайте «магию». Не пишите в задачах расплывчатых формулировок вроде «происходит расчет». Это введет разработчика в заблуждение. Лучше явно указать: «Требуется проработка алгоритма расчета коэффициента».

• Объясняйте изменения. Если в прошлый раз вы сделали всё сами из-за срочности, предупредите команду, что в следующий раз это не повторится.

Пример, как можно показать, что требования не проработаны:

Ожидаемый сценарий

1. Запрос на выплату с новой суммой и условиями контракта.

2. Происходит волшебство.

3. Создается новая версия контракта с:

   1. новым графиком;

   2. новым лимитом;

   3. новой суммой выплаты;

   4. новой комиссией.

Главные правила

1. Диагностируйте роль. Два вопроса (системы/заказчики) помогут понять, на чем нужно сосредоточиться.

2. Разделяйте требования. Говорите с бизнесом на языке бизнеса, с разработчиками — на техническом. Пишите разные документы.

3. Не отвечайте за сроки. Ваша задача — «что» и «как». «Когда» — зона ответственности PM.

4. Держите фокус на нужном документе. Для каждого этапа — своя документация.

5. Прямо формулируйте границы. Не бойтесь просить помощи и явно указывать, чье участие требуется.

Совмещение ролей — это вызов. Но с разделением обязанностей и фокуса внутри себя вы становитесь не узким специалистом, а ключевым звеном, которое ускоряет коммуникацию и повышает шансы проекта на успех.

Больше полезного по системному анализу — в нашем ИТ-сообществе. Мы делимся экспертизой через бесплатные вебинары, организуем конференции, проводим опросы и создаем среду для профессионального общения. Подписывайтесь, чтобы быть в курсе всех событий и не упустить ничего важного. До встречи внутри!