Інструкція для команди (user story): як читати, щоб зрозуміти, за що ми платимо

Це для людей, які бачать у Jira, Notion або листі від виконавця рядки на кшталт “As a user I want to…” і не розуміють, чи це нормально, чи нас уже починають дурити.

Чому це болить

Ми замовили розробку. Команда відкрила для нас доступ у свою систему задач. Ми зайшли — і побачили список з десятків карток, кожна з яких починається з фрази “Як [хтось] я хочу [щось]…”. Звучить як магія. На вигляд складно. У договорі написано, що ми за це платимо.

Питання, яке боляче ставити вголос, але треба: звідки ми знаємо, що цей текст узагалі чогось вартий?

Бо буває так, що картки в системі задач — це декорація. Поставили галочку “BA працює над беклогом”, виставили рахунок, поїхали далі. А ми платимо за рядки, які нічого нікому не пояснюють, бо команда розробників все одно прийде до тімліда і запитає словами.

Хороша новина: відрізнити нормальну інструкцію від поганої можна за 30 секунд. Без технічного бекграунду. Зараз покажу як.

Що таке user story — без магії

Це короткий шаблон, у якому одна задача описана з боку користувача, а не з боку розробника.

У IT його називають user story (історія користувача). Це не зашифрований код і не “методологія”. Це просто домовлена форма, у якій усі члени команди описують роботу однаково — щоб не плутатись.

Далі вживатиму “інструкція” і “user story” як синоніми. Англійський термін — щоб ми його впізнавали в листі, український — щоб ми про нього думали без піднесення.

Формула: хто / що / для чого

Класичний шаблон виглядає так:

Як [роль користувача], я хочу [виконати дію], для того щоб [отримати результат].

Розкладемо на прикладі. Уявімо, що ми замовляємо застосунок для оплати комунальних послуг.

Як користувач, який платить комуналку щомісяця, я хочу бачити нагадування за 2 дні до останнього дня оплати, для того щоб не пропустити термін і не платити пеню.

Що тут добре:

“Як користувач, який платить щомісяця” — це не “як юзер”, це людина з обставинами. Розробник тепер знає, що це той, хто заходить рідко, а не той, хто живе в застосунку.
“Бачити нагадування за 2 дні” — це конкретна дія, з конкретним числом.
“Не платити пеню” — це причина, а не повтор дії. І саме причина допомагає команді, коли вони впираються в технічне обмеження і треба знайти варіант.

Якщо знаємо ці три частини — ми вже відрізняємо нормальну історію від несерйозної.

Три ознаки слабкої історії

Ознака 1: розмита

“Як користувач я хочу зручний інтерфейс.”

Це не інструкція. Це побажання. “Зручний” — суб’єктивне слово. “Інтерфейс” — не дія, а абстракція. Така картка в системі задач не дасть розробнику жодного орієнтира — і він зробить так, як уявить сам. Потім ми скажемо “не те”, і почнеться переробка за наші гроші.

Ознака 2: без критеріїв

“Як користувач я хочу оплатити рахунок одним кліком.”

Уже краще. Є дія. Але немає відповіді на питання: що значить “оплачено”? З якими банками? Що бачить користувач після успіху? Що відбувається, якщо банк відмовив? Без критеріїв приймання історія — це початок розмови, а не угода. Про критерії був перший пост серії — варто перечитати, якщо ще не.

Ознака 3: без контексту

“Як адмін я хочу видалити користувача.”

Технічно повна формула. Але — для чого? У яких випадках адмін видаляє користувача? Що з даними після видалення? Чи можна відновити? Без причини команда зробить найпростіший варіант (одна кнопка “видалити назавжди”), а в нас потім вибухне регуляторна проблема, бо за GDPR/КЗПД дані мали зберігатися 3 роки.

Контекст рятує від цього. Одне речення “для того щоб…” закриває половину питань іще до того, як вони з’являться.

Приклад до/після

Беремо реальний рядок, який часто пишуть у задачі:

До (так не треба)

“Додати оплату через Apple Pay.”

Це не історія. Це технічне завдання, написане з боку розробника. Тут немає користувача, немає причини, немає критерію готовності.

Після (так треба)

Як користувач iPhone, який оплачує комуналку зі смартфона, я хочу мати кнопку Apple Pay поряд із кнопкою “Оплатити карткою”, для того щоб не вводити дані картки щомісяця.

Критерії приймання:

Кнопка Apple Pay видима тільки на iPhone (на Android не показується).

При натисканні відкривається стандартний інтерфейс Apple Pay.

Після підтвердження користувач бачить квитанцію на email протягом 1 хвилини.

Якщо Apple Pay недоступний на пристрої — кнопка не показується (а не показує помилку).

Друга версія — це угода. Ми можемо взяти телефон, відкрити застосунок і за хвилину перевірити, чи зроблено те, що замовляли.

Як попросити переписати без сварки

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

Краще працює така фраза:

“Я хочу простіше орієнтуватись у задачах. Можете для [конкретна задача] додати причину (‘для того щоб…’) і 3-5 критеріїв приймання? Це мені треба, щоб самому потім перевірити, чи зроблено те, що ми домовлялися.”

Що відбувається в цій фразі:

Ми не критикуємо команду. Ми описуємо свою потребу.
Просимо не “переписати все” — а доповнити конкретну задачу.
Пояснюємо, навіщо нам це треба — щоб самим перевірити. Це нормальне і зрозуміле прохання, а не “вчити команду роботі”.

У 9 випадках із 10 команда зробить — і часто скаже спасибі. Бо тімліду самому простіше, коли картки в системі задач написані по-людськи.

Часті помилки на цьому етапі

Думаємо, що user story пишемо ми. Зазвичай їх пишуть BA або тімлід. Наша задача — читати і ставити питання. Якщо нам нав’язують писати самим — це або сильна команда хоче навчити нас (добре), або слабка команда перекладає на нас свою роботу (погано).
Не звертаємо уваги на причину “для того щоб”. Це найслабкіша частина у 70% історій, які я бачив. Без неї команда робить за уявленням, а не за нашою бізнес-метою. Завжди питаємо: “а навіщо?” — і записуємо відповідь у картку.
Великі історії не розбиваємо. Якщо інструкція займає більше двох екранів — це не одна історія, а пакет з 3-5. Розбити їх перед стартом дешевше, ніж переробити після.
Підписуємо беклог “пакетом” на 3 місяці. Не треба. Достатньо описати наступні 2-3 спринти, а далі — додаємо в міру того, як з’являється конкретика. Контракт повинен дозволяти такий формат.

Що буде далі

Це третій пост серії про артефакти бізнес-аналізу. Попередні матеріали — про критерії приймання і про брифінг до контракту.

Наступний — про оцінку від IT-компанії. Як читати рядок “200 годин · $25K” і де у виконавця можуть бути інші інтереси, ніж у нас, плюс чому “fixed price” не завжди дешевший за погодинну роботу.

Якщо не хочемо пропустити — стежимо за мною у LinkedIn, там анонсую кожен матеріал серії.

Якщо ми зараз дивимось на беклог від виконавця і не розуміємо, чи це нормальні історії, чи декорація — це привід поставити паузу. У Ascend Griffin ми робимо короткі Discovery Call — 30 хвилин, щоб подивитися на ваші документи разом і сказати чесно, де ризики.