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

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

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

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

Техніки

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

Stakeholder analysis.
User story mapping.
Рольова модель та сценарії використання.
Прототипування.
Об'єктно-орієнтована модель.
Діаграма станів.
CRUD.
Навігація.
Адміністрування.
Звітність.
Нефункціональні вимоги.

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

Stakeholder analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ф. В. О.	E-mail	Телефон	З яких питань	Ступінь впливу
Селецький Артур Миколайович	[email protected]	+380 ХХХ-ХХ-ХХ	Виконання налаштувань системи	Квадрант 1

User story mapping

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очікуйте наступні частини з цієї теми на сторінках DOU.

Опубліковано: 15/10/19 @ 10:00
Розділ Різне

SEO Блог