Міняємо фреймворк у команді: з чого почати, які інструменти обрати та як контролювати процес

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

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

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

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

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

Що таке фреймворки і для чого вони потрібні

Щоби бути on the same page, почнемо спочатку.

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

Є велика кількість фреймворків під різні продуктові задачі. Value Proposition Canvas, Lean Canvas, Persona Canvas, Jobs To Be Done, HADI, ICE, RICE, Customer Journey Map, Hook Model, Scrum — цей список можна продовжувати довго.

Наприклад, є популярна методологія створення нового бізнесу, розвитку продуктів і виведення на ринок — Lean Startup. Також, впевнена, багато хто чув про Scrum — спосіб гнучкого управління складними проєктами. Фреймворки можна поєднувати. На прикладі нижче показано, як з Design Thinking на етапі тестування перейти на Lean Startup, а ітерації провести через методологію Scrum.

А тут комбінуються Design Thinking, Lean Startup, Agile та Growth Hacking:

Чи потрібен контроль менеджера

Є чотири основні функції менеджменту: планування, організація, керівництво та контроль. Використовуючи їх, керівники підвищують ефективність своєї команди, процесів та організації загалом. Але чи є насправді метод контролю ефективним та які існують альтернативи?

У книжці «Inspired» Марті Каган описує переваги методу управління цілями — Managment by Objectives (MBO). Він називав цей метод «протилежним управлінню через контроль» та вважав ефективним. В цій же книзі автор приводить цитату Дейва Паккарда, який зазначив, що найбільшого успіху компанія Hewlett-Packard досягла саме після впровадження MBO.

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

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

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

Алгоритм впровадження нового фреймворку

1. Визначте ціль. Правильно і чітко сформована ціль є запорукою успіху на шляху будь-яких змін. А позаяк зміни потребують інвестицій часу, зусиль і ресурсів потрібно ще на перших етапах визначити для чого ми це робимо і який очікуваний результат. Якщо ваша команда перформить і робить це на високому рівні, скоріш за все, потреби в зміні фреймворку немає.
2. Підберіть фреймворк, який найбільше відповідатиме потребам компанії та команди. Якщо такого немає, спробуйте скомбінувати інструменти чи частини фреймворків.
3. Визначте чіткі правила гри: дайте інструментарій, встановіть орієнтири, як рухатиметься команда, з якого моменту й що робитиме крок за кроком.
   Ймовірно, в колег немає такого широкого розуміння, як працюють продуктові фреймворки, як у менеджерів. Тому варто напередодні змін зробити коротку презентацію можливостей та обмежень, змін у процесах, нових бордів чи нових підходів до роботи. Той, хто ініціює зміни, завжди виступає відповідальним за них. Звісно, можна делегувати комусь вивчити новий фреймворк і зробити презентацію, але фінальний результат маєте приймати саме ви.
4. Довіртеся команді: визначте період для тестування нового фреймворку й канали збору зворотного зв’язку. Найбільший виклик на ранніх етапах полягає в тому, що потрібно відмовитись від звичних патернів поведінки. Це може викликати дискомфорт і сповільнення темпів роботи. Це приблизно як лівші почати писати правою рукою — потребує часу й зусиль. Тому варто просто залишити команду з новим інструментом і дати час на «потупити». Буде чудово, якщо вони приходитимуть із питаннями протягом адаптації та поділяться враженнями на командній зустрічі в кінці періоду. На ній зафіксуйте не тільки труднощі та позитивні зміни, але й екшн-поінти й тих, хто відповідатиме за їхню реалізацію.
5. Підлаштовуйте фреймворк під ваші реалії, а не команду під фреймворк. На даному етапі варто провести 1-2 зрізи за результатами роботи з новим інструментом. Проаналізуйте, які екшн-поінти виконані, які ні, де потенційно можуть бути найбільші складнощі. На тестування нового інструменту можна відводити щонайменше один місяць, але постійно слідкуйте за динамікою й оперативно реагуйте на сигнали команди.
6. Прийняти рішення та повідомити команду. Якщо новий фреймворк ефективно працює, додайте його опис у документацію. Якщо ж вирішили відмовитись від нього та повернутися до попереднього стану, поясніть причини.
7. Закріпити результат, якщо зміни пройшли успішно.

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

Нижче наведу дві історії, як змінювалися фреймворки в нашій команді. Насправді змін було значно більше. Деякі були настільки органічні, що команда до них приходила сама, а мені залишалося тільки правильно оформити цей інструментарій (в Jira, Confluence, Google Docs або закріпити повідомлення в Slack).

Історія № 1. Перехід з Kanban на Scrum

З розвитком компанії почали зростати команда, зв’язки та залежності. Виникла необхідність планувати загальний роудмеп декількох кросфункціональних команд. При цьому в одній з них не було власних ресурсів деяких спеціалістів з розробки — вони цілком залежали від core-команди. Як наслідок — усе частіше доводилося переглядати пріоритети завдань, з’являвся технічний борг.

