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

Цього тижня сталася знакова подія для нашого проекту – Карл Вігерс надав дозвіл на переклад і безкоштовну публікацію українською мовою його матеріалів з блогу на ресурсі Medium. І ми одразу приступили до роботи, тож очікуйте регулярних матеріалів з цього напряму, але й про інші класні україномовні матеріали забувати не будемо. Сьогодні статтю переклав і опрацював Іван Вільчавський

Особисто для мене, однією з найулюбленіших книг з бізнес аналізу є третє видання книги Карла Вігерcа та Джой Бітті «Вимоги до програмного забезпечення» («Software Requirements»). Нажаль ця книга не перекладена українською, але у ній автори дуже зрозумілою мовою описують всі базові концепції бізнес аналізу, що робить її особливо корисною для початківців у вказаній сфері. Книжка є досить змістовною (640 сторінок), але на щастя на її основі Карл Вігерс написав статтю на сайті Medium.com, у якій виклав найважливіші, на його думку, практики роботи з вимогами, які повинні виконувати команди кожного проекту. Нижче наведено зміст статті українською мовою.

Практика #1: Визначте цілі бізнесу

Організації беруться за проект для вирішення проблеми, використання бізнес-можливості або створення нового ринку. Визначення бізнес-цілей проекту доводиться до відома всіх учасників та інших зацікавлених сторін для пояснення того, чому вони працюють над проектом. Організація може сподіватися на досягнення як фінансових, так і нефінансових бізнес-цілей за допомогою нового продукту. Спробуйте кількісно оцінити бізнес-цілі та зробити їх вимірюваними, наприклад за допомогою таких тверджень:

• Захопити частку ринку розміром X відсотків протягом Y місяців.
• Досягнути обсягу продажів X одиниць або доходу $Y протягом Z місяців.
• Заощадити X доларів на рік, які в даний час витрачаються на застарілу систему з високим рівнем обслуговування.

Використання бізнес-цілей узгоджує роботу всієї команди та ключові рішення. Без визначення бізнес-цілей ви не зможете визначити чітке бачення продукту або встановити обсяг задач усього проекту або будь-якої ітерації. Команда не зможе приймати правильні рішення щодо змін обсягу задач або запропонованої функціональності, якщо не знає, як ці зміни відповідають бізнес-цілям. Утримання обсягу задач в центрі уваги допомагає команді уникнути виходу за його рамки, водночас адаптуючись до мінливих бізнес-реалій. І як ви зможете дізнатися, чи був проект успішним, якщо хтось заздалегідь не визначив вимірювані бізнес-цілі та критерії успіху?

До теми: Must have артефакти для розробки ПЗ

Практика #2: Зрозумійте, для чого користувачам потрібне ваше рішенням

Я рішуче виступаю за використання клієнтсько-орієнтованого підходу до розробки вимог та дизайну рішень, а не функціонально- чи продуктово-орієнтованого підходів. Розуміння завдань, які потрібно виконувати користувачам, а також цілей, яких вони хочуть досягнути, дозволяє бізнес-аналітику (БA) визначати функціональність, яка повинна бути реалізована розробниками. Коли ви зосереджуєтесь на вивченні функцій, а не цілей користувачів, ви можете легко не помітити деякі необхідні функції. Також легко помилково включити функціональність, яка здається крутою, але не допомагає користувачам виконувати свою роботу. Варіанти використання (Use Case) є ефективною технікою для підтримки цього користувацько-орієнтованого мислення.

Розуміння того, для чого користувачам потрібен ваш продукт, досягається шляхом здійснення таких важливих видів діяльності БА:

• Визначення широкого кола зацікавлених сторін проекту
• Встановлення характеристик різних класів користувачів, які мають багато в чому різні вимоги
• Ідентифікація осіб, які будуть служити голосом клієнта від кожного класу користувачів (чемпіонів продукту – product champions)
• Вибір відповідних методів виявлення вимог для взаємодії з користувачами
• Налагодження процесів прийняття рішень для вирішення конфліктів і встановлення пріоритетів для всіх класів користувачів
• Створення та оцінка прототипів або ранніх випусків для стимулювання зворотного зв’язку з користувачами

Практика #3: Розставте пріоритети вимог

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

Розстановка пріоритетів передбачає врахування того, наскільки кожна запропонована вимога сприяє досягненню бізнес-цілей проекту. Визначення пріоритетів вимог дозволяє команді вирішити, який з завдань, що залишилися у беклозі, відкласти або пропустити через обмеження часу та ресурсів. Існують численні методи визначення пріоритетів вимог, включаючи такі:

