Сложно найти бизнес-аналитика, который придя на проект в сложном домене не задавался бы вопросом: с чего начать и как не растеряться на первом этапе. Ольга Михайлова, бизнес-аналитик из компании a1qa, в начале декабря на митапе сообщества analyst.by (запись встречи можно посмотреть по ссылке) поделилась своим опытом работы в сложных доменах и рассказала, что делать в такой ситуации и как потратить время погружения с максимальной пользой.

С ЧЕГО НАЧАТЬ?

Ольга открыла свой доклад пошаговым описанием того, с чего же стоит начать свою работу на новом проекте в сложном домене.

1. Изучить презентацию на старте проекта

Исходя из опыта Ольги, очень редко встречаются проекты, где на входе нет вообще никакой информации. Поэтому, придя работать на новый проект, стоит первым делом спросить у менеджера проекта или продукт оунера, есть ли у них в наличии презентация (или любой другой документ), из которой вы могли бы понять следующее:

Кто? Кто является вашим заказчиком, а также заинтересованными сторонами проекта.
Для чего? Здесь вы должны узнать цели и задачи проекта. Ольга крайне не рекомендует пропускать этот шаг, так как эта информация даст вам дальнейшее понимание бизнес-процессов. Внимательно изучите эту информацию и задумайтесь, какие проблемы заказчика вы решаете.
Как? Понимание методологии разработки. Вполне вероятно, что для сложных доменов это будет Waterfall. Будьте внимательны! Возможно, что в документах будет декларироваться одна из Agile-методологий, но когда вы начнете изучать процессы, вы поймете что это не что иное как Waterfall.

По словам Ольги, бизнес-аналитику необходима эта информация, чтобы вы могли четко понимать чего вам ожидать от проекта и куда двигаться в плане артефактов и планирования БА-работ.

2. Глоссарий

Второе, что Ольга порекомендовала делать с самого первого дня работы на проекте, — начать вести глоссарий.

Зачем это нужно?

Если вы начинаете работать в новом для себя домене, велика вероятность, что вы встретите много новых аббревиатур и понятий, которые представители заказчика употребляют на митингах, но эти аббревиатуры вам лично могут ни о чем не говорить. Как только вы услышите новый термин или аббревиатуру — уточните у заказчика, что он означает и обязательно внесите в глоссарий. Это облегчит работу как вам, так и вашей команде.

3. Узнать как можно больше о заказчике

Третий шаг — это изучение более детальной информации о вашем заказчике.

А именно:

· Направления деятельности заказчика

Эта информация поможет вам в дальнейшем понимать, какие в компании заказчика есть смежные проекты, какие есть системы, с которыми вам, возможно, придется интегрироваться.

· Оргструктура

На этом шаге вы должны узнать об оргструктуре заказчика — в дальнейшем это станет вашей потенциальной матрицей ролей.

· Последние проекты

Этот пункт Ольга вынесла как лайфхак для сложных доменов. Это даст вам возможность ознакомиться с текущей документацией на проектах заказчика и усвоить оттуда best practices.

4. Изучить домен в первом приближении

Ольга рекомендовала изучение информации по домену в следующем порядке

· Информация на сайте компании:

Обычно на сайте заказчика много полезной информации, которая поможет вам в понимании бизнеса.

· Google:

Здесь совет простой: нет информации, которую невозможно нагуглить.

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

· Youtube:

Как бы это странно ни звучало, сейчас в YouTube есть масса полезной информации. Велика вероятность, что просмотрев пятиминутный ролик, вы поймете то, что заказчик или коллеги могли вам объяснять два часа.

· Коллеги:

Этот пункт Ольга не зря оставила напоследок. В своём выступлении она неоднократно призывает крайне уважительно относиться друг к другу и к чужому времени.

Изучив домен по этому плану самостоятельно, вы сможете прийти к коллегам с более конкретными/точечными вопросами (какую технику здесь лучше применить или какой схемой лучше отрисовать бизнес-процессы).

