Як ми налаштували Continuous Discovery Process у Jira

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт, мене звати Оксана, і я Product Manager, який вже 7+ років допомагає продуктовим командам покращувати підходи та процеси, пов’язані з дискавері активностями. Зараз працюю із 5 продуктовими командами застосунку Мій Київстар, і мені дуже імпонують аджайл підходи та практики Continious Discovery, які вдалось тут реалізувати.

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

Тому в цій статті хочу поділитися простими та практичними кроками, які вдалось реалізувати в моїх командах деякий час тому, і які справно працюють і приносять цінність навіть через декілька років опісля впровадження.

Що таке Continuous Discovery

Сам термін Continuous Discovery популяризувала Тереза Торрес, відома коучка з продуктового мислення та авторка книги Continuous Discovery Habits.

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

Зауважте, що в цій статті я зосереджуся виключно на формалізації процесу у Jira, але не буду надавати інструкцій щодо налаштувань Jira Software чи акцентуватися на теорії і фреймворках дискавері — тут рекомендую звернутися до наступних книг:

• Continuous Discovery Habits (Тереза Торрес).
• Inspired: How To Create Tech Products Customers Love (Марті Кеґан).
• Escaping The Build Trap (Мелісса Перрі).
• Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (Джейк Кнапп, Джон Зератські, Брейден Ковіц).

Додатково до Jira ми використовували інструменти, такі як Miro/FigJam, для візуалізації результатів наших досліджень і тестування, які потім зв’язували з Jira. Проте метою цієї статті є не акцент на створених в цих системах артефактах, а сам факт їхньої інтеграції у наш процес.

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

Основні челенджі, з якими зіштовхнулася команда

• Jira використовувалася лише як «інструмент для створення задач для розробників».
• Слово «discovery» кожен розумів по-своєму.
• Усі ідеї фіч (гарні чи погані) без попередньої валідації одразу потрапляли до розробницького беклогу.
• Продуктовий беклог потенційних ідей пріоритизували та валідували в Excel.
• Певним продуктовим рішенням передувало якісне дискавері, якісь — просто йшли в роботу без жодної валідації.
• Часті зміни вимог, переробки та затримки, бо не завжди впроваджені рішення допомагали досягнути бізнес-цілей чи вирішували болі користувача.

Головним завданням було забезпечити:

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

З урахуванням цього ми побудували новий підхід, заснований на процесі Continuous Discovery та Double Diamond Framework, та інтегрували його у робочий процес команди за допомогою Jira Software. Важливо зазначити, що на той момент уже існував модуль Jira Product Discovery, втім це рішення було ще сируватим, і для економії часу та ресурсів я все ж таки вирішила використати існуючий модуль Jira Software.

Хай-левельний план, з якого ми стартували

Крок 1. Визначити драфтовий процес Continuous Discovery, який відповідає потребам, цілям і наявним ресурсам.
Крок 2. Налаштувати його в Jira (і протестувати на одній з команд).
Крок 3. Скомунікувати та провалідувати зі стейкхолдерами.
Крок 4. Отримати фідбек після перших ітерацій і уможливити розвиток процесу.

Крок 1: Визначення основних активностей процесу Continuous Discovery

Як вже згадувалось раніше, Continuous Discovery Process — це ітеративний процес ідентифікації та валідації проблем і можливостей, що здійснюється шляхом постійного дослідження та перевірки гіпотез/припущень для досягнення цілей продукту, і це доволі часто потребує декількох ітерацій.

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

Ось як я змоделювала етапи цього процесу та промапила їх до активностей, які відбуваються в Jira:

Крок 2: Налаштування процесу у Jira (і тестування)

Щоб цей процес працював у Jira, варто зробити наступне:

1. Створити окремий тип задачі під назвою «Opportunity».
2. Налаштувати кастомний воркфлоу для типу задачі «Opportunity».
3. Створити окрему дошку Kanban під назвою «Discovery» із фільтром, який відображає лише задачі типу «Opportunity» із підзадачами «Sub-task» та з належними колонками.
4. Правильно зв’язати статуси задач типу «Opportunity» із відповідними колонками на дошці Kanban.
5. Створити дашборд для продуктової команди, щоб відстежувати підзадачі та кінцеві терміни виконання.

Нижче детальніше зображено, як це все виглядає у Jira.

Тип задачі «Opportunity»

Opportunity (проблема чи нова можливість) — це будь-яка ідея фічі, проблема/можливість/бізнес ціль чи бажання користувачів, виявлені під час інтерв’ю чи зворотного зв’язку. Або навіть запити стейкхолдерів щодо нової функціональності.

