У цій статті я розповім, чому для проєктування функціональності наших продуктів замість стандартних ТЗ ми використовуємо методологію User Story Mapping і як це допомагає нам вести розробку швидко і якісно.
Дисклеймер: у статті я не закликаю остаточно і безповоротно відмовитися від ТЗ, але хочу сказати, що класичне ТЗ підходить не у всіх ситуаціях, і не для всіх команд розробки.
Міфи про ТЗ
Головний міф про ТЗ – технічне завдання життєво необхідне, щоб розробка будь-якого цифрового продукту була виконана якісно, а без нього все буде дуже погано.
У такому підході написання ТЗ – це окремий етап розробки, на виході з якого з’являється детальний, максимально детальний документ, в ідеалі, написаний за ДСТУ. І без такого документа до команди розробників навіть підходити не можна. Навіть серед команд, що працюють за Scrum, нерідко трапляються такі, де завдання на розробку приходять тільки після підготовки аналітиком ПТЗ – приватного технічного завдання.
При цьому, як правило, всі учасники процесу забувають, що ГОСТи були придумані на зорі цифровізації. Виходить, що вони практично не змінювалися з тих часів, коли ЕОМ були розміром з хорошу шафу-купе, пам’ять цих монструозних обчислювальних машин була як у рибки, а підходи до розробки були зовсім іншими.
До сих пір у міждержавному стандарті ГОСТ 19.101-77 є вимога докладати лістинг програм “Текст програми” (фізична роздруківка програмного коду) нарівні з іншими обов’язковими документами, які входять до проєктної та робочої документації.
Але, навіщо?!
Згадаймо, що в ті давні часи ще не було не тільки “хмар”, AirDrop, GitHub та інших класних речей, а й навіть елементарних дискет. Просто не існувало жодної фізичної можливості перенесення програми з однієї ЕОМ на іншу. І оператори ЕОМ щоразу вводили програму вручну, передруковуючи текст із того самого обов’язкового документа “Текст програми”.
Власне, як спадщина тих часів, досі широко поширені каскадна розробка (Waterfall) і підхід до документування за ДСТУ, що стали актуальними саме в той час. Наприклад, так пишуть у Вікіпедії:
Без ривка у сфері обчислювальної техніки, зробленого в 1940-ті рр. і чітко сформульованого технічного завдання до розробників такого роду, обчислювальна техніка не розвинулася б до сучасних комп’ютерів…
У 1970-х було розроблено стандарти оформлення проєктної та робочої документації на розроблення ПЗ, а чітко сформульоване ТЗ було не тільки життєвою необхідністю, а й запорукою успіху всього процесу розроблення та введення ПЗ у промислову експлуатацію.
Держзамовники (і не тільки вони!) і зараз дуже люблять писати завдання на розробку за ДСТУ – здається, що це гарантує якість. Чому? Тому що створює ілюзію того, що перебіг усього проєкту буде під контролем, якщо все детально задокументовано. А якщо раптом у процесі виявляються відхилення, потрібно повернутися на крок назад і почати все заново – з переробки ТЗ.
В умовах відсутності конкуренції цей підхід був цілком виправданий: не спалюються ресурси на розробку, не витрачається даремно цінний час роботи ЕОМ, все регламентовано і документовано.
Проблеми ТЗ для продуктового розроблення
Чи застосовний такий підхід до розробки в сучасних реаліях? Застосовний, але для проєктної, а не продуктової розробки.
У чому ж відмінності?
Проєкт – завжди кінцевий, як за бюджетом, так і за термінами запуску. Спрощено: виграти тендер, написати суворе і чітке ТЗ за вимогами замовника, виконати за ним розробку і запуск проєкту до заданої дати, і після цього про існування проєкту забути – це проєктний підхід. Під проєкт, як правило, збирається команда, яка буде розформована або переведена на інші завдання одразу після успішного (або не дуже, тут вже як пощастить) запуску проєкту. І в цьому випадку розробка з ТЗ виправдана.
Продукт – це постійний розвиток. Продуктова розробка – це безперервний нескінченний процес, що ставить перед постійною командою виклики: розробляти новий продукт, виводити його на ринок, розвивати та покращувати, формулювати гіпотези, оновлювати інтерфейси, додавати нові фічі, збирати метрики та на їхній основі будувати нові плани, не маючи визначеного терміну завершення роботи. Успішність і готовність продукту вимірюються прибутковістю, затребуваністю, розумінням потреб клієнтів і готовністю до швидких змін, а тому проєктний підхід тут практично не застосовується.
У нас у компанії ведеться продуктова розробка крос-функціональними командами, і наша основна мета – швидкий і успішний розвиток продуктів. Тому в наших умовах тривале проєктування і написання ТЗ призвели б до істотних втрат: цінності, часу, якості та ресурсів.
Втрата цінності
У проєктній розробці, як правило, ТЗ опрацьовує одна людина: системний аналітик або технічний письменник. Іноді, якщо компанія серйозно обмежена в ресурсах, то навіть менеджер проєкту.
Ця людина спочатку спілкується з бізнес-замовником, збирає набір вимог до системи й описує їх у величезному, за обсягом, документі. Водночас, у більшості випадків, описувана функціональність системи – це або особисті забаганки замовника, або пряме копіювання у конкурентів, не підтверджене дослідженнями, гіпотезами, опитуваннями, метриками і даними.
По суті, на вході системний аналітик отримує набір “галюцинацій” (відмінний термін від ФРІІ), на основі яких проєктує рішення, формує вимоги і оформляє це все в ТЗ. Далі цей документ відправляють на реалізацію в команду розробки, вимушену сліпо і максимально точно слідувати написаному.
І на ділі, аналітик часто не знає, що дійсно потрібно кінцевому користувачеві, тому що не завжди добре занурений у контекст, якщо взагалі занурений.
Втрата часу
У проєктній розробці технічне завдання – фундамент усього проєкту. Йому має приділятися достатньо часу та уваги, щоб усі зацікавлені сторони переконалися: проєкт буде таким, як планувалося на початковому етапі.
Однак, зазвичай ТЗ пишеться “на конвеєрі” та в умовах постійного браку часу. Замовники не вважають за потрібне прочитати його, хоча б поверхнево, кажучи “Ой, я все одно в цьому нічого не розумію”, а розробники не вникають у деталі, роблячи те, що вони звикли робити раніше. У підсумку на виході з’являються розбіжності між картинкою, придуманою замовником, вимогами, описаними аналітиком, і результатом, розробленим командою. І проєкт іде на наступний виток із тими ж самими кроками: нове ТЗ, нові узгодження, зрушення термінів запуску.
Втрата якості
Аналітик:
- не може на самоті на етапі проєктування врахувати всі можливі аспекти розробки;
- не здатний проєктувати рішення на рівні системного архітектора (і не повинен);
- не відстежує нові інструменти, фреймворки і тренди розробки, тому що у нього часу на це немає;
- і навіть не завжди достатньо технічно підкований, щоб розбиратися в складних програмних нюансах.
На жаль, мені не так давно ще зустрічалися ТЗ, де інтеграція із зовнішньою системою описувалася однією фразою: “ресурс А буде інтегрований з ресурсом Б”. Тобто все, починаючи з моделі даних, закінчуючи схемою взаємодії, залишалося таємницею, покритою мороком.
Звичайно, тут могли б допомогти розробники, але проєктний підхід не передбачає їхнього підключення на стадії ТЗ і веде до подорожчання проєкту, на яке замовники йти не готові. У підсумку, якість проектування страждає, якість розробки, як наслідок, падає, якість випущеного проекту залишає бажати кращого.
Ресурси розробки обмежені
Якщо одна жінка здатна народити дитину за 9 місяців, це не означає, що 9 жінок здатні народити дитину за місяць. З командою розробки працює точно такий самий принцип: на якісну розробку складного комплексного програмного рішення потрібні сильні, досвідчені розробники, часовий ресурс яких обмежений. І коли розробка ведеться строго за ТЗ, далеко не факт, що ми використовуємо цей ресурс оптимально, тому що запуск проєкту відбудеться тільки після того, як буде виконано реалізацію всіх завдань за ТЗ.
У моєму досвіді був кейс, коли розробка велася 2 роки, і випущений “у світ” проєкт встиг за цей час морально застаріти, хоча замислювався як інноваційний.
(◕‿◕) Ми у Telegram: Анонси нових статей та бонусні матеріали
User Story Mapping: що це таке і в чому користь такого підходу
У нашому робочому процесі ми активно використовуємо методологію User Story Mapping. USM або карта користувацьких історій – це інструмент проєктування продукту, в основі якого лежить шлях клієнта. На зображенні наведено приклад шаблону User Story Map, уже в підсумковому, повністю завершеному вигляді, а нижче розглянемо, як така карта складається.
Як складається USM?
Робота над картою користувацьких історій складається з шести основних кроків:
- Формулюємо проблему: що, для кого і навіщо ми збираємося робити.
- Змальовуємо загальну картину: дивимося на верхньорівневі процеси і дії користувача, проходимо його кроками, рухаючись “на кілометр вперед, на сантиметр углиб”. Кожну дію фіксуємо як окремий епік.
- Досліджуємо і деталізуємо історії: вивчаємо можливі типи користувачів, розглядаємо різні варіанти виконання дій, опрацьовуємо негативні сценарії – так у нас з’являються користувацькі історії користувачів, які можна додатково декомпозувати на окремі завдання.
- Виокремлюємо релізну стратегію: концентруємося на тому, що насамперед потрібно бізнесу і людям, для яких створюємо продукт. Визначаємо тривалість спринтів, ємність команд, графік релізів.
- Виокремлюємо дослідницьку стратегію: що увійде до MVP, які гіпотези в нас є, як ми зможемо їх перевірити. Виділяємо ті історії, без яких продукт не зможе існувати, і відкладаємо все, що можна виключити на першому етапі без втрати ключових можливостей.
- Виділяємо стратегію розробки. Ділимо MVP на частини, з точки зору послідовності розробки так, щоб якомога раніше все запустити. У підсумку ми отримуємо чітку послідовність завдань, розбитих на спринти, і бачимо, в які строки зможемо поставляти оновлення продукту для наших клієнтів.
Як кроки виглядають на практиці?
Ми працюємо в розподілених командах, де всі працюють віддалено, а карта користувацьких історій – це інструмент для постійної роботи, тому для USM ми використовуємо Miro. Усі приклади, які я наведу нижче, взяті з реального життя, з дошки однієї з наших команд. Отже, пройдемося кроками нашого процесу.
Формулюємо проблему
Нещодавно в нашому мобільному застосунку ми вирішили запустити крос-продажі кредитних продуктів клієнтам банку. Якщо для банку це додатковий прибуток, то для клієнта – схвалений кредит без необхідності заповнювати довгу заявку, відвідувати офіс і приносити документи менеджеру.
Змальовуємо загальну картину
Під час складання загальної картини ми залучаємо стейкхолдерів, на цьому етапі відбувається активна взаємодія власників продукту й аналітиків, щоб спільними зусиллями зрозуміти, як користувач взаємодіє з продуктом.
Так, у випадку з крос-продажами, ми пройшли всіма кроками оформлення кредиту, які зазвичай виконують клієнти, і склали загальну послідовність дій.
Досліджуємо та деталізуємо історії
Після того, як визначено кроки, кожен зафіксований епік і призначену для користувача історію можна і потрібно додатково декомпозувати, не забуваючи про цінність для клієнта.
Формат користувацької історії спочатку має на увазі формулювання “Я, як користувач, хочу X, щоб отримати Y”. Але для дошки в Miro така фраза занадто довга, тому:
- у заголовок ми виносимо ключову дію, наприклад “Завантажити документи, що підтверджують дохід”;
- а в описі історії фіксуємо “Я, як користувач, хочу сфотографувати і прикріпити до заявки документи, що підтверджують дохід, щоб заощадити час і отримати схвалення великої суми без відвідування офісу”.
Декомпозицію історій виконують доти, доки кожна з історій не відповідатиме критеріям INVEST (незалежність, обговорюваність, цінність, можливість оцінювання термінів реалізації, компактність, тестованість).
І скелет USM у Miro починає обростати деталями.
Під час декомпозиції історій ми додатково шукаємо відповіді на запитання:
- кому ще функціональність може бути цікава;
- які у нас є обмеження і які з них дійсно критичні;
- які виняткові ситуації можуть виникнути;
- чи можемо ми вирішити це саме завдання іншими способами?
Цей етап – найважливіший. Саме тут можна знайти моменти, які викликатимуть у користувача wow-ефект під час роботи з продуктом, і усунути перешкоди, які здаються вже звичними. Так, наприклад, ми виявили, що для зарплатних клієнтів банку зовсім не обов’язково вимагати документи, що підтверджують дохід, і клієнтський шлях для таких клієнтів можна скоротити втричі, зробивши просте визначення типу клієнта на вході в заявку!
На цьому ж етапі у нас виконується оцінка трудовитрат на реалізацію кожної історії в сторіпойнтах (SP). Але тут є важлива деталь: у SP ми оцінюємо не стільки час, який буде витрачено на розробку, скільки зусилля на вирішення завдань: об’ємність, складність, зрозумілість для розробників, можливі ризики.
Завдання з передачі документів на перевірку саме по собі не складне для нашої команди. Але воно вимагає виконати інтеграційне тестування із суміжною системою, до якої мають бути передані документи, і тестування всього процесу, від прикріплення документів до отримання результатів їхнього розгляду, – а це вже суттєве ускладнення всієї історії.
Виділяємо релізну стратегію
У нас стандартна довжина спринту – два тижні, і в кожному спринті місткість команди, що займається кредитами (velocity) – 21 SP. Однак, реальна місткість завдань у спринті залежатиме від кількості свят і вихідних днів, а також можливих відпусток розробників. Тому для визначення релізної стратегії важливо розрахувати не тільки місткість команди, а й місткість (capacity).
Наприклад, при середній ємності в 21 SP, в одному зі спринтів одразу троє колег із команди збираються піти у відпустку, і місткість становитиме лише 7 SP. У релізній стратегії важливо це врахувати, тому що це безпосередньо вплине на той обсяг завдань, який команда встигне виконати в конкретний спринт.
Виділяємо стратегію досліджень
Визначивши релізну стратегію і маючи набір оцінених завдань, ми можемо переходити до пріоритизації та формувати послідовність, у якій реалізовуватимемо завдання з огляду на їхню важливість для клієнтів і прибутковість для бізнесу.
Під час роботи на дошці це виглядає як розкладання історій за спринтами з урахуванням їхньої оцінки та місткості команди в конкретному спринті. На виході з цього етапу ми отримуємо цілісну картину, зрозумілу не тільки розробникам і аналітикам, а й стейкхолдерам, без необхідності вчитуватися в детальну документацію. На такій дошці відразу видно, що робимо, коли і який результат отримаємо.
А далі йде розробка і реалізація з командою, але це вже інша історія…
Як USM закриває проблеми?
Коли ми складаємо карту користувацьких історій, ми розбираємо кожен крок клієнта, і не просто розуміємо, чого він хоче, а й з якою метою. А вже на основі опрацьованих користувацьких цілей і потреб розробляємо і формалізуємо вимоги до системи. Під час розроблення функціональності за цими вимогами ми плануємо роботи так, щоб ресурси розроблення використовувалися максимально ефективно. Давайте звіримо, як же USM закриває проблеми, які були описані вище?
Постійно пам’ятаємо про цінність
Ми розробляємо USM на основі цінності для клієнта, і весь беклог заснований на користувацьких сценаріях. Для розробки завжди обираємо тільки те, що дійсно важливо для користувача і несе цінність для бізнесу.
Економимо час
Очевидно, що за такого підходу немає зайвої роботи ні в кожному спринті, ні загалом. Ми робимо тільки те, що дійсно необхідно для досягнення наших цілей, не витрачаємо час на опис зайвих фіч у ТЗ. А завдяки гнучким методологіям, ми можемо оперативно переглянути наші плани, якщо зрозуміємо, що сформульовані гіпотези не підтвердилися метриками і ми йдемо кудись не туди.
Зберігаємо високу якість розробки
Користувацькі історії опрацьовуються всією командою під час спільних обговорень. Історія вважається готовою до розробки тільки після того, як кожен член команди підтверджує, що йому все зрозуміло, домовленості про реалізацію досягнуто, критерії приймання визначено, і вся команда з ними згодна. Такий підхід дає змогу зберігати високий рівень залученості команди та зацікавленості в кінцевому результаті.
Чому ми обрали User Story Mapping?
Важливо! Такий підхід не скасовує документацію.
Усе описане не означає, що в нас уся документація обмежується дошкою в Miro або будується на усних домовленостях у команді. Просто ми йдемо від зворотного: не пишемо ТЗ і не ставимо за ним завдань.
Спочатку ми формулюємо історії та описуємо призначені для користувача сценарії, потім обговорюємо разом із командою критерії приймання, технічні нотатки, опис опрацювання помилок і способи розв’язання, деталі реалізації, і вже потім підтверджуємо всі домовленості та формалізуємо їх у Confluence.
Як підсумок отримуємо і готову документацію, і список завдань. При цьому кожен член команди знає, що він робить і навіщо, і у кожного члена команди є єдине розуміння бізнес-контексту.
Головне в USM для нас – це гнучкість і адаптивність, формування особливої культури розробки, коли кожен учасник команди розуміє свою роль, пропонує оптимальні варіанти реалізації, може впливати на результат, а не просто пише код за ТЗ.
