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

Я працюю на enterprise-level записі Dev-Pro, присвяченому платформі Point of Sale для ресторанів швидкого харчування та retail-бізнесу. Коли-то на проекті був один бізнес-аналітик, зараз нас 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 , і там цілий потік був присвячений бізнес-аналізу.

Висновки

Часто ефект від роботи бізнес-аналітика неочевидний. Але саме завдяки нашій роботі на проектах стає менше проблем і переробок, зворотний зв'язок від користувачів стає краще. Сподіваюся, що ці рекомендації допоможуть вам поліпшити процеси, прискорити роботу і домогтися великих успіхів. В світі ще так багато функціоналу, який потрібно розібрати і задокументувати, нам потрібно допомогти ще безлічі команд. Давайте робити це ефективно!

Опубліковано: 05/07/18 @ 07:03
Розділ Різне

SEO Блог