Я — Senior Business Analyst і співкерівник спільноти бізнес-аналітиків DataArt, до якої входить 200 осіб. Майже чверть із них — джуніори і трейні. Також я є засновником і тренером центру Art of Business Analysis, спочатку створеного для підвищення кваліфікації middle і senior фахівців, але наразі ми розвиваємо і джуніорські програми. Причина — кадровий голод: попит на бізнес-аналітиків наразі пропорційний неймовірному попиту на розробників і тестувальників. – пише Денис Гобов, Senior Business Analyst у DataArt
Я зібрав 10 найпопулярніших запитань, що ставлять мені та моїм колегам бізнес-аналітики, які тільки починають свій шлях у професії. Сподіваюся, відповіді будуть корисними для всіх, хто збирається стати бізнес-аналітиком в IT, незалежно від нинішнього місця роботи і посади.
ЯК СТАЮТЬ БІЗНЕС-АНАЛІТИКАМИ В IT: МОЯ ІСТОРІЯ
Багато хто хоче працювати саме в IT, але не має бажання програмувати. Тоді починають розглядати можливі варіанти: тестувальник, тімлід, аналітик. Я, навпаки, спочатку був розробником, а потім став бізнес-аналітиком. Це теж досить поширений професійний шлях.
На початку нульових, ще в інституті, я потрапив у великий проект — ми розробляли для “Укрзалізниці” систему, яка автоматизувала управління пасажирськими перевезеннями (бронювання та купівля квитків, складання розкладу, заведення інформації про вільні місця тощо). У проекті всі були рівними, кожен трохи спілкувався з клієнтом, писав код і тестував. Там, де задачі були порівняно простими, схема працювала, але на одній складній підсистемі вона дала збій. Замовник не прийняв наш перший реліз, потім другий.
Причина полягала в тому, що ми недостатньо глибоко розібрались у бізнес-процесах замовника, не розуміли остаточно поточний і бажаний стан. Відповідно, код не міг бути правильним, скільки релізів ні випускай. Так у компанії з’явився запит на нову позицію.
Основний час у проекті я став приділяти спілкуванню з клієнтом, документуванню його потреб, продумуванню рішень, які задовольнять ці потреби. І зрозумів, що мені більше подобається не розробляти, а розбиратися, що потрібно клієнту та як це краще зробити.
ХТО ТАКИЙ БІЗНЕС-АНАЛІТИК?
Це людина, яка спочатку визначає, де знаходиться бізнес клієнта і де він має бути (куди ми йдемо?). Потім разом із замовником і командою прописує маршрут, щоб із мінімальними витратами принести максимальну користь бізнесу. Це якщо коротко.
Бізнес-аналітик потрібен на всіх трьох етапах проекту.
1. Передпроектний аналіз. Зазвичай триває 2–6 тижнів. Задача аналітика: виявити поточний стан бізнесу, його потреби та визначити межі рішень: що робимо, а що — ні. Це верхньорівневий аналіз. Якщо, припустимо, клієнт впроваджує ERP, аналітик визначає, які модулі потрібні, з чим інтегруємось, які будуть типи користувачів.
Головна складність на цьому етапі — сформувати єдине бачення для замовника і розробника: куди йдемо, що робимо та чого не робимо.
2. Аналіз в рамках проекту. Може тривати півроку, рік і більше. Бізнес-аналітик працює з детальними вимогами: виявляє, описує, моделює та погоджує. Управляє запитами на зміни, якщо в процесі з’явилися нові бізнес-задачі, змінився закон, що регулює діяльність клієнта, з’явилися або змінилися побажання зацікавлених осіб.
3. Постпроектний аналіз. Після релізу аналітик оцінює, наскільки рішення відповідає планам, що заважає приносити заявлену цінність, яку користь можна внести. Оновлює базу знань щодо продукту, якщо планується подальший супровід/розвиток системи або це передбачено контрактом.
З КИМ ПРАЦЮЄ БІЗНЕС-АНАЛІТИК?
Іноді кажуть, що бізнес-аналітик — це перекладач між бізнесом і IT. Я вважаю, що це людина, яка організовує спільну роботу. Це рівноправний учасник круглого столу, за яким сидять розробники, тестувальники, менеджери проекту, замовник, його постачальники і клієнти, регулятор в особі відділу контролю якості, держави і міжнародних організацій. Ось фактично з ними, тим чи іншим чином, працює бізнес-аналітик.
ЧИМ ВІДРІЗНЯЄТЬСЯ БІЗНЕС-АНАЛІТИК В IT ВІД ІНШИХ БІЗНЕС-АНАЛІТИКІВ?
З висоти пташиного польоту всі бізнес-аналітики роблять одне й те саме. Вони вивчають роботу організації замовника та пропонують способи досягнення бізнес-цілей. Це можна зробити різними способами, наприклад, за допомогою перерозподілу обов’язків у колективі, зміни бізнес-процесів, винесення якихось робіт на аутсорс. Тобто не обов’язково розробляти нове ПЗ.
Відмінність бізнес-аналітика в IT полягає в тому, що його головним інструментом для досягнення цілей є саме ПЗ. У його проекті потрібна розробка, доробка чи впровадження коробкового рішення.
ЯК ВИГЛЯДАЄ РОБОЧИЙ ДЕНЬ БІЗНЕС-АНАЛІТИКА?
Основна частина робочого часу йде на спілкування з командою, щоб донести вимоги замовника, проговорити варіанти реалізації, відповісти на наявні та зібрати нові запитання. По-друге, це спілкування з клієнтом: виявлення вимог, фіксація домовленостей, визначення пріоритетів. По-третє, паперова робота: підготовка специфікацій, аналіз документів, які є джерелами вимог.
ЯКІ КОМПЕТЕНЦІЇ ПОТРІБНІ БІЗНЕС-АНАЛІТИКУ?
Ось що відрізняє хорошого бізнес-аналітика:
- ШИРОКИЙ КРУГОЗІР. Знання предметних галузей, специфіки різних видів діяльності дозволяє швидше зануритись у проект та говорити з клієнтом однією мовою. Плюс потрібно тримати в голові патерни розв’язання задач, які можна перевикористати у проектах.
- РОЗВИНЕНІ КОМУНІКАТИВНІ НАВИЧКИ. Якщо вам важко спілкуватися з людьми та доносити інформацію у зрозумілому вигляді, можливо, ця робота не для вас. Щоправда, існує класифікація, згідно з якою є бізнес-аналітики та системні аналітики. Вважається, що перші більше спілкуються з людьми, а другі працюють з документами, і їм можна бути нелюдимими інтровертами. Насправді, такий розподіл зустрічається рідко. Найчастіше у великих аутсорс-компаніях бізнес-аналітик і системний аналітик — це одна людина.
- АНАЛІТИЧНИЙ СКЛАД РОЗУМУ. На практиці це означає, що аналітик вміє генерувати різні варіанти розв’язання задачі.
- РОЗВИНЕНА ЕМПАТІЯ — вміння подивитися на проблему з різних поглядів, зрозуміти, що відчувають замовник і кінцевий користувач, подивитися на постановку задачі очима команди: розробників, тестувальників. Це допомагає відразу врахувати багато потенційних складностей, запитань і побажань.
На сайті Art of Business Analysis ми зібрали розширений список базових компетенцій бізнес-аналітика (російською та англійською). Це те, що потрібно розвивати.
ЩО Є РЕЗУЛЬТАТОМ РОБОТИ БІЗНЕС-АНАЛІТИКА?
Головним результатом є зниження невизначеності в замовника і команди — з’являється розуміння, куди та як рухатись.
У більш приземленому сенсі результат — це документи: перелік функціональних і нефункціональних вимог, користувацькі історії, моделі — вони стають основою беклогу. Команда бачить, що в якому порядку робити. І замовник може підтвердити: “Так, це саме те, що я хочу”.
Ще один результат — база знань, яка потрібна, щоб розуміти, на основі яких вимог систему було побудовано. Вона стане у пригоді для супроводу системи та перевикористання в інших проектах.
ЯКІ ГРЕЙДИ В БІЗНЕС-АНАЛІТИКІВ?
У кожної компанії — своя класифікація. Розповім, як ми в DataArt визначаємо джуна, мідла, синьйора та експерта.
- Джун може приносити користь, але не є самостійною бойовою одиницею. Йому можна доручити, наприклад, задокументувати результати воркшопу та перетворити їх на вимоги за шаблоном.
- Мідл розв’язує стандартні задачі в рамках типових проектів. Він працює самостійно, йому не потрібна підтримка.
- Синьйор розв’язує складні нестандартні задачі, для яких немає шаблонів. Часто виступає ментором для мідлів і джунів.
- Основна цінність експерта — у навчанні інших бізнес-аналітиків. Він має величезний досвід, може підказати, який інструмент для цієї задачі працює найкраще, які підходи до побудови рішення є оптимальнішими, з якими потенційними задачами/проблемами проект може зіткнутись у майбутньому.
ЯКІ ТОЧКИ ВХОДУ В ПРОФЕСІЮ?
Якщо ви вже працюєте в IT (дизайнером, розробником, тестувальником тощо), можна спробувати наступні варіанти:
- Програми внутрішньої перепідготовки. У великих компаніях найчастіше такі програми є.
- Поєднання ролей. Можна працювати, умовно, тестувальником, та допомагати бізнес-аналітику на своєму проекті. Зазвичай це рутина на кшталт документування вимог за шаблоном, підготовка протоколів за результатами обговорень.
- Коли наблизитеся до рівня джуна, беріть участь у внутрішніх ініціативах з розробки чи поліпшення систем, використовуваних вашою компанією. Метою таких ініціатив, зокрема, є надання джунам можливості попрактикуватися, перш ніж довірити їм клієнтські задачі. Зазвичай це відбувається у неробочий час та не завжди оплачується, проте напрацьовується досвід і репутація.
Якщо працюєте не в IT:
- Трейні-програми. Великі компанії, зокрема DataArt, проводять набір до своїх шкіл. Це відбувається нерегулярно, тому потрібно стежити за анонсами. Туди непросто потрапити, але я наполегливо рекомендую спробувати. Перше, що запитають у такій школі, — як добре ви володієте англійською. Ще перевірять, наскільки серйозними є ваші наміри та чи вмієте ви зрозуміло висловлювати свої думки. Щоб закрити всі пункти, у DataArt, наприклад, просять написати есе англійською про себе та свою мотивацію. Кращих випускників компанії беруть на практику на позиції трені або джунів.
- Участь у стартапах, навчальних проектах. Напевно у вас є знайомі, що створюють інтернет-магазин чи мобільний додаток. Гадаю, вони готові скористатися вашими послугами безкоштовно. Такого досвіду буде достатньо, щоб на базовому рівні розібратися, чого від бізнес-аналітика чекають замовник і команда.
- Робота з ментором. Шукати ментора можна у своїй компанії, у тематичних чатах у Telegram і Facebook, через знайомих — де завгодно. Варто заздалегідь визначитися, що саме ви хочете прокачати з ментором та придумати, що можете дати натомість. Ментор буде відповідати на питання, радити літературу, давати задачі та перевіряти їхнє виконання.
ПРО ЩО ЗАПИТУЮТЬ НА СПІВБЕСІДАХ?
Крім перерахованих вище софт-скилів, майбутніх колег цікавлять ваші хард-скіли та технічні знання:
1) Виявлення вимог — ви знаєте техніки, які для цього використовуються, наприклад, інтерв’ю, аналіз документів, та вмієте їх застосовувати.
2) Специфікування та моделювання вимог — ви вмієте інформацію щодо проекту викласти у структурованому вигляді чи змоделювати.
3) Управління змінами — ви знаєте, за яким циклом проходить запит на зміну, які запитання потрібно ставити замовнику.
4) Пріоритизація — ви вмієте розставляти задачі в певному порядку та обґрунтовувати свої рішення.
5) Прототипування — ви вмієте прототипувати елементи майбутнього рішення, наприклад, за допомогою Balsamiq, Axure чи Figma.
6) Декомпозиція — ви знаєте, як розбити складну задачу на декілька підзадач.
7) Методології — ви розумієте принципи Agile, відмінності від каскадної моделі та знаєте, як будується робота бізнес-аналітика у залежності від методології.
Які саме технічні знання перевіряють на співбесідах — питання дискусійне. У більшості випадків запитають про SQL, тобто навичку написання запитів до баз даних. Точно потрібно знати принципи, за якими будуються програмні продукти. Добре б розуміти принципи об’єктно-орієнтованого програмування та API.
ЩО ЧИТАТИ ТА ДИВИТИСЯ ПОЧАТКІВЦЮ?
Книги:
Якщо ви погуглите, ви обов’язково натрапите на BABOK (Business Analysis Body of Knowledge). Це дітище Міжнародного інституту бізнес-аналізу (IIBA) — найавторитетнішої асоціації в нашій сфері. Однак я BABOK на початковому етапі не рекомендую, не дивлячись на те, що я є євангелістом цієї книги та проводжу тренінги на її основі. По-перше, вона величезна. По-друге, побудована як довідник, і, якщо почати з неї, в голові утвориться каша. Приступайте до цієї книги, коли напрацюєте практичний досвід — тоді краще зрозумієте, що там написано.
Замість BABOK раджу шість книг.
- “Handbook for the CPRE Foundation Level According to the IREB Standard” дозволить перейнятися термінологією бізнес-аналізу та інженерії вимог. Розповсюджується безкоштовно в електронному вигляді.
- Карл Вігерс “Розробка вимог до програмного забезпечення”. Іноді кажуть, що це біблія для початківців.
- “IIBA Global Business Analysis Core Standard” — витримка з BABOK, підготовлена IIBA, що розповсюджується безкоштовно.
- Алан Купер “Психлікарня в руках пацієнтів”. Легко читається та представляє цікавий погляд на індустрію, ПЗ і позицію бізнес-аналітика.
- Dean Leffingwell “Agile Software Requirements” допоможе зрозуміти специфіку вимог у рамках agile-проектів.
- Джозеф О’Коннор “Мистецтво системного мислення”.
ВЕБІНАРИ ТА СТАТТІ:
1. Мій вебінар, присвячений підготовці до співбесіди (рос.).
2. Доповідь Use Case VS User Story (рос.) — порівняння двох найпопулярніших технік специфікування вимог. Пробачте, теж моя.
3. Дві статті про те, як описувати вимоги до інтеграцій: файловий обмін та API (рос.).
4. Багато корисного на англомовному ресурсі Modernanalyst: форум, список із трьох сотень книг, архів вебінарів та анонси майбутніх виступів.
1 thought on “Бізнес-аналітик в IT: як увійти в професію та що робити на початку”