«Еволюція ретро»: навіщо тричі змінювали формат та які проблеми хотіли вирішити

Розповідаємо, як і чому продуктова команда почала використовувати ретроспективу.

Привіт! Я - Таня Афанасьєва, менеджер продукту в Selectel. Наш відділ займається розробкою та підтримкою зовнішніх мережевих сервісів, наприклад CDN. Команда складається з десяти осіб, серед них – team lead, product-менеджер, UX-фахівець, розробники, DevOps-інженери та інші. Основний склад сформувався два роки тому, коли компанія поєднала кілька продуктів в один сервіс. Більшість приходили з інших відділів чи компаній, тому колеги спочатку не були знайомі один з одним.

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

Що таке ретро

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

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

Весь процес заснований на прозорості та довірі всередині команди. Це допомагає налагодити комунікацію між колегами та запобігти проблемам до того, як вони перетворяться на серйозні бар'єри.

Перший формат, або «Нитинг»

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

Ретро команди клієнтських та внутрішніх сервісів. Джерело.

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

Ми розділили сторінку на три блоки: "Що допомагало роботі?", "Що заважало (закрити спринт) і можна покращити?" та «Чого навчилися нового? Що нового впізнали?». Протягом спринту колеги залишали відповіді на запитання, а на зустрічі зачитували їхній слух. Модератором ретро була я.

Приклад першого формату ретро. Усі записи вигадані.

Недоліки

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

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

Другий формат, чи «проблеми є, але вирішувати ми їх не будемо»

Новий формат перенесли до Miro, його зручно використовувати для брейншторму, планування та вирішення спільних завдань. На дошці розмістили три стовпці з попередніми питаннями, лише переформулювали у well, sad та new. Кожному учаснику роздали картки для записів.

Приклад другого формату ретро. Усі записи вигадані.

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

Недоліки

Кожен формат ретро має свої недоліки, і це не виняток. Добре, що їх було набагато менше, ніж у першому.

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

Принципи здорового ретро

Знову змінить формат ретро — недостатньо. Потрібно було сформулювати принципи, за якими функціонуватиме наш «захід».

Бажання та проактивність

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

Командна робота

Ми проводимо ретро для внутрішньої команди, тому на ній повинні бути присутніми всі учасники проекту або продукту.

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

Модератор

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

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

Регулярність та сталість

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

Також важливо встановити єдиний формат ретро. Команда має розуміти, навіщо ми його проводимо та які у нас цілі. Тут як у грі правила повинні бути відомі всім.

Людські якості

Конструктивність, відкритість, чесність та повага – це базові принципи, які застосовуються у всіх процесах. Без них складно побудувати здорову комунікацію та взаємодію у команді.

Третій формат

Мета нашої ретроспективи – підвищити ефективність процесів у роботі, виявити поточні проблеми та сформувати подальший план змін. Щоб їх вирішити, ми зафіксували новий регламент: розробили структуру ретро та розділили на кілька етапів. Розглянемо їх докладніше.

Підготовка до ретро

За день до ретро модератор нагадує учасникам заповнити картки у Miro. Останні пишуть нотатки у двох колонках «Що мені допомагало в роботі» та «Що заважало (закрити спринт) і можна покращити?». Тут важливо уникати надмірної похвали колег і очевидних проблем — наприклад, «дякую UX-проектувальнику за те, що намалював прототип», або «не вдалося виконати завдання вчасно, бо не було настрою».

Структура ретро

Етап 1. Що було добре і допомагало роботі? та «Що заважало (закрити спринт) і можна покращити?». Етап 2. Аналіз проблем та мозковий штурм. Етап 3. Формуємо action items. Завершення ретро та фідбек колег.

Процес після ретро

Це ще не кінець! Team lead або product-менеджер створює завдання Jira, щоб організувати роботу над поточними проблемами. Далі призначає виконавців та копіює посилання завдання на стікер.

Початок наступного спринту

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

Висновок

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