Філософія інженерії вимог (Requirements Engineering) у дев’яти принципах. Гайд для бізнес-аналітика

Привіт, мені звати Володимир Скляр, я бізнес-аналітик у компанії Artkai, займаюсь пресейлами, дискавері, вимогами на проєктах та налагодженням внутрішніх процесів. Сьогодні я хотів би звернути увагу ком’юніті на матеріали від International Requirements Engineering Board (IREB) щодо інженерії вимог (Requirements Engineering, RE).

Зокрема у цій статті я хотів би розповісти про позицію IREB відносно інженерії вимог, вивчення якої може підвищити професійний рівень бізнес-аналітика, незалежно від того, плануємо ми надалі отримувати сертифікат IREB або ні.

Вступ: Загальна інформація щодо IREB

Майже всі бізнес-аналітики знають про сертифікацію IIBA щодо знання ВАВОК. Значна менша частина ком’юніті замислюється про сертифікацію IREB, які з 2006-го пропонують схему сертифікації Certified Professional for Requirements Engineering (CPRE). Це значить, що далеко не всі бізнес-аналітики знайомляться з відповідними документами.

CPRE включає три рівні (Рисунок 1): Foundation, Advanced, Expert за двома напрямками, якими є [email protected] (як застосовувати методи RE в аджайл) та безпосередньо RE.

Рисунок 1. Схема сертифікації CPRE від IREB, source

Відповідно до рівнів сертифікації побудовано й структуру матеріалів IREB, яка включає:

  • Handbooks для трьох рівнів;
  • Syllabus для кожного з трьох рівнів;
  • Glossary щодо RE та [email protected];
  • збірник статей різних років під брендом Requirements Engineering Magazine.

Мова у цій статті піде, звісно ж, не про всі доступні документи, а лише про фрагмент з Handbook for the CPRE Foundation Level according to the IREB Standard, розділ 2 — «Fundamental Principles of Requirements Engineering». Йдеться про загальні принципи RE. Здається, це саме те, що слід пам’ятати бізнес-аналітику кожного разу при прийнятті рішень, свого роду — місія або компас професійної діяльності. Принципи RE можна застосовувати до всіх задач, активностей та практик бізнес аналізу.

Далі йде моє осмислення цього матеріалу, для чого кожен з принципів проаналізовано за схемою:
пояснення принципу → розгляд інструментів для практичного застосування цього принципу → кейс, який поясняє застосування принципу.

Принцип #1. Ціннісна орієнтація: вимоги — це засіб досягнення мети, а не мета сама по собі (Value orientation: Requirements are a means to an end, not an end in itself)

Пояснення

Цінність вимоги — це вигода, тобто ступінь вкладу у створення успішного продукту (тут і далі використовуємо термін «продукт» у сенсі програмний продукт, який може бути синонімом програмного забезпечення або програмної системи) та зниження ризиків коштовних помилок, що призводять до переробки продукту або до критичної ситуації при застосуванні продукту, мінус вартість виявлення, валідації, документування та керування для вимоги. Це може бути також визначено через імовірне зниження витрат щодо розробки та функціонування продукту.

Таким чином, RE має підтримувати баланс між вигодою від управління вимогами та вартістю цього процесу. Економія на RE підвищує ризики у майбутньому, але економічний ефект від RE непрямий та його складно точно виміряти. У загальному випадку, оптимальні затрати на RE залежать від проєкту та від ризику, який згодні прийняти учасники проєкту, тобто, чим більший ризик ми готові прийняти, тем меншими можуть бути зусилля щодо розробки вимог — та навпаки.

Інструменти для практичного застосування

Критичність кожної вимоги може бути оцінена з точки зору впливу на продукт (або впливу, до якого призведе втрата цієї вимоги) та важливості для стейкхолдерів. Таким чином, отримуємо матрицю «два на два» (Рисунок 2). За допомогою такої матриці можна виконати позиціонування вимог та визначити, чи дійсно потрібний на проєкті бізнес-аналітик. Для нескладного типового продукту можна взагалі обійтися без написання вимог.

Рисунок 2. Матриця «Влада cтейкхолдера — Вплив вимоги»

Щодо оцінювання впливу вимог, необхідно враховувати наступні фактори впливу:

  • зусилля, необхідні для визначення вимоги;
  • особливість вимоги з точки зору того, наскільки ця вимога сприяє успіху системи в цілому;
  • ступінь спільного розуміння між стейкхолдерами та розробниками та поміж самими стейкхолдерами;
  • наявність референсних продуктів, які можна вивчати як приклад або частково адаптувати;
  • тривалість циклу зворотного зв’язку щодо виявлення помилки у вимогах;
  • тип відносин між клієнтом і постачальником;
  • необхідність врахування нормативних вимог.

