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

Сьогодні до Вашої уваги пропонуємо переклад цікавої практичної статті, взятої з ресурсу habr.com про помилки бізнес-аналітиків

«…А Лотерейний Комп’ютер, який головним чином і наплутав, один із усіх замість того, щоб вибачатися та виправдовуватися, не тільки визнав помилку, але навіть явно пишався нею.

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

— Ну, і що з того? – запитав Клерк.

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

Роберт Шеклі, “Координати Чудес” (1968)

 Усім привіт. Мене звуть Святослав Щербатюк, я співпрацюю із дніпровським офісом ЕРАМ у ролі Lead Business Analyst. До цієї професії я прийшов чотири з лишком роки тому із юридичного супроводу інвестиційних проектів, яким займався десять років.

Сьогодні роль бізнес-аналітика в проекті розглянута досить детально: відомо, які якості він повинен мати, як йому краще будувати кар’єру, які навички розвивати. Достатньо скористатися пошуком Google, щоб знайти адекватні відповіді.

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

Отже, по черзі.

1. Англійська мова. Одна з основних і дуже суттєвих помилок – недостатня увага до рівня своєї англійської мови. На співбесідах доводиться нерідко зустрічатися з кандидатами з високим рівнем знань у предметній галузі та значним досвідом роботи, але слабкою англійською. Необхідно враховувати, що більшість ІТ-компаній та проектів орієнтовані на закордонних замовників. Необхідність у вільній англійській визначається місцем бізнес-аналітика на перетині продуктової та інженерної команди (роль і місце ВА в Scrum-команді — тема для окремої holy war) та завданнями, що стоять перед ним (ефективна комунікація між цими командами).

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

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

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

Це цікаво: Must have артефакти для розробки ПЗ

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

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

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

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

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

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

До теми: Гайд по User Stories для Junior BA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Усім новачкам у ВА бажаю не боятися помилок та сміливіше рухатися вперед. Успіхів!