Июль 05

4 важных совета для команды бизнес-аналитиков

Я работаю на enterprise-level аккаунте Dev-Pro, посвященном платформе Point of Sale для ресторанов быстрого питания и retail-бизнеса. Когда-то на проекте был один бизнес-аналитик, сейчас наc 13 на 200+ специалистов. Хочу рассказать какие выводы сделал за год работы на enterprise-level проекте, например, как мы переделывали фичу 15 раз и чему научились из этого опыта, о внедрении изменений, которые могут улучшить процессы и в вашей компании.

Как построен процесс бизнес-анализа на POS-проекте

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

Существуют разные схемы взаимодействия команды и бизнес-аналитиков. Например, некоторые больше работают с UX-командой, кто-то получает и анализирует отзывы конечных пользователей, другие коммуницируют с руководством компании-заказчика. Мы являемся частью enterprise-level проекта, где есть свои особенности.

Мы очень тесно работаем с Product Managers со стороны клиента. Все вопросы, связанные с тем, как что должно работать, — мы согласовываем с американскими коллегами, а реализацию обсуждаем с Dev Leads и QA Leads в Украине.

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

У нас затруднен доступ к фидбэку end users, мы не занимаемся исследованием рынка. Всю необходимую информацию и результаты анализа нам предоставляют Product Managers проекта — эксперты в сфере Quick-Service Restaurants, Table-Service Restaurants и Retail. Дело в том, что у нас множество типов заведений: от Table-service restaurants — обычных кафе, где можно поесть за столиком, например, skate-house, до фаст-фудов с бургерами или маленьких точек продажи мороженого. Продукт поддерживает все масштабы — от одного ларька до нескольких тысяч заведений. При таком количестве направлений лучше, если документацию создают эксперты в этой сфере.

Сфера ответственности и экспертизы

Часто можно встретить проекты, где нужен всего-то один бизнес-аналитик: это команды по 10-15 человек. Но что делать, когда аккаунт насчитывает более 200 специалистов, из них 13 — бизнес-аналитики?

У нашей системы много компонентов. Но мы не разделяемся так, что один бизнес-аналитик отвечает лишь за один тип реквестов. И нельзя сказать, что специалист разбирается во всех частях проекта сразу. В таком случае помогает открытость и коммуникация. Внутри БА-команды проекта мы часто обсуждаем различные фичи и нюансы. При работе с новым требованием стремимся вместе ответить на главный вопрос — «как это работает?». Чтобы учесть максимум сценариев взаимодействия со всеми компонентами системы, нужно расспросить детали у тех кто, с ними уже сталкивался.

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

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

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

Уроки

1. Введите груминг

Я рекомендую этот инструмент для более детальной проработки требований и сокращения времени разработки. Как живется без груминга: мы поработали над требованиями, Product Manager утвердил, команда запустила их в разработку. Затем сыпались тысячи вопросов от ребят, потому что ни мы, ни даже продакты, которые хорошо разбираются в доменной области, не можем продумать абсолютно все детали. Важно понимать, что у нас разный mindset: мы (BA, PM) размышляем, что нужно бизнесу, разработчики — как это будет интегрироваться с текущими компонентами, тестировщики продумывают все возможные негативные сценарии. Так и возникают вопросы.

Чтобы изменить эту ситуацию, мы ввели груминг: перед запуском требований в разработку мы собираем большую группу — Dev Leads, QA Leads, BA-team. Каждый задает всевозможные вопросы. Мы выясняем те моменты, которые остались без ответа, даем рекомендации и отдаем фичу в работу только тогда, когда вся команда соглашается и не остается пробелов. Груминг по одному требованию занимает от 1 до 5 митингов: иногда даже простые, на первый взгляд, требования, оказываются проблематичными и вызывают множество вопросов.

Это достаточно дорогой инструмент. Собрать 15-20 Senior-специалистов на один часовой митинг — уже немало. А если мы говорим о пяти таких встречах — счет получится большой, но это окупается. Во-первых, от разных экспертов поступают самые разные вопросы, иногда неожиданные, которые охватывают сразу несколько областей и взаимодействие с другими компонентами системы. Во-вторых, хотя документирование фичи и занимает больше времени (до пары недель), в итоге возникает меньше вопросов после начала разработки, а значит не нужно делать изменения, и мы освобождаем команду от переработок и переделок постфактум.

2. Всегда прописывайте end-to-end flow нового функционала и взаимодействие со всеми компонентами. Всегда!

Не повторяйте чужих ошибок, не отрывайте свой функционал от проекта — продумывайте взаимодействие со всеми компонентами!

Есть у нас такая фича — отдавать депозиты в банк. Заведение заработало определенное количество денег, потом приходят инкассаторы и забирают их. Требование такое мы сделали, даже его погрумили... А затем посыпались change-реквесты, которые меняли функционал. Почему? — Мы не учли большое количество факторов: с какими компонентами взаимодействует эта фича, какие аспекты затронет малейшие в ней изменения. Пришлось переделывать 15 раз.

После этого случая мы стали еще внимательнее относиться к разработке end-to-end flow. На этом этапе самое важное — искать все возможные взаимосвязи с другими компонентами. Казалось бы, фича стоит отдельно от основного приложения и выполняется другими компаниями, но она затронула множество частей системы. Мы ответственны за правильно составленные репорты, подсчет денег ресторана. Важна точность, даже мелкая ошибка недопустима. Теперь мы на ранних этапах стремимся обсудить больше неочевидных сценариев использования, точки соприкосновения компонентов, влияние новых фич на другие элементы системы.

3. Не бойтесь начать сначала

На некоторых проектах «легаси», устаревшие решения, остаются навсегда. За изменения не берутся по ряду причин — это может быть большое количество надстроек, страх, спешка, нехватка ресурсов... Но это всё отговорки. Ситуацию нужно менять! Если на проекте не было раньше бизнес-аналитика, а затем он появился — это не означает, что новый специалист должен хвататься только за новые требования. Дайте ему возможность улучшить то, что было раньше, а может, и мотивировать вас начать сначала.

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

4. Обменивайтесь знаниями активнее

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

Каждую неделю у нас есть All BA Meeting, где собираются бизнес-аналитики со всех проектов. Мы выбираем профильные темы и обсуждаем общие «болезненные» вопросы — ищем вместе их решения или делимся уже готовыми. Когда на ум ничего не приходит — разбираем Babok. Чаще — кейсы или доклады с конференций. Например, 9 июня прошла конференция PMCon, и там целый поток был посвящен бизнес-анализу.

Выводы

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