Коли з головою поринаєш у свої завдання, часом, не знаєш, що кожного дня робить колега за столом праворуч. Щоб виправити цю ситуацію, будемо розбиратися з професіями в IT. Із девелоперами і тестувальниками зрозуміло, вони продукт створюють. PM — спірний персонаж, але є майже в кожній команді, так що з якими питаннями до нього йти, всі вже розібралися.
А ось навіщо потрібна людина з модною професією Business Analyst (BA), ніхто чомусь не розуміє. Може здатися, що він цілий день пише документацію та забирає багато часу, обговорюючи якісь рішення з командою. Чим займається бізнес-аналітик, якщо вже є PM і технічний письменник?
Хто такий бізнес-аналітик — черговий прошарок менеджменту або кращий друг розробника? Пояснимо в цій статті.
ХТО ТАКИЙ БІЗНЕС-АНАЛІТИК
Бізнес-аналітик — це людина, яка стоїть між бізнесом і командою розробки. Він збирає і виявляє вимоги до майбутнього продукту або функцій системи, а потім перекладає їх на зрозумілу для інженерів мову.
Обов’язки BA в команді можуть варіюватися, але на всіх проєктах та у всіх вакансіях бізнес-аналітика вказані 4 основні функції.
- Управління вимогами: їх виявлення, підготовка і деталізація, поділ запитів на вимоги і «якісь не дуже важливі забаганки».
- Стратегічний аналіз: у багатьох компаніях BA разом з топ-менеджментом працює над стратегією розвитку компанії і проєкту, оскільки знає продукт найкраще.
- Проєктування рішень: підготовка документації та інколи створення прототипів. Усе, щоб придумати і донести до команди, яким чином рішення будуть розроблені та імплементовані.
- Управління продуктом: комунікація з дизайнерами, інженерами, стейкхолдерами, бізнесом і Product Owner-ами.
НАВІЩО ПОТРІБЕН БІЗНЕС-АНАЛІТИК
Уявіть ситуацію, замовник надсилає розробнику посилання на конкурентів і каже: «Мені потрібен сайт! Точнісінько, як ось цей!» Програміст: «Я не розумію, що значить “точнісінько”. Дайте ТЗ, менше доведеться переробляти».
Замовник йде до свого друга, за сумісництвом бізнес-аналітика, поскаржитися на програміста. Далі — діалог між замовником і бізнес-аналітиком.
Замовник: Ось ти мені скажи, ЩО ТУТ НЕЗРОЗУМІЛОГО? Взяти і зробити точно такий самий сайт, невже так складно повторити?
Бізнес-аналітик (сумним голосом): Ну, взагалі-то, я на боці програміста. Незрозуміло в твоєму запиті абсолютно все. Зараз доведу. Давай разом подивимося, що саме тобі подобається в цьому сайті. Тут є кнопка «Порівняти», вона тобі потрібна?
Замовник: Ні, не потрібна.
Бізнес-аналітик: У цих людей на сайті окрема сторінка для доставки і ще одна — для оплати, тобі точно потрібно дві верстати або можна доставку й оплату об’єднати в одну сторінку?
Замовник: Можна поєднати, мені й справді дві сторінки нічим заповнювати.
Бізнес-аналітик: Бачиш, вже виходить не один в один, правда?
Замовник: Я, напевно, мав на увазі швидше візуальне оформлення.
Бізнес-аналітик: А програміст говорив про функціонал.
Цей кейс показує, наскільки по-різному можна розглядати один і той же продукт (у цьому випадку сайт). Виходить, BA — та людина, яка може врятувати проєкт від «зробили, але не те». Тому залучати бізнес-аналітика краще до того, як команда зіткнеться з проблемами в комунікаціях із замовником.
Першим дзвіночком, що без BA не обійтися, можна вважати занадто поверхневі вимоги від замовника (як у прикладі вище). Трапляється й зворотна ситуація, коли команда начебто робить класні речі, але не може розповісти клієнтові, що саме розроблено, оскільки використовує занадто технічні терміни, які клієнт просто не розуміє.
Здається, мав би замовник технічний бекграунд, це могло б вирішити всі питання. А ось і не вгадали. Підковані в технічному плані замовники замість того, щоб сфокусуватися на складанні ТЗ, можуть почати розповідати команді, що і як робити, не володіючи достатньою експертністю у сфері. Або гірше того — починають писати код і відстоюють його імплементацію в проєкт. У цій ситуації BA виступає в ролі психолога: нагадує замовнику про те, що на нього працює команда професіоналів, і своїми діями він просто уповільнює процес розробки. Команду, в свою чергу, просить ставитися лояльніше до замовника і не надсилати йому посилання на Вікіпедію.
Є і третій тип проблем у комунікаціях — коли те, яким замовник бачить продукт, занадто відрізняється від того, що команда вважає оптимальним рішенням бізнес-потреби. Бізнес-аналітик у подібних ситуаціях виступає своєрідним рефері й об’єднує кращі пропозиції з двох варіантів, попутно аргументуючи зміни для обох сторін. Стривайте, але це більше схоже на роботу Project Manager-а, хіба ні?
В якомусь сенсі так і є. Не у всіх компаніях виділені окремі люди на обидві ролі, а з вимогами працювати потрібно в будь-якому випадку. Однак, у середніх і великих проєктах і у бізнес-аналітика, й у PM-а роботи вистачає на цілий день (ще й з овертаймами).
ОДИН ДЕНЬ БІЗНЕС-АНАЛІТИКА В IT
Давайте опишемо звичайний день, за який бізнес-аналітик встигає виконати всі свої базові функції. Звичайно, так проходять далеко не всі будні BA. Залежно від поточних завдань і стадії розвитку проєкту, змінюється кількість часу, робота бізнес-аналітика адаптується, але в ідеальному світі без палаючих дедлайнів розклад BA може виглядати наступним чином.
10:00 — 12:00 ДОПОМОГА КОМАНДІ
В окремих випадках комунікація з командою може займати мало не цілий день. В ідеальному розкладі за ці дві години BA відповідає на питання, коли щось незрозуміло і бере участь в обговоренні проблемних ситуацій.
Бувають випадки, коли в роботу беруть на перший погляд просту задачу, а під час виконання виявляється, що є технічні обмеження, і затверджене раніше рішення займе значно більше часу.
BA організовує мітинг, на якому пояснює команді початкову бізнес-потребу і питає, чи може команда запропонувати рішення, яке займатиме меншу кількість часу і ресурсів. Якщо оптимальне рішення знаходять, то бізнес-аналітик змінює вимоги. Ні — саме час «порадувати» клієнта новиною.
BA завжди повинен чітко розуміти, наскільки конкретна вимога важлива для клієнта, і чи потрібно додатково обговорювати із ним зміни. Спочатку краще питати все. Розуміння, в якій ситуації можна прийняти рішення самостійно, приходить із досвідом.
Що важливо при роботі з командами:
- Бути на зв’язку мало не 24/7.
- Фокусуватися на вирішенні проблеми: з’ясувати, в чому суть, перевести розмову в позитивно-конструктивне русло і запропонувати альтернативне рішення.
- Ескалувати проблеми вчасно: не намагатися все вирішити самостійно.
- Промовляти труднощі, з якими може стикнутися проєкт у разі змін. Вчасно повідомляти стейкхолдерів.
Важливо не зависати на комунікації з командою і навчитися розуміти, коли всі поточні питання вирішені і можна сконцентруватися на іншому завданні.
12:00 — 14:00 НАПИСАННЯ ДОКУМЕНТАЦІЇ
У документації є один мінус: якщо вона занадто велика, її ніхто не читає.
Що робить бізнес-аналітик на цьому етапі:
- Створює специфікації.
- Описує user stories/acceptance criteria/use cases.
- Формулює нефункціональні вимоги — описує умови, в яких система ефективна. Наприклад: «Система повинна бути відмовостійкою і сумісної з Google Chrome…».
- Моделює бізнес-процеси.
- Прототипує рішення.
Що важливо при написанні специфікацій:
- Заздалегідь визначити необхідні артефакти.
- Описувати вимоги ДОСИТЬ детально: ні більше, ні менше.
- Розуміти принципи usability.
- Дотримуватися нотацій у роботі з діаграмами.
14:00 — 15:00 ОБІД
Обід — це ідеальна можливість у неформальній атмосфері дізнатися про людей і поспілкуватися з командою, тому бажано не обідати на самоті.
15:00 — 18:00 КОМУНІКАЦІЯ З КЛІЄНТОМ
Робочі наради — це ті зустрічі, на яких можна не просто дізнатися про вимоги, але й докопатися до істинної потреби клієнта. Іншими словами, відповісти на питання «навіщо нам це потрібно?» і подумати, чи дійсно рішення оптимальне, чи є ще варіанти. Щоб спілкуватися із замовником однією мовою, потрібно розбиратися у предметній області бізнесу.
У ході таких інтерв’ю відбувається збір, виявлення й уточнення вимог, демонстрація документів, прототипів, моделей, діаграм, демо продукту або навіть готового рішення.
Важливо! Валідіруйте результати із замовником і обов’язково зберігайте «аппруви». Навіть скрін повідомлення в особистому листуванні вважається «аппрувом». Доступ до того ж Slack клієнта у будь-який момент можуть закрити, тому важливо, щоб ви зберігали «аппруви» у себе, поряд із вимогами.
18:00 — 19:00 КОНСУЛЬТАЦІЇ З ТЕХЛІДАМИ
Коли BA складає вимоги, він повинен розуміти всі суміжні технічні деталі. Навіть, якщо він уміє писати код, на проєкті за ним закріплені інші завдання, тому обов’язково потрібно радитися з тими, хто зайнятий розробкою: архітекторами, тім/техлідами й предметними фахівцями.
На таких консультаціях обговорюються високорівневі вимоги: яким чином їх краще спроєктувати, впровадити, декомпозувати тощо. Якщо в команді немає архітекторів, потрібно йти до розробників і радитися з ними. Прямий обов’язок BA — розуміти предметну область з усіх точок зору: не лише з боку бізнесу, а ще й з технічного.
ІЗ КОГО ВИХОДИТЬ ХОРОШИЙ BA
У бізнес-аналіз можна прийти як із бізнесу, так і з розробки. Сильні BA виходять із технічних письменників, оскільки вони розуміють, як саме формується хороша документація. З бізнесу в BA виростають менеджери, економісти і навіть спеціалісти з команди підтримки, оскільки вони розбираються у болях і потребах клієнта.
Роль BA в компанії можуть виконувати різні фахівці.
| Sales Manager | Спеціаліст із продажів — перший, хто починає виявляти вимоги і розуміти, що ж хоче клієнт. Досвідчені сейлзи прокачують необхідні навички BA, щоб грамотно зібрати першу інформацію про можливий продукт. |
| Account Manager | Аккаунт менеджер багато знає про продукт і побажання клієнта, так що може зорієнтувати замовника, куди розвиватися. |
| Product/ Project Manager | У межах роботи PM-ам доводиться доносити вимоги до команди і керувати ними, тому на більш-менш серйозному проєкті не обійтися без знань бізнес-аналізу. |
| Тімлід або найдосвідченіший розробник | Девелопер може виконувати роль BA, якщо замовник володіє хоча б якоюсь технічною компетенцією. Ця модель найчастіше зустрічається в аутсорсингу. |
| QA інженер | Тестувальник розуміє, що саме команда повинна розробляти. У ході тестування QA складає тест-кейси, і ці кейси — чи не єдина документація, за якою працює команда за відсутності BA. Це не найкраща практика, але, тим не менш, вона має місце бути. До речі, QA-фахівцям потрібно кілька місяців, щоб освоїти додаткові техніки, необхідні для BA, й піти в бізнес-аналітику. |
| UI/UX дизайнер | Дизайнери багато комунікують із клієнтами і працюють зі зворотним зв’язком. Вони можуть розповісти команді, що і як повинно працювати. Оскільки дизайнер не розбирається в розробці, роль BA на таких проєктах дизайнер ділить із командою. |
| Scrum master, Scrum team | Якщо команда працює по моделі Agile, ці фахівці можуть брати на себе роль BA. |
ЯК СТАТИ BA?
Якщо після прочитання статті вам здалося, що бізнес-аналіз може стати наступним етапом вашого кар’єрного росту — це хороша ідея. Навіть якщо після навчання ви передумаєте змінювати роботу, знання бізнес-аналізу істотно підвищать вашу цінність на ринку.
Щоб вирости в бізнес-аналітика, потрібно:
- Зрозуміти роль бізнес-аналітика у своїй компанії, адже завдання від проєкту до проєкту можуть сильно відрізнятися.
- Визначити свої поточні компетенції і порівняти з матрицею компетенцій BA. Іноді одна компетенція (наприклад, гарна англійська) може стати вирішальною.
- Виділити відсутні компетенції і пройти по ним навчання.
- Оволодіти основними техніками і методиками BA. Впроваджувати отримані техніки в роботі та відстежувати результати.
- Подати резюме на junior позицію із супровідним листом. Важливо написати, чому ви хочете працювати в цій компанії і чому вона повинна вас найняти: що ви для цього зробили, які курси пройшли і що вмієте. Не бійтеся разом із резюме подавати тестові проєкти, які робили в процесі навчання — вони стануть чудовим прикладом вашої першої роботи.
Комусь робочий день бізнес-аналітика здаватиметься нудним, хтось вирішить, що це — робота мрії (спокійніше, ніж у проєктних менеджерів, але, все одно багато комунікації і впливу на результат). У будь-якому разі, знання бізнес-аналізу з кожним днем стають все більш затребуваними на ринку, тому, якщо ви хочете розвиватися в IT, варто прокачатися в роботі з вимогами.