Кейс

На одному з проєктів в одній з компаній, з якою я співпрацював у минулому, відбувся такий випадок. Був досить заможний замовник, але без належного бачення свого майбутнього продукту та майже без процесів керування цим продуктом. Наша команда намагалась розробити вимоги до продукту та зробити UI, щоб найшвидше його узгодити та потім прискорити розробку.

Майбутня система мала бути великою, ми збирали вимоги через довгі інтерв’ю та обговорення, робили демо, отримували нові інпути та інсайти від стейкхолдерів, переробляли те, що було раніше зроблено, та рухались далі до наступного демо — і так декілька місяців.

На якомусь етапі цей процес де-факто втратив цінність для клієнта, тому що це багатоітераційне обговорення опцій майбутнього продукту ніяк не наближало до створення самого продукту. Хоча ми робили та змінювали все за бажанням клієнта, втілюючи в життя всі дрібниці, одного дня клієнт призупинив нашу співпрацю.

Цей випадок як раз демонструє розробку вимог заради самих вимог, без врахування їхньої цінності. Треба було спочатку оцінити вплив та важливість кожної з вимог та сконцентруватись на найкритичніших. Замовник не відчував прогресу та не розумів, як його гроші працюють на продукт. Ще одним з вивченим уроків стала неприпустимість слідування неефективним процесам замовника.

Принцип #2. Стейкхолдери: RE — це задоволення побажань та потреб зацікавлених сторін (Stakeholders: RE is about satisfying the stakeholders’ desires and needs)

Пояснення

Здається, що цей принцип не потребує довгого пояснення, бо усі канони бізнес-аналізу та управління проєктами кажуть про важливість та необхідність роботи зі стейкхолдерами, тому що стейкхолдери є джерелом вимог і, крім того, для RE є критичним залучення правильних людей на релевантні ролі.

Інструменти для практичного застосування

Головним інструментом є добре відома матриця стейкхолдерів «Влада — Зацікавленість» або «Влада — Вплив». Для полів матриці з багатьма близькими друг до друга стейкхолдерами можуть створюватись персони, що також є досить відомим інструментом. Ще можна поєднати матрицю стейкхолдерів з матрицею «Влада cтейкхолдера — Вплив вимоги», яку було розглянуто в розділі Принцип #1.

Матриця стейкхолдерів має бути присутня на будь-якому проєкті. Якщо бізнес-аналітик з’являється на проєкті, де відсутня матриця стейкхолдерів, то однією з перших справ є складання такої матриці.

Кейс

Існує багато кейсів, які демонструють, що співпраця зі стейкхолдерами є необхідною умовою успіху проєкту та навпаки.

Щодо прикладу, який був розглянутий для Принципу #1: ще однією помилкою команди там було неврахування влади та зацікавленості стейкхолдерів, тому що всі очікування усіх учасників з боку замовника оброблялись та імплементувалися однаково, без належної пріоритезації.

Принцип #3. Спільне розуміння: успішна розробка систем неможлива без спільної основи (Shared understanding: Successful systems development is impossible without a common basis)

Пояснення

Оскільки продукт розробляє команда із залученням стейкхолдерів, то оптимальною є ситуація, коли кожен з учасників проєкту має однакове розуміння проблем, що вирішуються, та вимог, що з цих проблем випливають. Таке розуміння може бути двох типів:

  1. явне (explicit) спільне розуміння, яке досягається шляхом ретельного виявлення, документального оформлення та узгодження вимог;
  2. неявне (implicit) спільне розуміння, яке ґрунтується на спільних знаннях про потреби, бачення, контекст тощо.

