Прихована ціна розмитих Jira-тікетів
Розмита задача в Jira рідко здається небезпечною з першого погляду. Справжня проблема приходить пізніше, коли різні люди по-різному розуміють недомовлене, і кілька днів зосередженої роботи виявляються витраченими не туди.
Чому розмиті задачі так довго живуть
У понеділок вранці розробник бере задачу. Заголовок ніби конкретний: «Додати сповіщення для користувачів про оновлення замовлення». В описі всього два рядки і посилання на обговорення в Slack тритижневої давності. На перший погляд цього достатньо. За три дні він збирає ланцюжок поштових сповіщень, який спрацьовує за кожної зміни статусу замовлення.
У четвер менеджер продукту дивиться зміни й каже: «Я мав на увазі не це. Нам потрібні були лише сповіщення всередині застосунку про події доставки, і в користувача має бути можливість відмовитися». Ніхто не помилився. Ніхто не лінувався. Просто задача так і не винесла назовні рішення, які в ній уже були заховані.
Ніхто не пише розмиту задачу навмисно. Її накидають за пару хвилин між зустрічами, з думкою потім повернутися і дописати деталі. І не повертаються. У момент написання весь контекст ще в голові автора. Він знає, які події важливі, які канали має на увазі і яких користувачів це стосується.
Але на сторінку це не потрапляє, бо здається «і так очевидним». Не очевидним.
Jira лише посилює це тим, що все занадто просто створити. Немає обов’язкового поля, яке спитає, що явно не входить у задачу. Немає обмеження, яке не дасть зберегти опис із двадцяти слів. Можна ввести три слова в заголовок, лишити опис порожнім і натиснути «Створити». Jira не заперечить. У цьому і сила, і пастка. Так і з’являється беклог, повний карток, які виглядають завершеними лише з першого погляду, а показують свою розмитість уже тоді, коли по них починають робити реальну роботу.
Що взагалі має бути в плані, готовому до розробки
Більшість задач відповідають на одне питання: що ми хочемо зробити? План, за яким справді можна працювати, відповідає на шість.
| Частина плану | На яке питання відповідає |
|---|---|
| Межі задачі | Що входить у роботу, а що явно не входить |
| Обмеження | Що не можна змінювати або ламати |
| Кроки | Що має статися і в якому порядку |
| Нестандартні випадки | Що робити, якщо звичний сценарій ламається |
| Залежності | Що має існувати заздалегідь |
| Критерій готовності | Як команда зрозуміє, що робота справді завершена |
Це не чеклист для кожної дрібної правки в беклозі. Але все, що йде в спринт і майже напевно з’їсть більше ніж кілька годин чиєїсь роботи, має отримати відповіді на ці питання ще до старту. Найчастіше команди пропускають саме межі задачі. Формулювати, що «не входить», здається зайвим, коли всі зосереджені на тому, що входить. Але саме тут дуже часто й починається переробка.
Обмеження — це тихі вимоги:
- не ламати поточний потік поштових сповіщень про замовлення;
- залишатися всередині вже наявного сервісу сповіщень;
- не піднімати нову інфраструктуру в цьому спринті.
Такі речі рідко записують, бо авторові здається, ніби всі й так це знають. Не знають. А критерій готовності — це межа між «мені здається, усе готово» і «ми домовилися, що це готово». Хороший критерій готовності можна перевірити й побачити.
Спочатку запитання, потім структура
Майже в кожній Jira рано чи пізно відбувається один і той самий цикл. Хтось додає шаблон опису з розділами на кшталт «Коротко», «Критерії приймання», «Технічні нотатки» і «Що не входить». Кілька тижнів люди чесно його заповнюють. А потім та сама розмита мова, яка раніше жила в голому описі, просто розповзається по більшій кількості підписаних блоків. Структури стало більше. Ясності — ні.
Шаблони не вирішують проблему, бо проблема не у формі. Вона в мисленні. Автор сам ще не розуміє, чого саме бракує. Порожній розділ «Нестандартні випадки» не допоможе людині, яка про них ще не замислилася. Допомагають запитання. Конкретні запитання, які змушують ухвалити рішення.
Особливо добре витягують приховані рішення п’ять запитань:
- Що саме змінюється в поведінці системи?
- Хто головний користувач і чого він намагається досягти?
- Чи є випадок, коли цього взагалі не має статися?
- Що зламається, якщо ми це не випустимо?
- Це стосується наявних користувачів, нових чи всіх одразу?
Ці запитання працюють тому, що на них можна відповісти предметно, але при цьому вони підходять майже до будь-якої продуктової задачі. Сам акт відповіді на них і є плануванням. Шаблон — лише місце, куди потім лягають відповіді.
Повний приклад
Ось як це виглядає на практиці. Початкова задача крихітна: «Додати сповіщення для користувачів про оновлення замовлення». В описі лише фраза про те, що користувач має отримувати сповіщення при зміні статусу замовлення, плюс примітка «звіритися з дизайном щодо візуального рішення». Цього достатньо, щоб задача потрапила в спринт. Але майже напевно недостатньо, щоб упевнено по ній будувати роботу.
Коротке коло уточнювальних запитань змінює все:
| Уточнювальне запитання | Відповідь |
|---|---|
| Які статуси важливі? | Лише «відправлено» і «доставлено» |
| Які канали? | Лише сповіщення всередині застосунку в цьому спринті |
| Чи можна відмовитися? | Так, за замовчуванням сповіщення ввімкнені |
| Що робити, якщо користувач не в мережі? | Поставити сповіщення в чергу до наступного входу |
| Це стосується вже наявних замовлень? | Ні, лише нових |
| Що робити, якщо відправка не вдалася? | Один повтор, потім запис у журнал |
За п’ятнадцять хвилин задача означає для всіх одну й ту саму річ. У новій версії з’являються реальні межі, реальні обмеження, впорядковані кроки, справжні нестандартні випадки і критерій готовності, який можна перевірити. Задача та сама. Ясність — зовсім інша. Різниця не в кращому шаблоні, а в невеликому, але усвідомленому колі запитань до початку роботи.
Де тут допомагає ШІ
ШІ не пише задачі. Задачі пишуть люди. Але ШІ дуже корисний в одній конкретній точці процесу: після того, як намір уже з’явився, і до того, як структура остаточно зафіксована. Мовна модель добре читає розмитий опис і питає: «А що буде, якщо користувач не в мережі?» Вона вміє брати розрізнені відповіді з обговорення в Slack і розкладати їх за межами задачі, обмеженнями й кроками. Вона вміє помічати, що в плані спливає перенесення даних, а серед залежностей про потрібну перевірку взагалі нічого не сказано.
Чого ШІ не вміє, так це ухвалювати продуктові рішення за вас. Він може спитати, чи це має бути лист, push чи сповіщення всередині застосунку. Але не знає, який варіант правильний саме для ваших користувачів і саме в рамках цього спринту. Він може запропонувати правдоподібний критерій готовності, але тільки людина, яка розуміє продукт, знає, чи справді цей критерій правильний.
Логіка тут проста: люди вирішують, ШІ допомагає навести лад. Люди задають межі, ШІ підсвічує прогалини. Саме за цим принципом — уточнити, спланувати, виконати — і побудований Just в Atlassian Marketplace. Той самий принцип працює і вручну. ШІ просто прискорює цикл.
Три речі, які можна зробити вже сьогодні
- Перед наступним спринтом візьміть найрозмитішу задачу зі списку і поставте до неї п’ять запитань із цієї статті ще до того, як хтось напише перший рядок коду. Майже напевно з’ясується, що щонайменше два важливі рішення все ще ніхто не ухвалив.
- Запишіть відповіді не в окремий документ, а прямо в задачу: що входить у роботу, які є обмеження і за яким критерієм команда зрозуміє, що все готово.
- Вважайте шаблон відправною точкою, а не стандартом. Підлаштовуйте його під мову своєї команди, але не пропускайте запитання. Якщо потрібен ширший контекст того, чому цей крок із уточненням стає ще важливішим, коли розмиті задачі починають напряму віддавати ШІ, перша стаття серії детально розбирає проблему розсинхрону: Чому більшість ШІ-інструментів для Jira посилюють проблему розсинхрону, а не вирішують її.
