Ці двадцять практик вимог можуть перетворити болісну боротьбу у щасливий успіх
Кожен проєкт і продуктова ініціатива досягають успіху або провалу залежно від своїх вимог. Навіть для створення першого прототипу потрібні певні вимоги. Вимоги дозволяють відповісти на важливі запитання, зокрема: Що ми будуємо? та Чому ми це будуємо? Що користувачі зможуть з цим робити? Які якісні характеристики є найважливішими? Які функції ми впроваджуємо спочатку, пізніше, а можливо, взагалі ніколи?
У моїй величезній книзі «Вимоги до програмного забезпечення» за 2013 рік зі співавтором Джой Бітті описано 52 «хороші практики» для розробки вимог. Інші книги пропонують ще більше вимог і практик бізнес-аналізу, понад 100 в одній книзі. Хоча такі вичерпні книги є цінними ресурсами, хто може запам’ятати — не кажучи вже про застосування — усі ці трюки?
Я скоротив ці вичерпні списки до 20 основних практик, які є найважливішими для вимог — і, отже, для успіху проєкту. Вони стосуються будь-якої діяльності з розробки або вдосконалення програмного забезпечення та систем, які виконуються проєктними або продуктовими командами, які дотримуються гнучких або традиційних методів і створюють будь-який тип продукту. Ці методи описані в моїй нещодавній книзі з Кандаз Хокансон «Основні вимоги до програмного забезпечення» (Software Requirements Essentials.)
Як і у випадку з усіма рекомендованими практиками, методами та техніками, не слідуйте цьому списку сліпо. Продумайте кожен прийом і запитайте себе: «Чи додасть це чогось нашому проєкту? Чи зменшить це ризики, чи допоможе нам, чи покращить якість, чи прискорить роботу? Чи будуть у нас проблеми, якщо цього не зробимо?» Якщо всі відповіді на ці запитання – Ні, не робіть цього. В іншому випадку це дійсно гарна ідея.
Закладання фундаменту
Практика №1. Зрозумійте проблему, перш ніж прийти до рішення. Не вважайте, що будь-яка представлена проблема чи рішення обов’язково правильні. Виконайте аналіз першопричини (root cause analysis), щоб переконатися, що команда розв’язує правильну проблему та розробляє рішення саме для її вирішення.
Практика №2. Визначте бізнес-цілі. Бізнес-цілі говорять вам, чому ви працюєте над ініціативою. Вони дозволяють визначити, коли бізнес-проблема вирішена, потреба задоволена або можливість використана. Попереднє визначення бізнес-цілей зосереджує команду на досягненні бажаних результатів.
Практика №3. Визначте межі рішення. (Define the solution’s boundaries.) Визначення меж дозволяє кожному знати, які бізнес-процеси, функції та події будуть частиною рішення, а які ні. Візуальні моделі, такі як діаграма контексту та діаграма екосистеми (context diagram and ecosystem diagram), показують, що знаходиться всередині рішення, його зовнішні інтерфейси та те, як рішення вписується в загальне системне середовище організації.
Практика №4. Визначте та охарактеризуйте зацікавлених сторін. Якщо ви не помічаєте деяких людей або груп, які залучені до проєкту або можуть вплинути на його напрямок, ви, ймовірно, пропустите важливі вимоги та обмеження. Зацікавлені сторони можуть бути в команді розробників, всередині організації або поза організацією. Визначте та взаємодійте з тими особами, які можуть авторитетно надати внесок від імені кожної групи зацікавлених сторін.
Практика №5. Визначте уповноважених осіб, які приймають рішення. Визначте типи рішень щодо вимог, з якими зіткнеться команда, і людей, які мають брати участь у прийнятті кожного з них. Кожна група, яка задіяна в прийнятті рішень повинна вибрати відповідне правило прийняття рішень, щоб вони могли ефективно співпрацювати.
Виявлення вимог
Практика №6. Зрозумійте, що користувачам потрібно робити з рішенням. Зосередьтеся на використанні, а не на характеристиках продукту. Розуміння того, що користувачі повинні досягти за допомогою продукту, допомагає переконатися, що команда впроваджує правильні функції та не витрачає час на створення непотрібних функцій, які просто здаються крутими.
Буде цікаво: Збір вимог онлайн: як аналітику знайти підхід до віддаленого замовника
Практика №7. Визначте події та відповіді. І підприємства, і системи програмного забезпечення реагують на різноманітні зовнішні події, які викликають певні відповіді системи за певних умов. Такі методи, як таблиці подій-відповідей і діаграми переходів станів, можуть гарантувати, що жодна комбінація подія/відповідь не буде пропущена.
Практика №8. Оцініть концепції та зв’язки даних. Ідентифікація об’єктів даних і логічних зв’язків між ними розкриває функціональні можливості, необхідні для маніпулювання ними. Діаграми взаємозв’язків сутностей, діаграми потоків даних і словники даних є хорошими способами документувати знання команди про відповідні дані.
Практика №9. Виявлення та оцінка атрибутів якості. Щоб з самого початку впровадити якість у продукт, дослідження вимог має розглянути, які з багатьох атрибутів якості є найважливішими для задоволення зацікавлених сторін і успіху продукту. Ви повинні розуміти очікування зацікавлених сторін щодо якості, щоб дизайнери могли приймати відповідні компромісні рішення між суперечливими атрибутами якості.
Аналіз вимог
Практика №10. Аналіз вимог і наборів вимог. У деяких видах аналізу розглядаються окремі вимоги: розкладання їх на деталі, виявлення неоднозначностей і винятків, визначення критеріїв прийнятності та визначення відповідних обмежень і бізнес-правил. Інші дії оцінюють набори вимог щодо конфліктів, прогалин, залежностей і пріоритетів для досягнення повного розуміння.
Практика №11. Створення моделей вимог. Моделі візуального аналізу представляють знання вимог у формі діаграм, які доповнюють текстові вимоги. Доступно багато цінних моделей для представлення інформації про вимоги різними способами. Моделі часто виявляють проблеми, які не видно з тексту.
Практика №12. Створюйте та оцінюйте прототипи. Прототипи — це часткові, попередні або можливі підходи до вирішення, які роблять абстрактні вимоги більш відчутними. Різні типи дизайну взаємодії та прототипи технічного дизайну можуть виявити та підтвердити раніше невідомі вимоги до того, як команда прийме певне рішення.
Практика №13. Розставте вимоги за пріоритетністю. Пріоритезація набору вимог дає команді послідовність їх реалізації, щоб забезпечити максимальну цінність для клієнта за мінімальний час. Особи, які приймають рішення, розподіляють вимоги до майбутніх етапів розвитку на основі їх пріоритетності.
Специфікація вимог
Практика №14. Напишіть вимоги послідовними способами. Щоб сприяти ефективній і точній комунікації — що є метою всіх розробок вимог — корисно писати вимоги різних видів відповідно до послідовних шаблонів. Представлення знань про вимоги на різних рівнях абстракції — від високого рівня до деталізації — допомагає керувати складністю.
Буде цікаво: Гайд по User Stories для Junior BA
Практика №15. Організуйте вимоги структуровано. Ви можете використовувати різноманітні контейнери для зберігання інформації про вимоги: документи, електронні таблиці, інструменти керування вимогами, лейбли чи будь-що, що підходить вашій команді. Правильно організуйте інформацію, яку ви зберігаєте, для легкого доступу, розуміння та перегляду.
Практика №16. Identify and document business rules. Визначте та задокументуйте бізнес-правила. Бізнес-правила, такі як полісі, стандарти та нормативні акти, є джерелом функціональних вимог і вимог до даних для програмних систем, які повинні запроваджувати або відповідати правилам. Таблиці рішень Decision tables є хорошим способом документування бізнес-правил, які включають складну логіку.
Практика №17. Створіть глосарій. Глосарій значущих термінів, скорочень, акронімів і синонімів допомагає переконатися, що всі учасники проекту розуміють ці важливі поняття однаково.
Перевірка вимог
Практика №18. Перегляньте та протестуйте вимоги. Експертні перевірки та концептуальне тестування вимог є ефективними способами розподілити зусилля з якості наперед і запобігти надмірній переробці через проблеми з вимогами пізніше. Приймальні випробування можуть конкретизувати деталі вимог, а тестування моделей набагато дешевше, ніж тестування коду.
Управління вимогами
Практика №19. Встановіть базові вимоги та керуйте ними. Команди можуть визначати базові плани, прив’язані до часу або обсягу роботи, а також домовленості про те, які функції будуть включені в певну ітерацію розробки, групу ітерацій або реліз.
До теми: Рекомендації з управління нефункціональними вимогами
Практика №20. Ефективно керуйте змінами вимог. Кожній команді потрібен певний процес для пропозиції, оцінки, прийняття рішень і повідомлення про неминучі зміни у вимогах. Аналіз впливу є важливою складовою управління змінами.
Ці 20 практик не є чарівним вирішенням усіх проблем вашого проєкту. Однак вони значною мірою сприятимуть тому, щоб ваші команди розробляли правильні рішення ефективно та результативно.
Оригінальна стаття – The Essential Practices for Business Analysis Success, переклад Олександра Серебрянська (Business Analysis Community Kyiv), ревью – Іван Вільчавський. Оригінальне фото від StartupStockPhotos з сайту Pixabay