Для оптимізації ресурсів щодо формування спільного розуміння необхідно сконцентруватись на найбільш релевантних речах, більшість з яких знаходяться у контексті продукту (див. Принцип #4). Також для оптимізації ресурсів необхідно досягнення балансу між використанням явного та неявного розуміння. Для цього аналізують так звані активатори (enablers) та перешкоди (obstacles) спільного розуміння. До активаторів відносять:

  • знання домену;
  • наявність стандартів для певних доменів;
  • досвід попередньої успішної співпраці між виконувачем та замовником, збіг їхньої загальної культури та цінностей;
  • взаємна довіра учасників проєкту, яка базується на інформованості, тобто не є сліпою;
  • існування аналогічних продуктів, які доступні для аналізу учасниками проєкту.

До перешкод відносять:

  • відносини між постачальником та покупцем, засновані на взаємній недовірі;
  • нормативні обмеження;
  • залучення великих та різноманітних команд;
  • висока плинність кадрів серед залучених фахівців.

Чим менша ймовірність і вплив помилкового спільного розуміння і чим більша перевага активаторів над перешкодами, тим більше можна покладатись на неявне спільне розуміння. І навпаки, чим менше активаторів і чим більше перешкод існує, і чим вищий ризик і вплив помилкового спільного розуміння вимог, тим більше таких вимог потрібно чітко специфікувати та валідувати.

Інструменти для практичного застосування

До інструментів підтримки спільного розуміння можна віднести наступні:

  • глосарії, що розробляються та підтримуються в актуальному стані з метою уникнути помилок і непорозумінь щодо використовуваної термінології;
  • дослідницькі прототипи продукту, які використовуються для створення спільного розуміння та для уточнення або валідації вимог;
  • існуючі референсні продукти, які у цьому випадку також виконують роль своєрідного прототипу;
  • валідація вимог (див. Принцип #6).

Для всіх цих інструментів важливими є швидкі цикли зворотного зв’язку, які забезпечують зниження впливу помилкового спільного розуміння.

Кейс

Слід зазначити, що навіть при чудовому спільному розумінні деякі важливі вимоги можуть бути втрачені, тому що ніхто їх не розглядав. Є багато веселих та сумних історій на цю тему. IREB, наприклад пропонує такий комікс (Рисунок 3).

Рисунок 3. Приклад правильного та помилкового спільного розуміння, source

Для прикладу, що розглядається, є певне правильне спільне розуміння, як явне, так і неявне. Але, наряду з цим, маємо помилкове неявне спільне розуміння щодо матеріалу гойдалки, а також втрачену вимогу щодо міцності гілки під гойдалку, яку слід було сформулювати замість нерелевантного неявного спільного розуміння того, що гойдалка має бути прикріплена до гілки.

Принцип #4. Контекст: систему не можна зрозуміти, коли вона в ізоляції (Context: Systems cannot be understood in isolation)

Пояснення

Для пояснення того, що ж таке контекст, IREB застосовує наступну діаграму (Рисунок 4).

Рисунок 4. Система, контекст та обсяг, source

Контекстом є частина середовища системи (продукту), яка має значення для розуміння системи та вимог до неї. Контекст системи знаходиться поміж межею системи та межею контексту. Межа контексту відділяє контекст системи від тих частин домену, які не мають відношення до системи і які не потрібно враховувати під час розробки вимог.

Межа системи проходить між системою та навколишнім контекстом, й обмежує систему з точки зору її імплементації та розгортання. Оскільки спочатку проєкту межі системи можуть бути нечіткими, то завданням RE є уточнення меж системи, визначення обсягу проєкту (scope) та зовнішніх інтерфейсів системи в її контексті.

Однак, недостатньо враховувати тільки вимоги в межах системи та зовнішні інтерфейси. Тому є декілька причин. По-перше, зміни тієї частини контексту, що входить до обсягу, можуть вплинути на вимоги. Наприклад, коли йдеться про автоматизацію бізнес-процесу, цей процес може бути змінений для його кращої адаптації, тобто зміниться контекст, і це вплине на обсяг та вимоги.

По-друге, у контексті можуть існувати явища та об’єкти реального світу, які система повинна відстежувати або контролювати, тобто це також є входом для вимог.

По-третє, можуть існувати вимоги, які залежать від фізичних об’єктів, і відповідати їм можна тільки, якщо виконуються вимоги до цих фізичних об’єктів. Наприклад, будь-яка система моніторингу або керування буде коректно працювати тільки коли фізичне обладнання знаходиться у справному стані.

Таким чином, бізнес-аналітику необхідно зберегти баланс між надмірною деталізацією нерелевантного контексту та ризиком упустити вагомі деталі контексту, які впливають на вимоги.

Інструменти для практичного застосування

Головним інструментом аналізу контексту та меж системи є контекстна діаграма (context diagram). Рисунок 5 надає приклад такої діаграми для системи керування бібліотекою.

Рисунок 5. Контекстна діаграма для системи керування бібліотекою, source

Додатком до контекстної діаграми може виступати верхньорівневий опитувальник, за допомогою якого розглядаються не тільки межи та інтерфейси системи, але й наступні питання щодо контексту:

  • якщо можуть відбутися зміни в контексті, як вони вплинуть на вимоги до системи?
  • які вимоги в контексті реального світу актуальні для системи?
  • як можна адекватно відобразити актуальні вимоги реального світу у вимогах до системи?
  • які припущення щодо контексту мають виконуватися, щоб система працювала належним чином та відповідала вимогам реального світу?

Кейс

Роздивимось кейс на прикладі діаграми, що наведена на Рисунку 5. Відмітимо, що ця контекстна діаграма представляє рішення (solution) безвідносно до того, чи виконуються певні функції офлайн або онлайн. Це відноситься, наприклад до постачальників книг, які можуть бути як електронні, так й паперові. У системі можуть змінюватися бізнес-процеси, наприклад, представлена система не надає деталізацію щодо особливостей процедури постачання електронних документів.

Для врахування цього, наприклад, може бути визнано доцільним розділити Book Database на дві частини відповідно до електронних та паперових носіїв. Це змінить контекст системи та, своєю чергою, вимоги до системи.

Принцип #5. Проблема, вимога, рішення: тісно переплетена трійка (Problem, requirement, solution: An inevitably intertwined triple)

Пояснення

Будь-яку ситуацію, в котрій люди не задоволені тим, як вони щось роблять, можна розглядати як виникнення проблеми. Щоб усунути цю проблему, може бути розроблена соціотехнічна система, або ця проблема може бути вирішена якимось нецифровим шляхом. Необхідно врахувати вимоги до рішення, щоб воно могло ефективно усувати проблему. Вказувати вимоги немає сенсу, якщо немає проблеми або якщо рішення не буде розроблено.

Проблеми, вимоги та рішення можуть переплітатися різними способами, наприклад:

  • ієрархічне переплетення: при розробці великих продуктів з багаторівневою ієрархією вимоги верхнього рівня ведуть до проєктних рішень верхнього рівня, які, своєю чергою, впливають на вимоги нижнього рівня, які ведуть до проєктних рішень нижнього рівня тощо;
  • технічна можливість реалізувати: визначення вимог, які не можна імплементувати є неефективним, однак оцінити реалізацію вимоги можна лише під час вивчення технічних рішень;
  • валідація: прототипи, які є засобом перевірки вимог, своєю чергою є частковими рішеннями проблеми;
  • прихильність щодо рішення: різні стейкхолдери можуть бажати різних рішень для певної проблеми, внаслідок чого вони вказують різні та суперечливі вимоги.

Однак, попри взаємозв’язок проблем, вимог і рішень, задачею RE є відокремлення вимог від рішення.

Інструменти для практичного застосування

Такими інструментами можуть бути техніки, що дозволяють відокремити вимоги від рішення, наприклад, контекстна діаграма, яка була розглянута у Принципі #4. Ще одним таким інструментом є Value Stream Mapping (Рисунок 6).

Рисунок 6. Value Stream Map для рішення з продажу автомобілів, source

Кейс

Припущення, що це майбутнє рішення обов’язково буде лише цифровим, не є коректним. Хорошою практикою з відокремлення рішення від вимог є діаграма Value Stream Map, приклад якої наведений на Рисунку 6.

Рішення включає три етапи: тест-драйв, угода щодо покупки автомобіля та постачання автомобіля власнику. Кожен з етапів включає набір активностей, які можуть бути втілені як в онлайн, так і в офлайн-форматі.

Принцип #6. Валідація: невалідовані вимоги є марними (Validation: Non-validated requirements are useless)

Пояснення

Коли продукт розроблений та розгорнутий, він має задовольняти бажання та потреби стейкхолдерів. Однак, виконувати таку перевірку у самому кінці розробки є дуже ризикованим. Щоб контролювати ризик незадоволення стейкхолдерів з самого початку, валідація вимог має розпочатися ще коли ці вимоги виявляють та документують. Бачення процесу валідації з боку IREB представлене на Рисунку 7.

Рисунок 7. Процес валідації вимог, source

У загальному сенсі, під валідацією розуміють процес підтвердження того, що компонент (система, продукт або його частина) відповідає потребам стейкхолдерів. Щодо RE валідація — це процес підтвердження відповідності задокументованих вимог потребам стейкхолдерів, тобто, підтвердження того, що вимоги було документовано коректно. Валідація є важливою складовою RE, тому що специфікація вимог набуває цінності лише після її валідації.

IREB рекомендує наступні критерії успішної валідації вимог:

  • побажання та потреби стейкходерів належним чином покрито вимогами;
  • стейкходери досягли згоди щодо вимог, тобто конфлікти вирішені, а пріоритети встановлені;
  • вимоги реального світу та припущення домену (Принцип #4) є обґрунтованими, тобто ми можемо очікувати, що ці припущення можуть бути виконані під час розгортання та експлуатації продукту.

Також при валідації вимог необхідно враховувати наступні аспекти:

  • залучення найбільш компетентних стейкхолдерів;
  • відділення ідентифікації помилок від їх виправлення;
  • залучення мультідисциплінарної команди для виконання валідації з різних точок зору;
  • повторення валідації на різних етапах розробки продукту.

Інструменти для практичного застосування

IREB класифікує методи валідації вимог згідно трьох категорій: техніки огляду (review techniques), вибіркова розробка (sample development) та дослідницькі техніки (exploratory techniques). Перші дві категорії є статичними, тобто вони виконуються без роботи програмного продукту. Дослідницькі техніки є динамічними, тому що вони фокусуються на поведінці продукту при його функціонуванні.

Серед технік огляду розрізняють неформальні та формальні. При неформальному рев’ю автор відправляє документ для аналізу рецензентам, при цьому процедура огляду, строки, критерії огляду та обробка коментарів проходять у довільної формі. Це може добре працювати для проміжних версій документів, але для релізу специфікації вимог кращим рішенням є формальний огляд.

Для формальних оглядів робочі процедури є регламентованими. Розрізняють два типи формальних оглядів, покрокове проходження (walkthrough) та інспекції (inspections). Суть покрокового проходження полягає в тому, що автор специфікації вимог крок за кроком пояснює її зміст аудиторії в інтерактивній сесії. Учасники рев’ю можуть коментувати, виявляти недоліки та пропонувати альтернативи. Такий підхід краще використовувати на ранній стадії проєкту для обговорення можливості реалізації певного концепту або при передачі специфікації вимог іншій стороні. Крім того, покрокове проходження може бути частиною спринтів.

Виконанням інспекції керує модератор, у процесі беруть участь інспектори, а автор документа виступає у ролі слухача, який, за необхідності, дає пояснення. Специфікація вимог може перевірятись на відповідність попередньо узгодженим цілям та критеріям, стандартам та регулюючим нормам, аспектам якості тощо. Результати інспекції мають бути задокументовані. Ця форма валідації може використовуватися для прийняття рішення про перехід до наступної фази або ітерації розробки продукту.

Під час вибіркової розробки, команда проєкту намагається на підставі документованих вимог створювати програмні артефакти (дизайн, код, архітектуру, тестові кейси, керівництва тощо). Оскільки сам продукт при цьому не працює, це також є статичною валідацією. Під час такої розробки може бути виявлено помилки, нечіткість вимог, упущення, неузгодженості та інше.

Дослідницькі техніки валідації об’єднують у собі прототипування, A/B тестування, альфа і бета-тестування.

Кейс

Я думаю, що багато колег стикалися з такою ситуацією, коли валідації вимог на проєкті та у спринтах не приділяється належна увага. З формальної точки зору, ПМ та БА щось спитали у розробників, ті відповіли, що вимоги зрозумілі, але насправді їх уважно ніхто не читав. Це призводить до зниження ефективності розробки, коли мало хто розуміє, де баг, а де фіча.

Виходом з такої ситуації є проведення на регулярній основі діяльності з requirements refining/grooming, як невід’ємної частини спринту. Це може бути проведено, наприклад, у форматі «3 amigos» за участю бізнес-аналітика, розробника та тестувальника.

Принцип #7. Еволюція: Змінення вимог не є проблемою, це звичайна ситуація (Evolution: Changing requirements are no accident, but the normal case)

Пояснення

Кожна технічна система еволюціонує. Потреби, бізнес та технічні можливості постійно змінюються. Як наслідок, вимоги, які повинні задовольняти потреби, підтримувати бізнес і використовувати технічні можливості, також змінюються. А незмінні продукти поступово втрачають свою цінність.

Вимога може змінитися в процесі, коли виявляються інші вимоги, коли продукт знаходиться у розробці, або коли він використовується. До причин, які призводять до змін вимог, відносяться, наприклад:

  • зміни у бізнес-процесах;
  • зміни на ринку через конкурентів, які випускають нові продукти;
  • зміни пріоритетів у стейкхолдерів або виявлення недоліків під час валідації вимог;
  • зміни у технологіях;
  • зворотній зв’язок від користувачів;
  • виявлення помилок у вимогах або у припущеннях щодо контексту.

Таким чином, розробка вимог спонукає балансувати між двома, здавалося б, суперечливими діяльностями:

1) дозволяти змінювати вимоги, тому що спроби ігнорувати еволюцію вимог були б марними;
2) зберігати вимоги стабільними, тому що без певної стабільності у вимогах вартість змін може стати непомірно високою.

Інструменти для практичного застосування

Інструментом втілення змін у вимоги є процес керування зміненням (Change Control) (див. Рисунок 8), який документується через запит на змінення (Change Request).

Рисунок 8. Процедура керування зміненнями, source

При керуванні змінами необхідно сфокусуватися на трьох головних аспектах:

  • аналізі впливу через оцінювання усіх можливих ризиків, які тягне за собою запропоноване змінення;
  • авторизація внесення змінення;
  • керування внесенням змінення та огляд результатів.

Виходячи з цього, Change Request може мати наступну структуру:

  • перелік вимог, на які впливають зміни;
  • роль та ім’я ініціатора змін;
  • етап проєкту, на якому вносяться зміни;
  • тип змін у сенсі того, на що вони впливають (обсяг, розклад проєкту, процедури проєкту, дизайн, код, тести, документація тощо);
  • статус запиту (наприклад, відхилений, схвалений або відкладений);
  • дати подання та зміни статусів запиту;
  • опис змін та їх впливу.

Кейс

У загальному випадку, процедура керування зміненням охоплює усі можливі ситуації, але ця процедура може бути досить бюрократичною та витратною. Хотілось би проілюструвати, як керування зміненням може бути підлаштовано під поточні потреби.

На одному з проєктів наша команда на стадії розробки дизайну постійно отримувала запити на доповнення функціонала продукту, розробка якого на той час ще не була детально оцінена. Таким чином, внесення змін торкалось, більшою мірою, доповнення вимог та їх аналізу на несуперечливість. Аналіз впливу був дещо скороченим, тому що не треба було змінювати дизайн, а треба було лише доповнювати його, а щодо розробки, то вона ще не почалась.

Тому, керування змінами вилилось у ведення логу з фіксацією запитів від замовника. Формально це зменшувало обсяг дій за процедурою, яка функціонувала у компанії, але деякі ресурси було збережено без втрати якості вимог.

Принцип #8. Інновації: Того, що було раніше, вже недостатньо (Innovation: More of the same is not enough)

Пояснення

Давати замовникам точно саме те, що вони хочуть, означає втрачати можливість робити речі краще, ніж вони були раніше. Тому при виявленні вимог недостатньо лише зафіксувати побажання стейкхолдерів. Налагоджені процеси RE базуються на інноваціях та виходять за рамки того, що кажуть стейкхолдери. Це дозволяє не просто задовольнити стейкхолдерів, але й зробити їх щасливими та захопленими. Водночас треба зберігати баланс, уникати пастки сліпої віри, що виконавці знають все краще, ніж замовники.

З одного боку, RE формує інноваційні системи, прагнучи до нових функцій і простоти використання. З другого боку, RE формує загальну картину, досліджуючи разом зі стейкхолдерами, чи існують якісь проривні способи виконувати функції, що призводять до широкомасштабних інновацій.

Інструменти для практичного застосування

Інструментами втілення інновацій є техніки виявлення вимог. Вони добре відомі, але цікаво подивитись, яким технікам віддає перевагу IREB, адже це:

  • опитування: інтерв’ю та опитувальники;
  • співпраця: воркшопи та колективний збір вимог (crowd-based RE);
  • спостереження: польові спостереження та учнівство;
  • вивчення артефактів: системна археологія (витягування вимог з існуючих систем), аналіз зворотного зв’язку від користувачів продукту або його прототипу, повторне використання вимог.

Кейс

IREB з приводу цього принципу пропонує кейс, який є достатньо типовим, тож подивимось на нього. Страхова компанія хоче оновити систему звітності для своїх агентів. Найчастіше використовуваним звітом є таблиця з багатьма стовпцями, яка більша за ширину екрана на лептопах агентів, таким чином, звіт потрібно прокручувати. Крім того, компанія планує замінити лептопи на планшети. Стейкхолдери хочуть надати можливість масштабувати звіт за допомогою додаткових кнопок.

Якщо бізнес-аналітик почне ставити питання, то може виявитись, що тільки невелика кількість стовпців у звіті використовується кожного разу, а решта або використовується лише в особливих випадках, або може бути зовсім видалена зі звіту, якщо адаптувати правила звітності, які компанія також планує змінити.

Крім того, застосування жестів керування сенсорним екраном планшета замість кнопок полегшить масштабування звіту. Таким чином, інноваційні вимоги до звіту можна задокументувати як:

1) звіт має містити ту саму інформацію, що й поточна система за вирахуванням вилучених стовпців;
2) коли звіт відкрито, тільки декілька важливих стовпців відображаються на повну ширину, тоді як інші стовпці згорнуті до мінімальної ширини;
3) згорнутий стовпець можна розгортати і згортати, торкнувшись його заголовка.

