Факти, що стосуються майже кожного проєкту. Можете ігнорувати їх на свій страх і ризик.
Я працював у сфері вимог до програмного забезпечення та бізнес-аналізу більше 35 років як практик, консультант і тренер. У роботі з понад 100 організаціями різного розміру і типу я звернув увагу на деякі факти про вимоги, що, як виявляється, є універсальними. У цій статті представлено деякі з цих позачасових «вселенських» істин та їх значення для практикуючих бізнес-аналітиків, продакт оунерів і продакт менеджерів.
Істина №1: Якщо ви неправильно зрозумієте вимоги, байдуже, як добре ви виконаєте решту проєкту.
Вимоги слугують основою для всієї подальшої проєктної роботи. Під «вимогами» я маю на увазі не початкову специфікацію, яку ви продумуєте на старті проєкту, а радше повний набір знань про вимоги, які поступово накопичуються у процесі роботи.
Метою розробки програмного забезпечення є створення продукту, який представляє цінність для певної групи клієнтів. Створення вимог покликане визначити таке поєднання можливостей і характеристик системи, яке найкращим чином забезпечить цю цінність. Розуміння цінності приходить з часом, коли клієнти надають перші фідбеки про результати роботи і уточнюють свої очікування та потреби. Якщо бізнес-аналітик не достатньо добре розбереться з цими очікуваннями і не трансформує їх у відповідний набір функцій та атрибутів продукту, шанси задовольнити клієнта невеликі.
Однією із технік валідації вимог є робота з відповідними представниками замовника для встановлення критеріїв користувацького приймання чи приймального тестування. Приймальне тестування не замінює ретельного системного тестування, але воно дає цінну перспективу для визначення того, чи вимоги дійсно сформульовані правильно.
Істина №2: Розробка вимог — це процес відкриття та винаходу, а не просто процес збору.
Часто говорять про «збір вимог». Ця фраза натякає на те, що вимоги просто лежать і чекають, щоб їх зірвали, як квіти, або висмоктали з мізків користувачів за участі бізнес-аналітика. Я віддаю перевагу терміну «виявлення вимог», а не «збір вимог».
Виявлення – це пошукова діяльність. Вона включає подекуди відкриття та винаходи паралельно з фіксуванням інформації про вимоги, яку надають представники замовника. Виявлення вимагає ітеративності. Учасники дискусії про вимоги навряд чи подумають про всі свої потреби заздалегідь, їхні міркування, ймовірно, будуть змінюватися у ході проєкту.
Бізнес-аналітик — це дослідник, а не просто писар. Вправний бізнес-аналітик ставить клієнту такі запитання, які заохочують до роздумів, розкривають приховану інформацію та генерують нові ідеї.
Нормально, коли бізнес-аналітик пропонує клієнту вимоги, які можуть відповідати його потребам, за умови, що клієнт погоджується, що ці вимоги додають цінності. Бізнес-аналітик може запитати: «Чи було б корисно, якби система могла виконати «те-то і те-то»?» Клієнт може відповісти: «Вау, це було б чудово! Ми навіть не думали просити про цю функцію, але це заощадило б нашим користувачам багато часу». Ця креативність є частиною цінності, яку бізнес-аналітик додає до розмови про вимоги.
Істина №3: Зміни трапляються.
Вимоги неминуче зміняться. Потреби бізнесу еволюціонують, з’являються нові користувачі або ринки, оновлюються бізнес-правила та державне регулювання. Вимоги стають чіткішими, оскільки ключові стейкхолдери схильні ретельніше обудумувати те, що вони насправді намагаються зробити з продуктом.
Дехто боїться процесу контролю змін (change control process). Ціль полягає не в тому, щоб перешкоджати змінам, а радше в тому, щоб забезпечити, аби проєкт запроваджував правильні зміни з правильною метою. Потрібно вміти передбачити та пристосуватись до змін, щоб звести до мінімуму збої та витрати для проєкту та його стейкхолдерів. Товкти воду в ступі після того, як вимоги були узгоджені – свідчення неповного чи неефективного їх виявлення або ж передчасного погодження. Коли я одного разу впровадив процес контролю змін у групі веб-розробників, члени команди адекватно сприйняли це як корисну структуру, яка допомогла їм впоратися з велетенським беклогом запитів на зміну (change requests).
Майже кожен програмний проєкт стає більшим, ніж передбачалося спочатку, тому очікуйте, що ваші вимоги з часом розростатимуться. Темп росту у кілька відсотків на місяць може істотно вплинути на довгостроковий проєкт. Щоб врахувати деяке очікуване зростання, створіть у графіках свого проєкту буфери на випадок непередбачених ситуацій. Цей «резервний фонд» не дозволить зруйнувати ваші зобов’язання з появою першої ж значної зміни.
Замість того, щоб намагатися сформулювати всі вимоги «правильно» одразу і «заморожувати» їх, окресліть набір первинних вимог на основі того, що відомо на даний момент. Базис — це твердження про вимоги, встановлені на певний момент часу: «Ми вважаємо, що ці вимоги будуть задовольняти конкретним потребам клієнта і є відповідною основою для переходу до наступних етапів проєктування та розробки». Почніть з реалізації початкових, найпріоритетніших вимог, отримайте зворотній зв’язок від клієнта, і лише тоді переходьте до наступного фрагмента функціональності. Коли agile-команди зобов’язуються реалізувати певний функціонал у певній ітерації, вони спершу визначають базові вимоги для цієї ітерації.
Зміни не бувають безкоштовними. Навіть для того, щоб розглянути запропоновану зміну і врешті відхилити її, потрібні зусилля. Розробники мають навчати стейкхолдерів проєкту розуміти, що, «звичайно, ми можемо внести зміни, які ви щойно попросили, і ось стільки це коштуватиме». Тоді вони зможуть приймати правильні бізнес-рішення про те, які зміни варто ініціювати і коли.
Істина №4: Інтереси всіх стейкхолдерів проєкту щодо вимог перетинаються.
Стейкхолдер — це особа або група осіб, яка бере активну участь у проєкті, на яку впливає проєкт, або яка може вплинути на його результат. Рисунок 1 визначає деякі типові категорії стейкхолдерів програмного проєкту.
Рисунок 1. Можливі стейкхолдери програмного проєкту (з «Вимоги до програмного забезпечення», 3-е видання, автори Карл Вігерс і Джой Бітті).
Бізнес-аналітик відіграє життєво важливу комунікаційну роль, взаємодіючи з усіма цими стейкхолдерами, щоб визначити рішення, яке найкраще задовольнить усі їхні потреби, обмеження та інтереси. Визначте ваші ключові групи стейкхолдерів на початку проєкту та з’ясуйте, які особи можуть найкраще представляти інтереси кожної групи. Будьте певні, що стейкхолдери матимуть суперечливі інтереси, які необхідно узгоджувати. Тому визначте осіб, які будуть приймати рішення щодо таких конфліктів, і нехай вони погодять процес пошуку компромісу до того, як зіткнуться з першим суттєвим непорозуміням.
Істина №5: Участь клієнтів є найважливішим фактором якості програмного забезпечення.
Недостатнє залучення клієнтів є найчастішою причиною провалу програмного проєкту. Клієнти часто стверджують, що не можуть витрачати час на з’ясування вимог. Однак, клієнти, незадоволені кінцевим продуктом, завжди знаходять достатньо часу, щоб вказати на проблеми. Врешті-решт ви отримаєте залученість клієнта. Просто набагато дешевше і набагато менш болісно отримати цю інформацію на ранній стадії, аніж після впровадження рішення.
Залучення клієнтів – це щось більше, ніж провести один-два воркшопи на початку проєкту. Регулярне задіювання уповноважених та зацікавлених представників клієнта є критичним фактором успіху для розробки програмного забезпечення. Нижче наведено декілька хороших практик для залучення клієнтів до розробки вимог.
Визначте класи користувачів. Клієнти — це підгрупа стейкхолдерів, а користувачі — підгрупа клієнтів. Ви можете додатково розділити своїх користувачів на класи, які мають істотно відмінні потреби. Перевага може бути на боці певних класів користувачів, чиї потреби тісніше пов’язані з бізнес-цілями. Непредставлені класи користувачів, швидше за все, будуть незадоволені результатом проєкту.
Виберіть лідерів продукту. Вам потрібно визначити, хто буде слугувати у буквальному сенсі голосом клієнта для кожного класу користувачів. Я називаю цих людей «лідерами продукту». В ідеалі лідери продукту є фактичними членами свого класу користувачів. Однак інколи вам можуть знадобитися замісники, які зможуть говорити від імені певного класу користувачів якнайкраще.
Погодьте права та обов’язки клієнта. Люди, які повинні працювати разом, рідко обговорюють, як саме вони будуть співпрацювати. Бізнес-анілітику варто домовитися з представниками клієнта на початку проєкту і узгодити обов’язки кожної сторони щодо роботи з вимогами.
Створюйте прототипи. Прототипи дозволяють користувачам завчасно взаємодіяти із частиною кінцевої системи, що допомагає покращувати вимоги та досліджувати варіанти рішень. Прототипи більш реалістичні, ніж письмова специфікація вимог, і зрозуміліші користувачам. Однак прототипи не замінюють документування вимог, необхідного для спільної роботи в одному напрямку.
Істина №6: Клієнт не завжди правий, але клієнт завжди має рацію.
Ми всі знаємо, що клієнт не завжди правий. Іноді клієнт може бути в поганому настрої, необізнаним або нерозсудливим. Якщо ви отримуєте суперечливі дані від кількох клієнтів, хто з них «завжди правий»? Ось декілька прикладів ситуацій, коли клієнт може бути неправий:
- Просуває рішення під виглядом вимог.
- Не може визначити пріоритетність вимог або очікує, що найвищий пріоритет можна отримати за допомогою найгучнішого голосу («пріоритезація за децибелами»).
- Не дотримується бізнес-правил та інших обмежень.
- Очікує, що нова система викличе зміни в бізнес-процесах.
- Несвоєчасно приймає рішення, коли виникає проблема.
- Не погоджується на компроміси у функціональних і нефункціональних вимогах.
- Вимагає непосильних зобов’язань.
- Не погоджується на вартість змін.
Клієнт не завжди може мати рацію, але бізнес-аналітик повинен розуміти та поважати будь-яку думку клієнта, коли він просить про певні функції чи атрибути продукту. Замість того, щоб просто обіцяти все, що вимагає клієнт, намагайтеся зрозуміти його обґрунтування та домовтеся щодо взаємоприйнятного рішення.
Істина №7: Перше запитання, яке потрібно поставити щодо запропонованої нової вимоги: «Це в межах скоупу?»
Кожен, хто тривалий час займається інформаційними технологіями чи розробкою продуктів, точно працював у проєкті, який страждав від розростання скоупу (scope creep). Це нормально і часто корисно, коли вимоги розширюються у ході проєкту. Однак розростання скоупу проєкту стосується неконтрольованого та постійного збільшення вимог, що унеможливлює випуск продукту за планом.
Щоб мінімізувати scope creep, стейкхолдери повинні спочатку узгодити і визначити скоуп проєкту, встановити розмежування для побажань, які входять в скоуп певного релізу, а які – ні. Потім, щоразу, коли якийсь стейкхолдер запропонує нову функціональність, бізнес-аналітик може запитати: «Чи ця вимога в межах скоупу?» Якщо відповідь «ні», тоді вимогу доведеться відкласти (або відхилити), або розширити скоуп проєкту, що відповідно вплине на збільшення вартості та строків. Погано визначені межі скоупу проєкту є відкритими дверима до його розростання.
До теми – ВІГЕРСОПЕДІЯ – Найважливіший урок про розробку програмного забезпечення за останні 50 років.
Істина №8: Навіть найкраща документація вимог не замінить людський діалог.
Навіть ідеально написані вимоги не матимуть усієї тієї інформації, яка необхідна розробникам і тестувальникам для виконання їхньої роботи. Бізнес-аналітикам та розробникам доведеться постійно розмовляти з обізнаними користувачами та предметними експертами, щоб уточнити деталі, з’ясувати незрозумілі моменти та заповнити прогалини. Ось для чого потрібна тісна співпраця команди з лідерами продукту протягом усього проєкту.
Письмові вимоги залишаються цінними і необхідними у будь-якому випадку, як би вони не зберігалися: у документі, електронній таблиці, каталожних картках, системі управління вимогами чи в іншій формі. Задокументований запис того, про що стейкхолдери домовилися у певний момент часу, «групова пам’ять» – надійніша, ніж пам’ять людини, і нею можна поділитися з тими, хто не був причетним до початкових обговорень.
Специфікація вимог потребуватиме більшої деталізації, якщо у вас не буде можливості часто спілкуватися з користувачами та особами, які приймають рішення. Це трапляється, коли ви передаєте виконання переліку вимог, створеного вашою командою, на аутсорс. Очікуйте, що багато часу піде на пояснення та перевірку того, чи зрозумілі вимоги в таких ситуаціях.
Істина №9: Вимоги можуть бути нечіткими, але продукт – конкретний.
Описати вимоги зі 100% точністю дуже важко. Ви придумуєте щось нове, і ніхто достеменно не знає, яким повинен бути продукт, і що він повинен робити.
Іноді людей влаштовують нечіткі вимоги. Клієнтам може подобатися розмите формулювання, оскільки це означає, що вони можуть згодом переінакшити ці вимоги так, як їм захочеться. Нечіткі вимоги можуть дозволити розробникам будувати те, що вони вважають за потрібне. Все це дуже весело, але це не допомагає вам створювати високоякісні рішення.
В кінці кінців, ви створюєте лише один продукт, і хтось має вирішити, яким він буде. Клієнти, бізнес-аналітики або продакт оунери, які не приймають рішень, змушують розробників так діяти, хоча вони, швидше за все, знають набагато менше про проблему чи бізнес. Точні вимоги поліпшують спільне очікування щодо результату роботи команди.
Істина №10: У вас ніколи не буде ідеальних вимог.
Ніколи не знаєш напевно, чи не пропущено якусь вимогу. Завжди є якісь вимоги (припущення або щось зрозуміле саме по собі), які залишаться незадокументованими. Замість того, щоб у певний момент заявляти про готовність вимог, власне, визначте базис, ряд знімків у часі, які будуть узгодженою основою для подальшої роботи та модифікацій.
Прагнення до досконалості може призвести до «аналітичного паралічу», що може мати зворотний ефект. Стейкхолдери, які «вигоріли» на проєкті, що загруз у проблемах з вимогами, іноді взагалі не бажають долучатися до розробки вимог у наступних проєктах. Це ще більш вірогідний шлях до провалу.
Успіх у бізнесі не залежить від того, наскільки ідеально описані вимоги. По суті, намагайтеся створювати вимоги, які є достатньо хорошими, щоб дозволити команді приступити до дизайну, побудови та тестування з прийнятним рівнем ризику. Найбільший ризик – це необхідність марно переробляти все дорогою ціною. Пам’ятайте про цю практичну мету «достатньо добре» в гонитві за бездоганними вимогами.
Оригінальна стаття – Ten Cosmic Truths About Software Requirements, переклад Тетяна Балабанова, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Оригінальне фото від kjpargeter з сайту www.freepik.com.