Продовжуючи серію уроків, здобутих з реальних практичних кейсів бізнесаналізу, описаних у першій та другій статтях, пропоную ще шість корисних інсайтів, які я [Карл Вігерс] отримав від досвідчених BA.
Буду радий почути й ваші історії — як успішні, так і не надто приємні – аби взаємний обміном досвідом замінив нам складне сходження по “кривою навчання”.
Дивовижно “стиснутий” дизайн
Будуючи кар’єру в розробці ПЗ я довший час був прихильником створення моделей аналізу та дизайну. Ось приклад, де моделювання ще до написання коду виявилося надзвичайно корисним.
На одному з проектів я моделював роботу фотографічної системи, що створювала єдине зображення з кількох знімків за допомогою восьми обчислювальних процесів. Після якісного етапу збору вимог та їх розбору команда прагнула негайно розпочати програмування. Але ми все ж знайшли час побудувати дизайн-модель — щоб зрозуміти, як будемо реалізовувати рішення. Використали класичні техніки моделювання, зокрема діаграми потоків даних (data flow diagram.)
Моделювання дуже швидко показало, що всі обчислювальні процеси можна згрупувати: перші три етапи, наступні три і заключні два – послуговувались однаковими алгоритмами обробки. Ідентичність алгоритмів не була очевидною з одних лише вимог, однак з точки зору дизайну проблема “стиснулася” з восьми складних наборів розрахунків до трьох.
Якби ми пропустили цей крок, то все одно помітили б дублювання коду — але значно пізніше. Ми зекономили багато часу, виявивши спрощення заздалегідь. Переробити модель завжди простіше й дешевше, ніж переписувати код. Тому я вважаю візуальне моделювання критично важливою складовою бізнес-аналізу та проєктування.
MoSCoW на практиці
Популярний метод пріоритизації вимог — MoSCoW — розділяє вимоги на:
• M – Must have – обов’язково має бути реалізована,
• S – Should have – бажано мати
• С – Could have – можна мати
• W – Won’t have – вимога не буде реалізована у цій ітерації/релізі
Але він не надає критеріїв, за якими вимога потрапляє в ту чи іншу категорію — і це суттєва проблема. На практиці MoSCoW часто перетворюється на інструмент маніпуляції.
Мій консультант-колега описав справжню практику одного зі своїх клієнтів:
Cтатус “M” майже для кожної вимоги доводиться виборювати. Якщо вимога не отримує “M”, її практично гарантовано не реалізують. Хоча задум був у пріоритизації, ті, хто користується цим методом, давно зрозуміли: не можна подавати вимогу, яка не має “M”. Чи розуміють вони різницю між S, C і W? Підозрюю, що ні. Але вони знають, що всі ці категорії фактично означають “не буде зроблено найближчим часом”.
Це не сприяє досягненню справжньої мети пріоритизації — виявити найкритичніші вимоги й визначити, коли їх слід реалізовувати. Тож мені більше подобається підхід із двома осями: важливість та терміновість.
• Must have = важливо та терміново
• Should have = важливо, але не терміново
• Could have = не важливо і не терміново
• Won’t have = може чекати нескінченно довго
Зробити Чарлі щасливим
Невдовзі після приєднання до команди з розробки, що швидко просувається, я попросив нашого UNIX-гуру Чарлі створити email-інтерфейс для системи трекінгу дефектів. Я написав близько десятка функціональних вимог. Чарлі був у захваті — за роки написання скриптів він ніколи не отримував від когось формалізованих вимог.
На жаль, я зволікав два тижні перш ніж надати вимоги. І виявив, що одна з моїх вимог була хибною. Я помітив помилку, тому що 20 тестів, що відображали моє уявлення про систему, суперечили одній вимозі. Мені було ніяково, але я виправив вимогу. Чарлі ще не реалізував її — на щастя. Коли він доставив скрипт, він працював ідеально.
Цей досвід укріпив мою думку: тестування та вимоги нерозривні. Фактично, “тестувати” ви починаєте в момент, коли сформували першу вимогу.
В agile-розробці команди часто пишуть тести (acceptance criteria) замість детальних функціональних вимог. Це нормально: вимоги описують, що створити, тести — як система має поводитися. Але кожен з цих артефактів дає лише один погляд. Я віддаю перевагу написанню і вимог, і тестів під час аналізу. Так помилки знаходяться найшвидше, і зменшується кількість переробок у дизайні та коді.
Таблиця, що краща за текст
Під час рев’ю специфікації одного з клієнтів я побачив групу вимог такого типу:
Text Editor повинен парсити документи формату <format>, що описують закони <jurisdiction>.
Було три можливих значення format, і чотири jurisdiction — у сумі 12 комбінацій. І справді, у документі було 12 вимог. Але одна комбінація була відсутня, а інша — задубльована. Виявити такі помилки у списку з десятків однотипних формулювань — складно.
Ефективніше оформлювати такі “матриці варіантів” у вигляді таблиці. Наприклад:
Editor.DocFormat: Text Editor повинен вміти парсити документи у форматах та юрисдикціях, наведених у Таблиці 1.
Таблиця 1. Вимоги до парсингу документів
У клітинках таблиці містяться лише суфікси ідентифікаторів. Наприклад, зелена клітинка в першому рядку розширюється до:
Editor.DocFormat.3: Text Editor повинен вміти парсити ASCII-документи, що визначають федеральні закони.
Якщо якась комбінація з логічних причин не має відповідної вимоги, у відповідну клітинку таблиці слід поставити N/A (not applicable — не застосовується), як у клітинці, виділеній рожевим кольором. Це значно зрозуміліше, ніж просто пропускати нерелевантну комбінацію в довгому списку, через що читач може задуматися, чому немає вимоги для розбору документів, що містять територіальні закони в нетегованому форматі. Такий підхід також забезпечує повноту набору вимог — якщо кожна клітинка таблиці заповнена, ви знаєте, що нічого не пропустили.
Просто скажіть, що не так
Вимоги до рішення не мають описувати всі деталі дизайну, але повинні чітко окреслити можливості продукту та обмеження, що застосовуються до користувацького інтерфейсу. Якщо обмеження не задокументовані або розробники їх ігнорують, користувачі можуть зіткнутися з труднощами у використанні та отримати досвід, сповнений роздратування.
Нещодавно я намагався повідомити про проблему через форму зворотного зв’язку на сайті. Я отримав помилку: “спеціальні символи не дозволені”. Однак система не повідомила, які саме. Очевидно, що сайт знав, які символи йому не подобаються, адже він їх виявив. Проте, замість конкретної інформації, я бачив лише загальне повідомлення про помилку, що не допомогло мені вирішити проблему.
“Спеціальний символ” — поняття нечітке. Крапка? Дужка? Двокрапка? Зрештою я здогадався, що проблема в лапках. У моєму контексті їх використання було логічним, але сайт їх не приймав.
Щоб розробники могли найкращим чином реалізувати взаємодію користувача з продуктом, BA мають сформулювати конкретні вимоги до юзабіліті, а дизайнер — забезпечувати точні повідомлення про помилки. Неконкретна помилка лише марнує час користувача й викликає обурення.
Скільки ж потрібно специфікацій?
Створення однієї єдиної специфікації або ж – цілої гори user stories, не є практичним підходом для масштабного продукту. Великі проекти з розробки систем часто починають із загальної специфікації, що містить системні вимоги, після чого створюють окремі специфікації до програмного забезпечення і, можливо, апаратного забезпечення.
Приклад 1: Компанія створювала масштабну систему керування процесами на нафтопереробному або хімічному заводі. Загальна специфікація містила 800 системних вимог.системних вимог містила близько 800 високорівневих вимог. Проект було розділено на 20 підпроектів, кожен з яких мав власну специфікацію програмних вимог із 800–900 детальних вимог, похідних від системних. Це призвело до великої кількості документації, але без такої структури проект був би некерованим.
Приклад 2: Інша компанія створювала лише один документ для кожного середньомасштабного проекту, який вони просто називали «Специфікація» (The Spec). Специфікація містила всю відому інформацію про проект: вимоги, оцінки, плани проекту, дизайни, плани якості, тести — усе. Управління змінами та версіями перетворилося на справжній кошмар. До того ж інформація в такому універсальному документі не підходить для різних аудиторій, які мають різні потреби.
Приклад 3: Третя компанія обрала проміжний підхід. Їхні проекти не були дуже великими; кожен можна було описати усього на 40–60 сторінках. Однак деякі члени команди хотіли розділити вимоги на цілих 12 окремих документів: один для пакетного процесу, один для системи звітності та по одному для кожного з 10
звітів. Такий «вибух документів» створює проблеми, бо важко синхронізувати зміни, які впливають на кілька частин рішення.
Приклад 4: Компанія, яка перейшла на гнучку методологію розробки (agile), припинила будь-яке формальне документування; у них взагалі не було специфікацій вимог. Натомість вони створювали user stories для великого проекту на численних стікерах, прикріплених до стін офісу. На жаль, клей на стикерах поступово втратив ефективність. Через кілька місяців стікери, що вже не трималися, могли падати на підлогу, коли хтось проходив повз стіну. Така система управління вимогами виявилася доволі крихкою.
Кращою альтернативою у всіх цих випадках є зберігання вимог у системі управління вимогами (requirements management tool). Такий інструмент особливо корисний для проектів, що планують кілька релізів або ітерацій розробки. Документ з вимогами для будь-якої частини продукту або конкретної ітерації тоді просто формується як звіт із бази даних на основі певних критеріїв запиту.
Залишайтеся з нами: нові історії та інсайти з бізнес-аналізу з’являться у наступних статтях цієї серії. Попередні частини: Частина 1 | Частина 2
Оригінальна стаття – Tales from the Business Analysis Trenches, Part 3 від Карла Вігерса, переклад – Анна Берднік, ревью – Іван Вільчавський. Оригінальне фото з статті.