Service Level Agreement як пігулка від стресу

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Усім привіт, мене звати Настасья Ровінська, наразі маю честь бути Business Analysis Technical Lead в компанії CodeIT. В проєктах граю на позиції Business Analysis/ Product Owner/ Product Manager.

Спільното, а у вас на проєктах іноді лунають такі фрази: «Цей баг потрібно пофіксити негайно»? Або таке: «В нашому беклозі багів більше, ніж тасочок на розробку»? Та найулюбленіше — «Ви можете писати код без багів?!» В нас таке буває, тож якщо вам цей біль знайомий, дозвольте поділитися, досвідом керування багами всередині команди за допомогою Service Level Agreement (SLA).

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

І вже не «драйвує» схема погасити пожежу негайно, хочеться якихось унікальних інструментів, які, як золота пігулка, вилікують від усіх захворювань. Тож коли на проєкті вкотре почались сперечання на тему «розробляти або фіксити» (майже «Бути чи не бути»), було прийнято рішення шукати надійні інструменти, які дозволять на рівні команди відточити процес роботи з багами.

Тут заради справедливості варто зазначити, що такі запити зустрічались, як в продуктових компаніях, так й в аутсорс/ аутстаф. Окрім того, мова йде про команди, які мають вже певний досвід, випустили у життя не один value-продукт та не включають себе до клану «мамкін-програміст».

Що там за проблеми з тими багами

Тож звідки народжується проблема «керування багами» та чого це взагалі стає проблемою? Поділимося міркуваннями та спостереженнями про коріння:

  • різні команді ролі по-різному визначають результати та питому вагу своєї роботи, не дивлячись на те, що усі однаково розуміють й прагнуть досягти Product Goal (мети продукту). Іншими словами, QA важливо не тільки виявити (зарепортити) баг, а й відстежити, що він виправлений. У той самий час, Project/Delivery Manager/Product Owner (залежить від складу команду) надає перевагу тому, щоб продемонструвати Замовнику новий функціонал за результатами спринту, аніж зафіксувати, що виправлено N-багів у спринті;
  • змінюються пріоритети розробки й баг, який вже було виявлено багато часу потому, але відкладено у беклог, набуває пріоритету ASAP;
  • тиск стейкхолдерів, щоб якомога швидше зарелізити новий функціонал, підбурює команду й некритичні недоліки відкладаються на потім;
  • іноді команда настільки заглиблена у продукт й звиклася з деякими його недосконалостями, що втрачає фокус й вже не може об’єктивно пріоритезувати баги;
  • обмеженість ресурсів змушує нехтувати якістю.

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

Нумо оформимо наші стосунки!

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

У результаті, температура у кімнаті підвищувалась, а ковдра почала тріщати по швах. Тож дійшовши до нездорового стану, було вирішено оформити стосунки з багами у форматі внутрішнього Service Level Agreement (SLA).

Для формування внутрішнього SLA обрали наступні критерії:

  1. пріоритет багу;
  2. частота відтворення;
  3. час реагування.

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

  • «Blocker» — користувач не може виконати головну цільову дію;
  • «Critical» — користувач не може виконати головну цільову дію, але існує обхідний шлях;
  • «Major» — помилка не впливає на головну цільову дію, але локалізується у головній воронці (funnel);
  • «Trivial» — помилка не локалізується в головній воронці й не впливає на цільові дії;
  • «Minor» — помилка не впливає на поведінку системи.

Частотою відтворення багу встановили наступні параметри:

  • якщо помилка відтворюється більше ніж у 50% користувачів — це High-priority;
  • якщо помилка відтворюється у 20% — 50% користувачів — це Medium-priority;
  • якщо помилка відтворюється менш ніж у 20% користувачів — це Low-priority.

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

Прийняті критерії було зіставлено з бажаним часом реагування. Отримала матрицю:

Час реагування

Blocker

Critical

Major

Trivial

Minor

High

<2 годин

≤2 дні

≤5 днів

наступний спринт

беклог

Medium

≤1день

≤5 днів

наступний спринт

беклог

беклог

Low

≤5 днів

наступний спринт

беклог

беклог

На розсуд PO/PM

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

Ну, і як це працює

Для зображення підходу SLA на практиці, розглянемо приклад. Нехай наша команда розробляє market-place. Надамо визначень до пріоритетів багів:

Пріоритет

Опис

Приклад

Blocker

Користувач не може виконати головну цільову дію

При оплаті покупки стається помилка

Critical

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

Користувач не може оплатити замовлення однією з платіжних опцій (нехай, PayPal), але інші працюють

Major

Помилка не впливає на головну цільову дію, але локалізується у головній воронці (funnel)

