Секретні техніки пропрацювання вимог. Частина перша

Оригінальна стаття з сайту DOU.UA, переклад – Марія Слободян. Фото від fauxels з сайту pexels.com

Пропонуємо переклад статті Артура Селецького, Co–Founder/Partner в It Network. Артур з колегами займаються розвитком ком’юніті бізнес-аналітиків і керівників проектів в Україні.

 

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

Мене часто запитують: “Як зрозуміти, чи всі вимоги враховані? Як перевірити, чи ми нічого не проґавили?” У цій статті поділюся своїм досвідом щодо того, як я перевіряю вимоги на повноту і який шлях з пропрацювання вимог проходжу.

Техніки

Наводжу перелік технік, які допомагають мені перевірити вимоги на повноту:

1. Аналіз стейкхолдерів (Stakeholder analysis).
2. Карта історій користувача (User story mapping).
3. Рольова модель і сценарії використання.
4. Прототипування.
5. Об’єктно-орієнтована модель.
6. Діаграма станів.
7. CRUD (Create, Read, Update, Delete – базові операції з об’єктом: створення, перегляд, оновлення, видалення).
8. Навігація.
9. Адміністрування.
10. Звітність.
11. Нефункціональні вимоги.

Тепер розглянемо кожну з технік детально і з прикладами.

Аналіз стейкхолдерів

Стейкхолдери (stakeholder) — фізичні особи чи організації, які впливають на проєкт.

Стейкхолдерами виступають:

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

Пригадую кумедну історію, яка сталася зі мною на старті кар’єри. У той час я працював у банку на посаді інженера ІТ-підтримки. Основним моїм завданням був супровід АБС (автоматизованої банківської системи) Б2.

В один чудовий день від розробників Б2 ми отримали черговий реліз. До релізу увійшов функціонал з автоматизації нарахування абонентних плат і комісій за клієнтськими рахунками. Ознайомившись із переліком і можливостями нового модуля, я був вражений: усе, що наші менеджери роблять вручну, можна налаштувати й автоматизувати. Роздрукував і побіг до головного бухгалтера з прекрасною новиною: “Ура-а-а-а! Усе можна зробити автоматично!”

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

Через два дні ми з головним бухгалтером перевіряли всі можливі варіанти. І о диво! Усе працювало як годинник.

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

Вранці наступного дня я прийшов на роботу о 10 годині. Підходжу до свого керівника ІТ-відділу і доповідаю: “Усе зроблено, ось дивись”. Відкриваємо АБС, а там… нічого немає. Усі комісії, які розрахувала система, успішно видалені менеджерами. Підходжу до менеджерів і запитую: “А чому видалили, щось неправильно нарахувала система?”

Відповідь мене вразила: “Ні, все правильно. От тільки що ми будемо робити цілий день, якщо система зробить усе за нас?”

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

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

Класифікують стейкхолдерів за впливом на проєкт і їх зацікавленістю.

Впливовість — це ступінь впливу стейкхолдера на проєкт (бюджет і вплив на людей).

Зацікавленість — це ступінь підтримки проєкту чи протидії йому.

Для роботи зі стейкхолдерами я використовую матрицю впливу і зацікавленості.

Матриця впливу і зацікавленості стейкхолдерів

Квадрант 1 (підтримка, сильний вплив). До цього квадранта мають входити спонсор проєкту, проєктна команда, замовники і топ-менеджери. Якщо хтось із перерахованих стейкхолдерів не входитиме до цього квадранта, успіх проєкту буде під великим питанням. Не можна допустити переходу стейкхолдерів із цього квадранта в інші квадранти. Це найважливіші та найвпливовіші союзники проєкту.

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

Квадрант 3 (протидія, слабкий вплив). У цьому квадранті розташовані слабкі противники проєкту. Вони протидіють нашому проєкту і при цьому не мають великого впливу на сам проєкт.

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

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

При виявленні стейкхолдерів я ставлю такі питання:

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

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

П. І. Б.	E-mail	Телефон	З яких питань	Ступінь впливу
С******кий Артур Миколайович	a.s*****kiy@buble.com	+380 ХХХ-ХХ-ХХ	Виконання налаштувань системи	Квадрант 1

До теми – Аналіз стейкхолдерів: модель значущості (Salience Model)

Карта історій користувача

У XVI столітті Козімо I замовив фрески для капели собору Сан-Лоренсо у Флоренції у Якопо де Понтормо. Понтормо понад 11 років розписував стелю капели сценами з Біблії: створення світу, Ноїв ковчег, Адам і Єва, Христос… Художник працював, практично не полишаючи капели і нікому не показуючи результати свого творіння.

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

