У продуктовій компанії немає розвитку. А ще — купа овертаймів і відсутність мотивації. Всі ці твердження — справжні міфи, які ми взяли на себе сміливість спростувати. Читайте великий розбір найпоширеніших стереотипів про продуктові IT-компанії, який провела редакція нашого блогу разом із технічним директором компанії Universe з екосистеми Genesis.
МІФ №1
Стартапи женуться за хайповими технологіями, а розвинуті продукти — за фічами. В обох випадках доводиться поступатися якістю.
Найголовніше, за чим мають гнатися всі технічні команди — це певні бізнес-цілі. Від цього відштовхуються стейкхолдери, приймаючи будь-яке рішення. Якщо є потреба отримати раунд інвестицій завдяки хайповій технології або збільшити кількість користувачів завдяки новій фічі, — це і є бізнес-цілі, яких треба досягти. Від них залежить доля компанії: якщо не буде фінансування, бізнес не виживе. Якщо не «викатувати» нові фічі, ви будете відставати від конкурентів, та як наслідок, ваші продуктові метрики падатимуть, зменшуватимуться доходи, і в результаті — бізнес не виживе. Тому статистично цей міф можна підтвердити. Але щодо поступок у якості — можна сперечатися.
Спочатку варто визначити: що таке якість? Технічні фахівці часто називають «якістю» чисто технічні показники — наприклад, Code Coverage, доцільність яких важко пояснити стейкхолдерам. Тому для них три години рефакторингу на тиждень — це і є компроміс у питаннях якості.
Якщо «якістю» назвати рішення, без якого «відвалиться» 10% юзерів та 5% доходу, виникнуть проблеми з масштабуванням чи безпекою, то на такі компроміси не піде жодна продуктова команда.
МІФ №2
У продукті стек технологій відстає, розробники не мають змоги експериментувати, тому повільніше розвиваються.
Змоделюємо ситуацію. Технічна команда може обрати рішення на хайповому стеці. Або на старому (водночас НЕ застарілому), яке можна швидко реалізувати, і воно стабільно працюватиме. З дуже високою ймовірністю продуктова команда скаже: «Нащо ризикувати? Давайте просто зробимо так, щоби все надійно працювало».
Кінцевому користувачеві неважливо, що у вас під капотом — звичайна Java чи блокчейн, якщо продукт закриває їхні потреби. Розробникам від цього боляче, адже всі прагнуть самовдосконалення, бути актуальними на ринку, експериментувати. Але це не привід ставити на перше місце технології, а на друге — бізнесові потреби. Якщо у вас є готовий продукт, користувачі, метрики тощо — вам є що втрачати. Ви не будете без нагальної потреби стрибати на нову технологію, тому що щось чули про неї. Одна з речей, яка вирізняє мідла від сеньйора — це розуміння, що ти пишеш код не заради технології, а щоби закривати бізнес-потреби. Цей скіл найкраще качається в продуктових компаніях. Якщо ви не вивчаєте нову технологію щомісяця, це не означає, що ви стоїте на місці. Ви розвиваєте інші навички.
МІФ №3
У розробника є можливість вплинути на продукт тільки під час запуску, надалі — це переважно підтримка та одноманітна робота.
Правдивість цього міфу залежить від стадії, на якій знаходиться продукт. Коли відбувся повний «feature freeze», немає розвитку, а є лише сапорт — фактично це стадія стагнації, у якій розробник дійсно не може впливати на продукт. У всіх інших випадках вплив є і досить потужний.
Крім основних флагманських продуктів компанії часто розвивають додаткові напрями, вивчають нові ніші та запускають у них мініпродукти, які із часом також можуть стати флагманами. Це досить поширена практика для продуктових бізнесів у всьому світі та в Україні. Наприклад, в Universe є напрям «утиліти», який запустили ще 2018 року, і він продовжує розвиватися та постійно доповнюється новим функціоналом. І є R&D, у якому команда експериментує з технологіями, нішами та зараз працює над продуктом, якого ще рік тому не було. Середовище в продуктовому ІТ постійно змінюється, тому ця робота для розробників досить драйвова та динамічна.
МІФ №4
Роль розробника менш важлива. Усі рішення диктують цифри в аналітиці (користувачі, маркетинг) тощо.
Це правда, але це стосується будь-якої IT-компанії, не лише продуктової. Навряд чи існує команда, у якій розробник може одноосібно приймати суперечливі рішення з аргументацією: «Я художник, я так бачу».
У кожній ІТ-компанії є розробники, які відповідають за код. І є менеджери, які відповідають, щоби задовольнялися вимоги замовника (в аутсорсі) або користувача (в продукті). Якщо розробнику в продуктовій компанії хочеться більше контролювати процес, є багато суміжних позицій, наприклад, Technical Product Manager. Або можна світчнутися на продакт-менеджера.
Також це не означає, що до розробників не прислуховуються, а просто дають завдання. Проактивних спеціалістів, які проявляють ініціативу, аргументують та доводять свою думку, завжди почують. Розробники часто бачать, як покращити процес або продукт зсередини, і в них завжди є можливість запропонувати ідею під час, наприклад, грумінгу чи іншої командної зустрічі.
МІФ №5
У продуктових компаніях багато овертаймів та нерівномірна завантаженість.
Наявність овертаймів залежить не від типу компанії, а від побудови процесів. Зазвичай у стартапах їх більше — адже від цього залежить виживання бізнесу. Також овертайми досить часто трапляються в невеликих сервісних компаніях, які бояться втратити замовників — навіть неадекватних, які в останній момент змінюють концепцію і просять усе переробити.
Кожен овертайм — це використання майбутнього ресурсу. З погляду менеджменту, це дуже бʼє по команді, особливо, якщо вона не розуміє кінцевої мети. Якщо менеджер заганятиме команду просто тому, що він так хоче, він швидко втратить її.
Щоб уникнути овертаймів, у великих компаніях (як продуктових, так і аутсорсингових) багато часу приділяється плануванню на квартал, епізод, рік, складають роадмапи, командні цілі.
МІФ №6
Більшість команди складають нетехнічні спеціалісти, тому розробнику немає, з ким обмінюватися експертизою.
Продуктові компанії бувають різні. Genesis — це велика екосистема, яка складається з компаній, всередині яких можуть бути різні проєкти. Коли в структурі таких масштабів правильно побудовані процеси, розвивати нетворкінг легко: завжди можна знайти контакт колеги з іншого проєкту та попросити поділитися досвідом.
В Genesis побудована система профільних спільнот, в яких можна обмінюватися експертизою, кейсами, проводити воркшопи, мітапи, дискусії. Або просто зустрітися на каву та поспілкуватися. Для технічних спеціалістів є пʼять комʼюніті: бекенд, фронтенд, QA, DevOps та геймдев.
МІФ №7
Працівники надто довго засиджуються на одному місці, втрачають мотивацію, тому проєктам бракує свіжих ідей.
В ІТ-індустрії панує умовне правило, що фахівець має кожні декілька років змінювати позицію / проєкт / компанію. Інакше — втрачається мотивація, залученість, завдання здаються одноманітними та нецікавими. «Життєвий цикл співробітника» — це поняття показує, скільки фахівець проведе часу в проєкті. Продуктові компанії ретельно відстежують цю метрику та намагаються оптимізувати. Як команда прагне покращити досвід користувача в продукті, так і компанія зацікавлена допомогти співробітникам стрімко зростати та досягати спільних цілей.
Як бізнес може мотивувати співробітників, окрім як фінансово?
1. Стимулювати професійний розвиток, допомогти опанувати нові скіли.
Комусь потрібен ментор, хтось прагне опанувати нову технологію, а хтось накопичив експертизу і прагне нею поділитися. Освітніх форматів в екосистемі чимало (як внутрішніх, так і зовнішніх). Якщо спеціалісти практикують continuous learning, браку свіжих ідей та підходів у них не буде.
2. Допомагати у карʼєрному зростанні.
Якщо у технічного спеціаліста зʼявилося бажання очолити команду, новий проєкт, або перейти в суміжну сферу, компанія має підтримати його ініціативу. Якщо не вистачає управлінських навичок, є школи менеджменту та лідерства (як в екосистемі загалом, так і в окремих компаніях). Наприклад, за останні пів року в Universe виросли QA engineer та IOS Engineer до QA Lead та IOS Lead відповідно. Вони пройшли внутрішні курси менеджменту, а також мали специфічні завдання на квартал, які треба було виконати за допомогою делегування на команду.
3. Сильна корпоративна культура.
Залученість — потужний інструмент мотивації. Розробник має відчувати свою роль не на рівні «я написав код і зробив пуш», а на рівні «я зробив пуш, задеплоївся код, а за ним продакшн, тому користувачі побачили фічу, тому LTV збільшився на 2%. І все це завдяки мені!».