Принцип #9. Систематична та дисциплінована робота: RE неможливо виконувати без цього (Systematic and disciplined work: We can’t do without in RE)

Пояснення

RE — це не стільки мистецтво, скільки технічна дисципліна, яка вимагає систематичного мислення та систематичних дій. Однак не існує ні універсального процесу RE, ні універсального набору практик RE, які б добре працювали в кожній конкретній ситуації або принаймні в більшості ситуацій. Тому, IREB сформував наступні рекомендації щодо системного підходу до RE:

  • налаштуйте процес RE, який добре підходить для поточної проблеми та добре поєднується з процесом, який використовується для розробки продукту;
  • з набору доступних технік та практик виберіть ті, які найкраще підходять для даної проблеми, контексту та робочого середовища;
  • завжди аналізуйте корисність та застосовність технік та практик для певного проєкту, навіть якщо вони успішно застосовувались раніше у попередній діяльності.

Інструменти для практичного застосування

Оскільки цей принцип є верхньорівневим та узагальненим, він має на увазі усі ті інструменти, що було розглянуто для попередніх принципів.

Кейс

Аналогічне правило стосується і кейсів, всі описані вище кейси демонструють дійсний принцип.

Висновки

IREB випускає дуже ємні матеріали, кожна сторінка котрих містить корисну інформацію з найкращих практик RE та бізнес-аналізу.

