Часто розробники і продакти існують у паралельних реальностях, але щоби не створювати непотрібні фічі, а робити продукт, який потрібен користувачам, команда має говорити спільною мовою. Завдання продакт-менеджера — створити таку мову й зробити так, щоб усі вірно почули і зрозуміли одне одного.
У своїй колонці для High Bar Journal Міша Нестор, Chief Product Officer «Київстару» та співзасновник фонду KOLO, розповідає, як продактам будувати і підтримувати продуктове мислення всередині компанії, а розробникам — розуміти продактів краще.
Продуктовий підхід vs enterprise vs аутсорс
Можна виділити три класичні підходи до створення цифрових продуктів, що притаманні різним видам бізнесів. Наприклад, в класичних ентерпрайз-корпораціях створення IT-продуктів зазвичай не є основною діяльністю. Тому розробкою рішень займається тільки IT-департамент. Аутсорсні й продуктові компанії, навпаки, створені саме для розробки софтверних продуктів. Ключова відмінність — у тому, що аутсорс-компанії створюють продукти для зовнішніх замовників.
Розберемо кожен з підходів до розробки підходів.
Enterprise-підхід (підхід класичного бізнесу)
У стандартному Enterprise-підході, навіть якщо всередині є великий IT-відділ, процес побудований так: пишуть технічне завдання, проводять тендери, вендори приносять готові рішення, і над їх інтеграцією працюють в команді, а потім — сапортять софт або оплачують ліцензії. Відповідно, роль команди – обслуговувати цей процес: спілкуватися із вендором, робити тендери, захищати бюджет тощо.
Аутсорс
Класичний аутсорс виглядає так: технологічна компанія знаходить постачальника послуг, набирає команду, що працює над скоупом, який задає Product Owner (часто – на іншому континенті). Юзери, які цим будуть користуватись, можливо, також знаходяться на іншому континенті.
Продуктова складова в аутсорсі часто відсутня. Хоча найкращі аутсорси пропонують також діскавері-фазу в якості консалтингу, щоб краще розуміти вимоги до майбутнього продукту.
Продуктовий підхід
В таких компаніях є команда або набір команд, що відповідають за усі етапи створення продукту або його частини: від розуміння, що потрібно юзерам, а що — бізнесу, до реалізації фіч, їх тестування, оптимізації та просуванні на ринку.
В продуктовому підході багато конфігурацій, і продуктові команди можуть бути частинами ентерпрайзу. Наприклад, моя організація у «Київстарі» складається з 250 людей, що працюють в продуктовому підході, але ми — частина більшого бізнесу.
В продуктовій команді зазвичай є продакт-менеджер, Scrum-майстер, дизайнери, бізнес-аналітики, фронтенд- і бекенд-розробники, QA-інженери. Можливо, також Performance Marketing Manager або Growth Manager. Команда працює ітераціями — двотижневими спринтами.
Завдання продакт-менеджера — вирішувати, чим буде займатися команда. Пояснити колегам бачення: куди ми йдемо, чому, як повинен виглядати продукт, який у нас roadmap, коли починається наступний великий модуль або фіча. Розказати, як ми будемо міряти ефективність створеного функціоналу. Після запуску — показати на метриках, як працює фіча, пояснити, чому ми щось змінюємо. Команда у цьому випадку працює разом. Інженери обговорюють завдання, планують і виставляють естімейти готовності рішень. Маючи оцінку від розробників, продакт може синхронізуватися з іншими частинами бізнесу або зі своїми керівниками.
Три поради розробникам для ефективної співпраці з продактами
Не варто триматись за фічу, в якій немає сенсу
Іноді розробники сильно прив'язуються до того, що вони зробили. Але якщо ця фіча не «полетіла», нам потрібно її «вбити». Для більшості розробників, особливо з аутсорсним бекграундом, — це складно. Проблема — у нерозумінні, що таке продукт. Навколо нас — ринок, і він рухається — технології змінюються, ландшафт змінюється, з'являються нові продукти, конкуренти. Наскільки мені відомо, у топових з інженерно-продуктової точки зору компаніях, наприклад, Netflix, кількість успішних фіч складає 30-40%. Не чекайте, що що 100% того, що ви створите, буде потрібним. Такого не буває. Продакти — не ясновидці. Ми можемо лише знизити ризики, але все, що не в продакшені, це гіпотеза. Як фіча буде працювати, можна побачити тільки в продакшені.
Якщо ми фокусуємося на метриках, і конверсія з інсталів в першу платну підписку складає 5%, а нам потрібно 10%, досягти цього — мета усієї команди, бо від цього залежить успішність продукту, зарплати команди і існування бізнесу у цілому. Наша мета — не створити прикольний дизайн або цікавий функціонал.
Робота продакта — проповідувати цей майндсет, зробити так, щоб усі однаково розуміли це. Тоді немає проблеми пояснити, чому від якоїсь фічі довелося відмовитись.
Фокусуйтеся на загальному результаті, а не складному інженерному завданні
Інженери часто винаходять для себе складні, цікаві технічні завдання, які в цей момент «з'їдають» гроші компанії, затримують випуск потрібних фіч, і в підсумку можуть призвести до того, що продукт не працює, команду скоротили, всі залишилися без роботи.
Часто всередині команди з'являються внутрішні «ватерфоли»: продакти зі стейкхолдерами щось вигадують, приносять ідею дизайнерам. Дизайнери окремо роблять фреймворки і віддають фронтендерам, ті думають, як це буде виглядати, потім приходять до беків і дають набір ендпоінтів. В підсумку це призводить до постійних затримок і фейлів, зокрема й абсурдних, коли хтось не передбачив розширення серверів під новий функціонал чи навантаження, тому що не знав про це, хоча розробка велася місяць.
Команда має працювати разом, усі мають брати участь у спільних зустрічах, де обговорюють фічі. Іноді члени команди не надають великого значення таким зустрічам, хоча направду це може допомогти абсолютно усім, хто бере участь у розробці продукту, навіть інженерам. Якщо вони обмежуються лише кодом і технічними задачами, то це «вбиває» дух того, чим повинна займатися продуктова організація, тому що призводить до розсинхрону і втрати мотивації.
Цікавтесь усіма аспектами створення продукту
Часто продукти з дизайнерами йдуть в свою discovery-реальність, а інженерам це не дуже цікаво. Тому продактам важливо ініціювати фокус-групи, зустрічі з користувачами продуктів для всієї команди. Наприклад, якщо ми створюємо софт для працівників колцентру у Львові, ми оформляємо відрядження для всієї команди, спілкуємось з колцентром, проводимо з ними робочий день, дізнаємось, що у них болить.
Інженер — теж жива людина, у нього є свій Android чи iPhone, а також комп'ютер. Коли він бачить, що для якоїсь іншої людини розроблений продукт є незручним, необхідність пояснень від product-менеджера зникає автоматично. З'являється емпатія — ти вже не будеш запускати рефакторинг на три місяці, якщо побачив, як людям болить відсутність якоїсь фічі.
Своїй команді я кажу: «Не забувайте, звідки беруться ваші зарплати — вони не падають з неба, а приходять (прямо або непрямо) як частина виторгу продукту, який ви робите».
В сервісних компаніях про гроші ніколи ніхто не говорить, але насправді в продуктових компаніях від розробників теж часто приховують, скільки грошей заробляє продукт. Більше того, з мого досвіду, є компанії, де навіть продакти не володіють цією інформацією.
При цьому в Україні є багато хороших хедів продуктів, сильних інженерних і продуктових команд. Я знаю, що є практики, направлені на те, щоб уникати недомовок. Все починається з того, щоб не відривати інженерів від користувачів, не відривати їх від бізнесу, забезпечувати розуміння, чим ми тут займаємося.
Наведу приклад з практики «Київстару» — щодватижні ми проводимо спринт-рев'ю, на які приходять колеги з різних команд, стейкхолдери, директори. І продакт-менеджери практично ніколи не роблять презентацію результатів спринта — цим займаються інші члени команди. Вони пояснюють, в чому цінність, як вони знаходили рішення, як це виглядає на продакшені, роблять демо. Кожен може отримати одразу зворотній зв’язок від стейкхолдерів або від користувачів (якщо це внутрішні продукти).
Для таких виступів потрібно безпечне середовище, щоб люди не боялися критики. І часто такі презентації — єдиний спосіб виявити майбутніх сеньорів. Для них це можливість проявитися. Правильно організований командний продуктовий процес допомагає зростати або змінювати ролі всередині компанії. У бізнесі з розвинутою продуктовою культурою сильний інженер може підбекапити в якихось питаннях продакта, що захворів. Тому що всі в курсі, що відбувається, для чого вони це роблять, які терміни, які естімейти, коли буде наступна фіча.
Ключове для продуктового підходу — відкрита комунікація в команді. Якщо розробник не розуміє, чого від нього хоче продакт, він має поставити запитання на командній зустрічі, а якщо такої зустрічі немає — ініціювати її; продуктові менеджери повинні ставити запитання користувачам і стейкхолдерам, а інженери — продактам.
Відповідальним за увесь процес є продакт, і це нормально. Потрібна одна людина, що ухвалює фінальні рішення, інакше — хаос.