Що важливо зробити бізнес-аналітику під час старту проєкту

4 January 2022

  • Автор: Кирилл Белявский

  • Складність: норм

  • Час: 8 хв

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

Мета цих порад — підготувати бізнес-аналітиків до реалій IT-проєктів.

І перше, що необхідно зробити, перш ніж занурюватися в роботу, — оцінити, наскільки складним буде проєкт. Попередня оцінка допоможе спрогнозувати ризики та підготуватися до можливих труднощів.

Оцінити складність проєкту

Що важливо зробити бізнес-аналітику під час старту проєкту

Для розуміння складності, проєкти зручно класифікувати за типом клієнта, розміром проекту, типом контракту та методологіями. У кожній з категорій є простіший та складніший варіанти.

Тип клієнта

Найпростіше буде працювати з ISV – Independent Soft Vendor, компанією, яка сама виготовляє програмне забезпечення. STARTUP можна віднести до цієї категорії. Компанії ISV найчастіше наймають додаткових підрядників – вендорів з України, Білорусі та Росії.

З клієнтами на кшталт ISV простіше налагодити контакт та спілкуватися, оскільки вони знаються на специфіці виробництва ПЗ, використовують технічну термінологію, а також розуміють усі аспекти.

З Enterprise клієнтами працювати важче. Як правило, це велика організація або підприємство, яке не взаємодіє зі сферою IT, наприклад, завод, мережа лікарень, або реальний бізнес, який просто прийняв рішення діджиталізуватися.

Enterprise клієнт залучає вашу компанію для реалізації необхідного рішення, як вендорів: оптимізація процесів, використання функцій, або ж повна діджиталізація підприємства.

Співпрацювати з Enterprise компаніями складніше з двох причин:

  1. Не розуміють, як пишеться програмне забезпечення, не знають, що таке SDLS. Хоча, в принципі, вони й не повинні розумітися на цьому. Підхід у них наступний: ми заплатили гроші – виконайте необхідне рішення.
  2. У великих організаціях більше бюрократії: узгоджень, політики, додаткових нюансів та самих стейкхолдерів.

Розмір та терміни

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

До категорії складних відносять тривалий проєкт, для якого знадобляться кілька команд розробки та багато стейкхолдерів з боку клієнта. Чим більше команд, тим більше необхідно комунікації та постійної синхронізації дій усіх учасників.

Тип контракту

Простий варіант – це Dedicated Team, який ще називають Time and Material. У цьому випадку команда працює над продуктом, а компанія бере гроші за час, відпрацьований командою. Припустимо, команда пропрацювала місяць, був виставлений рахунок. Рахунок сплачений, працюємо далі, і за місяць виставляємо наступний рахунок.

Контракт Time and Material є вкрай простим, тому що він не має своєрідних обмежень: команда працює, створює продукт та отримує гроші.

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

У Fixed Price з’являється складність, властива роботі ВА: Scope Creep — розповзання обсягу роботи.

Розглянемо один із прикладів, як відбувається scope creep. Із клієнтом домовилися на виконання певного обсягу, є чіткий термін закінчення проекту, фіксована вартість – робота розпочалася. Проте раптом замовник починає генерувати додаткові вимоги, і бізнес-аналітик розуміє, що необхідно виконати більше роботи, аніж планувалося спочатку. Обсяг роботи зростає, причому, як правило, дедлайн і оплата залишаються незмінними.

Головне завдання ВА в ситуації, що склалася – якомога раніше ідентифікувати речі, пов’язані з розповзанням завдання. Іноді доведеться жорстко спілкуватися із замовником, намагаючись відмовитися від нових точок зору, або ж наполягати на тому, що додаткові вимоги не були прописані. Це надасть змогу відсунути дедлайн.

Методологія

Для розробки проєктів використовуються два основних напрямки методологій: Agile та Waterfall.

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

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

Жорстка методологія є важливою для тих продуктів, де ризик помилки має згубні наслідки, наприклад, програмне забезпечення для апарату, який виконує операції на очах за допомогою лазера.

Тут не підійде підхід “Швидко написали програму та віддали”. Якщо під час операції сталося щось погане, команда каже: «Ну, фідбек не дуже хороший, проте в наступній версії ми його допишемо, переробимо та знову викотимо на ринок».