Для мене в наведених принципах, мабуть, найцікавішим було побачити, що вся наша робота — це, багато в чому, баланс та оптимізація, бо 9 принципів вимагають від нас дотримання відповідних 9 видів балансу. Тому додам у підсумку, що окрім використання інструментів, ще треба дотримуватися балансу

9 видів балансу

Принцип 1. Ціннісна орієнтація — баланс між вигодою від наявності вимог та вартістю процесу RE.

Принцип 2. Стейкхолдери — баланс між впливовими та зацікавленими стейкхолдерами.

Принцип 3. Спільне розуміння — баланс між використанням явного (яке досягається шляхом документування вимог) та неявного (яке ґрунтується на спільних знаннях) спільного розуміння вимог всіма учасниками проєкту.

Принцип 4. Контекст — баланс між надмірною деталізацією нерелевантного контексту та ризиком упустити вагомі деталі контексту, які впливають на вимоги.

Принцип 5. Проблема, вимога, рішення — баланс між відокремленням вимог від рішення та взаємозв’язком проблем вимог та рішень.

Принцип 6. Валідація — баланс між вигодою від валідації щодо виявлення проблем у вимогах та вартістю процесу валідації.

Принцип 7. Еволюція — баланс між еволюцією та стабільністю вимог.

Принцип 8. Інновації — баланс між втіленням інновацій та консерватизмом.

