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

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

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

• Продаж діскавері-фази як окремого продукту з певними термінами і вартістю.
• Проведення діскавері-фази вендором власним коштом, щоб залучити клієнта.

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

На практиці діскавері-фаза триває до 1 місяця. Майже ніхто не інвестує в цей процес так, щоб він тривав 2-4 місяці.

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

Завдання — допомогти клієнту

Є дві команди — замовника та підрядника. З боку підрядника її склад зазвичай такий:

• проектний менеджер або людина, яка відповідає за продаж;
• бізнес-аналітик;
• дизайнер;
• технічний експерт.

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

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

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

Досвід команди є важливим

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

Я наведу приклад. У вас є рівно місяць, щоб зрозуміти, який обсяг (scope) потрібен, і підготувати комерційну пропозицію. Якщо ваш дизайнер junior, то вкластися в 1 місяць буде дуже складно, тому що він буде повільно створювати потрібні прототипи. Через це затягуватиметься і подальша робота всієї команди та проекту.

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

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

Злагодженість команди

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

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

Ваше завдання як професіонала — розповісти послідовність ваших дій, пояснити, яка допомога для цього потрібна. Тобто розкласти клієнту все по поличках. Для цього й потрібні стартові (kick-off) зустрічі, де ви представлятимете свою команду, розповідатимете, чим ви займаєтеся та яка подальша робота. Звісно ж, проектний менеджер (project manager) може розповісти глобально, але за те, як відбуватиметься процес збору вимог, відповідальні саме ви!

Замовник — це група людей, працівників компанії, які займалися своєю рутинною роботою щодня. Вони, можливо, ніколи не стикалися з процесом збору вимог. Допоможіть їм, розповідайте, робіть, не бійтеся. Ви професіонал у цій справі і ви маєте драйвити. Бо хто ж, як не ви?

Обов’язки бізнес-аналітика під час діскавері-фази

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

• Варіанти використання (Use cases) — основні сценарії роботи з системою або додатком.
• Бізнес-процеси. Ви маєте подивитись, які процеси вже є, і спробувати описати, якими вони мають бути. Процеси завжди є, навіть якщо вони не описані. Почитайте про концепт (as is / to be).
• Посадові інструкції. У будь-якій компанії, особливо великій, є такі інструкції. Ознайомтеся з ними, дізнайтеся, чим займаються люди і що входить до переліку їхніх обов’язків.
• Звіти. Знайдіть усі звіти, які використовуються всередині компанії. Це допоможе вам зрозуміти структуру даних, що є на сьогоднішній день і чого не вистачає для повної картини.
• Скріншоти поточних систем. Робіть скріншоти всього, що тільки можна – щоб було з чого почати і не вигадувати з нуля.
• Історії користувачів (User stories) — якщо після діскавері-фази у вас немає списку user stories з високорівневими описом вимог, значить ви провалили цю фазу!

Якщо ви крутий бізнес-аналітик, то ви маєте від самого початку створювати і структурувати беклог. Рекомендації:

• Будьте проактивними та спрямовуйте клієнта, бо не він робить проект, а саме ви!
• У момент виявлення або збору вимог потрібно робити assumptions (припущення). Це допоможе вам у майбутньому при оцінці проекту та розробці.
• Починайте думати із самого початку категоріями “epic” і “user story” — це допоможе вам далі керувати беклогом, який зайде в проект.
• Перед тим як іти на будь-які зустрічі, читайте про предметну галузь.
• На всі зустрічі ходіть із дизайнером, тому що ви маєте розуміти проект на одному рівні.
• Не бійтеся ставити дурні запитання. Краще поставити дурні запитання і видати хороший результат, ніж не запитати нічого і облажатися. Ця мудрість прийшла до мене з роками 🙂

Обов’язки дизайнера

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

Якщо йдеться про розробку програмного забезпечення для внутрішнього використання, не вигадуйте велосипед. Так і скажіть дизайнеру — не потрібно винаходити те, що тільки ускладнить роботу користувача всередині організації. Інтерфейс має бути якомога простішим, і бажано, щоб він мав схожі патерни поведінки з глобальними продуктами (MS, SAP, Oracle).

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

Дизайнер обов’язково має створювати прототипи. Головне завдання — показати, який вигляд матиме майбутній застосунок. Вони допоможуть оцінити складність проекту. У комерційній пропозиції ви посилатиметеся на дизайн, і клієнту буде все зрозуміло.

Завдання технічного фахівця

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

Результати діскавері-фази

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

Чому я говорив спочатку “думайте через еріс і user story”? Тому що для того, щоб скласти комерційну пропозицію, вам потрібно створити WBS (work breakdown structure). Кожен шматок інформації, який ви отримали на діскавері-фазі, допоможе sales-команді побудувати правильну комерційну пропозицію.

У вас мають бути Mockups, які відповідатимуть вимогам, тому що вони будуть базисом для подальшої роботи.

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