Уроки, здобуті з робочого досвіду, навчають нас як того, що слід робити, так і того, чого робити не варто.
Кожен, хто присвятив час практиці певної дисципліни, накопичує досвід і історії, які підсилюють його майбутні можливості та результативність. Менш болісно вчитися на чужому досвіді, ніж робити кожну помилку самому і поступово здобувати кожне усвідомлення власним шляхом.
Це перша стаття з циклу, у якому я ділюся багатьма подібними історіями, зібраними від практиків про бізнес-аналіз. Матеріал адаптований з моєї книги «Software Requirements», 3‑тє видання, написаної у співавторстві з Джой Бітті; історії подані від першої особи: частина — мій досвід, інша — досвід Джой. Одні описують, як ми відкривали для себе дієві практики бізнес-аналізу, що справді окупилися. Інші — це застережливі історії про пастки, яких варто уникати. Усі вони реальні. І всі стали для нас повчальними як для практиків, консультантів, тренерів і авторів.
Переконайтеся, що вирішуєте правильну проблему
На одному з наших тренінгів ми пропонуємо студентам бізнес‑проблему та відповідну бізнес‑ціль. Упродовж вправи ми періодично надаємо додаткові деталі щодо вимог. На кожному кроці просимо студентів запропонувати рішення проблеми, враховуючи наявну інформацію. Наприкінці вправи всі ідеї рішень виявляються подібними, але рідко яка з них насправді розв’язує початкову проблему.
Це дуже схоже на те, що ми спостерігаємо на реальних проєктах. Команди можуть встановити чіткі цілі, а потім описати, розробити й протестувати систему, не звіряючи її з цілями в процесі. Зацікавлена сторона може вигадати нову блискучу функцію, яку хоче бачити реалізованою. Команда додає її, бо це здається розумним, цікавим і здійсненним. Проте згодом виявляється, що готове рішення, попри всі «круті» можливості, не вирішує початкової проблеми.
Ці навчальні приклади демонструють важливість того, щоб на початку будь‑якого продукту чи проєкту визначити бізнес‑цілі, а потім безперервно узгоджувати можливості запропонованого рішення з досягненням цих цілей. Під час опрацювання бізнес‑вимог варто ставити кілька ключових запитань — це допомагає утримувати всіх стейкхолдерів сфокусованими на спільній меті.
Безголосий клас користувачів
Бізнес‑аналітик в одній страховій компанії був у захваті, коли впливова користувачка на ім’я Ребекка погодилася стати ключовою представницею користувачів, або продуктовою чемпіонкою, для їхньої системи обробки страхових позовів нового покоління. Ребекка мала безліч ідей щодо функцій системи та дизайну інтерфейсу. Радіючи, що мають поради експертки з предметної області, команда розробки із задоволенням виконувала її запити.
Однак після доставки продукту вони були шоковані численними скаргами на те, що системою важко користуватися. Ребекка була «просунутою» користувачкою. Вона сформулювала вимоги до зручності використання, які були чудовими для таких експертів, як вона, але 90 відсотків користувачів, які не були експертами, сприйняли систему як неінтуїтивну і складну для навчання.
БА цього продукту не усвідомив, що система обробки заяв мала щонайменше два класи користувачів (а, ймовірно, й більше). Велика група «непроcунутих» користувачів була усунена від процесів збору вимог та UX‑дизайну. Компанія розплатилася за це дорогою переробкою.
БА мав залучити додаткових продуктових чемпіонів, які представляли б користувачів‑неекспертів та інші зацікавлені спільноти. Широкий пошук стейкхолдерів, визначення, кого з них найважливіше задовольнити, і добір відповідних людей, які говоритимуть від імені кожної групи, — необхідна частина планування бізнес‑аналізу.
Кар’єрний шлях у бізнес‑аналізі
Старший менеджер підрозділу медичного обладнання у великій компанії мав проблему. «Два роки тому я найняв трьох медичних технологів до мого підрозділу, щоб вони представляли потреби наших клієнтів, — сказав він мені. — Вони виконали чудову роботу, але вже не залишаються в курсі поточних медичних технологій, тож більше не можуть точно говорити про те, що потрібно нашим клієнтам сьогодні. Який для них тепер розумний кар’єрний шлях?»
Це поширений виклик. Я припустив, що ці колишні медичні технологи — хороші кандидати, щоб стати бізнес‑аналітиками в їхній організації.
Бізнес‑аналітики приходять із дуже різним бекграундом: серед них є колишні користувачі, розробники, спеціалісти з якості та керівники проєктів. Окрім базових навичок і рис характеру БА, часто дискутують, наскільки важливою є галузева експертиза. На мою думку, вона дуже допомагає. Хоча ці фахівці вже не були в курсі останніх подій у лікарняній лабораторії, як досвідчені представники користувачів вони могли ефективно спілкуватися з нинішніми практиками, адже добре знали їхні процеси та лексику.
Два роки в середовищі розробки продуктів дали цим колишнім медтехам добру уяву про процеси специфікації та проєктування продукту. Широкий спектр їхнього цінного доменного досвіду створив надійну основу для ролі, що містком поєднує поточних медичних технологів і розробників, які створюють для них рішення. Їм потрібне було додаткове навчання з розроблення та управління вимогами, а також інших аспектів бізнес‑аналізу, і ці колишні користувачі справді успішно перейшли на роль БА.
Разом із водою виплеснути й дитину
Я консультував одну компанію, де старший менеджер заборонив прототипування. Він бачив випадки, коли замовники тиснули на розробників, щоб ті завчасно видали одноразові прототипи як готовий продукт — з передбачувано поганими наслідками. Прототипи могли виглядати добре, але погано обробляли помилки користувачів і некоректні дані, не містили всіх потрібних опцій, не забезпечували необхідної продуктивності та були складними для підтримки й розвитку. Ці неприємні випадки привели менеджера до висновку, що прототипування неминуче призводить до проблем.
Звісно, видавати замовнику прототип, призначений для відбракування, і просто називати його «продуктом» — це шлях до проблем. І все ж прототипування — це спектр потужних прийомів, які можуть суттєво допомогти створити правильний продукт.
Замість того щоб відкидати прототипування як небезпечний метод, варто просвітити всіх залучених. Переконайтеся, що вони розуміють різні види прототипів, чому створюється саме цей, як команда використає результати оцінювання прототипу і що з ним буде після того, як він виконає свою функцію.
Ігри з пріоритетами
Пріоритезація — ключовий елемент аналізу вимог, проте вона може стати ареною для протистояння, зловживання владою чи ігор. Типова реакція на прохання клієнтів розставити пріоритети: «Мені потрібні всі ці функції. Просто зробіть». Вони можуть не усвідомлювати, що пріоритезація допомагає забезпечити ефективну та своєчасну поставку продукту.
Важко переконати стейкхолдерів обговорювати пріоритети, якщо вони знають, що вимоги з низьким пріоритетом можуть так і не бути реалізовані. Один розробник, який також виконував роль БА, стверджував, що пріоритети не потрібні, адже якщо він записує вимогу, то має намір її реалізувати. Проте його підхід не відповідає на питання — коли саме буде створено кожну частину функціональності.
Інший розробник розповів мені, що в його компанії політично неприйнятно називати вимогу «низькоприоритетною». Тому вони запровадили категорії «високий», «надвисокий» та «неймовірно високий». Звісно, це нічого не змінило — лише переклеїло ярлики на шкалі.
Я працював з компанією, якій було дуже складно вчасно завершувати проєкти. Керівництво заявляло, що буде кілька релізів застосунку, тож вимоги з нижчим пріоритетом можуть зачекати. Та на практиці кожен проєкт постачав лише один реліз. Відповідно, всі стейкхолдери знали, що мають лише один шанс отримати всю потрібну їм функціональність. У підсумку кожна вимога ставала «високого пріоритету», перевантажуючи спроможність команди поставляти як задумано. Інкрементальний підхід із суворою пріоритезацією беклогу допоміг би розв’язати цю проблему.
Справді, деякі можливості системи є важливішими за інші, якщо дивитися з позиції досягнення бізнес‑цілей і задоволення різних стейкхолдерів. Раціональний та безперервний процес пріоритезації гарантує, що команда завжди працює над функціональністю, яка якнайшвидше принесе найбільшу цінність стейкхолдерам.
Вартість якості
Остерігайтеся вимоги встановити 100 відсотків як цільове значення атрибутів якості, таких як безпека, захищеність, надійність чи доступність. Навіть коли потреба об’єктивно надвисока, гарантувати 100‑відсоткову відповідність неможливо, а спроби можуть виявитися дуже дорогими.
Життєво критичні застосунки — наприклад, транспортні системи чи медичні пристрої — справді мають надзвичайно жорсткі вимоги до доступності. Не можна допустити, щоб імплантований кардіостимулятор періодично «падав». Один із моїх клієнтів висловив подібну потребу для системи керування виробництвом. Оскільки простої коштували їм дуже дорого, вони заявили, що їхні керуючі комп’ютери мають бути доступні 24×7, 365 днів на рік, а у високосні — 366.
Один із таких продуктів визначив більш реалістичну вимогу «п’ять дев’яток», тобто система має бути доступною 99,999% часу. Інакше кажучи, простої не можуть перевищувати 5 хвилин 15 секунд на рік. Лише ця вимога становила, можливо, близько 25% вартості системи. Вона фактично подвоїла витрати на «залізо» через необхідну надмірність. Також це спричинило дуже складні архітектурні рішення для гарячого резервування та стратегії перемикання. Це просто ціна за екстремальні обмеження — і все одно це не 100%.
Ретельно зважуйте витрати та інші наслідки вимог до атрибутів якості, перш ніж фіксувати їх. Коли стейкхолдери почують, у що це виливається, вони можуть вирішити, що мають більше гнучкості, ніж гадали спершу.
У наступних статтях цього циклу ми з Джой поділимося ще багатьма повчальними епізодами з наших пригод у сфері бізнес‑аналізу.
Ця стаття адаптована з книги «Software Requirements», 3‑тє видання, авторства Карла Віґерса та Джой Бітті. Карл також є автором численних інших книжок, серед яких «Software Requirements Essentials» (спільно з Кандас Гокансон), «Software Development Pearls», «The Thoughtless Design of Everyday Things» і «Successful Business Analysis Consulting».
Оригінальна стаття – Tales from the Business Analysis Trenches, Part 1 від Карла Вігерса, переклад – Іван Вільчавський. Оригінальне фото з статті.