При пошуці продукти за категорією товарів стає помилка

Trivial

Помилка не локалізується в головній воронці й не впливає на цільові дії

Товари не фільтрується за ціною

Minor

Помилка не впливає но поведінку системи

На сторінці присутня граматична помилка

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

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

Які аспекти додатково можна враховувати:

  • критерії реагування на проблему на продуктовому середовищі та на тестовому можуть бути різні;
  • задати виключні правила для вихідних/ святкових днів та неробочі години (як реагуємо, якщо проблема стається в суботу о 6:30, коли вся команда чемно відпочиває);
  • відлік часу на реагування потрібно визначати не з моменту репорту, що проблема існує, а з моменту, коли конкретний розробник відгукнувся, що він бачить завдання, яке на нього призначено (тут недостатньо того, що QA зарепортив баг в Jira, потрібно пересвідчитись, що розробник знає про існування багу);
  • складання та деталізація SLA залежить від складу команди та може бути виконана як QA, так і керівником проєкту.

Як ще можна працювати за SLA? Пригадаємо розповсюджену фразу з інструктажу з безпеки у літаку: «Спочатку одягніть кисневу маску на себе, а потім — на дитину». Тож якщо ви з командою відточили процес, верифікували обрані параметри й вже відчули переваги роботи, то можна розповсюдити цей підхід серед стейкхолдерів.

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

Крім того, чимало відкритих джерел зазначають, що в SLA мають бути вказані «права та обов’язки». Тут варто орієнтуватися на команду й доступні ресурси. Якщо ви маєте можливість заохотити розробників за вчасне усунення проблеми, то зробіть це, принаймні маленьким смаколиком.

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

Головне пам’ятати, що ви впроваджуєте SLA заради контролю над очікуваннями та встановлення правил гри. Команда має відчувати переваги, а не пресинг.

Lessons learned, або Висновки

Чого уникати:

❌ не потрібно нав’язувати команді підхід роботи за SLA й здебільшого «спускати зверху», як наказ до виконання. Команда повинна бути готовою до того, щоб встановити певні кордони;

❌ не потрібно встановлювати будь-які показники особисто — усі параметри SLA мають бути узгоджені з командою. У іншому випадку може виникати спротив команди;

❌ не варто завдавати недосяжних показників. Це призведе до того, що після декількох спроб рухатися за планом SLA команда відчує неспроможність виконання й цей документ буде покладено у смітник. Краще взяти більший час на виправлення, аніж демотивувати команду;

❌ не варто запроваджувати формат роботи за SLA, коли в команді стресовий період.

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

Що має сенс:

✅ застосовуйте емпіричний підхід до показників, які узгодили. Якщо практика свідчить, що команді потрібно більше/ менше часу на виправлення, або пріоритети були розподілені некоректно, ви завжди можете переглянути ці параметри та змінити їх;

✅ запросіть зворотний зв’язок після декількох підходів роботи за SLA та спробуйте скорегувати процес за потреби;

✅ заохочуйте та мотивуйте команду навіть за маленькі кроки в роботі за процесом SLA;

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

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

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

Доброго дня! Прочитав Ваш матеріал, потім за кілька днів ще раз прочитав. Сьогодні повернувся з питанням. У статті мова йде про те, як (по суті) аналізувати наявні баги та приорітизувати їх усунення. Ви писали про половину беклогу з багами, або такі показники як 50% користувачів не можуть здійснити оплату. Це дуже великі показники, наприклад, якщо помножити на 1 млн користувачив. Суть питання полягає у тому, чи розглядали Ви Blocker, Major, Critical як ризики, щоб працювати з проблемами до того, як вони з’являються? Тому що сам факт наявності половини беклогу багів можна сприймати як ризик великого приорітету. Друге питання — це аналіз причин виникнення багів — також не побачив у вашій статі (чи це є за межами обсягу цього документу). Щиро дякую.

Доброго дня й дякую за запитання. Ви слушно зазначили, що аналіз причин та наслідків не наводяться у цій статті, й так це поза межами.
Але я спробую відповісти й навести деякі спостереження-приклади.
Стосовно запитання «чи розглядали Ви Blocker, Major, Critical як ризики, щоб працювати з проблемами до того, як вони з’являються». Це окремий процес який повинен бути ретельно опрацьований, й не тільки на ретроспективі. За результатами дослідження причин та наслідків складається план запобігання.
Тут варто зазначити, що запобігання проблемі не завжди можливе з точки зору компанії, а також не завжди можливе з точки зору команди-розробників.
Наприклад, нехай в нас застосунок, на якому можна здійснювати якісь покупки й сплачувати за допомогою декількох сервісів. Й от саме сьогодні сервіс, якому надають перевагу 80% користувачів не працює. Чи в нас стався Blocker? На мою думку так. Чи можемо це виправити «негайно» — ні. Така ситуація може статися знову? — Так.
Тобто з точки зору команди-розробників ми безсилі. Ну максимум можемо звернутися до нашого постачальника платіжного сервісу й повідомити про проблему; можливо отримаємо якийсь прогноз про час виправлення. Але суттєво не впливаємо на вирішення проблеми.
З іншого боку можемо переглянути договір з цим платіжним сервісом, але це також не стосується активних дій розробників.
Якщо взяти цей самий приклад й уявити, що платіжний сервіс змінив API, про що нам було заздалегідь повідомлено, але команда вчасно не внесла зміни на своєму боці — то ту вже наша відповідальність.

Дякую, дуже корисна стаття!

Max, дякую за відгук. Рада, якщо стала у нагоді.

проєкт — це тимчасове підприємство, призначене для створення унікальних продуктів, послуг або результатів (згідно з визначенням PMBoK)

PMBOK не визначає проект як підприємство.
Project — a temporary endeavor undertaken to create a unique product, service, or result. iehouse.org/...​ploads/2021/07/PMBOK7.pdf

Oxford визначає «endeavor» як «спробу досягти мети». («an attempt to achieve a goal»).

Wikipedia визначає «Підприє́мство» як самостійний суб’єкт господарювання, зареєстрований компетентним органом державної влади або органом місцевого самоврядування, для задоволення суспільних та особистих потреб шляхом систематичного здійснення виробничої, науково-дослідної, торговельної, іншої господарської діяльності в порядку, передбаченому Господарським кодексом України та іншими законами. uk.wikipedia.org/wiki/Підприємство

Valentine Barmak, дякую за коментар. Змінила лінку )
Гадаю визначення безпосередньо залежать від перекладу.
Ось тут, наприклад, ukraine.iiba.org/babok-glossary-ukraine, проєкт — це тимчасова діяльність, спрямована на створення унікального продукту, послуги або результату.
А за цим перекладом biconsult.ru/...​/PMBOK-6th-Edition-Ru.pdf визначають, як підприємство.

Стаття цікава.
Про 20% сподобалось :-)

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

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

Якщо іде процес розробки, то чи на імпрувменти і таскі можна застосовувати блокер?

Алекс, для того, щоб відповісти на Ваші питання, мушу перепитати:
1. Що ви маєте на увазі під непродукційним оточенням?
2. Правильно я розумію, що Ви маєте на увазі ситуацію, коли під час поточної розробки поступає запит на зміни й команда вимушена переключитися на нову задачу вищого пріоритету?

Кожна аплікація чи сервіс в кінці розробки має бути використана бізнес одиницею. Зазвичай середовище на кінці називається продакшн. Production environment. І власне тут бізнес заробляє гроші. Тому зазвичай саме на продакшені зазвичай є SLO or SLA. Звідси і моє питання. Як можна ввести SLA/SLA для енвайроменту що не приносить фінансової користі.
Стосовно другого питання. Вищий пріоритет це зрозуміло. Питання було саме про тип задачі як імпрувмент чи таск. Приклад, команду попросили прикрутити нову авторизації через смс. Чи такий імпрувмент для вашої працюючої системи може мати статус блокер?

Стосовно першого запитання, то не бачу перепонів для використання SLA для продукти, що знаходиться в стадії розробки та ще не мав жодного релізу у прод. У даному випадку команда при плануванні своїх робіт має чіткі критерії, які баги виправляємо в поточному спринті, які в наступному, а які класти в беклог. Наявність або відсутність проду тут не впливає.
Що ж до другого питання. Якщо уявити ситуацію при якій «існування продукту» на проді залежить від імплементації якоїсь критичної фічи, то звісно ми можемо сказати, що наступив блокер й все відкласти для розробки АСАП. Але це не схоже на системний підхід, скоріше на якусь екстренну ситуацію.

Зрозумів. Не заздрю і співчуваю вашим командам, якщо ви використовуєте SLA для non-prod енвароментів.
Друге питання ви мабуть трохи не розумієте. Я описав приклад. Якщо трапилася екстрена ситуація, то це баг. З багами все ясно і зрозуміло. Питання було про додатковий функціонал. Якщо він навіть і навчора, то чи є чіткі критерії, які зроблять з нього блокер?

Алекс, а в чому полягає Ваше співчуття, поясніть будь-ласка?

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

Дякую, було цікаво :)!

Дякую за відгук, Євгене. :)

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