Всем привет, меня зовут Сергей Прощаев, Tech Lead и руководитель направления Java / Kotlin разработки в FinTech & E-commerce, и уже несколько лет преподаю на курсах разработки и архитектуры в OTUS.
За это время я провёл десятки собеседований и участвовал в найме системных и бизнес-аналитиков. И знаете, что бросается в глаза? Многие кандидаты блестяще знают BABOK, умеют рисовать BPMN и писать User Stories, но стоит спросить: «Какие риски вы видите в этом требовании?» — начинается ступор. А ведь именно невыявленные риски превращают перспективный продукт в бесконечный марафон переделок.
Сегодня разберём, как бизнес-аналитик может управлять рисками системно: что такое риск на самом деле, как его категоризировать, как оценивать влияние и как митигировать. Приведу реальный кейс из банковской практики и покажу лучшие практики команд, которые я внедрял сам. Погрузимся в проблемы и найдём наиболее эффективное решение.
Что такое риск и как бизнес-аналитик его видит
В среде разработки под риском многие понимают «что-то может пойти не так с кодом». Но для бизнес-аналитика риск — это любое событие или условие, которое может повлиять на ценность продукта для пользователя или бизнеса. И оно не обязательно техническое.
Я определяю риск как расхождение между тем, что мы думаем о продукте, и реальностью — рынка, пользователей, регуляторов, интеграций. Именно аналитик — тот человек, который должен усомниться в самых базовых предположениях ещё на старте.
Помню случай: мы проектировали личный кабинет для крупного B2B-клиента. Продакт говорил: «Всё просто, обычная регистрация и просмотр отчётов». Я задал уточняющие вопросы и выяснил, что клиент юридически обязан разделять сотрудников на роли с разным уровнем доступа к данным, иначе нарушение 152-ФЗ. Если бы мы начали пилить «обычный кабинет» без этого знания, через месяц пришлось бы всё переписывать. Вот это и есть риск, который аналитик должен выловить до написания первой строчки кода.
Категоризация рисков: не всё одинаково вредно
Чтобы не утонуть в бесконечном списке «а что, если...», я сегментирую риски по природе возникновения. Это помогает трезво оценить, где нужны действия немедленно, а где — достаточно мониторинга.
Типичные категории, с которыми я работаю:
Продуктовые риски: неверно понятая потребность, изменение приоритетов пользователей, сложный UX, блокирующий ключевой сценарий.
Технические риски: сбои интеграций, недоступность внешнего сервиса, низкая производительность под нагрузкой.
Организационные риски: потеря ключевого эксперта, зависимость от смежной команды, затянутое согласование макетов.
Регуляторные и рыночные риски: выход нового закона, изменение тарифов провайдера, неожиданный шаг конкурента.
Для визуализации часто использую mindmap, который рождается прямо на обсуждении с командой. Ниже — типовой скелет такой карты (рис. 2).
Эта mindmap — не артефакт ради галочки. Она как карта минного поля: сразу видно, где рванёт и кто отвечает за разминирование.
Главное, что она даёт — мгновенное разделение ответственности. Продуктовые риски (сложный UX, неверные требования) — это зона аналитика и продакта. Значит, не спорим, а идём к пользователям и проверяем прототип. Технические угрозы — отказ внешнего API, потеря данных — вотчина архитектора: он проектирует асинхронную очередь, фоллбек, ретраи. Организационные — задержка смежников или уход ключевого разработчика — немедленно экскалируются скрам-мастером. Регуляторные «сюрпризы» ложатся на плечи комплаенса.
Без такого разделения риски сливаются в одну пугающую массу, и команда начинает бесконечно гадать: «А насколько это вообще страшно?»
У меня был показательный случай: мы три встречи спорили, критичен ли отказ сервиса рассылок при регистрации. Стоило вынести этот риск в ветку «Технические» с конкретным владельцем — архитектором — и вопрос закрылся за полчаса. Архитектор предложил класть письма в очередь, а не отправлять синхронно. Споры умерли, задача ушла в бэклог. Вот за что я ценю такую карту: она убирает эмоции и запускает конструктив.
Влияние рисков: когда цена ошибки исчисляется миллионами
Влияние риска редко ограничивается «ой, баг». Чаще всего это каскад: непродуманный сценарий → недовольство пользователей → потеря выручки → репутационный удар. И хорошо, если вы заметите это на этапе тестирования. Хуже — когда всё ломается на проде.
Хрестоматийный пример — миграция британского банка TSB на новую платформу в 2018 году. В ходе переноса 1,9 млн клиентов потеряли доступ к счетам. Причина глубже, чем «упал сервер»: проектная команда, по отчётам, недооценила риски интеграций с legacy-системами и не проработала edge-case сценарии восстановления данных. Как итог — сотни миллионов фунтов убытков и регуляторные разбирательства. С точки зрения бизнес-анализа, здесь провалились на этапе идентификации рисков: не спросили «а что, если процесс миграции прервётся на середине?», «а как мы откатимся?», «а выдержит ли колл-центр вал обращений?».
Такие истории — не абстрактная страшилка. Я сам пару раз обжигался, когда недооценивал организационные риски. Например, в одном финтех-проекте мы запланировали интеграцию с внешним сервисом верификации документов. Команда того сервиса обещала API через две недели. Мы синхронно завязали график выкатки. По факту API пришёл через два месяца, а нам пришлось спешно перекраивать архитектуру и добавлять заглушки, сжигая бюджет. Сейчас я всегда закладываю буфер на внешние зависимости и делаю асинхронный фоллбек — урок из того самого провала.
Способы митигации: от паники к плану
Управление рисками — это не попытка всё предсказать, а создание системы, которая спокойно переваривает неожиданности. Мой подход опирается на простой цикл:
Идентификация (я + команда, методом «pre-mortem»).
Оценка вероятности и влияния (матрица risk score).
Выбор стратегии: избежать, снизить, передать или принять.
Реализация мер и закрепление в критериях приёмки.
Периодический пересмотр — например, раз в спринт.
Лучшая практика, которую я подсмотрел у сильных команд, — pre-mortem анализ. Собираемся до старта разработки и говорим: «Представьте, что проект провалился. Что именно пошло не так?». Эта техника легализует критическое мышление и вытаскивает скрытые допуски наружу. Попробуйте — вы удивитесь, сколько важных рисков всплывёт за 30 минут.
Для оценки я предпочитаю простую матрицу «Вероятность × Влияние», без сложных коэффициентов. Она помещается на один лист и понятна стейкхолдерам. А меры реагирования обязательно прошиваю в критерии приёмки (Acceptance Criteria). Например: «Если email-сервис не отвечает дольше 3 секунд, регистрация не должна падать — пользователь видит сообщение об успешной заявке, а письмо уходит в очередь».
Ниже — процесс, который я теперь включаю в план работ с любой сложной фичей (рис. 3).
Этот цикл — не абстрактная методология, а мой рабочий инструмент, который живёт в Confluence и обновляется каждые две недели вместе с командой.
Идентифицировать риски — первый и самый творческий этап. Здесь мы включаем pre-mortem: «Представьте, что наш сервис лёг в час пик. Почему это произошло?» Ответы вытаскивают на свет скрытые допущения. Например, в одном проекте именно на этом шаге выяснилось, что никто не знает, как поведёт себя API смежников под нагрузкой в 200 RPS — а мы уже рисовали архитектуру, завязанную на синхронные вызовы.
Оценить вероятность и влияние — переводим эмоции в цифры. Я использую простую матрицу: вероятность от 1 до 5, влияние от 1 до 5. Перемножаем — получаем риск-скор. Это позволяет не спорить «кажется, это критично», а договориться: всё, что выше 15, — в работу немедленно.
Приоритизировать — честно признаём, что закрыть все риски невозможно. В приоритет идут те, что угрожают ближайшему спринту или ключевой функциональности. Остальное — в бэклог аналитика с пометкой «наблюдать».
Выбрать стратегию реакции — для каждого риска определяем: избегаем (например, меняем архитектуру), снижаем (добавляем асинхронную очередь), передаём (покупаем готовый сервис вместо самописного) или принимаем (осознанно идём с этим риском, но фиксируем его).
Интегрировать меры в Acceptance Criteria и архитектуру — мой любимый этап. Меры митигации не живут в отдельном документе; они прошиваются в критерии приёмки. Например: «Если email-сервис не отвечает дольше 3 секунд, пользователь получает сообщение об успешной заявке, а письмо уходит в очередь». Это означает, что разработчик видит нефункциональное требование прямо в задаче, а тестировщик — готовый сценарий для проверки.
Мониторить и пересматривать — раз в две недели мы садимся и смотрим: какие риски сработали, какие устарели, какие новые появились. Важно: реестр не должен превращаться в кладбище из 50 пунктов. Я держу там только то, что реально влияет на ближайшие итерации. Остальное — в архив с датой пересмотра.
Этот цикл не требует отдельного ритуала. Он встроен в наши обычные встречи: груминг бэклога, планирование спринта, ретро. Именно это делает его живым артефактом, а не формальным отчётом для галочки.
Что я вынес из реальной практики и лучшие кейсы
Один из ярких примеров — как Revolut при масштабировании на новые страны использует модульную микросервисную архитектуру, которая позволяет изолировать и быстро адаптировать компоненты под локальные регуляторные требования (KYC, AML, data residency и т.д.). Вместо того чтобы каждый раз перестраивать большой монолит, они могут менять/конфигурировать отдельные модули или правила внутри них. Это классический кейс упреждающей митигации регуляторного риска через архитектурный дизайн. В такой среде бизнес-аналитик участвует не просто в написании фич, а в проектировании системы, которая остаётся гибкой при частых изменениях законодательства.
У меня самого была история с внедрением «admin-панели», ради которой я переписал подход к сбору требований. Изначально продакт прислал список из 25 возможных действий админа. Вместо того чтобы сразу всё прототипировать, я пошёл в поддержку и спросил: «Какие операции вы делаете каждый день?». Оказалось, 90% запросов — сброс пароля и разблокировка. Остальные 23 пункта были «было бы неплохо». Мы сократили скоуп почти вдвое, сэкономили два спринта разработки и избавились от риска распыления усилий. Приём простой: не стесняйтесь валидировать гипотезы на реальном пользователе до того, как пишется задание.
Вывод: аналитик — это предохранитель
Управление рисками — не отдельная дисциплина для отчёта, а способ мышления. Хороший бизнес-аналитик не тот, кто напишет больше страниц спецификации, а тот, кто задаст вовремя неудобный вопрос, проверит предположение и зашьёт страховочные механизмы в проект. Это экономит миллионы рублей, месяцы работы и нервы всей команды.
Если этот разбор показался вам полезным и вы хотите превратить навык управления рисками из интуитивного в системный, приглашаю вас на бесплатные демо-уроки курса «Системный и бизнес-анализ» в OTUS.
На них можно вместе с экспертами разобрать практические задачи, задать вопросы и понять, насколько такой формат обучения помогает закрывать пробелы.
14 мая в 18:00 — «Графическое описание бизнес-процессов и требований». Как визуализировать процессы, алгоритмы, объекты и данные, когда текстового описания уже не хватает для нормального понимания и согласования. Записаться
21 мая в 20:00 — «Формирование бизнес-модели продукта на примере Business Model Canvas». Урок о том, зачем нужна бизнес-модель продукта и как работать с Business Model Canvas на прикладном примере. Записаться
Полный список бесплатных уроков мая смотрите в дайджесте.