Какие бывают риски
Риски в проектах могут быть разного масштаба и характера, но любой из них в той или иной степени может повлиять на то, что продукт так и не выйдет в прод.
- Бизнес-риски — когда функционал работает, но в итоге не решает задачу заказчика, или рынок к моменту релиза меняется настолько, что продукт становится нерелевантным.
- Финансовые — недостаточное или сокращенное финансирование проекта (например, бюджеты уменьшают во время реализации), стоимость лицензий или облачных хранилищ растет, бюджет необходимо пересчитывать от изначального.
- Внешние и геополитические — санкции, недоступность привычных сервисов и библиотек, блокировка платежных шлюзов, уход крупных вендоров с рынка.
- Риски прекращения или закрытия смежных программ — особенно параллельных проектов, которые изначально заложены в архитектуру и будущие интеграции, сюда же можно отнести возможную смену приоритетов со стороны топ-менеджмента.
- Технические — несовместимость систем, узкие места в архитектуре, перегрузка инфраструктуры.
- Процессные — нехватка ресурсов, срывы сроков на поставку данных.
- Коммуникационные — разные трактовки требований, «мискомьюникейшн», когда каждый уверен, что всё понял, но на деле все поняли по-разному.
Аналитик не может убрать все эти риски из жизни проекта, но он может их подсветить и зафиксировать. Это важнее, чем кажется: показать блокеры и объективные причины, почему проект нельзя будет реализовать в срок или почему реализация пойдет совсем не так гладко. На некоторые факторы риска (например, политические или финансовые) аналитик не может влиять в силу объективных причин, но как минимум должен быть в курсе актуальной повестки. Например, в России отсутствует полный функциональный аналог ряда профессиональных инструментов для дизайна и разработок (Figma, Autodesk, JetBrains), и аналитик этого не изменит.
А вот риски, которые аналитик не только может, но и должен выявлять:
- Бизнесовые и коммуникационные — всеми «правдами и неправдами» узнать, чего же хочет заказчик, что все друг друга поняли, чтобы реальность совпала с ожиданиями.
- Технические — здесь достаточно знать уязвимые места и держать на контроле: придумать обходные пути для MVP и обязательно записать в технический долг.
Как аналитик выявляет риски
Задает вопросы
Очень много вопросов. Причем аналитик знает, что «глупых» вопросов не бывает. Это не про то, что требования меняются в процессе, а про то, что они просто недовыявлены. Хороший аналитик всегда немного «тревожный» — он задает вопросы наперед: «А что, если?..» Так рождаются альтернативные сценарии и вскрываются корнер-кейсы.
- «А что будет, если пользователь введет неверный код трижды?»
- «А если сервис оплаты вернет таймаут?»
- «А как пользователь поймет, что его заказ сохранился?»
Каждый такой вопрос превращается в конкретный риск и в требование, которое можно формализовать.
Есть такая техника — «5 почему», о ней я писала в этой статье, в разделе об основных методиках сбора требований аналитиком. Когда бизнес говорит «Нужно ограничить доступ к этому разделу», аналитик спрашивает «А зачем?», выясняя конкретную мотивацию, получает ответ и задает контрольный «почему?». Так слой за слоем всплывают скрытые риски: например, что для интеграции понадобятся платные лицензии для всех сотрудников, а бюджета на это никто не закладывал. Конечно, аж пять «почему» излишне, иногда лишний или ненужный функционал отпадает на первых трех.
Ищет нестыковки
Аналитик сравнивает требования из разных источников: документацию, Jira, переписку, устные договоренности. На бумаге всё красиво, но в головах у разных стейкхолдеров картинка часто разная. У меня есть привычка всё записывать — хоть тезисами в блокноте, хоть кратко схемами от руки. А самый идеальный вариант — в конце созвона отправить краткое резюме по итогам встречи, своего рода протокол, мол, «Коллеги, для фиксации и чтобы держать контекст: обсудили то-то, договорились об этом, остались неразрешенные такие вопросы» — очень помогает от переобуваний 🙂
А что касается сбора самих пожеланий со стороны заказчика, аналитику важно читать требования с прицелом «что может пойти не так». Смотреть на неоднозначные формулировки, отсутствие граничных значений, отсутствие исключений. А еще искоренять и избегать «каучуковых слов».
«Резиновыми выражениями» или «резиновыми словами» называют общие, шаблонные фразы, которые теряют свою конкретность и смысловую нагрузку, поскольку их используют слишком часто в разных контекстах. «Система должна работать быстро», а что такое быстро в контексте нефункциональных требований? За сколько миллисекунд должна открываться страница? Это вам обойдется… Уточнять, конкретизировать.
Как-то раз я слушала интересный доклад на конференции, где подробно разбирали стоп-слова для аналитика. И хорошо запомнила, что необходимо конкретизировать общие выражения, избегать размытых по формулировкам слов наподобие «любой», «много/немного», «большое количество», «насколько возможно», «по мере необходимости» и тому подобное. Кстати, выражение «тому подобное» тоже лучше сразу выявлять и разворачивать. А еще «типичный» — это страшное слово, которое может воплотиться в требование, способное перевернуть суть проекта. В общем, суть в том, чтобы устранить все размытые формулировки, а для этого смотрите пункт 1 — задавать много вопросов. Ничего не должно улизнуть от пытливого ума аналитика.
Рисует
Диаграммы, схемы и прототипы — это артефакты не «для красоты», а полноценный инструмент выявления рисков. Визуализация позволяет увидеть дыры или зависимости. В BPMN и Sequence-диаграмме сразу видно, где процессы упираются в одно узкое место. В прототипах UX-сценариев хорошо проявляются слабые места — например, что будет, если пользователь уйдет со страницы и вернется?
Ведет реестр рисков и определяет важность
Фиксирует, классифицирует и держит под контролем. Чтобы не «подумал и забыл», а можно было вернуться и обсудить всей командой. Иногда риск можно сразу отложить в техдолг, но важно, чтобы он был записан.
Хорошая практика — продумать обходной план. Пусть он более дорогой или менее удобный, но он послужит подстраховкой. Пример: если внешний API недоступен, можно запросить данные через несколько вспомогательных эндпойнтов. Да, дольше, но зато пользователь не остается без результата.
Что касается приоритизации: не каждый риск нужно решать прямо сейчас, иногда есть бэклог поважнее. Но важно понимать, где критичный блокер, а где мелочь, которую можно потянуть.
Кейсы из практики
Риск скрытой интеграции
Это классическая история: бизнес-заказчик приходит с запросом: «Нужно сделать поиск по базе клиентов». На первый взгляд всё просто: у нас есть таблица в БД, прикручиваем фильтр, делов на полспринта.
Закрался только вопрос: а все ли клиенты точно в одной базе? В итоге оказалось, что половина данных хранится во внешней системе лояльности. Еще одна база — это новые интеграции, отдельные сценарии ошибок, ретраи. Если бы это всплыло уже в момент разработки, сроки бы увеличились в два раза.
Риск лицензирования
В проекте по созданию корпоративного портала хотели сделать расширенный отчет. Оказалось, что нужный функционал доступен только в Enterprise-лицензии BI-сервиса, а это большая статья расходов ежегодно, в бюджете этих денег не было. На MVP договорились убрать часть хотелок и раздать отчет только менеджерам в админку, а Enterprise вынесли в следующий бюджетный цикл.
Риск перегрузки системы
Заказчик загорелся идеей «показывать пользователю, сколько человек прямо сейчас смотрят тот же товар» — создаем чувство ажиотажа, дефицита, подталкиваем к покупке. На первый взгляд просто показываем число, но простое представление в синвенсах последовательности вызовов показало, что каждый просмотр генерирует отдельный запрос в базу: при трафике в тысячи пользователей это бы превращалось в миллионы запросов. А представим ситуационные увеличения: первая же распродажа — и база падает. Посовещались с разработчиками, решили считать просмотры раз в минуту и складывать в кеш — фронт будет ходить за данными туда.
Риск юридический + безопасность
Всё, что касается сохранения сенситивных данных (номера карт, персональные данные), — это как ходить по минному полю. Аналитику не обязательно разбираться в тонкостях сертификации, законодательства о хранении персданных, но очень важно подсвечивать эти риски и получать консультацию юристов и иных узких специалистов на раннем этапе, а не когда проект будет готов.
Нарушение возможных стандартов чревато не только незапуском проекта, но и наказанием, штрафными санкциями и запретом на работу.
Вместо заключения
Аналитик не должен волшебным образом найти панацею и избавиться от всех рисков в проекте, но точно может выявить и подсветить места, где в будущем могут появиться проблемы. Его главное оружие (инструмент) — задавать вопросы, минимизировать серые пятна и фиксировать результаты, чтобы они не растворялись в размышлениях вслух.
В качестве бонуса дам примерный перечень вопросов, который поможет отыскать возможные лакуны в проекте.
Чек-лист аналитика: 10 вопросов, которые помогут найти потенциальные риски
Сбор требований и проектирование
- Какие бизнес-задачи или проблемы бизнеса нужно решить с помощью продукта? Здесь же: каких целей хотим достичь?
- Какие особенности пользователей нужно учитывать при проектировании продукта?
- Есть ли ограничения по законодательству или нормам безопасности? Мы вообще имеем право делать это? (особенно касается персданных)
Продумывание архитектуры и интеграций
- Что будет, если внешний сервис не ответит?
- Есть ли лимиты на количество записей/пользователей/операций?
- От каких внешних систем или команд мы зависим?
- Есть ли у нас обходной путь, если ключевой сценарий не сработает?
Исследование пользовательского пути
- Какие ошибки должен видеть пользователь и что он может сделать дальше?
- Что произойдет, если пользователь бросит процесс на середине и вернется позже?
- Сколько времени может занять операция и что увидит пользователь в этот момент?
Это могла бы быть заметка из цикла статей «Нужен ли в проекте аналитик», на эту тему мы рассуждали здесь. Можно с уверенностью сказать — да, нужен: именно на нем лежит ответственность по выявлению и обозначению потенциальных рисков в проекте.