Принцип 9. Систематична та дисциплінована робота — систематичне використання всіх виявлених типів балансу.

Мені ці принципи допомагають орієнтуватись у повсякденній роботі, можливо, вони допоможуть й кому-небудь з читачів.

👍ПодобаєтьсяСподобалось17
До обраногоВ обраному13
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Хороша оглядова стаття IREB.
Ще доречі розглядають психологічни моделі взаємодії стейкхолдерів в випадку з power-impact матрицею, коли відповідно зміна вимог є компенсаторною потребою та конфліктом транзакції по ТА. Жарти про Драматичні Трикутники Стейкхолдер-Менеджер-Команда давно вже не жарти, та відповідно стало модно закупати відалені псих консультації в рамках якогось типового CBT. То має дуже спірні результати, як й будь які колективні сессії.

якась нетривіальна тема) а можна лінки для ознайомлення?

Та, варто почитати Транзактний Берна, та відповідно визначення погранички для DBT / CBT. Бо CBT прирівнює BPD до EUPD, що некорректно за визначенням BPD. Відповідно навіть на quora розводять trash talk’и з цього приводу... Нажаль зазвичай в академ колах прийнято ігнорувати попередні дослідження, та відповідно каверкати визначення для кращої монетизації — створювати культ особистості, бо по іншому грошей не заробиш.