Техніку user story mapping використовую як техніку візуального представлення послідовності дій, які потрібно реалізувати. User story mapping – один із методів декомпозиції вимог, який забезпечує розуміння продукту, починаючи з повного охоплення всіх потреб і завершуючи зануренням у детальні історії користувача.

На практиці в рамках етапу аналізу вимог я використовую такий процес побудови user story mapping:

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

User story mapping процесу узгодження відпусток

Рольова модель і сценарії використання

Недарма в шаблоні (я як роль) найпоширенішого методу фіксації вимог (user story) використовується роль. Для досягнення максимальної цінності від проєкту ми маємо чітко розуміти, для кого і з якою метою ми реалізовуватимемо той чи інший функціонал.

Під час побудови рольової моделі використовую три підходи:

1. Посадова — визначення ролей на базі посадових обов’язків.
2. Функціональна — визначення ролей на базі функціональних задач.
3. Гібридна — поєднання підходів посадової та функціональної рольової моделі.

Під час побудови посадової рольової моделі часто зіштовхуюсь з такими труднощами:

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

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

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

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

Після того як ролі визначено, для кожної з них перераховую сценарії використання.

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

Роль	Сценарій використання
Адміністратор	Створення проєкту Редагування картки проєкту Призначення керівника проєкту Побудова звітів у розрізі портфеля проєктів
Керівник проєкту	Побудова проєктного плану Робота з задачами Побудова звітів
Користувач	Перегляд проєктного плану Виконання задач Запит на зміну терміну виконання задач

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

До теми – Історії користувача vs. Історії роботи (User vs. Job Stories)

Прототипування

Як показує практика, більшість людей сприймають все, що відбувається, на око, що необхідно враховувати і під час виявлення вимог. Один із найпотужніших методів виявлення вимог – це прототипування. У цьому я переконався в одному з проєктів, куди мене підключили на роль лідера команди бізнес-аналітиків, коли проєкт заходив у глухий кут. Ситуація була така: вже 3-тя команда не могла впоратися з виявленням вимог і узгодженням їх з одним із клієнтів. Йшов 5-й місяць проєкту, а команда аналітиків не могла зрушити з місця. Команда надала вже 4 варіанти технічного завдання, а замовник усе не хотів підписувати. Команда говорила, що замовник не в собі й узгодити вимоги нереально. Я намагався ознайомитися з усіма документами, які готувала команда. У них було дуже багато важкого тексту, з технічними термінами. У підсумку я для себе визначив кілька модулів системи і приблизно зрозумів функціонал. Часу на підготовку було небагато: один день і одна ніч.

І ось моя перша зустріч із замовником, керівник проєкту представляє йому мене і цілі зустрічі – узгодження вимог. На що отримуємо багато невдоволення зі словами: “Який жах! Ще один аналітик”.

Я почав зі слів: “Чи правильно я розумію…”, а ставлячи запитання, відразу взявся малювати на аркуші А4. За півтори години у нас було намальовано близько 20 екранних форм. Я подякував замовнику і побіг в офіс розробляти клікабельні прототипи.

Ближче до півночі роботи зі створення прототипів було завершено. Наступного ранку я зателефонував замовнику і попросив призначити зустріч щодо узгодження вимог. На що відразу отримав відповідь: “Нічого читати не буду”. Я парирував, що зараз нічого читати й не потрібно. Вона була здивована і все ж погодилася через годину зустрітися. Ще більше її здивувало, що ми почали не читати документи, а далі працювати з прототипами, тільки вже розробленими в спеціалізованій програмі. Одразу на місці ми почали додавати та видаляти елементи, і протягом години вимоги були узгоджені. А далі справа техніки: описати їх у документі й дати на підпис. Через тиждень документ із вимогами було підписано.

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

Рекомендую використовувати такі інструменти:

• Axure;
• Balsamiq;
• Visio;
• олівець і папір;
• будь-який інший інструмент.

У коментарях поділіться, які інструменти використовуєте ви.

Що ще важливо пам’ятати: прототип не дизайн! Не захоплюйтеся, інакше вам доведеться розробляти і погоджувати дизайн достроково.

Життєвий цикл прототипу: від створення на дошці до розробки дизайну

І найголовніше, прототип не має бути красивішим, ніж сама реалізація. Так, це також траплялося…

Ну, і вистраждане роками визначення прототипу, яке я додаю в розділ “Визначення” в усі документи з вимогами: “Прототип – це схематичне зображення форм і окремих елементів сторінки. Пропорції елементів дизайну, розміри шрифтів і заголовків, відстані між елементами, дизайн елементів та їх розміщення є умовними”.

Замість підсумку

У першій частині ми розглянули 4 техніки: stakeholder analysis, user story mapping, рольова модель і сценарії використання, а також прототипування. Мені вони допомагають у щоденній і далеко не найпростішій проєктній ролі — бізнес-аналітика.