Статья написана в соавторстве с Антоном Бабенко, BA Lead в Binariks
Каждый IT-проект имеет свои особенности: уровень сложности, количество стейкхолдеров и их компетентность, доступность и заинтересованность клиента, сроки и бюджет. На фазе дискавери происходит концентрированное выявление требований и оценка — сможет ли компания выполнить конкретный проект в рамках бюджета. Успешно проведенный этап дискавери помогает понять цели продукта/решения, получить реалистичную оценку, план реализации плюс — продать разработку.
У каждого бизнес-аналитика есть свое представление о том, как должны выглядеть артефакты на Discovery Phase. Они могут быть разными по форме и подаче, но главное здесь — не форматы и шаблоны, а та информация, которая будет в них заложена.
Три артефакта для бизнес-аналитика
Как в сказке «Три орешка для Золушки» эти волшебные плоды приводят к happy end, так и артефакты из списка ниже помогают BA успешно обработать всю информацию, полученную на Discovery Phase:
- Business Requirements Document.
- Use Case Diagram.
- Context Diagram.
Каждый артефакт упрощает работу BA, помогая тщательно проработать основные вопросы на дискавери-фазе.
Business Requirements Document
Business Requirements Document (BRD) — документ, в который вы вносите всю информацию от клиента: от бизнес-возможностей до бизнес целей и метрик успеха. Пример структуры BRD:
- Business Problem statement
- Business objectives
- Project scope
- Main project success/cancellation criteria
- Functionals and Non-Functional requirement
- Project costs
- Stakeholder list
- Project assumptions and constraints
- Project risks
Дискавери-фаза нужна, чтобы понять, что необходимо бизнесу клиента, что предложить в качестве решения, как это реализовать. Поэтому рекомендую максимально полно заполнять BRD и не стесняться задавать вопросы заказчику.
Помните, клиент не обязательно четко понимает, что на самом деле нужно для его бизнеса, либо может акцентироваться на второстепенных моментах. Задача бизнес-аналитика на фазе дискавери — «докопаться» до сути, и уже на базе этого разработать предложение заказчику по решению его проблемы или рекомендовать IT-компании вовсе отказаться от проекта.
Use Case Diagram
Быстрый и наглядный способ обобщенно представить технические возможности будущего продукта. Благодаря Use Case Diagram легко понять:
- Кто потенциальный пользователь вашего решения.
- Какие роли, система прав и доступов нужны.
- Какие основные действия будут производить юзеры, что необходимо для этого.
В Use Case Diagram не обязательно описывать мельчайшие детали — главное охватить все ключевые use cases и роли, ведь на дискавери-фазе нужно «копать» вширь, а не в глубину. На этом этапе важнее собрать полную информацию обо всем проекте, чтобы выявить и оценить как можно больше потенциальных рисков, чем досконально изучить какую-то область.
Discovery — это как раз тот случай, когда лучше собрать 80% данных и разобраться в них на 20%, чем наоборот. Иначе можно упустить ключевых стейкхолдеров, необходимые функции и массу других вещей. В итоге важная информация не будет учтена, что вызовет ошибки в оценке проекта и дальше по цепной реакции.
Context Diagram
Контекстная диаграмма — это все ваши потенциальные интеграции и данные, которые нужно анализировать, преобразовывать, мигрировать, то есть все, что окружает проект и может повлиять на конечный результат:
- потенциальные пользователи;
- бизнес-процессы внутри компании заказчика;
- сторонние организации;
- особенности территории распространения IT-продукта;
- различные регуляции.
Контекстную диаграмму можно делать на нескольких уровнях: Business Context Diagram и System Context Diagram. В первом случае в центр диаграммы мы ставим организацию/бизнес заказчика, а по периметру — основных контрагентов. Стрелками обозначаем информацию, которой они обмениваются с «центром».
На System Context Diagram в центре будет не бизнес клиента, а система, с которой мы работаем. По периметру — другие системы, устройства, учреждения, которые так или иначе взаимодействуют или должны взаимодействовать с нашей, а на стрелках обозначаем данные/информацию, которой они обмениваются.
Вместо вывода
Каждый бизнес-аналитик может использовать разные виды и количество артефактов, и нет идеального списка для любого случая. Но именно Business Requirements Document, Use Case Diagram и Context Diagram помогают быстро и максимально четко проанализировать будущий проект, адекватно оценить все риски и в наглядной форме зафиксировать полученную информацию.
Поэтому, если бы я оказался на необитаемом острове с проектом в работе и мог выбрать только три артефакта — эти были бы фаворитами. Только сначала, попросил бы в качестве бонуса глоссарий основных терминов, которыми оперирует клиент и команда, чтобы говорить с заказчиком на «одном языке» и тем самым облегчить работу всем участникам Discovery Phase.