Оригінальна стаття – Telepathy and Clairvoyance: Requirements Practices That Don’t Work, переклад – Євген Лєпіхов, допомога з перекладом – Олександра Серебрянська (Business Analysis Community Kyiv). Посилання на фото від benzoix з сайту www.freepik.com.
Досить важко сформулювати правильні вимоги через обговорення, семінари та використовуючі прототипи. Ще важче, коли люди очікують, що ти читаєш їхні думки.
Згідно з Академічним тлумачним словником, телепатія — це «припущення щодо передавання на відстані думок однієї людини іншій». Ясновидіння — це «чудодійна здатність розпізнавати явища, недоступні для сприйняття звичайної людини». Ці навички, безумовно, значно полегшили б розробку програмного забезпечення — якби вони існували. Проте, здається, що телепатія та ясновидіння все ще залишаються технічною базою для деяких проектів.
Здогадайся сам!
Люди іноді думають, що певні вимоги до продукту настільки очевидні, що не варті формулювання.
Дехто також вважає, що може образити бізнес-аналітика, сказавши про “щось”, що, на їхню думку, БА вже знає.
Як аналітик, я краще почую “щось” двічі або тричі — тим самим підкріплюючи достовірність фактів і своє розуміння. Інше діло – чиїсь припущення, щодо наявності інформації в мене, коли по факту це не так.
Дехто вважає себе надто зайнятим аби витрачати свій час на обговорення вимог із аналітиком або іншим представником технічної команди. Таке ставлення виглядає як: “Ви вже маєте знати, що я хочу. Дайте знати, коли буде готово”.
До теми: Провалений ІТ-проект. Чому змінюються вимоги?
Тобто телепатія і ясновидіння – обов’язки аналітика (ні).
Дві великі зони ризику – це припущені вимоги та неявні вимоги. Припущені вимоги – це ті, які люди очікують, не кажучи про них ані слова. Неявні вимоги – виявляються у результаті розбору інших вимог, а не шляхом прямого твердження.
Не варто очікувати, що аналітик читатиме думки абощо, задля отримання замовчаних вимог.
Як показує практика, не варто сподіватись на 100% покриття вимог, проте учасники проекту мають узгодити рівень деталізації, аби свідомо ігнорувати дещо.
Мистецтво докладності
Особисто я віддаю перевагу чіткому та ґрунтовному опису очікувань, замість сподівань щодо чиїхось здогадок про мої думки. Чудово, якщо всі зацікавлені з проекту мають достатньо тісну ментальну взаємодію, щоб отримати ідеальний продукт без необхідності записувати деталі вимог. Чим більше ці люди працювали разом і чим більше команда розробників знає про бізнес домен, тим легше досягти зазначеної взаємодії.
Це також цікаво: 13 типових помилок в роботі бізнес-аналітиків початківців
Але моя загальна філософія полягає в тому, що якщо вимоги не описують певний функціонал або характеристику, не варто очікувати знайти це у продукті. Час від часу ми висловлюємо вимоги неформально, бо припускаємо, що читач має «фільтр сприйнятливості», схожий на наш власний, але насправді люди можуть тлумачити ті самі твердження по-різному.
Ця неоднозначність призводить до невідповідності очікувань та результатів розробки. Можливо, ви керуєтеся іншими припущеннями, ніж я. Припущення — це твердження, яке ми вважаємо істинним за відсутності інформації про те, що воно правдиве. Бізнес-аналітик має виявляти та знаходити підтвердження усім припущення, оскільки часто вони недійсні або застарілі.
Ризик непорозумінь зростає, якщо розробку віддали в аутсорс. Якось я передивлявся вимоги до проекту, розробку якого планували передати в аутсорс. Документ містив багато вимог, які починалися так: «Система має підтримувати…» Я запитав авторку документа, як розробники компанії-підрядника знатимуть напевно, яка саме функціональність мається на увазі під словом “підтримувати” у кожній з вимог. Трохи подумавши, вона відповіла, до того ж, правильно: «Мабуть, ніяк».
Логічним рішенням авторки стало деталізувати, що мається на увазі під “підтримувати” по всьому документу, аби усунути неоднозначності. Це набагато краще, ніж покладатися на телепатію чи ясновидіння.
Ось приклад неявної вимоги.
Ви запитуєте функцію “скасувати” для певного функціоналу. Розробник реалізує функцію “скасувати”. Ви тестуєте її – працює нормально. Ви запитуєте розробника, де знаходиться операція “відновити”.
Розробник відповідає, що не було жодних вимог щодо “відновлення”.
Радимо почитати: Як писати хороші User Stories
Ви пояснюєте, що запит на функцію “скасувати” також передбачає наявність “відновити”, та просите доповнити функціонал. Розробник додає функцію “відновити”, і вона працює. Але потім ви цікавитесь, чому “відновити” спрацьовує лише один раз. Це призводить до подальших дебатів: а скільки разів має спрацьовувати “відновлення”? Чи бажаєте ви миттєво переноситися до будь-якої точки у послідовності “скасувань” аби відновити скасоване? Яка кількість “скасувань” має зберігатися у памʼяті та після чого історія “скасувань” має видалятися? І таке інше.
Якщо розробники та користувачі знаходяться у тісному контакті, вони можуть почати з базових вимог та поступово обговорити та узгодити, як саме має працювати функціонал “назад/вперед” у повному обʼємі (перш ніж починати розробку). Таким чином, вам не знадобляться багаторазові ітерації розробки, аби підігнати функціонал, під фантазії замовника. Однак, якщо ви передаєте розробку в аутсорс, вам краще подбати про докладність заздалегідь та додати всі нюанси у вимоги. Інакше не дивуйтеся, якщо тлумачення скупо написаних вимог розробником на відстані не відповідатиме очікуванням замовника. Підрядник може навіть виявити цей неявний функціонал, але візьме за основу саме задокументовані вимоги, припускаючи, що ви повернетеся із запитом на додатковий функціонал (окремим документом). Тоді підрядник може запросити додаткове фінансування і більше часу, аби впоратись із розростанням обсягів вимог (“scope creep”). Приклади аналогічні до “скасувати”\”відновити”, створюють загальну картину, коли наявність невизначених вимог може припускатися або матися на увазі. Вимог може бракувати, коли маємо справу із складною булевою логікою: з різними комбінаціями умов, що призводять до різних результатів. Таблиця рішень або дерево ухвалення рішень можуть виявити ці прогалини. Граничні значення також проблематичні. Одна з вимог визначає, як розрахувати вартість доставки, якщо ціна замовлення клієнта менше $100; інша вимога – коли сума перевищує $100. Але якщо це рівно $100? Хтось має зробити припущення або дізнатися.
Телепатія не працює
Ви не зможете опрацювати нюанси усього функціоналу лише через роздуми та обговорення. Іноді лише ітерації розробки або прототипи дозволяють користувачам зрозуміти, що їм потрібно. Проте припущення у вимогах та відповідний вибір дизайну можуть призвести до дорогої переробки. Нещодавно я прочитав про конструктивне рішення, яке прийняли інженери щодо ручки керування у винищувачі F-16 “Бойовий сокіл”:
Спочатку інженери зробили ручку керування винищувачем суцільно нерухомою, оскільки сенсори могли враховувати тиск рук пілота на штурвал, імітуючи фактичні рухи. Але пілоти ненавиділи це. Вони хотіли рухати штурвалом, отримуючи відчуття контролю. [взято з “Око гадюки: Тренування пілота F-16”, 2004 р.]
Ніщо не замінить можливість отримати інформації щодо вимог та можливих рішень від людей, які використовуватимуть продукт власноруч. І немає жодних виправдань тим, хто не записує зібрану інформацію, аби гарантувати, що розробники продукту зможуть задовольнити потреби клієнта.