Чітка та ефективна комунікація. Все досить просто. Для її досягнення існує багато способів.
Розробка програмного забезпечення частково стосується обчислень, а частково – комунікації. Однак розробка вимог повністю стосується комунікації. Зазвичай ми краще розуміємо технічну сторону створення програмного забезпечення, ніж людський аспект спілкування. Але саме ті учасники команди, які керують діяльністю з вимог, незалежно від їх посад, я називаю їх бізнес-аналітиками (або просто БА) – знаходяться в центрі комунікаційної мережі проєкту (рисунок 1).
БА координують обмін знаннями про вимоги між усіма учасниками проєкту.
Рисунок 1. Бізнес-аналітик координує обмін знаннями про вимоги між усіма учасниками проекту.
На Рисунку 1 видно, що вся комунікація двостороння. Деякі учасники переважно постачають вимоги до проєкту з боку замовника, наприклад, від спонсора проєкту, команди маркетингу, ключових клієнтів або від представників користувачів. Інші ж учасники, які знаходяться з боку розробників та споживають результати процесу розробки вимог (архітектори, дизайнери програмного забезпечення та інтерфейсу користувача, розробники, тестувальники).
БА повинен інформувати всіх учасників про сукупність знань про вимоги, пріоритети, статус та зміни. Кожен може брати участь у перегляді вимог; вони побачать різні типи проблем з різних точок зору. Деякі учасники будуть робити численні висновки, пов’язані з вимогами, які виникають в кожному проєкті. І кожен, хто залучений до цього процесу, повинен надати коментар чи ідею щодо вимог аби допомогти команді досягти та підтримати цілісне розуміння.
До теми: Крос-культурна комунікація за Хофстеде: дані замість припущень
Деякі люди побоюються, що визначення вимог до програмного забезпечення пригнічує креативність, обмежує гнучкість, або ж гальмує зміни, але це не повинно бути так. Справжня мета полягає в тому, щоб переконатися, що потрібні люди мають необхідну, своєчасну та чітко представлену інформацію аби узгодити роботу всіх зацікавлених осіб для досягнення успішного рішення. Простіше кажучи, головна мета розробки вимог – це чітка та ефективна комунікація.
Різні аудиторії, різні потреби
Бізнес-аналітик має важку роботу. Інші учасники будуть повідомляти вимоги словесно. БА також посилатися на документи, як-от джерела бізнес-правил чи інформація про пов’язані продукти. Він повинен оцінити, класифікувати та зафіксувати всю цю інформацію у відповідній письмовій формі. Я кажу письмову, бо бізнес-аналітику необхідно прокомунікувати інформацію назад до джерел для перевірки та тим, хто буде використовувати вимоги у своїй роботі. З огляду на те, що аудиторія має різноманітне походження та словниковий запас, БА мусить ретельно продумати найкращі шляхи для взаємодії з кожним з них. Люди, які отримують знання про вимоги, відрізняються між собою за кількома аспектами:
- Яку інформацію вони повинні бачити?
- Коли їм потрібна ця інформація?
- Скільки деталей їм потрібно?
- Як вони бажають отримувати цю інформацію?
- Як вони хочуть, щоб була організована письмова інформація?
Кожен, хто коли-небудь намагався створити єдиний документ з вимогами, який би містив всю необхідну інформацію для всіх учасників проекту, швидко зрозумів, що це неможливо. Існує багато видів інформації про вимоги: бізнес вимоги, вимоги користувачів, вимоги до рішень, функціональні вимоги, нефункціональні вимоги, обмеження тощо. Бізнес-аналітик зобов’язаний визначити, як передати кожен з типів вимог відповідно до рівня деталізації та організувати її таким чином, щоб вони були зрозумілими для кожної аудиторії.
Щоб не будувати припущень, бізнес-аналітик має поцікавитись у різних груп, яка інформація їм необхідна та як вони хочуть її отримати. Наприклад, розробники та тестувальники мають потребу в деталізації кожної вимоги з якою вони працюють, на відміну від спонсора проєкту, якому ці деталі не важливі. Люди, які хочуть лише загальне уявлення, можуть віддати перевагу зображенням, а не словам, щоб не заглиблюватися в деталі. Спільний репозиторій, такий як засіб управління вимогами, може слугувати в якості основного місця зберігання інформації про вимоги для тих, хто потребує всіх деталей.
Зверність увагу: ВІГЕРСОПЕДІЯ – Комунікація вимог: від голоса замовника до вуха розробника
Для певних наборів інформації корисно використовувати стандартні шаблони, щоб читачі знали, де знайти те, що їм потрібно. Я виявив, що особливо корисними є шаблони для документів про бачення та межі (Vision and scope), документів про випадки використання та специфікацій вимог до програмного забезпечення. Творці документів повинні співпрацювати з одержувачами кожного результату, щоб адаптувати стандартний шаблон, який найкраще задовольнить їхні потреби.
Автори документів вибирають лексику, рівень деталізації та організаційну схему, які мають сенс для них. Але, можливо, їхній вибір не є найефективнішим для деяких одержувачів. Старший системний інженер описав проблему використання мови, яка відповідає основним вимогам аудиторії:
“Виконавець є критично важливим споживачем вимог, оскільки його інтерпретація прочитаного диктує, яким буде продукт. Вимога, написана мовою бізнес-замовника, може бути насичена термінами та процесами, незнайомими для пересічного виконавця. Виконавцю буде складно точно зрозуміти, що саме від нього вимагається. Вимоги часто формулюються мовою бізнес-клієнта, щоб отримати згоду на виконання договору. Переклад цих поглядів на вимоги, зрозумілі виконавцю, є важливим кроком.”
Розгляньте можливість створення глосарію, аби всі учасники проекту однаково розуміли відповідні бізнес-терміни, технічні терміни, абревіатури та акроніми. Глосарій можна використовувати в різних проектах у тій самій галузі застосування, що сприятиме підвищенню узгодженості.
Вибір технік подання інформації
Найбільш очевидний спосіб представлення інформації про вимоги — це природна мова. Однак для великої системи це стає громіздким, незалежно від того, чи ви записуєте вимоги в документі, на індексних картках або стікерах, чи в інструменті управління вимогами. Читачі можуть отримати детальну інформацію про вимоги, але важко візуалізувати загальну картину з усіх цих деталей і побачити, як всі частини поєднуються між собою. Природна мова схильна до двозначності, нечітких слів, які залишають занадто багато місця для уяви читача, та неправильного перекладу. Проте, природна мова є способом спілкування людей, тому писати вимоги таким чином є логічним.
Ви можете писати вимоги, використовуючи різні техніки. Деякі команди використовують випадки використання та списки функціональних вимог. Інші покладаються на історії користувачів, описи функцій та/або приймальні випробування. Метод, який ви обираєте, не має значення, за умови, що техніка досягає мети чіткої та ефективної комунікації з аудиторією.
Корисна стаття: Топ-10 порад для збору вимог
Звичайно, ви не обмежені використанням природної мови. Ви можете доповнювати — хоча й рідко замінювати — письмові вимоги різними представленнями або способами відображення: візуальними моделями, прототипами, дизайном інтерфейсу, таблицями та математичними виразами. Кожен спосіб відображення показує певну частину того, що люди повинні знати про вимоги; поєднання декількох способів відображення забезпечує більш глибоке розуміння. Існують навіть формальні нотації вимог, правильність яких можна довести, хоча вони рідко використовуються, крім як у системах, що мають життєво важливе значення.
Для тих аудиторій, яким потрібен лише загальний огляд, варто зробити акцент на діаграмах, а не на тексті. Давно я відвідував чудовий курс з аналізу та моделювання дизайну, який повністю змінив мій підхід до розробки програмного забезпечення. Діаграми можуть ілюструвати потоки процесів, взаємозв’язки даних, навігацію в інтерфейсі користувача, системні стани та переходи між ними, логіку прийняття рішень тощо. Я з ентузіазмом включив візуальне моделювання до своїх практик розробки.
На моє розчарування, я швидко зрозумів, що жодна діаграма не може показати все, що мені потрібно знати про систему програмного забезпечення. Натомість кожна модель показує частину знань про систему з певної точки зору.
Бізнес-аналітики мають обирати відповідні моделі на основі інформації, яку потрібно бачити їхній аудиторії.
Стандартні словники та нотації мають ключове значення для чіткої комунікації. Ми не можемо працювати разом, якщо не маємо однакового розуміння слів і символів. Один з клієнтів-консультантів колись попросив мене переглянути модель, яку намалював один з їхніх бізнес-аналітиків. Я зрозумів діаграму, але бізнес-аналітик використовував нетрадиційні нотації стрілок. Я не мав уявлення, що означають ці стрілки — не було легенди — або чому вони відрізняються від стандартних стрілок, що використовуються в інших місцях.
Буде цікаво: ВІГЕРСОПЕДІЯ: 15 порад для успіху в аутсорсинговій розробці програмного забезпечення
Методологи розробили численні стандартні системи позначень для малювання аналітичних і проєктних схем, зокрема структурований аналіз (structured analysis), IDEF0(Integration Definition for Function Modeling), уніфіковану мову моделювання (Unified Modeling Language (UML)) та мову моделювання вимог (Requirements Modeling Language (RML)). Я наполегливо рекомендую використовувати такі стандартні моделі. Не варто вигадувати власні системи позначень, якщо ви не дійшли висновку, що не існує жодної моделі, яка б відображала те, що вам потрібно, що малоймовірно.
Вам потрібно буде навчити людей, які бачать діаграми, як читати нотації; легенди на діаграмах, які пояснюють використані символи, можуть допомогти. Схеми мають бути максимально простими – зосередьтеся на чіткій комунікації з аудиторією.
Поговоримо?
Високоякісна розробка програмного забезпечення базується на високоякісних вимогах, отриманих із правильних джерел, виготовлених у зручні форми та повідомлених у потрібний час усім, хто повинен знати. Ефективний бізнес-аналітик володіє багатьма формами комунікації: слуханням, опитуванням, перефразуванням, письмом, моделюванням, презентацією, фасилітацією та читанням невербальних сигналів. Якщо ви виконуєте роль бізнес-аналітика, вам знадобляться всі ці навички, а також мудрість, щоб знати, як і коли їх застосовувати, щоб об’єднати всіх учасників проєкту для досягнення спільної мети.
Оригінальна стаття – The Overarching Goal of Requirements Development, переклад – Юлія Підгайна, ревью – Галина Остапенко. Оригінальне фото з статті автора.