Останні кілька років у сфері digital усі говорять про продуктові команди, тому ми пропонуємо просту інструкцію: чи потрібна вам продуктова команда чи ні і, якщо потрібна, то де її взяти.
Що таке продуктова команда
Продуктова команда – це команда, яка займається розвитком продукту, іншими словами, головна її мета – покращити метрики, зрозуміти користувача та вплинути на бізнес-показники. У цьому її основна відмінність від проєктної та функціональної команд, які працюють із конкретними вимогами клієнта.
Властивості продуктової команди
Років десять тому були поширені саме проектні команди: вони були готові за певний час зробити продукт таким, яким його задумав замовник, не кращим і не гіршим. Але згодом бізнесу стало зрозуміло, що не завжди на старті виходить точно визначити, яким має бути продукт. І тому бізнес став дивитись у бік продуктового підходу.
Так і з’явилася система, про яку йдеться. Щоб прораховувати вигоду від digital-продукту та змінювати його за потреби, потрібно розуміти поведінку користувача. І розуміти цю поведінку мають усі люди, які працюють над продуктом. У цьому полягає відмінність: раніше сам бізнес визначав, що продавати, що ні. Тепер у цьому процесі троє:
- Бізнес,
- Користувачі,
- Продуктова команда, яка грає одночасно за перших та за других.
Основні властивості продуктової команди:
- Вона працює над одним продуктом або над ізольованою його частиною, не відволікаючись на інші;
- Люди в команді мають всі необхідні компетенції, щоб зробити продукт і потім його розвивати;
- Роботу команди можна прогнозувати, вона вимірна за часом;
- Така команда здатна і прагне самоорганізації.
Якщо ви не знаєте, чи потрібна вам продуктова команда, пропонуємо покрокову інструкцію, яка допоможе відповісти на це запитання.
Визначтеся, чи потрібна вам продуктова команда
Продуктову команду не варто збирати, якщо ви працюєте над проєктом, який не плануєте перетворити на digital-продукт. Ваш сайт може бути інтернет-представництвом, де ваші потенційні клієнти дізнаються більше про вас і знайдуть ваші контакти, але при цьому він може бути не інтегрований у ваші бізнес-процеси. Вважати цей проєкт продуктом складно. Проєкт має терміни завершення, а продукт — ні. Як тільки ви досягнете ідеального рішення для сайту, працювати над ним більше не потрібно. Можна оновлювати новини та галереї, можна підтримувати його технічно, але розвивати цілі немає. Отже, продуктова команда поки що не потрібна. Досить окремого проджект-менеджера, дизайнера та програміста, які правильно зрозуміють ваші завдання та грамотно їх реалізують.
Збирати продуктову команду рано, якщо ідея цифрового продукту не отримала підтвердження через аналітику і поки що залишається гіпотезою. Щоб цю гіпотезу перевірити, можна використовувати дослідження, а також провести дослідження потенційного ринку, щоб переконатися, що виробництво продукту є економічно обґрунтованим. Також можна зібрати невелику growth team, яка швидко і за допомогою нехитрих технічних рішень розробить чорнову версію продукту. На такому продукті можна протестувати попит. Якщо попит підтвердиться, тільки тоді з’явиться привід збирати продуктову команду або залучати крос-функціональну команду на аутсорс.
Консервативним компаніям, які не звикли до швидких точкових рішень, також не варто збирати продуктові команди. Якщо у вашій компанії редагування, завдання та пріоритети спускаються виключно зверху, а узгодження будь-яких змін йде через кілька інстанцій, то сенсу збирати окрему команду для продукту немає.
Отже, продуктова команда потрібна, якщо
- Є план розвитку продукту,
- Ви робите продукт, який затребуваний кінцевим споживачем,
- Продукт потрібен бізнесу.
Визначте склад продуктової команди
Ви вирішили: продуктова команда потрібна. Тепер важливо визначити її склад. Іти варто від того, яким ви задумали продукт. Можливо, в команді буде достатньо одного програміста, дизайнера та аналітика. А може, потрібні будуть послуги десятків людей з різними компетенціями.
У будь-якому випадку продукту потрібен керівник – product-менеджер. Саме він прийматиме рішення та нестиме відповідальність за продукт, орієнтуючись на запити користувачів, бізнес-інтереси замовника та переваги самої команди.
Іноді на роботу залучають кілька продуктових команд. Якщо працювати потрібно над сервісом, який має багато різних функцій, то кілька команд — це спосіб заощадити час. А чим швидше розвивається продукт, тим більше користі бізнесу він приносить. У деяких випадках, коли реалізувати нову функціональність продукту потрібно в стислий термін, у команду можна залучати зовнішніх фахівців. Ця практика допомагає не роздмухувати штат, особливо якщо йдеться про реалізацію невеликих фіч або окремих ідей.
Виберіть, з ким працювати: інхаус чи аутсорс
Інхаус-команда складається у вас у штаті. Аутсорс-команда працевлаштована не у вас, а, наприклад, у компанії, яка займається розробкою у сфері digital. Обидва варіанти хороші, потрібно вибрати той, що підходить вам:
Якщо у вас у штаті вже є всі необхідні фахівці і у них є експертиза за всіма потрібними для реалізації продукту напрямами, то працювати потрібно інхаус.
Якщо якоїсь експертизи не вистачає, то подумайте про аутсорс. Шукати та наймати співробітника довго та дорого. Якщо у вас немає якоїсь експертизи всередині, то при спробі найняти в штат такого експерта ви ризикуєте зіткнутися з проблемами:
- Відповідальність за вибір лягає на ваші плечі;
- Ризики у зв’язку з наймом некомпетентної або невідповідної людини теж на вас;
- Час фахівців, витрачений пошук і співбесіди, і загалом термін виведення/занурення людини завжди негативно позначається на продукті, отже, і бізнесі.
При роботі з аутсорс-компаніями ризики та відповідальність також є, але як мінімум агенція їх з вами ділить і дає гарантії на свою роботу. А час, витрачений на пошук та виведення некомпетентного, але з прокаченими софт-скіллами фахівця, якого ще не так просто звільнити, ніхто не поверне.
Схема коли частина членів продуктової команди працює в штаті, а частина працевлаштована в іншій компанії називається гібридною. Вона відмінно підходить і в тому випадку, коли команду потрібно швидко посилити в якійсь екстреній ситуації, наприклад, якщо:
- Конкуренти дихають у спину;
- Кон’юнктура ринку змінюється, і необхідно впроваджувати набагато більше нових функцій або змінювати вектор розвитку продукту;
- Впливають подієві фактори, що вимагають запуску великого функціоналу в стислі терміни.
Якщо у вас у штаті взагалі немає потрібних фахівців, краще знайти команду повністю на аутсорс. У цьому випадку команда візьме на себе початкову фазу продукту, і якщо продукт «вистрілить», можна буде найняти експертизу інхаус, щоб розвивати продукт самостійно або спільно із зовнішньою експертизою. Ось переваги такого підходу:
- Можна ґрунтовно підходити до пошуку фахівців, доки аутсорс-команда працює над продуктом немає простою, доки потрібну експертизу не найняли;
- Можна залучати команду продукту для співбесід та відбору, тобто користуватися експертизою при наймі, що суттєво скоротить ризик найму некомпетентних людей;
- Аутсорс-команда вибудує всі процеси як у розробці, так і в управлінні продуктом, а внутрішній команді достатньо буде запозичити їх собі.
Під час вибору команди на аутсорс обов’язково вивчіть її. Важливо, щоб компанія, яка вам допомагатиме, розповідала не лише про свої перемоги, а й про свої невдачі. Це найкорисніша інформація для замовника: по-перше, вона показує, що команда не боїться помилок і труднощів, а по-друге, демонструє, як легко та наскільки ефективно вона знаходить вихід із складної ситуації.
Продумайте, скільки команд вам потрібно
Деякі продукти настільки великі, що для роботи над ними потрібно кілька команд. Якщо ви вирішили ділити проект на складові, потрібно враховувати ризики.
Насамперед це комунікативні витрати: чим більше команд бере участь у створенні продукту, тим більше буде зустрічей і листування, які дозволять оперативно передавати інформацію від однієї команди до іншої. Якщо над продуктом працює одна велика команда, таких витрат буде набагато менше. Але водночас єдиною командою важче керувати — великі команди складно зробити самоорганізованими.
У цьому якщо роботу всіх команд добре організувати, кожна з них проводитиме ревью роботи інших.
Приймаючи рішення скільки команд потрібно для роботи над продуктом, також варто враховувати і наступні фактори:
Команди бувають 2-х типів: discovery team (growth team) та core team. Discovery займається розробкою та випробуванням нових фіч, відповідає за розвиток та перевірку гіпотез. Core team займається супроводом продукту: стежить, щоб все працювало 24/7/365, вирішує аварійні ситуації, вживає заходів, щоб не допустити їх у майбутньому, а ще впроваджує нові, вже перевірені командою discovery фічі та розвиває старі.
Кожна команда на проекті має мати свою зону відповідальності. Краще, якщо ці зона не перетинатимуться або перетинатимуться мінімально. Наприклад, нехай одна команда відповідає за дизайн, а друга – за розробку. Це краще, ніж якщо обидві робитимуть макети або писати код. Але якщо уникнути перетину неможливо, важливо формалізувати завдання: чітко прописати, хто в кого приймає фічі і хто за яку частину робіт відповідає.
Продумайте свою взаємодію з командою
Продуктовий підхід передбачає, що замовник не дає команді чіткого покрокового ТЗ, а формує запит, проблему чи мету. Завдання команди – вирішити проблему чи досягти мети.
У більшості сучасних підходів продуктова команда працює спринтами – тимчасовими відрізками завдовжки 1-4 тижні. За їхніми підсумками зазвичай проводиться зустріч під назвою «огляд спринту». На цих зустрічах команда та представники бізнесу обговорюють прогрес та коригують беклог.
Також усі активні учасники проекту відвідують ретроспективи – зустрічі за підсумками спринтів, на яких команда розбирає свої помилки та методи їх вирішення. А також фіксує успіхи та способи їх досягнення, щоб повторити. Хоча ці зустрічі розраховані в основному на членів команди, за бажання ви також можете брати в них участь. Головне, щоб усі учасники спілкувалися на рівних і нікого не соромилися.
Однак майже будь-яка продуктова команда щодня зустрічається на дейлі-мітингах. Це щоденна коротка летучка з поточних питань, на якій кожен розповідає про плани на день або отримує нові завдання. Замовнику чи його представникам ходити на такі летучки зовсім не обов’язково.
Підведемо підсумки
Продуктова команда не єдиний спосіб роботи над продуктом. Однак практика показує, що цей підхід є дуже ефективним. Саме продуктові команди створили найуспішніші та найбільші успішні продукти у сфері digital за останні роки.
