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 пріоритети для нас ключові. Ми будемо будувати дизайн і досягати вимірів першочергово для цих сценаріїв. Поєднання
Останній крок — 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», щоб не пропустити нові технічні статті
7 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів