Бізнес-аналіз – це спеціальна навичка. Ці практики та поведінки можуть допомогти бізнес-аналітику докласти свій внесок в успіх проекту.
Менеджери з розробки програмного забезпечення роблять, іноді, припущення, що кожен кваліфікований розробник може проводити інтерв’ю з клієнтами, писати вимоги та робити це без будь-якого навчання, ресурсів чи наставництва. Таке припущення є необґрунтованим. Незалежно від того, хто у команді виконує цю роботу, бізнес-аналіз має свій власний набір навичок і звід знань. Аналітики зі значним користувацьким досвідом можуть не мати глибоких технічних знань. Ті ж, хто перейшов у бізнес-аналіз зі сторони розробки можуть не розуміти бізнес-домен користувача. Для цієї роботи, орієнтованої на людей, бізнес-аналітикам потрібно мати відповідні персональні якості та навички. А це підходить не усім. Бізнес-аналітик забезпечує можливостями, що відрізняє успішний проект від того, що має труднощі. Кожна організація, яка займається розробкою програмного забезпечення повинна розвивати кадри навчених та досвідчених бізнес-аналітиків. Давайте розглянемо деякі з ключових навичок та вмінь.
Створіть спільне середовище
Іноді, у проектах з розробки програмних рішень виникають напружені відносини між замовниками, розробниками, менеджерами та маркетологами. Сторони можуть не довіряти мотиваціям або не враховувати потреб чи обмежень одне одних. Безпрограшний результат значитиме, що замовники задоволені продуктом, організація досягає своїх бізнес-цілей, а члени команди пишаються виконаною роботою. Бізнес-аналітик докладає значних зусиль для успіху розробки програмного забезпечення, допомагає зміцнити конструктивні відносини та співпрацю з клієнтами. Визначає ключових осіб, які можуть слугувати голосом клієнта для кожного окремого класу користувачів вашої системи. Я називаю цих людей “чемпіонами продукту”. Також визначає хто буде приймати рішення щодо пріоритетів у спірних питаннях та конфліктах, які процеси для прийняття рішень будуть використовуватися. Зробіть це до того, як команда проекту зіштовхнеться з першим важливим рішенням. Бувають випадки, коли замовники та їх менеджери неохоче витрачають час на обговорення вимог. Ви можете нагадати їм про проблеми, що виникали на попередніх проектах через погану залученість користувачів. Майже кожна організація має свої страшилки про нові системи, що не задовольнили потреб користувачів, не відповідали прихованим очікуванням щодо зручності використання чи продуктивності або повторювали недоліки вже існуючих систем. Нагадавши вашим замовникам про це, ви може підштовхнути їх більше залучатися у наступному проекті. Жодна організація не може дозволити собі постійно змінювати або відкидати системи що не вдалися через відсутність співпраці між замовниками та бізнес-аналітиками у розумінні потреб користувачів. Якщо замовники не погодяться досягати спільного розуміння своїх вимог, результат може бути програшним для всіх.
Подолайте комунікаційну прірву
Бізнес-аналітик є посередником у комунікаціях, який усуває прірву між нечіткими уявленнями замовника та чітким розумінням вимог розробником. Щоб бути дієвим аналітиком розвивайте навички у всіх формах комунікації: слухання, говоріння, письмо та моделювання. Оволодійте словником домену; не змушуйте ваших замовників розуміти комп’ютерний жаргон. Включайте глосарій як частину документації вимог у кожний проект, для впевненості, що всі однаково розуміють важливі терміни. Під час обговорення вимог не бійтеся просити уточнення у представників замовника. Ви можете пояснити, що не в повній мірі знайомі з бізнесом замовника і саме тому не повністю розумієте, що вони пояснюють. Іноді цей підхід робить замовників більш схильними допомагати, оскільки вони бачать, що ви дійсно прикладаєте зусилля в намаганні зрозуміти їх проблеми та потреби. Ми всі мислимо в рамках нашого власного досвіду та знань. Приділить час для того, щоб дізнатися більше про своїх замовників та зрозуміти, як буде зручніше для них вести комунікацію. Спостерігайте за невисловленими припущеннями, що лежать в основі потреб користувачів чи вашого власного розуміння. Критикуйте ці припущення, щоб визначити їх актуальність та наслідки.
Метою розробки вимог є досягнення спільного розуміння зацікавлених сторін щодо рішення, яке вирішить проблему замовника. Бізнес-аналітик складає перелік вимог, які відтворюють це спільне розуміння. Це означає, що вам потрібно вміти спілкуватись як з користувачами (погляд на задачу), так і з розробниками (технічний погляд). Нерідко тільки один письмовий документ з вимогами не зможе досягти обох цілей. Вам потрібно створювати моделі вимог, які містять відповідний рівень деталізації для ефективного спілкування з кожною аудиторією. Візуальні моделі чудово доповнюють текстові описи для досягнення цієї мети. Я рекомендую зосередитися на обговоренні вимог, пов’язаних з задачами, які користувачі бажають вирішити за допомогою системи – їх варіанти використання, а не на функціях, які вони хочуть вміщати. Якщо ви розумієте задачі та цілі користувачів, ви отримаєте необхідні функціональні вимоги, які дозволять їм вирішувати ці задачі. Вимоги, що орієнтовані на вирішення задач користувачів є більш точними та ефективними, ніж стратегія спрямована на функціональні можливості. Цей підхід також допомагає уникнути проблем реалізації функціоналу, який ніхто ніколи не буде використовувати. Крім функціональності досліджуйте очікування користувачів щодо якості системи, що часто залишається непомітним. Продуктивність, зручність у використанні, безпека та надійність – це загальні категорії якості. Один зі способів полягає в тому, щоб спитати користувачів, що вони вважають за неприйнятний показник продуктивності, зручності у використанні, безпечності та надійності. Коли користувачі кажуть, що система повинна бути “зручною”, вам потрібно зрозуміти, що саме це означає для них. Після цього ви зможете переформулювати незрозуміле “зручне для користувача” у конкретні вимоги, які розробники можуть задовільнити.
Фарбуйте всередині ліній
Багато проектів стикаються з неконтрольованим зростанням обсягу проекту, який, інколи, виходить з-під контролю. Багато з таких проектів ніколи чітко не визначали свій намічений обсяг та межу між тим, що до нього входить і що не входить. Навіть важко зрозуміти, чи відбулося неконтрольоване зростання, якщо зацікавлені сторони, від самого початку ніколи не погодили і не задокументували обсяг.
Розпочніть вивчення вимог з бізнес-вимог проекту. Чому організація прийняла рішення розпочати цей проект? Які переваги вони сподіваються отримати для себе та своїх клієнтів? Чи можуть менеджери сформулювати коротке бачення того, яким узагальнено повинен бути продукт? Без розуміння бізнес-цілей, ви не зможете відповісти на критичне питання: “Чи входить це в обсяг проекту?” коли хтось пропонує функціонал. Структурований документ з баченням і обсягом є хорошим місцем для зберігання важливої інформації про проект. Більшість команд використовують ітеративний процес розробки програмного забезпечення, тому визначте обсяг першого випуску або ітерації як складову кінцевого продукту. Опишіть шлях розвитку від цього початкового випуску до кінцевого бачення продукту через серію ітерацій. Задокументуйте будь-які відомі обмеження, наприклад, функціональність, яку ви не плануєте реалізувати, але яку деякі зацікавлені сторони можуть очікувати. Таке управління очікуваннями може допомогти уникнути неприємних сюрпризів наприкінці проекту.
Запитуйте відкриті питання
Найгірше питання, яке можна поставити під час обговорення збору вимог, це: “Що ви хочете?” Друге найгірше питання – “Які ваші вимоги?” Ніхто не знає, як відповідати на такі питання. Щоб витягнути відповідні знання, бізнес-аналітик повинен сприяти активній дискусії з користувачами.
Користувачі природним чином фокусуються на звичайній, очікуваній поведінці системи для загальних задач. Тож з’ясовуйте можливі альтернативні способи виконання завдання користувачем та пов’язані завдання. Питання, які починаються з: “Чи хтось коли-небудь потребуватиме…”, можуть розкрити вимоги, про які ніхто ще й не здогадувався.
Користувач, який каже: “За замовчуванням повинно бути…”, ймовірно, описує звичайний процес або найпоширеніший сценарій використання. Фраза типу: “Користувач також повинен мати можливість…” вказує на альтернативний процес або сценарій. Ці альтернативи можуть мати менший пріоритет, тому ви можете реалізовувати їх у подальшому. Встановлення пріоритетів на початковому етапі допомагає команді сконцентруватися на постачанні мінімально необхідного рішення якомога швидше. Також запитуйте про можливі помилки, які можуть виникнути і як система повинна відреагувати. Якщо користувач каже, що система повинна бути “стійкою”, він має на увазі, що вона повинна свідомо обробляти некоректні дані та неочікувані ситуації. Якщо ви не з‘ясуєте при виявлені вимог винятки, ви можете лише сподіватися, що розробники про них подумають і зроблять розумні припущення як саме система повинна з ними впоратися. БА – це не просто писар. Креативте та пропонуйте ідеї користувачам під час виявлення вимог. Аналітики часто можуть думати нестандартно, ті ж, хто занадто близько знаходяться до проблеми обмежені в цьому. Але будьте уважні до “прикрашання”. Це спокуса додавати додаткову функціональність, яка може здатися цікавою або необхідною. Якщо ви не знаєте як буде використовуватися функціональність або для чого вона потрібна, скоріше за все, вона вам не потрібна. Дієвий аналітик може мислити на різних рівнях абстракції. Іноді ви можете узагальнити запит певного користувача з переліком пов’язаних вимог, що задовільнять ширше коло потреб. Вам також потрібно вміти визначати, коли треба поглибитися в деталі, якщо потреби розмиті. Чим більше подробиць ви можете надати розробникам щодо того, що потрібно створити, тим менше їм доведеться вгадувати, це зекономить їм час на пошуки відповідей.
До теми – ВІГЕРСОПЕДІЯ – Почути голос клієнта: підхід “лідера продукту”.
Встановлюйте пріоритети завчасно і часто
Усі зацікавлені сторони вважають, що їх вимоги повинні мати найвищий пріоритет, але ви не зможете розробити все одразу. Аналітики повинні працювати зі замовниками, щоб визначити пріоритети для того, щоб команда могла спочатку реалізувати найважливішу функціональність. Одним із обов’язків БА є сприяння перемовин між зацікавленими сторонами з метою спільного погодження пріоритетів. Команді виявлення вимог слід заздалегідь вирішити, як класифікувати пріоритети вимог, щоб впевнитися в правильній послідовності розробки. На початкових етапах розробки вимог визначте різні класи користувачів, а також інших зацікавлених сторін – це може позначитися на вимогах. Визначте, які класи користувачів є “вибраними”. Задоволення їх потреб найбільш тісно пов’язане з досягненням бізнес-цілей проекту. У разі виникнення суперечностей між вимогами чи пріоритетів, що надходять з різних груп, вибрані класи користувачів мають привілей. Одна з ефективних стратегій – це почати співпрацювати з представниками продукту для ідентифікації основних варіантів використання або історій користувачів. Означте пріоритети для цих вимог користувачів, щоб визначити які з них починати детально опрацьовувати. Вимоги з найвищим пріоритетом – це ті, які є найважливішими (функціональні можливості, які користувачі дійсно потребують) і найбільш терміновими (функціональні можливості, які користувачі потребують негайно). Незаперечне твердження в розробці програмного забезпечення полягає в тому, що вимоги змінюються протягом процесу розробки. Розглядайте свій беклог вимог динамічним, що підлягає змінам в мірі того, як змінюється реальність. Змінюйте пріоритети вимог у міру надходження змін, щоб переконатися, що команда забезпечує надання максимальної цінності клієнтам якнайшвидше.
Покращуйте свої навички
Обізнаний БА повинен поєднувати навички комунікації, фасилітації та міжособистісного спілкування з технічними та бізнес-доменними знаннями. Ці навички є особливо важливі:
- навички слухання, щоб розуміти те, що люди говорять, і відчувати те, що вони можуть не висловлювати;
- техніки інтерв’ю, щоб спілкуватися з окремими особами та групами про їх потреби;
- техніки фасилітації, щоб проводити семінари з виявлення вимог;
- навички письма, щоб ефективно передавати інформацію замовникам, керівникам та технічним спеціалістам;
- навички моделювання, щоб у візуальних формах представляти знання, що доповнюють природну мову тексту;
- організаційні навички, щоб структурувати і керувати величезним обсягом інформації, зібраної під час обговорення вимог;
- міжособистісні навички, щоб домовлятися про пріоритети та вирішувати конфлікти між зацікавленими сторонами;
- доменні знання, щоб мати авторитет серед представників користувачів і ефективно спілкуватися з ними.
Я раджу вам провести самооцінку своїх навичок і вибрати одну-дві області, які ви бажаєте покращити. Список на сторінках 65–67 книги “Software Requirements, 3rd Edition” – це те, з чого можна почати. Після цього, будьте готові докладати більше зусиль для поглиблення знань у кожній з цих областей та активно намагайтеся практикувати нові навички у наступному проекті або ітерації. Один з більш структурованих способів покращити свої навички – це отримання професійної сертифікації в галузі бізнес-аналізу. Існує багато варіантів, серед яких можна вибрати наступні:
- The International Institute of Business Analysis (IIBA) пропонує кілька рівнів сертифікації, зокрема Entry Certificate in Business Analysis (ECBA), Certification of Capability in Business Analysis (CCBA) та Certified Business Analysis Professional (CBAP);
- Project Management Institute (PMI) має сертифікацію Professional in Business Analysis (PMI-PBA);
- The International Requirements Engineering Board (IREB) пропонує Certified Professional for Requirements Engineering (CPRE);
- British Computer Society (BCS) пропонує серію сертифікацій в галузі бізнес-аналізу на рівнях beginner/початківець, practitioner/практик, professional/професіонал, consultant/консультант та еxpert/експерт.
Отримання однієї або кількох сертифікацій свідчить про серйозний рівень накоплених знань та досвіду справжнього професіонала в галузі бізнес-аналізу.
Підсумовуючи
Вимоги не просто лежать і чекають, поки їх хтось збере. В кращому випадку, вимоги існують як фрагменти у свідомості користувачів, візіонерів та розробників. Завдання бізнес-аналітика полягає у тому, щоб акуратно виокремити їх, перетворити у зручну форму та передати для роботи.
Небагато ролей на проекті є такими ж складними, як роль бізнес-аналітика. І мало яка роль є стільки ж критичною.
Оригінальна стаття – The Habits of Effective Business Analysts, переклад – Анна Захарова, ревью – Олександра Серебрянська (Business Analysis Community Kyiv), оригінальне фото з сайту Freepik.com.