Якщо брати до уваги високу ціну помилки, використовується Waterfall: всі можливі вимоги дуже довго описуються та вивіряються, проходять аудит та сертифікацію, і лише потім імплементуються. При жорсткому підході працювати складніше: ціна помилки є набагато вищою і необхідно передбачити усі аспекти вже з першої спроби, на етапі написання вимог.

Що важливо зробити бізнес-аналітику під час старту проєкту

Підіб’ємо підсумок короткого екскурсу у категорії проектів:

  • Найпростішим варіантом буде ISV проект або Startup, з маленькою командою та короткими термінами виконання.
  • Складні проєкти належать до Enterprise клієнтів, довгострокових проектів з великою кількістю стейкхолдерів.

Чим більше необхідної інформації щодо проекту та вимог стейкхолдерів спромігся з’ясувати ВА на старті, тим менше буде модифікацій у процесі, і тим кращі способи вирішення бізнес-завдань зможе знайти аналітик.

На початку важливо розібратися з контекстом проекту, а потім зрозуміти власну зону відповідальності та попрацювати з очікуваннями решти учасників.

Збагнути свою зону відповідальності

Перш ніж створити бездоганні очікування від роботи ВА в інших учасників, необхідно самому зрозуміти, яка роль ВА у проєкті та як розподіляються зони відповідальності у команді.

За які завдання BA є відповідальним:

  • аналізує бізнес потреби, контекст, стейкхолдери;
  • збирає запити;
  • керує запитами;
  • комунікує запити;
  • відповідає за вміст товару;
  • контролює завдання, пов’язані із функціоналом.

Якщо узагальнити, то бізнес-аналітик відповідає за всі завдання, пов’язані із запитами, скоупом, змістом продукту та прийманням функціоналу. Проте трапляється й так, що перед бізнес-аналітиком стоять і інші, невластиві йому завдання.

Чим ВА не має опікуватися:

  • Розподіл завдань між розробниками (вирішувати, кому з розробників яке завдання доручити).
  • Рівномірне навантаження команди роботою.
  • Commitment команди — обіцянка команди розробити конкретний функціонал, типовий для agile та скраму. Наприклад, команда обіцяє, що до наступної ітерації буде виконана певну частину функціоналу.
  • Прийняття технічних рішень, бо це відповідають інші люди.
  • Підрахунок часу (скільки хто витратив на конкретне завдання) та різноманітний reporting.
  • Розподіл зарплат та премій.

Опираючись на власний досвід, активності, які невластиві ролі ВА, не лише перешкоджають виконанню прямих обов’язків, а й провокують свого роду конфлікти.

Наприклад, якщо ВА залучений до commitment команди, це перешкоджає управлінню вимогами: аналітик буде підлаштовувати вимоги під обіцянку команди, або ж не прийме commitment, знаючи, що до вимог клієнта належать аспекти, з якими ВА не згоден.

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

Пропрацьовувати очікування

Неправильна робота з очікуваннями спричинить помилки в комунікації, взаємне невдоволення та конфлікти. Помилкові уявлення про роль ВА можуть виникнути як з боку самого бізнес-аналітика, так і з боку команди або РМ.

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

Провести базовий stakeholder analysis

Аналіз всіх стейкхолдерів та зв’язків між ними є однією з початкових дій ВА на проекті. З перших днів роботи бізнес-аналітик з’ясовує наступні аспекти:

  • структуру команди та кількість людей, з якими ВА слід працювати;
  • структуру управління – хто кому підпорядковується і перед ким звітує;
  • клієнт – який у нього бекграунд, очікування, пріоритети.

Зазвичай, РМ проводить онбординг для бізнес-аналітика та відповідає на запитання. Якщо цього не сталося, слід проактивно знайти відповіді, тому що stakeholder analysis надає важливий контекст, від якого залежатимуть інші рішення ВА щодо роботи з очікуваннями.

Зрозуміти очікування РМ-а

Що важливо зробити бізнес-аналітику під час старту проєкту

Найчастіше бізнес-аналітику доводиться спілкуватися з РМ, оскільки це головна людина, яка відповідає за проект. Завдання РМ-а — реалізувати проєкт згідно з контрактом, уклавшись у терміни, бюджет, обсяг роботи, а також якість.

Для досягнення мети проєктного менеджера від бізнес-аналітика необхідні дві важливі речі:

  1. Беклог, опрацьований на декілька кроків уперед.
  2. Постійний обсяг роботи команди.