• Вхід або вихід
• Попарне порівняння та впорядкування рангів
• Трирівнева шкала
• Техніка MoSCoW
• Відносне зважування
• Тест на 100 доларів

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

Практика #4: Виявляйте та оцінюйте атрибути якості

Люди, природно, зосереджуються на функціональності продукту під час обговорення вимог, але це лише частина рішення. Нефункціональні вимоги значною мірою сприяють задоволеності користувачів та придатності рішення до використання. Говорячи про нефункціональні вимоги, люди найчастіше думають про атрибути якості. До таких характеристик продукта можна віднести зручність використання, підтримуваність, безпеку, надійність і багато інших. Щоб допомогти дизайнерам розробити найбільш підходяще рішення, БА повинні обговорити нефункціональні вимоги під час фази виявлення вимог.

Розробники безпосередньо не впроваджують вимоги щодо безпеки, надійності, портативності, безпеки чи інших характеристик. Натомість ці атрибути служать джерелом багатьох функціональних вимог і визначають дизайнерськими рішеннями. У таблиці 1 вказуються ймовірні категорії технічної інформації, яку будуть генерувати різні типи атрибутів якості.

Атрибути якості	Вірогідна категорія технічної інформації
Доступність встановлення, інтеграційність, інтеропераційність, надійність, цілісність, безпечність, захищеність, зручність використання, верифікабельність	Функціональні вимоги
Доступність, змінюваність, ефективність, надійність, масштабованість	Архітектура системи
Інтеропераційність, захищеність, зручність використання	Обмеження дизайну
Ефективність, змінюваність, портативність, надійність, можливість повторного використання, масштабованість, верифікабельність, зручність використання	Вимоги до дизайну
Портативність	Обмеження реалізації

Таблиця 1. Переклад атрибутів якості в технічні характеристики (з «Вимог до програмного забезпечення», 3-е видання, автори Карл Вігерс і Джой Бітті)

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

Це цікаво: 13 типових помилок у роботі початкуючих бізнес-аналітиків

Практика #5: Переглядайте вимоги

Як дізнатися, чи точні ваші вимоги? Як ви можете визначити, чи достатньо вони зрозумілі, щоб усі члени команди знали, що з ними робити, а інші зацікавлені сторони знали, чого очікувати від рішення? Незалежно від того, як ви вирішите документувати вимоги, іноді вони неоднозначні, неповні або просто неправильні.

Однією з найпотужніших доступних практик забезпечення якості вимог є їх експертна оцінка. Запросіть декілька колег спільно розглянути текстові вимоги та діаграми. Різні учасники проекту — БА, дизайнери, розробники, тестувальники, користувачі — під час цих оглядів знайдуть різного роду проблеми. Огляди вимог створюють певні виклики. Замість того, щоб просто запрошувати людей переглянути вимоги, проведіть для них певне навчання, щоб вони знали, як більш ефективно брати участь у таких заходах та знаходити якомога більше проблем.

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

Практика #6: Ефективно керуйте змінами вимог

Незалежно від того, наскільки добре ви розумієте проблему і наскільки ретельно ви готуєте вимоги, вони не будуть ідеальними, повними або статичними. Світ змінюється навколо нас, коли ми працюємо. З’являються нові користувачі і нові ідеї. Бізнес-правила з’являються і розвиваються. Проекти неминуче виходять за межі свого спочатку передбаченого обсягу завдань. Кожна команда повинна передбачити зміни вимог і встановити механізми управління ними, не підриваючи зобов’язань команди.

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

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

Класна стаття: Підготовка до співбесіди на JUNIOR/MIDDLE ВА

Нехтуйте цими практиками на свій страх і ризик

Звичайно, крім цих шести є багато інших цінних практик роботи з вимог. Однак саме зазначені практики значно підвищують ваші шанси побудувати рішення, яке буде ефективним та досягне бажаних результатів бізнесу. Їх застосування не гарантує успіху для будь-якого БА, власника продукту чи менеджера продукту. Але нехтування ними, швидше за все, гарантує невдачу.

Якщо вам до вподоби статті Карла Вігерса українською – поширюйте їх зі своїми колегами бізнес аналітиками. Крім того, пропоную придумати назву для вказаної серії статей. Я пропоную Вігерсопедія)) Якщо маєте інші пропозиції – напишіть їх у своєму коментарі до цієї статті.