Відокремлення в окремий тип задачі є важливим моментом, адже дозволяє команді завжди знаходити всю інформацію, пов’язану з дослідженням, і краще розуміти, чому впроваджується те чи інше рішення, але водночас уникати перевантаження Stories та Dev Tasks інформацією, які зазвичай використовують для опису Acceptance Criteria та деталей технічної імплементацї.

Таким чином, коли рішення буде провалідоване для розробки, ви створюєте Epics і Stories у беклозі розробки та пролінковуєе Opportunity із відповідними Epics/Stories.

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

Ви можете налаштувати поля задачі Opportunity відповідно до ваших потреб. Я пропоную розпочати з наступних атрибутів, але за необхідності додати більше:

• Issue Key, Summary і Description (обов’язкові поля).
• Assignee (відповідальний) і Reporter (ініціатор) — теж обов’язкові.
• Priority (використовується для визначення бізнес-цінності або впливу на користувача).
• Estimate (оцінка) — можна використовувати години, Story Points або розмір «T-shirt» для оцінки складності роботи з задачею.
• Links:

• посилання на інші елементи в Jira (Epics, Stories, Components)
• посилання на зовнішні інструменти, такі як Confluence, Miro, Figma тощо.

Для деталізації кожного дослідження та документації ви можете використовувати сторінку в Confluence, щоб зберігати всі отримання знання від дослідження в більш візуалізованому вигляді. Ідеально створити шаблон для такої документації та пов’язати його з задачею Opportunity у Jira.

Таким чином ви зможете структурувати процес Product Discovery для кожної Opportunity в Confluence, зберігаючи всі деталі для майбутнього використання.

Opportunity workflow

Знову ж таки, я рекомендую почати з цього дуже простого процесу, але поступово адаптувати його відповідно до вашої конкретної ситуації разом із командою.

Я спеціально об’єдную етапи Ideate & Evaluate та Test & Learn в один статус у Jira.

• З практичної точки зору ці процеси зазвичай сприймаються як вхідні та вихідні дані одного етапу, що дозволяє зробити воркшопи чи командні зустрічі більш ефективними та результативними.
• До того ж це допомагає заощадити місце на Kanban-дошці.

Однак за бажанням ви можете розділити ці статуси або додати додаткові колонки, що відповідають особливостям вашого процесу.

Окрема «Discovery» дошка з пролінкованими статусами

Ви можете використовувати функцію Backlog для вашої Kanban-дошки Discovery, щоб відображати на ній лише ті можливості, які наразі відібрані для дослідницьких активностей. Якщо це підходить для вашого випадку — ви можете зв’язати статус «Open» з логікою беклогу.

Це дозволить краще організувати роботу, відокремивши можливості, що перебувають на етапі підготовки, від активних завдань у процесі Discovery.

Дашборди, щоб відслідковувати задачі та підзадачі за пріоритетом, датою чи іншим атрибутом

З точки зору трекінгу задач ми створили окремі дашборди для:

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

Щоб покращити відстеження прогресу та проблем, можна додати:

• Різноманітні гаджети чи ад-они, які допомагають візуалізувати дані про прогрес.
• Фільтри за ролями у Discovery (наприклад, дизайн, технічний, продуктовий, аналітика даних тощо) або за стрімами/ назвами команд, якщо їх декілька.

Це забезпечить кращу прозорість процесу та дасть змогу кожному учаснику швидко знаходити релевантну інформацію.

Крок 3: Узгодження та комунікація процесу Discovery

Композиція команди та колаборація

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

Виділіть час на комунікацію та узгодження їхніх робочих процесів з процесом Discovery і поясніть, як працюватиме механіка в Jira. Особливо важливо пояснити роботу з підзадачами, формат і спосіб виконання роботи, які активності будуть проводитися разом (воркшопи з ідеації, підходи до брейнстормів), які індивідуально. Ідеально було б створити RACI-матрицю. Це допоможе уникнути плутанини, забезпечить прозорість процесу та чітке розуміння ролей кожного члена команди.

Цілі та валідація

Обговоріть важливість комунікації та прописування цілей, задля яких створюється кожна задача; які цільові метрики і показники ви будете відстежувати для кожної Opportunity.

Визначте підхід до формулювання гіпотез, критерії валідації заздалегідь та поділіться ними зі стейкхолдерами цього процесу.

Проговоріть, який у вас доступний арсенал інструментів для тестування та валідації рішень: юзабіліті тестування з вашим прототипом, A/B тестування чи щось інше.

Узгодження з наявними процесами

