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

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

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

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

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

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

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

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

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

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

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

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

Важливий досвід команди

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опубліковано: 29/11/18 @ 11:00
Розділ Різне

SEO Блог