Service Level Agreement як пігулка від стресу
Усім привіт, мене звати Настасья Ровінська, наразі маю честь бути 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 обрали наступні критерії:
- пріоритет багу;
- частота відтворення;
- час реагування.
Розглянемо ці критерії детальніше. Крім класичного підходу пріоритезації багів, встановили визначення, що саме мається на увазі під кожним пріоритетом. Так отримали:
- «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 в цілому. Проаналізуйте які перепони стають на шляху та як їх можна усунути.
Команда та взаємодія дійсно важливіші за будь-які процеси. Справний продукт дійсно важливіший за вичерпну документацію. Але дорослі команди готові випробувати різні інструменти та відкриті до будь-яких експериментів задля досягнення мети та спільного задоволення.
17 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів