Це друга стаття з серії, в якій ми ділимося реальними історіями з практики бізнес-аналізу, з якими зіткнулися я або Джой Бітті, співавтори книги «Software Requirements, 3rd Edition» (Вимоги до програмного забезпечення, 3-тє видання). Навчання на прикладах того, що інші зробили правильно або неправильно на своїх проєктах з розробки програмного забезпечення, — це ефективний спосіб уникнути таких помилок самому. Першу статтю з цієї п’ятичастинної серії ви можете знайти тут. «Я» в кожній з цих історій може бути як я, так і Джой.
Мені було б цікаво почути і ваші історії про бізнес-аналіз, як хороші, так і, можливо, не дуже хороші, у відповідях на ці статті. Давайте вчитися одне в одного через досвід, який справді вартий уваги.
Фантазійні вимоги
Менеджерка в компанії з розробки продуктів, яка зазнала майже катастрофічного розростання обсягу робіт, з гіркотою сказала мені: «Ми надто захопилися польотами у хмарах з вимогами».
Вона мала на увазі, що будь-яка ідея, яка спала на думку комусь із співробітників, була включена до вимог. Ця компанія мала чітке бачення продукту, але не керувала обсягом розробки через планування серії релізів і не відкладала деякі запропоновані функції на пізніші (можливо, нескінченно пізніші) релізи.
Врешті-решт, після чотирьох років розробки команда випустила надмірно роздутий продукт.
Може бути корисно зафіксувати «фантазійні» вимоги у беклозі для подальшого розгляду. Я вважаю за краще зробити це, ніж пропустити потенційно важливі ідеї або проігнорувати хороші пропозиції, які можна швидко реалізувати. Проте продумане управління обсягом робіт і пріоритизація з чітким фокусом на досягненні бізнес-цілей, а також запланований підхід із поступовими релізами дозволили б команді випустити корисний продукт набагато раніше.
Деякі продукти за своєю природою великі і не підходять для інкрементованих релізів, хоча, звісно, кожен продукт розробляється поетапно, по шматочку. Як ми бачили в першій статті цієї серії, ретельна пріоритизація є критично важливою для того, щоб переконатися, що команда працює над функціональністю, яка приносить найбільшу цінність для стейкхолдерів найшвидше. Можливо, ви ніколи не реалізуєте всі «фантазійні» ідеї, які запропонували стейкхолдери. І це нормально.
Практикуйте те, чому навчаєте
Одного разу досвідчений бізнес-аналітик врятував мене від самого себе. Я розмовляв зі своєю подругою і колегою Танею про програмне забезпечення для мого вебсайту. Я сказав їй, що мені потрібен якийсь скрипт, який міг би перехоплювати певні електронні листи, які я отримую, і витягувати з них певну інформацію. Не знаючи, як написати такий скрипт, я попросив Таню, досвідчену веброзробницю, порадити, як краще діяти.
Таня відповіла: «Вибач, Карле, але я не думаю, що це твоя справжня вимога. Твоя справжня вимога — отримувати потрібну інформацію іншим способом, а не вручну читати й обробляти електронні листи по мірі їх надходження в поштову скриньку». Вона була абсолютно права. Я потрапив у типову пастку користувача, який видає рішення проблеми як вимогу.
Як і належить вправному бізнес-аналітику, Таня відійшла від мого початкового запиту, проте одразу виявила справжню суть проблеми. Коли ви дивитеся на проблему під іншим кутом, майже завжди виявляється, що існує кілька способів вирішення проблеми, і деякі з них можуть бути кращими за той, що першим спав на думку. Ви навіть можете виявити, що озвучена проблема не є справжньою проблемою. Дякую тобі, моя розумна подруго Таню!
Переймаючи мислення, спрямоване на користувача
Я є великим прихильником використання техніки для документування вимог Use Case ще з тих часів, коли вперше про них дізнався. Побачивши їхню цінність під час вивчення вимог, я зосередив свої стратегії збору вимог на розумінні того, що користувачі повинні робити з продуктом, а не лише на його характеристиках і функціях. Я провів багато лекцій і практичних занять, присвячених опрацюванню вимог загалом, а також ефективному використанню Use Cases зокрема, наголошуючи на застосуванні цього орієнтованого на користувача підходу. Досвід роботи в класі виявився надзвичайно повчальним і надихаючим.
Під час мого дводенного курсу по опрацюванню вимог до програмного забезпечення ми проводимо одногодинний практичний семінар із збору вимог. Я ділю клас на чотири команди, приблизно по шість студентів у кожній, і пропоную їм проєкт. Завдання полягає в тому, щоб визначити кілька класів користувачів для цього проєкту, потім — декілька use cases для одного з класів користувачів, а далі детально пропрацювати один із цих use cases, використовуючи шаблон use case, який я представив під час заняття. Я спостерігав, як приблизно 700 команд виконували цю вправу.
Одна й та сама закономірність повторюється майже на кожному занятті. Одна команда одразу розуміє, як працюють use cases, можливо тому, що хтось із їхніх учасників уже мав досвід роботи з ними раніше. Ця група демонструє вражаючі результати у вирішенні свого завдання за відведену годину.
Дві інші команди спочатку трохи затримуються, стикаючись з труднощами, але після короткої консультації з мого боку вони стають на правильний шлях і досягають прогресу у вивченні свого use case.
Однак четверта команда так і не розуміє концепцію use case. Їхній фліпчарт заповнений стікерами з випадковими фрагментами інформації: функціональними вимогами, характеристиками продукту, user stories, нефункціональними якісними атрибутами, бізнес-правилами, об’єктами даних та обмеженнями.
Після цього команда просто дивиться на свої стікери, не розуміючи, що робити далі з усією цією інформацією.
Коли я запитую цю четверту команду, з чого вони почали обговорення, фасилітатор завжди відповідає: «Я запитав у групи, які у них вимоги, і записав усе, що вони мені сказали». Команди, які розуміють суть use cases, просуваються у вирішенні задачі набагато швидше та ефективніше.
Це відповідає і моєму власному досвіду роботи над проєктами. Use cases забезпечують чітку структуру як для виявлення, так і для організації інформації, пов’язаної з потребами користувачів та можливостями рішення, чого не можуть забезпечити самі лише user stories. Я й досі залишаюся прихильником підходу use cases.
Занадто багато «кухарів» на одній «кухні» або воркшоп у режимі хаосу
Бізнес-аналітики часто проводять воркшопи зі збору вимог із групою замовників, щоб зібрати та оцінити інформацію про їхні потреби. Проте, якщо учасників занадто багато, воркшоп може сповільнитися до суперечливого та непродуктивного темпу.
Моя колега Деббі була розчарована повільним прогресом першого воркшопу з опрацювання Use Case, який вона проводила для проєкту веб-сайту. Дванадцять учасників заглибилися в довгі дискусії про несуттєві деталі, передчасно досить глибоко занурилися в тему, втратили фокус і не змогли дійти згоди щодо конкретних use case, які вони мали розглянути. Терпіння, як і настрій учасників, швидко вичерпалися. Деббі запитала мене, що їй робити.
Дванадцять людей не зможуть дійти згоди навіть у тому, щоб вийти з палаючої кімнати, не те що домовитися, як має працювати Use Case. Я запропонував Деббі скоротити кількість учасників сесії з виявлення вимог удвічі. Їхня ефективність значно покращилася, коли вона скоротила кількість учасників до шести осіб, які представляли ключові ролі: бізнес-аналітика, кількох основних користувачів, системного архітектора та розробника.
Звісно, у меншій групі під час воркшопу втрачається частина інформації та ідей. Проте прискорення прогресу більш ніж компенсує цю втрату. Учасники воркшопу можуть обмінятися інформацією з колегами поза межами сесії та принести зібрану інформацію, ідеї та відгуки на наступну сесію. Зрештою, бізнес-аналітик повинен отримати інформацію від усіх зацікавлених сторін, але не з кожного питання і не від усіх одночасно.
Як діють стейкхолдери
Одного разу я проводив воркшоп, метою якого було визначення технологічних процесів для заводу з виробництва напівпровідників. У сесії брало участь близько десятка інженерів. Я розпочав роботу біля дошки, малюючи схеми процесів у міру того, як ми обговорювали кожен крок. Після завершення кожного потоку я зупинявся, щоб сфотографувати результат, перш ніж переходити до наступного етапу.
Через пів дня після початку першої сесії один з інженерів запитав, чи може він спробувати попрацювати біля дошки. Я з радістю передав йому маркер. Оскільки він уже був експертом у цій системі, то без труднощів зміг самостійно накреслити кожен процесний потік на дошці. Потім він пройшовся по кожному етапу, залучаючи колег на кожному кроці, щоб вони підтвердили або виправили його.
Коли інженер узяв на себе роль фасилітатора, це дозволило мені зосередитися на тому, щоб ставити уточнювальні запитання та робити нотатки. Незабаром інженери почали передавати маркер один одному, щоб кожен мав можливість висловитись.
У подібних групових обговореннях хтось повинен брати на себе ініціативу в проведенні таких групових дискусій і фіксуванні важливої інформації, але це не обов’язково має бути саме бізнес-аналітик. Активне залучення стейкхолдерів, як на цьому воркшопі, підвищує їхню зацікавленість у процесі й веде до створення більш повних і точних результатів.
Скажіть «ні» вимогам, побудованим на припущеннях
Одного разу мені випала нагода познайомитися з командою розробників, яка створювала портал, призначений для виконання багатьох завдань, включаючи завантаження, редагування та публікацію контенту на вебсайті. Вони мали приблизно 1000 одиниць уже наявного контенту, організованого в ієрархічну структуру. Команда, що відповідала за управління контентом, припустила, що користувачі зможуть без труднощів орієнтуватися в цій ієрархії та швидко знаходити потрібний матеріал для редагування. Вони не вказали жодних вимог щодо навігації по інтерфейсу користувача.
Однак, коли розробники реалізували користувацький інтерфейс, вони організували весь контент на одному рівні, а не ієрархічно, і показували лише 20 елементів на екрані. Щоб знайти конкретний фрагмент контенту, користувачеві доводилося послідовно переглядати до 50 екранів. Початковий інтерфейс був абсолютно непрактичним для передбаченої мети.
Це випадок, коли орієнтований на користувача підхід був би дуже корисним. Якби команда розробників створила прототип інтерфейсу користувача та отримала зворотний зв’язок від команди управління контентом перед затвердженням дизайну, недоліки їхнього початкового підходу стали б очевидними. Трохи більше специфікацій і діалогу між розробниками та командою управління контентом могло б запобігти значній, незапланованій і дорогій переробці.
Більше історій з БАйок з життя аналітика читайте в наступних статтях.
Оригінальна стаття – Tales from the Business Analysis Trenches, Part 2 від Карла Вігерса, переклад – Марʼяна Закорчевна, ревью – Галина Остапенко. Оригінальне фото з статті.