Хороший бізнес-аналітик не просто сумлінно записує все, що кажуть йому зацікавлені сторони. Хороший БА завжди задає питання «Чому?»
Протягом одного проєкту з реінженірингу програмного забезпечення, бізнес-аналітик (БА) на ім’я Доун спитав одного з розробників, чому в існуючий системі розрахунок плати за комунальні послуги виконувався певним чином. Відповіддю було: «Державний статут визначає, яким чином повинні бути розраховані ці збори».
Після розслідування, Доун виявив, що відповідно до статуту, існуюча система насправді не реалізовувала обчислення належним чином. Система розраховувала ці комунальні платежі неправильно досить тривалий період часу. Ця невідповідність ніколи б і не виявилася, якби Доун просто прийняв заявлену формулу. Питання «Чому» виявило серйозну помилку, яку нова система виправила.
БА не просто сумлінно записує все, що йому кажуть зацікавлені сторони. Проникливий БА завжди питає «Чому». Важливо, щоб дослідження «чому» не були виражені конфронтаційно, звинувачувально або з викликом. Я часто задаю питання, що починаються з «Могли б ви мені допомогти зрозуміти…»
Ця фраза довша за «чому» і означає теж саме, але вона містить більше відчуття співпраці. Представники користувачів часто подають вимоги, що містять ідеї вбудованих рішень, або мову інтерфейсу користувача. Питаючи, чому рішення повинно бути реалізовано саме таким чином, ви допоможете виявити справжнє обмеження дизайну від просто пропозиції або ідеї користувача про те, як може працювати певна функція. Питання «чому» кілька разів поспіль, допомагає БА перейти від запропонованого «хочу» до основної потреби зацікавленої сторони. Це допомагає команді розробки вирішити справжню проблему, а не просто поверхнево представлену. Техніка «5 чому» – це шлях до основних першопричин в дослідженні проблеми. Це також працює добре під час виявлення вимог. Вам рідко доведеться перепитувати «чому» 5 разів, але спускання на один-два рівні може бути дуже важливим. Акуратне дослідження може виявити іншу корисну інформацію, як ці приклади:
-
Відповідь на «чому» може ідентифікувати бізнес-правило, що впливає на проєкт. Далі ти можеш визначити чи бізнес-правило досі доречне та чи повною та точною інформацією про нього ти володієш. Ти можеш дізнатися, де бізнес-правило задокументовано (або це просто усна домовленість в організації), хто відповідальний за підтримку інформації, та чи є пов’язані правила, про які тобі необхідно знати.
-
Питання чому іноді висвітлює припущення, що має людина, яку ви питаєте. Припущення – це твердження, яке ви вважаєте правдивим, за відсутності знання, що це правда. Важливо намагатися виявити припущення, що можуть мати зацікавлені сторони. Припущення можуть бути некорректними або застарілими. Вони також можуть суперечити припущенням когось іншого. Такі конфлікти роблять важчим для зацікавлених сторін мати спільні очікування від проєкту.
-
Запитання чому може виявити неявні або припущенні вимоги, які ніхто не вважав необхідним згадувати. Нехтування такими вимогами веде до неприємних сюрпризів, коли користувачі виявляють їх відсутність у продукті.
-
Завжди є гарною ідеєю знати звідки кожна вимога прийшла та чому вона повинна бути додана в проєкт. Відповідь на питання «Чому ця вимога включена?» надає обгрунтування вимоги. Це допомагає БА дізнатися про запити, що лежать за рамками проєкту. Це запитання іноді також показує, що «вимога» насправді є ідеєю дизайну для ще не сформульованої вимоги вищого рівня.
-
Припустімо, що зацікавлена сторона представляє певну вимогу, як високопріоритетну. Для тебе вона не виглядає такою важливою або терміновою. Якщо ти запитаєш, чому вона є високопріоритетною, можливо ти дізнаєшся, що вона логічно пов’язана з з іншими вимогами, що є високопріоритетними. Без знання цього, хтось може мимоволі відкласти на пізніший цикл розробки вимогу, що здається не такою важливою. Ця затримка може пошкодити відповідні вимоги, які заплановано для раннього впровадження.
-
Іноді БА думає, що розуміє вимогу, але під час подальшого дослідження виявляється, що ні. Питаючи декілька разів чому вимога необхідна, може надати додаткові деталі, які зміцнять розуміння БА цієї вимоги.
-
Питаючи чому або задаючи схожі питання, може допомогти БА відрізнити необхідні знання від сторонньої інформації. Питаючи чому один раз чи двічі може зберегти багато роботи твоєї команди. Був один проєкт по заміні існуючої CRM системи з пакетним рішенням. Вище керівництво наказало команді використовувати стандартні пакетні функції якомога більше і обмежити обсяг конфігурації або змін у пакеті. Один представник користувачів попросив команду розробки додати лічильник, який показував, скільки разів клієнт використовував певну функцію продукту. Це б коштувало значних зусиль для того, щоб змінити основний пакет, щоб він відповідав цій вимозі. Коли БА спитав у зацікавлених сторін, чому їм потрібна ця функція, вони відповіли, що ця функція присутня в їх нинішній CRM системі. БА досліджував далі: «Що саме показує цей лічильник?», «Чому ви перевіряєте його?», «Які дії приймаєте залежно від того, що він показує?». Це обговорення зрештою показало, що всі зацікавлені сторони вважали, що хтось інший використовує дані лічильника. В дійсності ж, ніхто його не використовував взагалі! Розумієте, про що я?
Перепитуючи декілька разів, БА і представник користувачів погодилися, що ця функція не є необхідною, тим самим вони заощадили значний час і гроші на розробку.
БА повинен бути трохи скептичним. Не вір всьому, що ти чуєш, та не приймай все це за чисту монету. Питай «чому» достатньо разів для того, щоб мати впевненість що ти виявив справжні вимоги.
Оригінальна стаття – Why Ask Why?, переклад – Вікторія Чорна, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Зображення зі статті автора.