Переклад статті, опублікованої на порталі DOU.ua
Я працюю на 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. Найчастіше – кейси чи доповіді з конференцій.
Висновки
Найчастіше ефект від роботи бізнес-аналітика не є очевидним. Але завдяки саме нашій роботі на проектах стає менше проблем та переробок, зворотний зв’язок від користувачів стає кращим. Сподіваюся, що ці рекомендації допоможуть вам покращити процеси, прискорити роботу та досягти великих успіхів. У світі ще так багато функціоналу, який потрібно розібрати та задокументувати, нам потрібно допомогти ще безлічі команд. Давайте робити це ефективно!
Автор: Maksym Slaschilyn, BA в Dev.Pro
Стаття опублікована 5 липня 2018