З практичної точки зору — більшість проявів Workplace Deviance на пост-радянському ринку частіш є проявамі BPD.

Та, варто почитати Транзактний Берна, та відповідно визначення погранички для DBT / CBT. Бо CBT прирівнює BPD до EUPD, що некорректно за визначенням BPD. Відповідно навіть на quora розводять trash talk’и з цього приводу... Нажаль зазвичай в академ колах прийнято ігнорувати попередні дослідження, та відповідно каверкати визначення для кращої монетизації — створювати культ особистості, бо по іншому грошей не заробиш.

З практичної точки зору — більшість проявів Workplace Deviance на пост-радянському ринку частіш є проявами BPD.

По трикутниках — то до Карпмана (розвиток напряму Берна).

Для роботи в командах відповідно треба розглядати Трикутник Переможця, та TED.

Компанії мають брати ці моделі як відповідну oснову для Конвенції Конструктивної Комунікації Співробітників.

p.s. CBT вже частково вважають психокультом... в «деяких» країнах, бо часто туди засовують езотерику, коли не треба, особливо усілякий new age.

На мою особисту думку RE IREB більш зрозумілий, «стрункий», корисніший і таке інше ніж BA IIBA. Звістно RE це лише частина BA, BА набаго ширший і може взагалі не торкатись IT/IT systems.
В BABOK дуже загралися з теорією і «натягуванням» її на якість «шестикутники» і таке інше. Тобто overkill інформації.
Стосовно RE — я би точно рекомендував (ознайомитись, не обов’язково сертифікуватися) всім людям що працюють в IT, не тільки BA та PO, а всім — QA, розробникам, архітекторам, PM, PdM, і навіть DevOps. Просто для того щоб мати трохи культури (та поваги) до вимог (requirements).
Дякую Володимир за популяризацію RE!

