ВІГЕРСОПЕДІЯ – Ніхто не очікує методів інквізиції при зборі вимог: ставлячи питання наступного рівня

Сьогодні до вашої уваги вже другий переклад статей Карла Вігерса з його блогу від Івана Вільчавського та помічників з команди Business Analysis Community Kyiv

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

Бізнес-аналітик повинен глибоко занурюватися в тему під час обговорення вимог.

Бізнес-аналітик — це не просто писар, який записує все, що говорять клієнти, і передає інформацію команді розробників. БA повинен ставити питання, що спонукають до роздумів, щоб стимулювати мислення людей, з якими він проводить інтерв’ю. У цій статті пропонуються деякі неочевидні поради для щодо постановки запитань, які допомагають створити гарні передумови для виявлення більшої кількості вимог. Майте на увазі, що запитання для виявлення вимог — це обговорення, а не допит. Слідкуйте за питаннями, які можуть здатися агресивними або конфронтаційними.

Зондування під поверхнею

Окрім вивчення функціональності, яку пропонують клієнти, БA має допомогти клієнтам мислити на глибшому рівні. Після обговорення певного сценарію використання подумайте про такі запитання:

• Чи є інший спосіб, яким хтось може виконати це завдання?
• Чи захоче користувач коли-небудь <щось зробити>?
• Чи може коли-небудь виникнути <якийсь стан>? Що тоді відбувається?
• Що ще може статися, про що ми ще не говорили?

Це способи виявлення менш ймовірних сценаріїв або опцій, які система повинна надати користувачеві.

Запитання, які вимагають відповіді «так/ні» або з кількома варіантами відповідей, можуть невиправдано обмежити відповідь. Під час обговорення вимог ви можете втратити можливість виявити — або винайти — щось, що виходить за рамки упереджень БА. Питання, які представляють обмежений набір варіантів («Чи справді доступність повинна становити 99,9 відсотка, чи 97 відсотків було б достатньо?») можуть обмежити процес мислення. Ви можете пропустити найкращу відповідь, якої не було в списку представлених вами можливостей. Спробуйте більш відкриті питання на кшталт: «Які допустимі періоди для того, щоб система була недоступна?»

До теми: 6 найважливіших практик по роботі з вимогами за Карлом Вігерсом

Що може піти не так?

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

Як БA, вам потрібно дослідити винятки під час обговорення ваших вимог. Ставте такі питання, як “Що повинно статися, якщо виникне <сюди можна вставити помилковий сценарій чи помилкову дію>? Це може допомогти виявити приховані вимоги, які ще не були обговорені. Мені подобається, коли хтось із досвідом тестування бере участь у сесіях з виявлення вимог, тому що тестувальники особливо вправні в тому, щоб помітити виняткові випадки. Я також залучаю тестувальників для перегляду документації з вимогами та пошуку винятків та альтернатив, які ми не розглядали.

Не вірте всьому, що чуєте

Бізнес-аналітик повинен трохи бути скептиком. Одним з проектів була заміна чинної системи на пакетне рішення (готове рішення іншої компанії, яке використовується у вашому продукті). Користувач попросив додати певну функцію до основного пакета; це не було б дешево. Коли БA запитав, навіщо їм потрібна ця функція, користувач сказав, що вона присутня в поточній системі. БA продовжив дослідження і врешті-решт виявив, що кілька зацікавлених сторін усі думали, що хтось інший використовує дані, згенеровані цією функцією. Насправді цим ніхто не користувався! Кілька разів запитавши «чому», БA і представник користувача погодилися, що функція не потрібна, тим самим заощадивши чималі гроші і зусилля.

Навіщо питати «чому»?

Під час проекту з реінжинірингу БA, на ім’я Дон запитав розробника, чому розрахунок плати комунального підприємства виконується певним чином в системі. “Урядова постанова диктує, як ми повинні розраховувати ці збори”, – відповів він. Після розслідування Дон виявив, що поточна система не впровадила обчислення належним чином відповідно до цієї постанови. Система неправильно прораховувала ці комунальні платежі досить довгий проміжок часу. Розбіжність ніколи б не була виявлена, якби Дон просто прийняв заявлену необхідність поточної формули. Запитання «чому?» виявили істотну помилку, яка була виправлена у новій системі.

«Чому?» – відмінне питання в мішку хитрощів БА. Спробуйте запитати конфронтаційно, звинувачувально чи складно. Я часто ставлю питання, які починаються з: «Чи можете ви, будь ласка, допомогти мені зрозуміти…» Ця фраза довша за просте «чому», але вона означає те саме і привносить більш відчуття спільної роботи. Запитайте “чому” достатньо разів, щоб бути впевненими у тому, що у вас є реальна вимога в руках.

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

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

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

Відповідь на запитання «Чому ця вимога включена?» надає обґрунтування цієї вимоги. Завжди корисно знати, звідки взялася кожна вимога і чому це необхідно. Ці знання допомагають БA визначити, чи входить запит до меж проекту (project scope). Це питання іноді показує, що «вимога» насправді є ідеєю рішення для невстановленої вимоги вищого рівня.

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

Вирвані з контексту

У своїй книзі «Досліджуючи вимоги: якість, що передує дизайну» Дональд Гаус і Джеральд Вайнберг описують питання, вільні від контексту. За їхніми словами, питання без контексту – це «питання високого рівня, які можуть бути поставлені на початку проекту для отримання інформації про глобальні властивості проблеми, що вирішується, та потенційного рішення». Такі питання створюють додаткові конкретні питання про можливості і характеристики продукту. Ось кілька зразків контекстно-вільних запитань:

• Які проблеми, ви очікуєте, будуть вирішені цією системою?
• Які проблеми вона (система) могла б створити?
• Як ми зможемо зрозуміти, що проект досяг успіху?
• Хто винесе це рішення?
• Що може вважатися успішним рішенням з точки зору клієнтів?
• З ким мені слід працювати, щоб отримати найкращу інформацію про систему?

Мета питання

Моє останнє запитання в обговоренні вимог: “Чи є ще щось, що я повинен запитати у вас?” Це метапитання, питання  про питання. Я спокійно визнаю, що не знаю всіх правильних запитань. Іноді після того, як я запитую про це, людина, з якою я розмовляю, розуміє, що ми ще не обговорювали якусь важливу тему: «Так, нам потрібно говорити про налаштування безпеки за замовчуванням для нових співробітників». Я просто не знав достатньо про це, аби запитати.

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

Бізнес-аналіз – це важко! Оскільки це внутрішньо орієнтована на спілкування людська діяльність, я не знаю жодного «короткого шляху» виконати її. Клієнти, які беруть участь у виявленні вимог, можуть бути розчаровані всіма питаннями БA та тим, скільки часу може зайняти процес. Але так воно і є. Набагато менш болісно вести ці обговорення перед створенням програмного забезпечення.

 

Оригінал статті можна знайти тут – https://medium.com/analysts-corner/no-one-expects-the-requirements-inquisition-asking-next-level-questions-605cc18b29b2