На кожному конкретному проєкті у РМ будуть з’являтися додаткові очікування. Якщо бізнес-аналітик на старті не з’ясував, як менеджер уявляє собі обов’язки ВА, конфлікти будуть неминучі.

Як з’ясувати очікування РМ:

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

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

Чому не можна обійтися звичайним описом обов’язків у вакансії? Чому рекомендується саме поговорити з РМ-ом?

Як правило, описи вакансії є надто узагальненими. Мало і базового job description, який є в компанії, адже він теж відірваний від контексту. А вам важливі особливості та розуміння, на що конкретний РМ очікує від конкретного ВА на конкретному проекті.

Якщо ваші очікування від позиції ВА не збігаються з баченням РМ-а, це краще з’ясувати відразу. Інакше може статися і так, що РМ з командою очікують від вас чогось, про що ви не знаєте, і на цьому ґрунті починаються конфлікти.

Позиція ВА — це щось максимально точне і певне – немає «еталонного ВА з палати мір та ваг». Обов’язки залежать від контексту проекту, клієнта, компанії. Тому прояснити ситуацію на самому початку співпраці з РМ та командою є обов’язковим моментом, якщо прагнете уникнути конфліктів.

Створити очікування у команди та клієнта

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

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

Яким чином ВА може сформувати очікування:

  • Розробіть невелику презентацію та попросіть 15 хвилин у команди, аби розповісти про себе та свою роль на проєкті. Розкажіть, чим займатиметеся, яку користь будете приносити та з якого дива наявність бізнес-аналітика на проекті є настільки крутою фішкою.

Поясніть ground rules – правила роботи з Вами. Вони можуть відрізнятися у розумінні різних людей.

Замість висновку: 5 порад, як не провалити перший проект

  1. Не бійтеся проговорити, якщо щось незрозуміло. Приходячи на проєкт, новачки вважають, що повинні вміти відразу все, тому намагаються виконати будь-яке завдання, не ставлячи «зайвих» питань.
  2. Не бійтеся просити допомоги на ранньому етапі. Якщо Ви відчуваєте, що можете з чимось не впоратися, підніміть руку і скажіть: «Мені здається, я не можу впоратися сам, потрібна допомога». Або ж: «Я чогось не розумію, мені необхідна допомога».

Як правило, новачки мимоволі щосили намагаються вирішити завдання самі, до моменту, коли вже дійсно пізно. І коли ВА зрештою повідомляє, що не зміг впоратися із завданням, допомогти вже значно складніше.

  1. Стережіться паралічу аналізу. Параліч виникає, коли ми помічаємо декілька варіантів розвитку подій, і всі здаються рівноцінними, тому прийняти рішення просто немає можливості: «Треба б за це взятися, проте тут все залежить від цього, а це теж незрозуміло. А якщо взятися за інше, то воно також залежить ще від чогось». Остаточне рішення прийняти неможливо, і ми сидимо, наче паралізовані.

Гарний спосіб уникнути паралічу аналізу – це рішення, яке мій друг називає “типове не те”.

Наприклад, ви маєте намір обговорити якесь питання з клієнтом, проте останній раптом каже:

— Слухай, взагалі нічого поки що не зрозуміло, давай потім.

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

— Я бачу це таким чином. Що Ви на це скажете?

Швидше за все, вам не скажуть:

— Не хочу дивитися, давай потім.

А все-таки подивляться та зроблять уточнення:

— Оце зовсім не годиться, тут правильно, а тут варто щось змінити.

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

  1. Чітко обговорюйте ризики, коли бачите, що існують якісь підозри. Слід повідомити всіх, кого це стосується, і бажано зробити це якомога раніше. Чим раніше ви про це заявите, тим менше проблем потім може статися.
  2. І, найголовніше, пам’ятайте, що провалити проєкт наодинці майже неможливо – це «командна» робота. Проєкт не провалиться з вини однієї людини. Слід це зрозуміти, аби спокійно виконувати свою роботу та не хвилюватися, що все може зіпсуватися лише через вас.

Кирилл Белявский

Lead Business Analyst в SoftServe. Більше 8 років досвіду в бізнес аналізі. Спікер курсів I am BA та Supreme BA. Регулярний лектор на курсах, мітапах і конференціях, веде подкаст про життя і бізнес-аналіз.