Цей процес добре працює як зі SCRUM, так і з Kanban виглядом налаштувань проекту в Jira, але важливо узгодити підхід до пріоритетизації (що означає кожен пріоритет, як команда пріоритизує можливості), підхід до оцінки (чи вибираєте ви T-shirt, story points години, або ідеальні дні, і як виглядатиме процес оцінки), правила перехресного лінкування задач, лінкування задач із сторінкою в Confluence або іншими ресурсами. Крім того, вам також потрібно визначити ваші ітерації та розклад зустрічей для синхронізації по процесу.

Комунікація процесу зі стейкхолдерами

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

• Для продуктової команди — основна увага має бути приділена співпраці: хто овнить процес, хто фасилітує, хто може проводити дослідження, хто залучений в процеси тестування. Як отримати доступ до матеріалів дискавері, як процес Discovery пов’язаний з процесом делівері, які очікування від розробників під час активностей дискавері.
• Для інших крос-функціональних команд — загальне ознайомлення з процесом, яку цінність він приносить, як він пов’язаний з їхніми процесами, як впливає на пріоритизацію/ роудмапу та як отримати доступ до будь-яких матеріалів.
• Для спонсора, інших стейкхолдерів — хай-левельні переваги процесу, скільки часу займе його імплементація, яку цінність зможе команда принести завдяки цьому.
• Як опцію я також створила сторінку в Confluence в розділі «How we work» та задокументувала процес і всі узгоджені правила. Посиланням на таку сторінку слід поділитися з усіма стейкхолдерами для майбутнього використання та онбордингу нових членів команди.

Варто приділити увагу очікуванням до самого процесу дискавері, та тому, яку цінність він принесе, щоб отримати buy-in від усіх стейкхолдерів. Якщо можете вивести цифри чи показники ефективності — ще краще.

Переваги і цінності впровадження цього процесу:

• Доступність: усе зберігається в Jira і доступне для всіх зацікавлених сторін. Цінність для стейкхолдерів — збереження бази досліджень для «майбутніх поколінь». Завжди можна глянути, чому було прийняте те чи інше продуктове рішення.
• Прозорість: кожен стейкхолдер процесу має доступ і може розуміти, на якому етапі перебуває дослідження чи тестування можливості. Цінність для стейкхолдерів — можливість в декілька кліків зрозуміти, над чим зараз працює команда.
• Зручність: використання Jira Software, що спрощує навігацію та дає можливість автоматизувати чи спростити багато моментів. Цінність для стейкхолдерів — більша ефективність команди у процесі дискавері.
• Фокус: замість створення численних Epic і Story для ще не підтверджених рішень, ми використовуємо цю дошку як фільтр: тільки підтверджені й провалідовані рішення потрапляють в беклог розробки. Цінність для стейкходерів — зменшення міскомунікації, ризиків та невідомого у прийнятті рішень, і потенційно більш ефективні продуктові рішення самої продуктової команди.

Крок 4: Аналіз та ітерація процесу

Звісно, не все буде зроблено з першого разу. У нашому випадку перехід до такого процесу та міграція всіх існуючих можливостей зайняли близько 1 місяця. Протягом наступних 2 місяців ми зосередилися на зборі відгуків і вдосконаленні.

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

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

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

Челенджі та уроки

Визначення можливостей. Основною зміною у мисленні команди стало фокусування на проблемах і можливостях, а не на фічах. Під час переходу на цей процес за основу ми взяли існуючий беклог з різних ідей і фіч, як початковий скоуп для створення задач Opportunity.

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

Ефективність команди. Оскільки це був новий процес, «час реалізації» перших Opportunities був довгим. Але ми наздогнали це після кількох ітерацій. З моменту запуску (за 3 місяці) вдалось «прогнати» через процес 80% всіх наявних продуктових ідей. Опісля — фокус змістився на нові проблеми і можливості.

Оптимізація воркфлову. Після перших ітерацій ми трохи змінили вокрфлов (спочатку всі статуси, такі як «Ideation», «Evaluation», «Testing», «Learning» були розділені, і це викликало непорозуміння щодо очікуваних результатів цих статусів та значно затягувало сам процес). Ми об’єднали їх в статуси «Ideation» & Evaluation«, «Testing & Learning» у Jira.

Підсвічування досягнень та масштабування процесу. Для стейкхолдерів, які не входили до продуктової команди, наш процес міг здатися непотрібним ускладненням вже існуючого процесу делівері. Адже якщо ідея фічі вже звучить класно, то для чого ці додаткові процеси і зайва організація? 🙂

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

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

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

Сподіваюсь, цей досвід буде корисним та застосовним до вашої ситуації. Адже ми всі постійно вчимося та визначаємо кращі способи роботи. Якщо у вас є інша конфігурація Jira для цього процесу (особливо в новому інструменті Jira під назвою «Product Discovery») — будь ласка, поділіться в коментарях. Було б чудово отримати ідеї від інших продуктових команд.