Такое общее ознакомление с тем, куда вы идете и с чем будете работать, обычно занимает несколько дней. Ольга подчеркнула, что не стоит рассматривать погружение как отдельный этап работ бизнес-аналитика, и думать, что ваша работа начнется только после погружения. Когда мы приходим на проект и начинаем в него погружаться — это значит, работа уже началась. Все, что вы узнаете сейчас, в том или ином виде ляжет в ваши артефакты БА и требования.

ЧАСТЬ 2. KICK OFF MEETING

Вы получили приглашение на kick-off митинг с заказчиком, что делать дальше?

Стоит сразу заняться подготовкой, чтобы максимально с пользой потратить отведенное на kick-off время. Как говорит Ольга, прийти на этот митинг неподготовленным — признак непрофессионализма аналитика.

Что на kick-off meeting нужно обсудить обязательно:

1. Бизнес-процесс:

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

2. Методологии техпроекта

Что касается сложных доменов, у заказчиков почти всегда есть методологии техпроекта. Например, (по размеру это скорее всего будет почти учебник) описания критических значений датчиков или оповещений при разных состояниях системы. Ваша задача запросить их и разобраться. Если этих методологий нет, узнайте, кто занимается их разработкой.

3. Subject Matter Experts

Ольга отметила, что еще одной важной задачей на кик-офф митинге является запись имен и фамилий тех, кто отвечает за определенные части процесса, и кто является людьми, принимающими решения.

4. Обучающие материалы

Также вы можете запросить обучающие материалы для погружения в домен: видеозаписи, презентации. Этими материалами заказчики обычно с удовольствием делятся, чтобы не тратить время для очевидные (для них) вещи.

5. Reverse Engineering

Узнайте у заказчика, каким ПО они пользуются в настоящее время.

Стоит помнить, что это необязательно будет ПО в обычном понимании — это могут быть какие-то журналы учета, это может быть excel документ. Вы же будете смотреть на все это как на ПО, в котором нужно разобраться и понять, как клиент это использует.

6. Out of scope

Обязательно зафиксировать, чем НЕ занимается бизнес-аналитик на проекте. Так, например, Ольга крайне не советует пытаться лидировать в организационных изменениях или заниматься методологией техпроекта. Если внедрение новой системы или функциональности предполагает поменять орг процессы — набрать людей, уволить людей, поменять структуру организации — этим НЕ должны заниматься БА, хотя исходя из практики на них иногда пытаются это повесить

Что касается методологии, этим не стоит заниматься, потому что это сложный домен, есть риск закопаться и потом остаться виноватым.

Очень важно после митинга зафиксировать полученную информацию в мемо и подтвердить с заказчиком.

ЧАСТЬ 3. ПОГРУЖЕНИЕ

Мы посетили кик офф митинг — что делать дальше?

1. Проводим реверс-инжиниринг ПО и разбиваем на функциональные модули. Это поможет в первом приближении понять необходимую функциональность и составить список вопросов для интервью.

Для этой задачи вам может понадобится от одного дня до недели.

2. Назначаем дополнительные интервью с заказчиком, чтобы разобраться с деталями бизнес-процесса. Для этой задачи вам понадобятся эксперты, которых вы выделили на кик-офф митинге.

3. Изучаем документацию, которую предоставил заказчик.

По словам Ольги, это могут будут тысячи, а, возможно, и десятки тысяч страниц. Ваша задача на данном этапе — хотя бы верхнеуровнево понять, где и что описано, и куда, в случае чего, вам можно будет обратиться за более детальной информацией.

4. Ищем коллег, которые могут поделиться опытом.

Когда вы изучили всю информацию, и у вас появились более углубленные вопросы, самое время обратиться к коллегам, чтобы получить ответы на конкретные вопросы.

Часть 4. Как понять, что погружение закончено?

Ответ достаточно прост: для сложного домена, скорее всего, никогда.

Сколько бы вы ни работали, вы постоянно будете что-то изучать и сталкиваться с чем-то новым. Погружение — это часть работы на таком проекте.

Если вас спросят: “Закончили ли вы погружение?” можно ответить утвердительно, если:

1. Вы понимаете, что вам говорит заказчик

Когда вопросов: “Поясните, пожалуйста, что вы имели в виду” становится один-два за часовое интервью — можно сказать, что погружение закончено.

2. Вы понимаете бизнес-процесс, который необходимо автоматизировать