Едуард, дякую за підтримку, приємно зустріти однодумця

Отличная статья как раз в тему подготовки к экзамену по Foundation Level👍 Спасибо автору!

спасибо, успехов на экзамене 🙏

Речі цікаві, але як на мене все це (і більше) покрито в BABOK, ну і відповідних екзаменах. Чи несе щось принципово нове ця філософія для спеціалістів, які рухаються в руслі, накресленому IIBA?

P.S. Статтю такого розміру добре було б розбити на частини, чи приховувати деякий контент під кнопкою «читати більше» (не знаю, чи доступна така на ДОУ).

Дякую, це як спонукання ще раз уважно передивитись ВАВОК
Якщо принципово, мабуть це все так або інакше є у ВАВОК
А ось щодо форми самого викладення, конкретики та стислості, саме таких принципів у ВАВОК не має. І це стосується не тільки цих принципів, також й інших розділів, наприклад, підходів IREB до документування вимог
Але це, скоріш, справа смаку, ще один погляд на проблему ВА, але більш прагматичний
Щодо формату викладення, так, спойлери (collapsed text) у тексті мають сенс, але, як я розумію, на ДОУ вони не підтримуються

Аффтар решил «утопить» читателя в таком количестве условностей, что это читать просто боль! Своими «девизами» и новыми-старыми идеями, такое впечатление что пишут не для донесения сути а показать какой я менеджерский-менеджер. Статья полный ТРЕШ!

Уважаемый тролль, видно, вам понравилась статья, раз зацепило)
но про содержание статьи в вашем гениальном комменте ничего нет, ведь вы пишете о себе
я понимаю вашу боль, типа «маргиналы пишут статьи, а у меня, великого, ресурса на это нет, а то бы написал бы ого-го!»
на самом деле ТРЕШ — это называть себя сео несуществующей компании и биться в истерике от безуспешных попыток собрать хотя бы $10 на никому не нужный статрап. а ведь не дадут)

Владимир далее, научитесь выражать свои мысли, а не писать «условное гавно» через гугл переводчик, данный сайт о ТЕХНОЛОГИЯХ а не о «высерах» которые плодят «эфективные менегера» которых в случае проблемм просто выставляют на мороз:)

Мои действия не требуют комментариев человека который не в состоянии трезво оценивать критику и думать о том про что он пишет в публичном пространстве. Заметте я вас не обзывал и не оскорблял, троли и протие сказочные единороги живут в сознании человека который не в состоянии создать ничего, видимо точные науки не ваше, вот и в менеджеры подались.

А про профессиональную деятельность давайте опустим, вы же успешный наемный галерный раб, а что кому нужно судить не вам, про 10ки тузы и ваше 21 :) число! Хорошего дня!

ДОУ вряд ли поможет вашей неудовлетворенности собой и жизнью, здесь это не лечат. если захотите, попробую помочь найти для вас хорошего специалиста

Підписатись на коментарі