Карл Вігерс опублікував статтю про шість практик, які повинен виконувати кожен бізнес-аналітик. Це продовження його попередньої публікації, де він описав практики #1–6. Пропонуємо до прочитання.
У попередній статті я описав шість найважливіших, на мою думку, практик роботи з вимогами, які повинна виконувати кожна команда розробки програмного забезпечення або систем:
- Практика #1: Визначте бізнес-цілі
- Практика #2: Зрозумійте, що користувачам потрібно робити з рішенням
- Практика #3: Пріоритизуйте вимоги
- Практика #4: Виявіть і оцініть атрибути якості
- Практика #5: Рецензуйте вимоги
- Практика #6: Ефективно управляйте змінами вимог
Звичайно, це не все, що бізнес-аналітик повинен робити, щоб допомогти проєкту досягти успіху. Ось ще шість практик, які, знову ж таки, будуть корисними практично для кожного проєкту. Мені важко уявити проєкт, якому ці активності не принесуть користі. Нехтуйте ними на свій страх і ризик.
Практика #7: Зрозумійте проблему, перш ніж шукати рішення
Занадто часто команди будують і випускають вимоги, функціональність і навіть цілі продукти, якими ніхто не користується, — тому що вони не повністю зрозуміли бізнес-ситуацію та проблеми, які намагалися вирішити. Розуміння проблем або можливостей, які вирішуватиме рішення, об’єднує всіх учасників навколо ключових питань.
Бізнес-проблема — це будь-яке питання, що заважає бізнесу досягати цілей або реалізовувати можливості. Організації запускають проєкти саме для розв’язання бізнес-проблем. Однак ці проблеми або можливості часто не формулюються явно і не документуються.
Ключ до вирішення справжньої проблеми — не вважати, що сформульована проблема чи запропоноване рішення є безперечно правильними. Зіткнувшись із проблемою, проведіть аналіз першопричин: рухайтесь назад, щоб виявити глибинні проблеми та фактори, що їм сприяють. Тоді ви зможете знайти можливі рішення для усунення цих факторів. Якщо вам пропонують готове рішення, запитайте: «Якщо <рішення> — це відповідь, то яким було запитання?» Можливо, ви з’ясуєте, що глибинна проблема потребує зовсім іншого підходу — простішого, складнішого, вужчого або ширшого. Без аналізу цього не дізнатися.
Діаграма аналізу першопричин, або «риб’яча кістка» (fishbone), — це спосіб відобразити результати аналізу, як показано на Рисунку 1. Проблема розміщується в «голові риби». Причини найвищого рівня вписуються в прямокутники на діагональних лініях, що відходять від «хребта». На горизонтальних лініях, що відгалужуються від кожної діагоналі, вказуються сприятливі причини другого рівня і так далі — аж до кінцевих, найглибших і найдієвіших першопричин.
Коли ключові стейкхолдери погодили чітке розуміння основних бізнес-проблем, розгляньте можливість написати заяву про проблему за таким шаблоном:
- Ситуація. Опишіть контекст і середовище.
- Проблема. Опишіть бізнес-проблеми або можливості так, як ви їх розумієте зараз.
- Наслідки. Опишіть ймовірні результати, якщо проблему не вирішити.
- Вигода. Сформулюйте бізнес-цінність від вирішення проблеми.
- Бачення. Опишіть, як виглядатиме бажаний майбутній стан.
До теми: Вігерспедія: не можна просто так збирати вимоги
Практика #8: Визначте і охарактеризуйте стейкхолдерів
У кожному проєкті є стейкхолдери — особи або групи, які активно беруть участь у проєкті, на яких він впливає або які можуть впливати на його напрямок. Частина стейкхолдерів — це замовники, частина замовників — користувачі. Користувачів можна згрупувати в кілька класів із різними потребами. Не врахований стейкхолдер може призвести до прогалин у вимогах або несподіваних обмежень, виявлення яких у майбутньому виявляється руйнівним. Шукаючи стейкхолдерів, варто ставити такі питання:
- Хто впливає на бюджет і терміни проєкту або контролює їх?
- Хто може сформулювати бізнес-цілі проєкту?
- Хто буде безпосередньо користуватися продуктом? Хто — опосередковано?
- Хто відповідає за інші системи або проєкти, на які наш вплине?
- Хто може мати правовий, відповідний або регуляторний вплив?
- Чиї бізнес-процеси зачепить система?
- Хто може знати про обмеження проєкту, процесу або продукту?
Зафіксуйте достатньо інформації про кожну групу стейкхолдерів, щоб усі їх розуміли. Розгляньте такі питання:
- Хто вони і де знаходяться?
- Наскільки великий їхній вплив на проєкт?
- Які в них інтереси і побоювання?
- Яких переваг від продукту вони очікують?
- Яку інформацію вони можуть надати?
- Що їм потрібно знати про проєкт?
- Хто може співпрацювати з командою, щоб представляти інтереси кожної групи?
Час, витрачений на аналіз стейкхолдерів, допомагає залучити правильних учасників до спільної роботи і закласти міцну основу для успіху проєкту.
Зверни увагу: Чи прагне ваша організація покращити вимоги?
Практика #9: Визначте події і реакції на них
Техніка виявлення вимог, корисна для багатьох бізнес-застосунків і особливо ефективна для систем реального часу, — це визначення зовнішніх подій, на які може реагувати бізнес або програмна система. Кожна подія викликає певну реакцію у відповідь. Рисунок 2 показує три типи подій: бізнес-події, сигнальні події та часові події.
Бізнес-подія виникає в зовнішньому світі і перетинає межу бізнес-домену. Як частина реакції на бізнес-подію, користувач у домені може звертатися до програмної системи, ініціюючи один або кілька прецедентів використання. Сигнальні події надходять від апаратного пристрою або як повідомлення з каналу зв’язку. Часові події спонукають систему виконати дію у визначений час або коли минув певний інтервал після попередньої події чи умови.
Таблиця реакцій на події (event-response table) перелічує можливі події і очікувану реакцію системи залежно від її стану на момент виявлення події. Таблиця 1 містить невеликий фрагмент такої таблиці для домашньої системи сигналізації. Сама по собі вона не відображає всіх необхідних деталей — для цього все одно потрібні прописані вимоги. Аналіз подій також допомагає у плануванні тестування і визначенні обсягу релізу.
Практика #10: Аналізуйте вимоги і набори вимог
Аналіз звучить як щось, що відбувається само собою, коли досить довго вдивляєшся у вимоги. Насправді ми можемо застосовувати конкретні техніки, щоб виявляти проблеми і покращувати і вимоги, і рішення. Саме тут бізнес-аналітик додає справжню цінність. Одні аналітичні активності стосуються окремих вимог, інші — їх набору в цілому, як показує Таблиця 2.
Буде цікаво: Вігерспедія: наскільки детальними мають бути вимоги?
Практика #11: Організуйте вимоги структуровано
Людська пам’ять недосконала і неповна. Вона згасає й спотворюється з часом, а інші люди не мають до неї доступу. Тому команда розробки повинна фіксувати вимоги, щоб вони служили постійною колективною пам’яттю. Вимоги можна зберігати в документах, таблицях, базах даних, інструментах управління вимогами, вікі або на стікерах на стіні. Методи специфікації вимог різняться за змістом, структурою, формою, деталізацією та ступенем формальності.
Яку б структуру ви не обрали, потрібно зберігати різні частини знань про кожен тип інформації про вимоги, з якою ви працюєте. Використовуйте стандартні шаблони для організації вимог проєкту. Шаблони надають «слоти» для різних частин інформації: автор вимоги знає, куди її вписати, а читач — де знайти.
Розпочинаючи новий проєкт, обдумайте оптимальний спосіб організації, зберігання та комунікації вимог. Формат зберігання повинен бути легко змінюваним у міру еволюції вимог. Структура має дозволяти визначати різні атрибути вимог, які дають повніше розуміння кожного елемента. Ефективна альтернатива документам із вимогами — зберігати їх у базі даних. Доступні десятки інструментів для управління вимогами. Пам’ятайте, однак, що вони не допоможуть вам визначити стейкхолдерів, поставити правильні запитання або написати хороші вимоги.
Неорганізована купа різнорідної інформації про вимоги — це не специфікація вимог, а просто звалище даних. Успіхів з таким підходом.
До теми: Вігерспедія: десять вселенських істин про вимоги до програмного забезпечення
Практика #12: Виявляйте та документуйте бізнес-правила
Бізнес-правила — це твердження, що визначають певні аспекти бізнесу або впливають на поведінку людей і програмних систем усередині нього. Категорії бізнес-правил включають терміни, факти, обмеження, умови дій та обчислення. Наприклад, магазин може мати таку політику щодо повернення коштів:
RET-1. Для отримання відшкодування за повернений товар покупець повинен пред’явити чек.
RET-2. За товари, придбані понад 30 днів тому, може бути надано лише кредит магазину.
RET-3. Відшкодування не здійснюється за товари, придбані більш як 90 днів тому.
Бізнес-правила існують і застосовуються поза межами конкретного програмного застосунку. Саме тому вони самі по собі не є вимогами. Однак вони часто є джерелом функціональності та даних, необхідних для того, щоб програмна система відповідала цим правилам. Типові джерела бізнес-правил — корпоративні політики, закони, нормативні акти та галузеві стандарти.
Під час виявлення вимог БА повинен активно вислуховувати можливі бізнес-правила. Якщо хтось вживає обмежувальні слова: «тільки», «повинен», «може» або «не може» — за цим може критися бізнес-правило. Бізнес-правила можна документувати у текстовому вигляді, у базі даних механізму правил або в структурованих форматах, наприклад таблицях рішень.
Також до теми: Чому клієнти так часто змінюють вимоги?
Застосування цих шести практик у вашому проєкті — разом із шістьма попередніми, наступними чотирма та фінальною групою чотирьох практик — не гарантує успіху. Однак я впевнений, що вони дадуть команді кращі результати і менше головного болю.
Ця стаття адаптована з книги «Software Requirements Essentials: Core Practices for Successful Business Analysis» Карла Вігерса та Кендейс Хоканон. Карл є автором численних книг із розробки програмного забезпечення та інших тем, серед яких «Software Requirements» (разом із Джой Бітті), «Software Development Pearls» та «The Thoughtless Design of Everyday Things».
Переклад: Тарас Кобець