Это значит, что вы как минимум можете нарисовать схему бизнес-процесса: кто, кому, зачем, какая информация передается.

3. Вы можете пересказать информацию от заказчика команде

Именно в сложных доменах как нигде проявляется важность работы БА. Если вы можете своими словами и кратко передать команде, что вы собираетесь делать и зачем — можно сказать, что погружение закончено.

Часть 5. Погружение команды

Исходя из информации, которую вы собрали выше, ваша задача представить команде:

a) Обзор домена

b) Обзор компании

c) Обзор бизнес-процесса

d) Матрицу ролей на проекте

Подготовьте презентацию с этой информацией и убедитесь, что подробная документация есть в общем доступе.

Часть 6. Планирование БА работ в сложном домене

Планирование БА работ критически важно для сложного домена. Чем тщательнее вы спланируете свои работы, тем проще вам будет работать.

1. Займитесь составлением отдельной дорожной карты для БА

Она пригодится, чтобы понимать с какой скоростью вы движетесь, где нужно ускориться, а чему можно уделить больше времени.

Ольга порекомендовала обязательно заложить цикличность процесса вашей работы в дорожную карту. Что имеется в виду под цикличностью? Сначала бизнес-аналитик проводит интервью, потом идет на обработку и возвращается для уточнения. В сложном домене вряд ли возникнет такая ситуация, когда уточнение не понадобится, обязательно учитывайте это при планировании.

2. Составьте и держите актуальным список экспертов доменной области

3. Уточните у заказчика и зафиксируйте список необходимых артефактов

4. Подготовьте предварительный список функциональных модулей системы

Часть 7. Проведение интервью

Ольга поделилась лайфхаками по поводу проведения интервью:

1. Подготовка

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

Что вам понадобится?

Очень полезная техника, которой Ольга поделилась, это матрица проведения интервью

Как это делать?

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

Это очень важно для того, чтобы четко видеть, что по процессу X, например, я не поговорил ни с кем, а процесс N у меня упущен из внимания, потому что нету эксперта, который за него отвечает.

Таким образом, вы также можете себя перепроверить. Возможно, вы вовлекаете в интервью и описание процессов одного и того же эксперта, а с остальными пока не общались.

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

10 верхнеуровневых вопросов вам будет легко удержать в памяти. В запасе стоит иметь еще 10 дополнительных вопросов на случай, если по какой-то причине вы не сможете обсудить первые 10 (необходимо отправить уточняющий запрос, привлечь другого эксперта и т.д.).

2. Проведение

Ольга дала несколько ценных советов о том, как проводить интервью:

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

Фокусируйтесь на вопросе “Зачем?”. Всегда, когда вам что-то рассказывают, держите в голове, понимаете ли вы, зачем это делается, или нет. Если нет, значит вы упустили какую-то важную информацию по поводу вашего процесса.
Обязательно ведите запись для того, чтобы потом не переспрашивать и иметь возможность передать эти знания команде. Возможно, в последующем это видео ляжет в ваш архив для передачи знаний и пригодится еще не одному бизнес-аналитику.

3. Обработка полученной информации

Для того, чтобы качественно обработать полученную информацию, пригодятся следующие советы:

Максимальная визуализация

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

Поиск подтверждающих материалов

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

Часть 8. Инструменты для обработки интервью

Это те инструменты, которые помогут при сборе первичной информации, помогут донести эту информацию до команды, и потом эту информацию можно детализировать на конкретные требования:

EPC
SIPOC
Use Case Diagram

Хорошая новость — ничего сложнее этих инструментов на первом этапе вам не потребуется.

EPC

С помощью EPC диаграммы мы отрисовываем сам процесс.

Здесь есть все, что нужно для его описания:

Начало и конец
Шаги
Участники
ПО
Данные
Границы решения

Схема простая, но для понимания бизнес-процесса она работает очень хорошо.

Важное замечание — ограничений на количество шагов в процессе нет, но с точки зрения Ольги, если у вас получается больше 15 шагов, то стоит сделать схему более верхнеуровневой. Такая схема будет более полезной для понимания.

SIPOC Diagram

С помощью SIPOC мы пошагово можем описать поставщиков, информацию, системы, потребителей и этапы/шаги.

