13 типових помилок в роботі бізнес-аналітиків початківців

Окремий аспект мовного питання – професійний сленг, на який звертають увагу і роботодавці, і замовники, і члени команди. Завдання бізнес-аналітика – налагодити ефективну комунікацію, а це можливо лише якщо ви вмієте говорити однією мовою з усіма членами команди. До того ж переважна більшість професіональної літератури та тренінгів представлено саме англійською. Отже, без знання іноземної мови неможливий повноцінний професійний розвиток.

2. Сліпе слідування фреймворку. З питання ефективних комунікацій випливає ще одна доволі серйозна помилка новачків — догматичне слідування підходам обраного фреймворку. Потрібно пам’ятати, що ІТ – це галузь, яка динамічно розвивається і секрет успіху в ній полягає у здатності адаптуватися до швидких змін обставин.

Можна скільки завгодно твердити команді, що «ми працюємо за класичним Scrum/lean/Kanban», але якщо поставлені завдання та процеси їм не зрозумілі або забирають більше часу та ресурсів, ніж могли б при застосуванні підходу, відмінного від хрестоматійного, то сенсу в цьому немає. Було б непрофесійно в такому випадку сказати «це погана команда, вони неправильно слідують моєму ідеальному підходу до методології». Завдання бізнес-аналітика — вивчити різні підходи й підібрати той, який буде найбільш ефективним для конкретної команди в конкретному проекті. Зазначу, що за час своєї практики я не зустрічав жодного проекту з абсолютно «книжковими» процесами.

3. Ігнорування культури та корпоративних політик замовника. Закриваючи тему важливості ефективної комунікації для бізнес-аналітика варто згадати необхідність зважати на культуру та корпоративні політики замовника при плануванні своєї роботи.

Не дивлячись на певну очевидність цього питання і те, що воно вже багатьом набило оскому, деякі бізнес-аналітики не приділяють належної уваги культурній площині взаємовідносин із замовником. Однак, цей момент в купі з недостатнім володінням англійською мовою може призводити до ситуацій, коли клієнт сприйматиме бізнес-аналітика як «грубуватого, недостатньо ввічливого». Це негативно впливає на роботу ВА в одному з найважливіших аспектів – взаємодії зі стейкхолдерами.

Так, наприклад, краще не забувати, що представники азіатських культур не завжди можуть прямо сказати «ні», а, працюючи з американцями або канадцями, варто приділити 5 хвилин бесіді про успіхи їх місцевої спортивної команди. Про те, що часто фахівців зі східноєвропейської, слов’янської культури представники західної культури сприймають як нечемних, мені доводилося чути неодноразово (приміром, люди використовують зворот “can you” замість більш м’якого «could you» і забувають додати «please»). На одному з проектів стейкхолдер прямо запитав, за що його так ненавидить команда. Зрештою, з’ясувалося, що складність криється у відмінності культур та недостатньому рівні англійського.

Важливо розуміти, що для бізнес-аналітика подібна помилка є неприпустимою, адже від якості його спілкування із замовником залежить вірогідність з’ясувати деталі, про які клієнт з будь-якої причини прямо не згадує.

Щоб покращити навички комунікації з клієнтами:

• поповнюйте словниковий запас тонкощами й синонімами;
• вчіть conditionals;
• працюйте над вимовою;
• вивчіть правила застосування артиклів «a» і «the».

Більше практичних порад можно знайти в цій статті.

4. Ігнорування змін в домені замовника. В безпосередній проектній роботі однією з помилок може бути припинення вивчення доменної області та специфіки бізнесу клієнта. Трапляються ситуації, коли навіть досвідчені бізнес-аналітики, пропрацювавши на проекті тривалий час, не можуть відповісти на питання, як саме працює їх продукт в доволі простих сценаріях. Втрата інтересу до тенденцій і трендів у доменній області і припинення відстеження справи замовника можуть зіграти злий жарт з проектом особливо в динамічних, мінливих царинах бізнесу. Про необхідність постійно навчатися і занурюватися в бізнес клієнта згадують практично всі експерти, коли мова йде про плюси та мінуси професії бізнес-аналітика.

5. Відсутність правильного roadmap. Однією з серйозних складнощів може стати відсутність на проекті таких основних документів як vision і roadmap, заснованих на клієнтських планах продажів. Можливо, це питання важливіше для великих проектів і належить до сфери обов’язків product-менеджерів, але бізнес-аналітик в будь-якому випадку може і повинен ініціювати та фасилітувати процес створення таких документів. Якщо ВА планує розвиватися в напрямку product-менеджменту, це варто враховувати.

В якості прикладу зі свого особистого досвіду можу привести ситуацію, коли група ВА розробляла проект roadmap-у для подальшого його розгляду й затвердження product-менеджмент командою. Фахівці, зокрема, аналізували функціонал додатків потенційних конкурентів, плани продажів компанії на наступний рік, плани розвитку пов’язаних модулів, а також stories з беклогу, які з якихось причин були давно відхилені product-менеджерами. На базі всіх цих досліджень і було створено roadmap, який замовники затвердили.

6. Немає плану комунікацій і карти стейкхолдерів. Якщо заглибитись в деталі роботи бізнес-аналітика, то помилками початківців можна вважати відсутність плану комунікації та матриці стейкхолдерів. Слід привчати замовника проводити регулярні мітинги, а себе —наперед готувати перелік питань для обговорення. Часте скасування зідзвонів через відсутність тем або брак конструктиву в діалозі може призвести до того, що стейкхолдери просто не прийдуть на здавалося заздалегідь запланований мітинг у найвідповідальніший час. У ключовий момент він може не бути для них достатньо важливим і терміновим.

