Білль про права та білль про обов’язки замовників програмного забезпечення допомагають визначити взаємовідносини при розробці вимог.
Найкращі програмні продукти базуються на найкращих вимогах. Якісні вимоги є результатом ефективної співпраці між розробниками та клієнтами, зокрема, реальними користувачами: партнерство. Спільна робота може бути успішною лише тоді, коли всі учасники розуміють, що потрібно для досягнення успіху як їм, так і їхнім партнерам. Бізнес-аналітик (БA), як правило, є ключовою особою, яка повинна налагодити таке партнерство.
У Біллі про права замовників програмного забезпечення (Requirements Bill of Rights for Software Customers) на Малюнку 1 перераховано десять очікувань, які замовники можуть мати щодо взаємодії з аналітиком та командою розробників стосовно діяльності з визначення вимог до проєкту. Слово “ви” в правах та обов’язках відноситься до замовника проєкту з розробки програмного забезпечення.
Оскільки зворотною стороною права є відповідальність, на Малюнку 2 перераховано десять обов’язків, які замовник несе перед БA та розробниками під час процесу формування вимог. Ви також можете розглядати їх як білль про права розробника (developer’s bill of rights).
Малюнок 1. Вимоги Білля про права замовників програмного забезпечення
Малюнок 2. Перелік вимог та обов’язків для замовників програмного забезпечення
Під час запуску проєкту замовник і учасники розробки повинні переглянути ці два списки і провести переговори, щоб дійти згоди. Якщо ці списки не зовсім підходять для вашої організації, змініть їх відповідно до вашої культури. Переконайтеся, що ключові учасники розробки вимог розуміють і приймають свої обов’язки. Таке розуміння може зменшити непорозуміння пізніше, коли одна сторона очікує чогось, чого інша не хоче або не може забезпечити.
До теми: Рекомендації з управління нефункціональними вимогами
Вимоги Білля про права замовників програмного забезпечення
Нижче наведено десять прав, на які можуть розраховувати замовники, коли йдеться про вимоги.
Право #1: Очікувати, що бізнес-аналітики будуть спілкуватися вашою мовою
Обговорення вимог повинно зосереджуватися на потребах і завданнях вашого бізнесу, використовуючи бізнес-лексику. Глосарій – це ефективний спосіб донести бізнес-термінологію до інших членів команди.
Право #2: Очікувати, що BA дізнаються про ваш бізнес і ваші цілі
Взаємодіючи з вами для з’ясування вимог, БA можуть краще зрозуміти ваші бізнес-задачі та те, як система вписується у ваш світ. Це допоможе розробникам створити рішення, яке відповідатиме вашим потребам. Запрошення БA та розробників поспостерігати за тим, як ви працюєте, покаже їм, як рішення вписується в ваш робочий процес і покращує його.
Право #3: Очікувати, що BA будуть фіксувати вимоги у відповідних формах
БA аналізує інформацію, надану зацікавленими сторонами, і ставить додаткові запитання, щоб відрізнити вимоги користувача від бізнес-правил, функціональних можливостей, цілей якості та інших елементів. Результатом цього аналізу є набір вимог, збережених у відповідних формах, таких як документ специфікації вимог до програмного забезпечення або інструмент управління вимогами, а також різні діаграми. Ці вимоги становлять угоду про функції, якості та обмеження рішення. Вимоги повинні бути написані та організовані таким чином, щоб їх було легко зрозуміти.
Право #4: Отримувати пояснення практик вимог і результатів
БA використовує різні практики, щоб зробити розробку вимог ефективною та результативною, а також для представлення знань про вимоги. Він повинен пояснити свої рекомендовані практики та пояснити, яка інформація входить до кожного результату. Якщо БA створює незнайомі діаграми на додаток до текстових вимог, він повинен пояснити мету кожної діаграми, що означають символи і як перевірити діаграму на наявність помилок.
Право #5: Змінити свої вимоги
Ви маєте право вносити зміни до вимог, якщо бізнес розвивається, зацікавлені сторони надають більше інформації або ви ретельніше обмірковуєте те, що вам потрібно. Однак, зміни завжди мають свою ціну. Іноді додавання нової функції вимагає компромісів з іншими функціями або з графіком розробки. Важливою частиною обов’язків БA є оцінка та інформування про наслідки змін. Учасники повинні домовитися про простий, але ефективний процес управління змінами.
Право #6: Очікувати на атмосферу взаємоповаги
Обговорення вимог іноді може розчаровувати або навіть викликати протистояння. Замовники, які беруть участь у розробці вимог, мають право очікувати, що БA та розробники ставитимуться до них з повагою та цінуватимуть час, який вони вкладають в успіх проєкту. Аналогічно, замовники повинні демонструвати повагу до команди розробників, оскільки всі співпрацюють задля досягнення спільної мети – успішного завершення проєкту.
Право #7: Почути ідеї та альтернативи для ваших вимог та їх вирішення
Повідомте БA про те, як ваші існуючі системи не відповідають вашим бізнес-процесам, щоб переконатися, що нове рішення не просто автоматизує неефективні або застарілі процеси. Тобто уникати «переасфальтування коров’ячих доріжок». БA часто може запропонувати вдосконалення бізнес-процесів і нові можливості рішень, які клієнти не передбачали.
Право #8: Описати характеристики, які зроблять продукт простим у використанні
БA запитають про характеристики програмного забезпечення, які виходять за межі його функціональності: його якісні атрибути. Ці атрибути роблять програмне забезпечення простішим, ефективнішим або приємнішим у використанні. Наприклад, користувачі іноді просять, щоб рішення було зручним або надійним. Ці терміни надто суб’єктивні, щоб допомогти розробникам. Замість цього БA має вивчити конкретні характеристики, які для вас означають зручність, або надійність.
Право №9: Почути про способи коригування вимог для прискорення розробки за рахунок повторного використання
Якщо БA знає про існуючі компоненти програмного забезпечення або вимоги, які наближаються до вирішення певних потреб, які ви представили, вони можуть запропонувати способи зміни ваших вимог, щоб розробники могли повторно використовувати ці ресурси. Коригування ваших вимог, коли доступні розумні можливості повторного використання, економить час і гроші.
Право #10: Отримати систему, яка відповідає вашим функціональним потребам і очікуванням щодо якості
Це абсолютне право клієнта. Однак це може статися лише в тому випадку, якщо представники клієнтів чітко повідомлять всю інформацію, яка дозволить розробникам створити правильне рішення, якщо розробники повідомлять вам про варіанти та обмеження, і якщо зацікавлені сторони дійдуть згоди. Клієнти іноді не формулюють пункти, які, на їхню думку, є загальновідомими. Однак підтвердження спільного розуміння в команді проєкту так само важливо, як і висловлення чогось нового.
Буде корисно: Провалений ІТ-проект. Чому змінюються вимоги?
Вимоги Білля про обов’язки замовників програмного забезпечення
Протилежністю праву є обов’язок. Ось десять обов’язків, які мають представники замовника, коли справа доходить до визначення та управління вимогами до своїх проєктів.
Обов’язок #1: Розповісти БA та розробникам про ваш бізнес
Команда розробників покладається на те, що ви зможете ознайомити їх із своєю бізнес-діяльністю та сленгом. БA можуть не знати про знання, які ви сприймаєте як належне. Несформульовані припущення щодо таких знань можуть призвести до проблем пізніше.
Обов’язок #2: Приділяти час, необхідний для надання та роз’яснення вимог
Як і всі, клієнти – зайняті люди. Тим не менш, вам потрібно присвятити час семінарам, інтерв’ю та іншим заходам зі з’ясування та перевірки вимог. Будь ласка, будьте терплячі до ітеративного та інкрементального підходу до розробки та уточнення вимог. Це природа складної людської комунікації і ключ до успіху.
Обов’язок №3: Бути конкретним і точним, надаючи інформацію про вимоги
Є спокуса залишити вимоги розпливчастими та нечіткими, тому що уточнення деталей є нудним і трудомістким процесом. Але в якийсь момент хтось повинен вирішити всі неясності та неточності. Ви – найкраща людина для прийняття таких рішень. В іншому випадку ви покладаєтесь на те, що БA, або розробники вгадають правильно. З’ясуйте сенс кожної вимоги, щоб фахівець з технічного завдання зміг точно її сформулювати і знайти правильне рішення.
Обов’язок №4: Своєчасно приймати рішення щодо вимог, коли їх запитують
БA попросить вас прийняти багато рішень про вимоги: вирішення суперечливих запитів від кількох клієнтів, вибір між несумісними атрибутами якості, встановлення пріоритетів тощо. Клієнти, які мають повноваження приймати такі рішення, повинні робити це негайно, коли їх запитають. Розробники не можуть продовжувати впевнено, доки хтось не прийме ці рішення.
Обов’язок №5: Поважати оцінку розробника щодо вартості та реалістичності вимог
Усі функції програмного забезпечення мають вартість. Деякі функції можуть бути технічно неможливими або занадто дорогими. Розробник може бути носієм поганих новин про доцільність або вартість. Ви повинні поважати це судження, навіть якщо це означає, що ви можете отримати не те, про що просили, у тій формі, про яку ви мріяли.
Обов’язок №6: Визначати реалістичні пріоритети вимог у співпраці з розробниками
Клієнти повинні співпрацювати з БA, щоб встановити пріоритети вимог, що допомагає команді забезпечити максимальну цінність за найменших витрат і в потрібний час. Поважайте рішення команди розробників щодо того, яку частину необхідної функціональності вони можуть вмістити в кожному циклі розробки. Просто зробити кожну вимогу пріоритетною є не реалістично
Обов’язок №7: Переглянути вимоги та оцінити прототипи
Залучення клієнтів до рев’ю — це єдиний спосіб підтвердити, що вимоги повні, правильні та необхідні. БA повинен зробити вимоги доступними для перегляду в керованих фрагментах під час виявлення вимог і протягом циклів розробки.
Щоб краще зрозуміти ваші потреби та дослідити найкращі способи їх задоволення, команди програмного забезпечення іноді створюють прототипи запланованого продукту. Ваші відгуки щодо цих попередніх, часткових або дослідницьких реалізацій надають розробникам цінну інформацію.
Обов’язок №8: Визначити критерії прийняття
Один із обов’язків замовника полягає у визначенні критеріїв прийняття, яким має відповідати продукт, щоб вважати його прийнятним. Такі критерії включають приймальні тести, які оцінюють, чи дозволяє рішення користувачам правильно виконувати певні операції. Гнучкі проєкти значною мірою покладаються на приймальні тести, а не на письмові вимоги, щоб конкретизувати деталі історій користувачів.
Обов’язок №9: Оперативно повідомляти про зміни у вимогах
Зміни неминучі і часто цінні, але чим пізніше в циклі розвитку впроваджуються зміни, тим більший їхній вплив. Повідомте БA, як тільки дізнаєтеся, що вам потрібно змінити вимогу. Щоб мінімізувати негативний вплив змін, дотримуйтесь визначеного проєкту процесу контролю змін. Це гарантує, що відповідні зацікавлені сторони можуть приймати обґрунтовані бізнес-рішення щодо внесення відповідних змін у потрібний час.
Зверніть увагу: 13 типових помилок в роботі бізнес-аналітиків початківців
Обов’язок №10: Поважати процес розробки вимог
Виявлення та конкретизація вимог є великими завданнями. У підході БA до розробки вимог є обґрунтування. Не соромтеся попросити БA пояснити, чому вони запитують певну інформацію або просять вас взяти участь у певній діяльності, пов’язаній з вимогами.
Взаємне розуміння та повага до підходів і потреб один одного значною мірою сприяє налагодженню ефективної співпраці. Погодження прав і обов’язків кожної сторони по відношенню одна до одної закладає основу для успішної взаємодії.
Оригінальна стаття – Forging a Collaborative Customer–Development Partnership, переклад – Олександра Горлович, ревью – Іван Вільчавський. Зображення від Карла Вігерса з оригінальної статті.