×Закрыть

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, и там целый поток был посвящен бизнес-анализу.

Выводы

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

LinkedIn

11 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

"

У нас затруднен доступ к фидбэку end users, мы не занимаемся исследованием рынка

"
это означает — вы уперлись в стеклянный потолок, и без тени сомнения согласны продолжать так дальше.
А знаете ведь — отсюда и переделка фичи 15 раз. Это в книге 99го года написано.

эффект от работы бизнес-аналитика неочевиден

потому и не очевиден, что вы с продуктом по большому счету не работаете. Вы работаете с документацией...

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

редко встречал именно тим лидов аналитиков, а точнее — никогда не встречал что бы аналитики были выделены в отдельный отдел и покрывали все проекты со своим тим лидом во главе (такой себе CIO отдел), в бизнесе да, а вот в айти отделе обычно все раскиданы по функциональным подразделениям, отвечаешь за систему — к этой команде и приписан)

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

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

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

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

Для команды в 13 специалистов, занятых на разных подпроектах, «нужно общаться» — это уже не решение :) Формальных процессов обмена знаниями, согласования функциональности, актуального роадмапа у вас нет? Выделенной роли BA Lead? Все подобные активности решаются на стороне клиента?

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

Вам просто не доверяют. Вот и все.

Подписаться на комментарии