Ціль була простою — надавати надійні прогнози для релізу завдань, щоби підтримувати наші внутрішні та зовнішні зобов’язання щодо дорожньої карти. Нам потрібно було, щоби технічна підтримка платформи, регулярні та ad-hoch задачі узгоджувалися разом і мали чіткі часові рамки. Команді запропонували перейти на новий фреймворк — Scrum.

Основні переваги цього фреймворку:

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

Основним інструментарієм для першої ітерації переходу на цей фреймворк стали:

• дошка в Jira — відповідальний продакт-менеджер;
• сторіпоінти та система оцінки — відповідальний тимлід;
• грумінги;
• пленінги;
• ретроспективи.

Складності на цьому етапі були в тому, щоби перебудувати самі підходи команди. Завжди була спокуса додати задачу в спринт після пленінгу. На початку планування за сторіпоінтами були проблеми з навантаженням команди, нерівномірний розподіл завдань на борді. Наприклад, на початку спринту тестувальники не мали роботи, а під кінець були перенавантажені. Також постало питання, як спланувати роботу дизайнерів і аналітиків.

Що ми зробили? Насамперед дали команді свободу та час, щоби розібратись та адаптуватись. Для цього дещо зменшили темпи розробки. Також після кожного спринту ми аналізували проблеми та варіанти вирішення, визначали відповідальних за кожне завдання. Проводили моніторинг виконання сторіпоінтів, постійно комунікували про динаміку цих показників. На цьому етапі мені дуже допомогла книга «Мета» Еліягу Ґолдратта, яку мені порекомендував наш СЕО, коли я прийшла до нього з проблемою «простоїв» при переході на Scrum. Десь за 3-4 місяці ми остаточно вийшли на новий фреймворк. Тоді ж зʼявилися перші документи з правилами роботи команди.

Далі стало краще — ми почали збільшувати перфоманс шляхом оптимізації роботи. У тимліда був цільовий KPI з підвищення кількості сторіпоінтів, і за пів року команда без додаткового контролю досягнула покращення показників з 13 до 15 сторіпоінтів. Ми не зупинилися на цьому, і вже на початку 2022 року були місяці, коли ми досягали показників до 19 сторіпоінтів на одного розробника.

Динаміка виконання СП:

Ключові рішення команди для адаптації під даний фреймворк:

• беремо задачі різної складності, щоби розподіляти навантаження на тестувальників під час спринту. Тобто на 15 сторіпоінтів ми брали 1 завдання на 5 сторіпоінтів, 2 по 3, а все інше заповнювали дрібними задачами. Або ж якщо брали 2 задачі по 5 сторіпоінтів, тоді 5 інших задач мали бути по 1 сторіпоінту);
• якщо нам потрібно швидко зробити якусь задачу (щось інше має бути видалено зі спринта), ми не перезапускаємо спринт, а продовжуємо його;
• якщо ми робимо задачі швидше — то можемо брати наступні з беклогу (скрамбан) або ж приділити більше часу технічним задачам;
• дизайнери й аналітики теж працюють по спринтах;
• Kanban досі залишився ядром нашого візуального процесу керування роботою.

Даний фреймворк чітко закріпився в команді, інколи ми повертаємось до Kanban (проєктні рішення), але коли проєкт починає набирати більш планового флоу, — знову переходимо на Scrum.

Ключовими моментами в переході на новий фреймворк стало:

• чітка ціль і проінформованість команди;
• система OKR і високий рівень відповідальності;
• регулярні ретроспективи;
• постійні поліпшення й адаптація процесу під реалії команди та компанії.

Історія № 2. Перехід на фреймворк для пріоритезації ідей RICE

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

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

На той момент цим інструментом користувалися продакт-менеджери та аналітики. Фреймворк був кастомізований і базувався на різних підходах до оцінки та пріоритезації ідей. Проблема його використання сформувалася з переходом продукту на нову стадію розвитку — з етапу Growth and Establishment до Expansion.

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

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

Модель оцінки RICE — це система визначення пріоритетів, яка допомагає продакт-менеджерам визначити, які продукти, функції та інші ініціативи включити до своїх дорожніх карт. Ідея оцінюється за чотирма факторами: охоплення, вплив, впевненість і зусилля. Цей підхід дозволяє ухвалювати більш обґрунтовані рішення та мінімізувати особисті упередження.

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

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

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

Що почитати на цю тему:

• Inspired: How to Create Tech Products Customers Love, Marty Cagan;
• The Goal: A Process of Ongoing Improvement, Eliyahu M. Goldratt;
• The Five Temptations of a CEO, Patrick Lencioni;
• The Five Dysfunctions of a Team, Patrick Lencioni;
• Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland.

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

А найкращим механізмом впровадження нових підходів до роботи є повнота вхідної інформації, зрозумілі цілі, орієнтири та можливість постійно впливати на процеси.