Відкриті запитання стимулюють креативне мислення під час виявлення вимог та у ході будь-якого іншого обговорення.
«Чого ви хочете?» – запитання, яке наврядчи можна назвати найкориснішим серед тих, які бізнес-аналітик (БА) може поставити під час обговорення вимог. Звісно, на нього можна отримати певні відповіді, але вони, скоріш за все, будуть надто поверхневими та неповними. Існує безліч альтернативних корисних запитань для проведення сесій з виявлення вимог, і мережа рясніє відповідними рекомендаціями, як-от ось цей вичерпний список відкритих запитань від Лори Бранденбург.
На відміну від закритих запитань, що передбачають короткі та нерозлогі відповіді, відкриті запитання – дуже цінний інструмент як під час обговорень вимог, так і під час будь-якого інтерв’ю чи розмови. Такі запитання підштовхують учасників дискусії розкрити свою думку, навести пояснення своїм аргументам, тим самим розширити діалог до нових, дотичних сфер. Відкриті запитання часто починаються зі слів «чому» та «як».
БА, виявляючи вимоги до програмного забезпечення, мусить заохочувати креативне мислення серед людей, яких він розпитує, аби «пробитися» через поверхневість односкладних відповідей. При цьому, БА має слідкувати за тим, щоб таке інтерв’ю не перетворювалося на допит для співрозмовника. Аби отримати більше інформації про те, чого стейкхолдери не озвучили раніше, і, як наслідок, використати ці вхідні дані для розробки більш значущого системного рішення, зверніть увагу на такі запитання:
- «Подумайте, чи існують якісь інші способи для користувача <зробити це>?»
- «Чи може <певна умова чи подія> колись відбутися? Якщо так, яким має бути подальший розвиток подій?»
- «Чи буде корисною для користувачів можливість <зробити це>?»
- «Серед того, що ми зараз проговорюємо, чи є якісь припущення, які нам треба затвердити?»
- «Що ще може відбутися, окрім того, що ми вже проговорили?».
Зважаючи на мій досвід, дискусії з виявлення вимог зазвичай фокусуються на очікуваній нормальній поведінці системи. Але будь-хто, дотичний до світу програмування, знає, що розробники готують код таким чином, аби він також покривав безліч виняткових умов. Таким чином, дуже важливо під час збору вимог до програмного забезпечення виявити все, що може піти не так під час взаємодії користувача з системою. Крім цього, треба визначити, як саме система може виявити певну помилку, а також як система уникатиме цієї помилки, реагуватиме на неї та відновлюватиметься після неї. Завдання БА на зустрічах із виявлення вимог полягає, зокрема, в тому, щоб дослідити виключення до поведінки системи. Поставте запитання «Що має відбутися, коли <виникає певна помилка>?». Це може допомогти визначити пропущені вимоги, які ще ніхто не озвучував під час дискусії. Таким чином також можна окреслити певні примущення, не озвучені раніше, для їх подальшого опрацювання.
Особливу експертність у виявленні непокритих виключень в вимогах до системи демонструють тестувальники. Коли це можливо, я запрошую когось, хто має досвід у тестуванні, на сесії з проговорення вимог. Додатково, я залучаю тестувальника у перегляд підготовленої документації, аби виявити виключення та альтернативні сценарії, які було упущено в ході дизайну вимог. Ця техніка з попереднього вичитування вимог тестувальником буде також корисною для визначення, чи всі описані вимоги можна буде перевірити після їхньої імплементації.
Запитання, що передбачають відповідь на «так»/«ні» або декілька варіантів відповідей, варто використовувати з обережністю. Такі запитання можуть обмежити відповідь, і через це втрачається можливість знайти або відтворити більш креативні рішення, щось таке, що виходить за межі суб’єктивності та упередження зі сторони БА. Це, звісно, не означає, що більше не можна ставити запитання з вичерпними варіантами відповідей. Іноді стейкхолдерам таки дійсно треба зробити вибір серед наявних варіантів. Важливо лише не зациклюватися на такому формулюванні, аби не лімітувати пошук можливостей для майбутньої системи.
Останнє моє запитання на сесіях із виявлення вимог зазвичай – це «Чи є щось ще, про що мені варто вас спитати?». Це – метазапитання, тобто запитання про запитання. Я залюбки визнаю, що не знаю всіх запитань, які вартує поставити. Іноді людина, якій я ставлю це запитання, розуміє, що ми досі не обговорили якусь важливу тему, а я просто не мав достатньо знань, щоб розпитати про це.
Запитання «Чи є щось ще, про що мені варто вас спитати?» є також досить колаборативним. Воно демонструє, що ви покладаєтеся на експертизу інших людей, аби надалі разом працювати для досягнення взаємовигідного результату.
Я використовую це саме запитання і у повсякденному житті. Кілька років тому я займався встановленням кухонних стільниць в своєму домі. Ніколи до того мені не доводилося змінювати дизайн свого помешкання, отже, у мене не було достатньо знань про цей процес. Десь в кінці нашої розмови з підрядником я запитав його: «Чи є щось ще, про що мені варто спитати вас про цю роботу?». Він трохи замислився, а потім підняв дуже важливу тему, яку ми не обговорили. Як результат, це вплинуло на загальне рішення стосовно дизайну кухні, яке мені треба було прийняти. Я потішився, що ми виявили це запитання ще на етапі планування робіт, а не посеред процесу ремонту, коли усі матеріали були би вже викуплені та підготовлені до інсталяції.
Бізнес-аналіз – це непросто! Це людська діяльність, заточена навколо комунікації, лише з невеликим відхиленням на інші додаткові активності. Під час сесій із виявлення вимог стейкхолдерів може дратувати велика кількість запитань. Так, іноді БА мусить звертатися до стейхолдерів, аби отримати попередній зворотній зв’язок з приводу певної теми, переконатися у точності розуміння нових вимог, оновити в пам’яті якісь вимоги, уточнити дещо з попередніх дискусій… Але така наша робота. Витратити час на ці проговорення перед тим, як систему імплементовано, буде набагато дешевше та менш болісно, аніж робити це на пізніших етапах. Відкриті запитання, що стимулюють креативність та заохочують необмежене встановленими рамками мислення, – це потужний інструмент в арсеналі бізнес-аналітика.
І так, «Чого ви хочете?» – це таки відкрите запитання, але, напевно, воно надто відкрите, аби бути корисним.
Оригінальна стаття – Ask Open-Ended Questions to Elicit Open-Minded Responses, переклад – Христина Новікова, ревью – Іванна Івченко. Зображення з оригінальної статті.