Quality Attribute Workshop: як проводити, що питати у клієнта та що робити, якщо він не може дати чіткої відповіді

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

Сьогодні я поділюся своїм досвідом, як правильно організувати роботу в рамках Quality Attribute Workshop (QAW), на що звертати увагу і як діяти в деяких складних ситуаціях, щоб отримати від клієнта саме те, що потрібно для подальшої ефективної роботи.

Навіщо потрібен Quality Attribute Workshop (QAW) і з яких етапів він складається

QAW — це важлива частина discovery або assessment-сесії. Її задача — визначити нефункціональні вимоги до системи. Якщо цього не зробити, очікування до готового рішення залишаться на рівні «highly-available / highly-secure / highly-performed», де кожен це «highly» розуміє по-своєму. Відповідно, в результаті у клієнта можуть виникнути питання, а апелювати не буде до чого.

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

Поетапно QAW проходить за такою схемою:

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

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

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

Як вибудовувати діалог з клієнтом під час QAW

Якщо на брейнштормі починати говорити абстрактними поняттями, що «ми плануємо зробити одну систему, яка буде відповідати іншій системі певним способом, втрата даних при цьому не буде перевищувати 0,001%», є ймовірність того, що не всім буде незрозуміло. Чим більше конкретики, тим краще. Тому я намагаюся вибудовувати дискусію навколо їх же юзкейсів — «Користувач повинен буде авторизуватися в системі, щоб мати можливість згенерувати звіт. Це критичний функціонал, який буде доступний завжди (в 99,95% випадків), при цьому чат системи може на певний час відключатися і це не критично». Так ми просуваємося сценарій за сценарієм — обговорюємо, вислуховуємо бачення стейкхолдерів, даємо всім висловитися, при цьому не критикуємо.

Дуже важливо домовитися про виміри (measurments). На цьому етапі повинні бути узгоджені чіткі показники або діапазони для кожного сценарія. Буває таке, що клієнт сам не знає, чого хоче. Все-одно потрібно отримати відповідь, щоб убезпечити себе на майбутнє. У таких випадках добре займати проактивну позицію і радити щось, посилаючись на свій досвід або світові best practices. Якщо це не працює, можна йти на невеликі провокації. Наприклад, ви обговорюєте час очікування (latency) SaaS-рішення в сфері охорони здоров’я. Клієнт не знає, яким воно повинно бути. Спробуйте запропонувати секунд 10, це змусить його почати думати швидше і пропонувати більш вдалі для себе варіанти.

Так потрібно пройтися по всіх сценаріях.

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

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

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

Буває таке, що у стейкхолдерів є близько години на все. Частіше це трапляється під час прісейлів, ніж дискавері. В такому випадку я розумію, що ми зможемо тільки дуже швидко пробігтися по основним пунктам, які допоможуть зрозумітискладність майбутньої інфраструктури, деплоймента, зрозуміти загальний хід думок клієнта. Для мене важливо з’ясувати вимоги до безпеки і продуктивності системи. Хоча, залежно від контексту, можуть бути також sustainability, usability (для веб-аплікейшна) і т.д. Тут зрозуміло, що не буде часу йти сценарій за сценарієм, тому я заздалегідь готую quality attribute-сценарій, на вимірах залишаю питання, щоб ми брейнштормили вже конкретно їх, а не самі сценарії. Звичайно, навіть в такому випадку може не вистачити часу обговорити всі. Тому визначайте для себе найбільш важливі моменти, першочергово з’ясовуйте їх, а решта домовляйтеся закінчити в листуванні.

В результаті всіх описаних вище кроків ми формуємо Utility Tree. Назва неочевидна, але це табличка, де ми описуємо всі наші сценарії, визначаємо для кожного з них рівень Importance і Complexity. Також можуть бути описані ризики, припущення і т.д.

Medium і High пріоритети для нас ключові. Ми будемо будувати дизайн і досягати вимірів першочергово для цих сценаріїв. Поєднання L-H свідчить про якусь проблему, її краще дослідити і врахувати на етапі дизайну.

Останній крок — QA Scenario refinement, коли ми упорядковуємо вимоги, їх наповнення, вносимо ясність. Іноді тут виникають ще якісь питання, в таких випадках краще попросити про ще одну сесію, щоб до старту роботи з’ясувати все.

Ось приклад розгорнутого опису. Я зазвичай роблю більш скорочений.

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

Як розподілити ролі команди для проведення QAW

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

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

Question-кіпер — ставить питання по технічній частині, ризиках і тд, допомагає фасилітатору направити розмову в потрібне русло. Це фахівець з конкретної технології.

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

Якщо говорити про інструменти для запису матеріалу в ході сесій, ми найчастіше використовуємо MS Teams + Sharepoint, оскільки там в одному місці зберігаються і файли, і завдання, зручно шерити матеріал між собою і вибудовувати взаємодію команди. Ще є XMind, його часто використовують бізнес-аналітики. У мене ще є вордовскій темплейт, який мені зручно заповнювати. А ось дошка — небезпечна річ, оскільки вона швидко закінчується, писати потрібно розбірливо, всі записи — фотографувати і потім все-одно переносити в електронний вигляд.

Кілька корисних першоджерел:
resources.sei.cmu.edu/...​t-view.cfm?assetid=474329
resources.sei.cmu.edu/...​t/2018_010_001_513488.pdf
kilthub.cmu.edu/...​582656/files/12069557.pdf

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному10
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

це — дуже крута стаття!

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

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

Основные направления которые нужно прорабатывать это производительность, доступность, безопастность, модифицируемость. Так же есть еще совместимость, надежность.

Есть какой-то список/чеклист по которому можно не забыть важные нефункциональные требования?

Також, якщо подумати, такий принцип формування інформації про продукт з розподіленням по фічам і пріоритетам може бути актуальний не тільки для QA Deprtment, а і для Business Analysts / Proxy Product Owners, що знаходяться на стороні замовника.

може бути актуальний не тільки для QA Deprtment

а де тут згадувався QA department?

в моєму попередньому повідомленні був посил, що дана стаття являється хорошим підгрунтям для розбудови QA Department і впровадження QA/QC процесів.

А в вищеозвученому повідомленні додав, що актуально не тільки для QA.

Дякую.
Якраз актуальна тема по тому як витягнути вимоги с замовника на новому проекті для впровадження QA/QA процесів і практик.

Коментар порушує правила спільноти і видалений модераторами.

Отличная метдология, уже применял на практике.

Из личного опыта хочу сказать что на этапе брейншторма сценариев зачастую и другие архитектурные драйверы выявляются, важно кастомерам описать перед началом QAW что кроме quality attributes, есть еще constraints, concerns, business goals, major features. Хоть и основной целью является работа с quality attributes.

Второй момент, на этапе приоритезации я для себя понял такую вещь, что среди стейкхолдеров стоит разлечать технических и бизнес стейкхолдеров. Так, я на этапе приоритезации раздавал стикеры одного цвета бизнес людям (pdm, ba) и другого цвета ключевым разработчикам/архитекторам. Говорил что у каждого есть 40 баллов и пусть их распределят между всеми аттрибутами.
Потом очень интересно наблюдять какие баллы и куда ставит бизнес, а какие разработчики.

Дальше было уже легче преоритезировать делая аргумент что вот это критично для бизнеса и нужно делать, а вот то критично с точки зрения разработчиков и об этом тоже не стоит забывать.

Отличная идея с цветами — возьму себе на вооружение!

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