Классическая SIPOC диаграмма состоит из следующих элементов:

Suppliers
Inputs
Process
Outputs
Customers

Ольга порекомендовала использовать SIPOC-диаграмму в связке с EPC-схемой.

Это отличный дабл-чек описания процесса: это помогает вам понять, что вы не описали и какой информации не хватает.

Use Case Diagram

По словам Ольги, процесс работы над Use Case диаграммой выглядит следующим образом:

Шаг 1 Из данных, полученных после реверс инжиниринга, создаете и визуализируете список юз кейсов.

Шаг 2 После интервью с экспертами из этой начальной визуализации получается более детализированное feature tree. На данном этапе формируется более цельная картина.

Шаг 3 Затем Ольга предлагает составить небольшую верхнеуровневую схему, где будут описаны функциональные модули системы. Даже для большого бизнеса будет достаточно 5-10 модулей. Для вас как БА — эти модули — это главы, на которые вы впоследствии будете разбивать требования.

И, наконец, про требования!

Вне зависимости от методологии разработки требования к системе должны содержать:

1. Термины и определения — ваш глоссарий.

2. Бизнес-процессы (EPC + SIPOC) — бизнес-процессы обязательно должны быть где-то описаны и задокументированы, чтобы ваша команда понимала, что вы разрабатываете и как это должно работать.

3. Функциональные модули (на основе Use Case diagram)

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

4. Матрицу ролей

Это таблица, где в строках прописаны бзнес-роли, а в колонках системные роли.

Подведем итоги!

Успех в сложном домене складывается из следующих составляющих:

1. Самообразование в домене
Ольга отметила, что не стоит надеяться, что вы сможете выплыть только за счет своих знаний в бизнес-анализе — с бизнесом придется разговаривать языком бизнеса, поэтому с самого начала нужно хотя бы минимальное понимание домена.

2. Максимальная визуализация информации
Это ваши схемы, диаграммы, таблицы. Если хотите, чтобы ваша работа была продуктивной, постарайтесь максимально визуализировать, никто не любит заниматься чтением лонгридов на 100 страниц.

3. Трансфер знаний в команде
Ольга советует всегда держать в уме: то, что вы узнали и задокументировали, вам нужно будет донести до каждого члена вашей команды. Если вы можете пересказать полученную информацию своими словами, значит вы ей владеете, и она для вас доступна. Также она доступна для вашей команды, а это самое ценное в вашей работе.

Вопросы и ответы

Лекция завершилась Q&A сессией, на которой Ольга ответила на вопросы, которые интересовали зрителей. Вот некоторые из них:

Вопрос: На проекте скоро должна стартовать фаза дискавери, заказчик поделился набором документов и видео для изучения и попросил подготовить верхнеуровневые документы.

Возможно мы не так поняли домен или неправильно поняли то, чего заказчик хотел. Насколько это критично, если бизнес-аналитик на кик-офф митинге представит заказчику документацию исходя из неверного понимания предоставленной информации или домена в целом?

Ответ: Это отличный кейс, спасибо за вопрос. Вы можете сказать: “На основании вашей информации, я составил такую схему, такой майнд мэп. Не надо бояться ошибиться на этом этапе, с девяносто процентной вероятностью — вы поняли что-то не так, и вас с удовольствием поправят. И это не будет говорить о том, что вы плохой специалист, или что команда плохо поработала, просто могут быть какие-то нюансы, которые вам непонятны именно в силу сложности домена.

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

Вопрос: Как повлиять на заказчика, если он на запрос какой-то информации отвечает, что это не касается бизнес-аналитика или работы на проекте в целом, поэтому лучше делать то о чем он просит? Как правильно объяснить заказчику что это ценная информация, которая впоследствии пригодится бизнес-аналитику?

Ответ: Если вы на сто процентов уверены, что эта информация вам действительно пригодится, тогда лучше нарисовать схему или написать требование и поставить знак вопроса рядом, и с этим прийти к заказчику. Покажите, зачем вам эта информация и что вы с ней потом будете делать — поверьте, в таком случае информацией делятся гораздо охотнее.

Автор статьи: Виктория Алешко

Сложный домен. Применяем простые техники