У плануванні спілкування важливо враховувати не лише суть питання, але й те, як воно сформульоване. Часто буває, що від того, як поставлене питання залежить і відповідь клієнта. Це вкрай важливо, коли бізнес-аналітику, як представнику команди виконавця, потрібно відстояти рішення інженерної команди, зокрема при проведенні user acceptance testing і здачі робіт замовнику. Для побудови робочої матриці впливу та зацікавленості можна розподілити стейкхолдерів по чотирьом квадрантам. Гарний практичний приклад можна знайти в цій статті на dou.ua.

7. Домовленості не фіксуються. Продовжуючи тему, можна відзначити таку помилку, як відсутність meeting notes, складених за результатами спілкування зі стейкхолдерами. Писати meeting notes – чудова форма захисту команди, особливо на динамічних проектах з високою мобільністю менеджерів.

Мені доводилося стикатися з ситуаціями, коли через певний час замовник або забував про досягнуті домовленості, або у зв’язку зі зміною продуктової команди такі домовленості губилися, і нам потрібно було переконувати замовника, що ті чи інші зміни, наприклад, в реліз-плані – це не прорахунок, а реальна домовленість.

8. Відсутність visibility. Варто згадати й формат щоденних стендапів. Замовнику вкрай важливо мати достатній рівень visibility, знати куди й наскільки ефективно було витрачено його кошти. Бізнес-аналітикам початківцям (хоча часто не лише їм) не завжди вдається стисло й інформативно пояснити замовнику, яку роботу виконано.

Пам’ятайте, що клієнту не сподобається, коли він дізнається, що, наприклад, весь минулий тиждень хтось з членів команди знаходився у блокері та нічого не робив. Я зустрічав ситуації, коли клієнт на аргумент про те, що хтось був заблокований чимось, запитував: «А що особисто ти зробив, щоб подолати блокер/чим займався поки був заблокований?». Використайте час, коли ви в блокері, для покращення існуючих процесів на проекті. На щастя, такої роботи (особливо на нових проектах) вдосталь. А коли будете розповідати замовнику про завершені задачі, виходьте з позиції проактивності, думайте про те, які зустрічні питання можете випередити.

9. На деталі витрачається забагато часу. В якості помилки початківців можна виділити надмірне фокусування на деталях тікета та/або тонкощах імплементації при його описі. На довгострокових проектах слід враховувати, що деталі імплементації можуть змінитися з переходом на нову технологію, при цьому бізнес клієнта залишиться таким же. Неправильно складені acceptance-критерії з великою кількістю деталей імплементації (наприклад, такі, що описують конкретні методи або API request/response) призведуть до того, що продуктовий беклог доведеться переписувати.

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

10. У вас немає бачення всього проекту. Також типовою помилкою для великих, довготривалих проектів може бути відсутність розуміння «великої картини», зв’язку з іншими елементами екосистеми і відсутність «helicopter view».

Розуміння зв’язків свого модуля з іншими та знання того, як розвивається пов’язана система, дозволяє правильно і своєчасно розвивати власний продукт, не впадаючи в деталі імплементації. Крім того, так можна суттєво покращити рівень написання вимог. В таких випадках дуже добре допомагає створення контекстної діаграми.

11. Ви йдете від зворотнього. Із попередньою пов’язана помилка написання вимог «від зворотнього» — про те, чого система не повинна робити. В результаті виходить беклог вимог, з якого зрозуміло, що система не буде виконувати, але неясно, що ж вона робити буде. Це може бути пов’язане з тим, що фокус на бізнесі клієнта втрачається Потрібно памятати, що ВА в першу чергу думає безпосередньо про те, що робить система для вирішення бізнес-потреб клієнта.

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

Мабуть, найбільш дієвою порадою було б нічого не боятися, але й не ручатися від імені команди за будь-які строки і роботи перед замовником/стейкхолдерами. Варто крок за кроком виконувати всі дії, які очікуються від нового на проекті бізнес-аналітика. Не забувайте, що той-таки BABoK містить весь необхідний вам план дій. Це нормально, коли на початку проекту нічого не зрозуміло.

Пам’ятайте, що головний інструмент бізнес-аналітика – комунікація. Навіть, якщо нічого не відомо, виявлення стейкхолдерів – хороший початок для з’ясування мети проекту, бізнесу замовника та укладання початкових контекстних і workflow-діаграм, які дадуть відповіді на всі запитання проекту. А більш досвідчені колеги, які довше працювали з даним клієнтом чи проектом, допоможуть вам уникнути формування у замовника неправильних очікувань від продукту.

13. Страх помилки. Він паралізує і замість того, щоб почати діяти і в процесі руху проекту скоригуватися, бізнес-аналітик початківець починає довго «готуватися до дії»: ретельно виписувати листи замовнику, зациклюватися на описі edge case сценаріїв, малоймовірних workflow, якими на перших етапах проекту, як правило, можна знехтувати. Помилятися нормально: і Agile, і Scrum – це про те, щоб помилятися швидко і так само швидко відреагувати на помилку.

Джерело: Cтаття Святослава Щербатюка, Lead Business Analyst, в блозі компании ЕРАМ на Хабр