Крос-функціональні команди: що робити, коли новий найм не вирішує проблем бізнесу [ukr]

Дякую. Раз-два, є? Чутно мене? Клас. Давайте ще 30 секунд, може всі зайдуть, сядуть. Дуже здивований, як всі попередні спікери дуже чітко в таймінг вкладаються. Я так не вмію, якщо що. Тому, якщо що, буду десь повільно, а десь дуже швидко. Такі справи.

Мене звати Дмитро, CTO, співзасновник компанії Apple Flame. Маю там трошки досвіду в IT-шці. Так склалося в моєму житті, що все життя я розробляю дейтинг. Не те, що це перша мрія всього життя, але так складалося, і я вже не сперечаюся цьому. Є, як є, принаймні, я вже маю хоч якусь експертизу в цьому, і тому вже насолоджуюсь життям з цим. Наразі. В Apple Flame я керую трьома проектами. Це Hylie, Temi і R&D-напрямками. Сьогодні буду розповідати саме про кейс з проектом Hylie.

Досить така сумна історія з радожливим кінцем. Про що проект Hylie? Це класичний дейтинг, такий як Tinder, Bumble, Badoo і так далі, якщо ви знаєте такі продукти. Ми маємо трошки більше 30 мільйонів користувачів. Маємо там більше 2 мільйонів лайків, скіпів кожен день. Там сотні тисяч завантажених фотографій, сотні тисяч повідомлень там і так далі. Ми починали, як думаю, багато хто з вас, маленький стартап в кімнаті, де 5 людей, де всі зі всіма там на курилці, планування на курилці. Знаєте, не було ні Jira, ні Asana там виходили покурити, там що будемо робити сьогодні, це, це, це, клас, давай зробимо. Ну так було рік, два. Три, там набирали людей, ставало більше, важче, там завели Asana якусь, якісь там задачі вже заводили. Потім в нас ставало більше, більше, більше і більше, ми наймали, там з'являлись гроші. Все як там класичний стартап, який вистрілив, так. Все було класно, допоки ми не найняли таку кількість людей, якою там керувати стало вже важко.

І про це зараз і починається наша розмова. Це точка, це ми десь... Десь там два-три роки тому, що ми мали, ми мали 35 інженерів, три платформи, iOS, Android, Backend. У нас вже тоді зародився інженерінг менеджмент як напрямок, у нас з'явився перший інженерінг менеджер, який запровадив Scrum, який запровадив Jira, ну, загалом всю інфраструктуру Atlassian. І ми тоді думали, що наче все прикольно, наче все працює, все класно, але є але. 35 інженерів між собою треба якось комунікувати. Коли вони працюють всі над монолітом, в одній команді, немає чітких зон відповідальності, немає, ну, коротше, є хаос. Основне слово, яке я хочу зараз сказати, це хаос. Був повний хаос тоді. І ось тоді ми почали думати, що робити. Як я відчував себе тоді? Ну, якось так.

Що ми почали з цим робити? А, точніше, так. Які проблеми у нас на той момент були? Ми не могли нічого вчасно релізити. Ну, там, нічого. Дев'ять з десяти тасок, які ми хотіли зробити, вони вчасно не виходили. Всі проблеми, які у нас з'являлися, треба там щось для маркетингу робити, що ми робимо – робимо найм. Треба, не знаю, для лігалів щось робити. Що ми робимо – робимо найм. Гаотичні зони відповідальності. Ніхто за що не... Ну, знаєте як. Ми всі відповідальні за проєкт, це означає, що ніхто не за що не відповідальний. Всі відмовлялися брати будь-яку відповідальність, люди виграли, звільнялися, боялись, ну, був ад. Що ми вирішили з цим робити? Подумав я, познайомився з крутим чуваком, до речі, як кому цікаво, можете по QR-коду знайти його LinkedIn. Крутий чувак, який займається project-менеджментом вже десятки років. Я такий, блін, Андрюха, зроби нам аудит нашого SDLC, розкажи нам, що у нас працює. Ну, і ми подумали, зробимо аудит, зараз нам на аудиті розкажуть, як робити добре, а як погано робити ми не будемо. В що це вилилося? Висновки аудиту були такі, я не буду їх зачитувати, вони написані, ну, загалом там все погано, треба переробляти все. Ну, ми не втрачали надії, інженер-менеджер тоді був генералом, йдемо, ми зараз все зробимо, складемо roadmap, там все буде добре. Ну, ми щось робили, ну, і це фінальний лист від цього аудитора, в якому головна думка stop doing some crazy things, да, і стоючи зараз в цій точці часу, я розумію, що ми тоді робили такі дурниці, і я дуже вдячний йому, що він прийшов і нам це зробив, бачите, навіть вирішив кредити йому віддати, і QR-код вставити.

Ну, здається, що все класно, нам розказали, як робити добре, погано робити ми не будемо, що було далі, ну, чесно кажучи, нічого не змінилося. І проблема не в аудиті була, і не в аудиторі, проблема була саме в нас, і в тому, як ми керуємо, і в тому, як у нас все організовано. Андрій нам розказав, там, як правильно робити, як все робити, але були певні такі штуки, знаєте, в кожній команді є своя культура. І навіть в нас, в інших проєктах, я бачив, що немає таких проблем, як саме в цьому проєкті, і в чому ж вона полягає. Є культурні відмінності, є різні там типи людей, які по-різному взаємодіють, по-різному беруть відповідальність, там, і так далі. І почали вже копати самі, почали вже копати самі, чого ж не виходить, чого ж ми виконуємо. Є якісь поради з Roadmap, покращені з DLC, але краще, ну, там, стає в моменті якісь речі, там, да, трошки краще, але глобальність цього цього не міняється. Ну, і зіштовхнулися з такою важкою штукою, як Communication Complexity. Так як у нас, як би грубо це не звучало, всі варилися в одному котлі, у нас було багато людей. Що це означає, так? Це ромбіки, це... Люди, там, лінії, це зв'язки між людьми. Якщо у тебе команда, там, з 4 людей, вона має, там, 6 зв'язків. Якщо команда з 5 людей, вона має, там, 10 зв'язків, з 8, це вже 28. Ну, і відповідно, якщо у тебе команда в 35 людей, то це майже 600 зв'язків, а якщо взяти загалом всю команду, яка керувала проєктом, ну, яка займалася проєктом, то це, там, 68 людей було на той момент, і це було більше, більше 2 тисяч хаотичних зв'язків один з одним. Тобто, зараз сказати, тю, блін, там, можна наняти проджекта, продукта, там, ще одного інженірінг-менеджера. Ми пробували, не допомагало. Можливо, ми щось робили не так, я не знаю. В цей момент, на цій точці, коли ми це зрозуміли, я зрозумів, що це все.

Далі треба щось міняти кардинально, якимись маленькими кроками, якимись маленькими степами, щось. Тут трошки покращити, там трошки покращити, тут щось налаштувати, далі так справа не буде йти. Ми тонемо в хаосі, проєкт тоне в хаосі. На той момент, скажімо так, в проєкті були серйозні виклики, серйозні фінансові проблеми на той момент також були. Коротше, зі всіх фронтів дивилося, нормально піддавлювало. Вирішили, що треба щось міняти, так як я адепт цілий. Цілий поляга... Цілі полагання. То, звісно, почали з цілей. Що ми почали робити? Поставили собі такі чотири цілі, які ми хочемо від того, що ми будемо робити далі. А саме спростити цю робочу комунікацію і робочі процеси, щоб вони були прозорі, зрозумілі, щоб кожній людині в кожний момент часу, в кожній задачі було зрозуміло, принаймні, до кого йому йти і що в нього запитувати. Безумовно, фокус на продуктовій цінності, бо хто був в трекі Бі на минулому, позаминулому виступі, коли виступав Євген, він казав, що треба будувати не код, а вистроювати бізнес-модель і орієнтуватися на бізнес. І саме тоді у нас також була така проблема, знаєте, всі... Зараз ми все напишемо самі. Все. Нам не потрібні ніякі там клієнти, продукти, сервіси.

Ми зараз все напишемо самі. Ми писали багато коду, а цінності в ньому було, ну, не зіро там, але досить мало і зараз там досить важко це розгрібати. Все досі це є ехо тих часів. Забезпечити можливість масштабування команд, бо зрозуміло було тоді, що, ну, якщо ми наймемо ще 5 людей, ми просто потонемо в цьому хаосі, вони просто, ну, питаннями заклюють тебе і далі не буде. Ну, і четверте, така проблема з зірочкою, розв'язання проблем продуктового беклогу. На той момент у нас були певні проблеми з продуктами, не завжди встигали, не дуже якісно встигали описувати задачі і хотілося ж якось, щоб розробники не докапувались там, а тут в тебе не так описана задача, як ми домовлялися, тут там щось недоописано, щось недозрозуміло і так далі. А щоб вони більше активно приймали участь в тому, як формувати. Як формується наш беклог, які задачі ми робимо, і щоб вони розуміли, навіщо ми це робимо, це найголовніше. Як йшли? Вирішили, що будемо робити крос-функціональні команди, бо, ну, тіпа, робили певні ресерчі, знову ж таки, стоячи тут і зараз, я можу сказати, що різниці, там, ділити, по якій структурі, не багато великого значення воно не має. Має значення, як ви до цього підходите. І як правильно виводити всі процеси.

Перша команда у нас суперорганічно виділилася, вона виділилася навколо платежів і всього, що пов'язане з платежами, це paywall, recurrent, cashback і так далі. Ми вже там раділи, що все класно, все завелося, там, спойлер, жодна з інших команд сама не завелася і доводилось багато працювати над цим. З цим тушили пожари, які в нас виникали, бо все ще, там команда яка відокремилась, було 8 людей, а ще, там, 25 у нас все ще там було в цьому хаосі. Ось, але вже в той момент почало ставати краще, продукт почував потроху рости. Що ми робили? Шість місяців ми спостерігали. Спостерігали, крутили комбінації, як можна поділити, кого ділити, на які команди. Як саме, які зони відповідальності будуть, і так далі. Від ідеї того, як ми прийшли до цього там, повноцінно працюючих команд, у нас пройшов один рік. Хтось з вас скаже, що це дуже багато, я теж скажу, що це дуже багато, але процес нас зайняв стільки, і тут, не про що не жалію, насправді, тут не треба поспішати про це. Тому я трошки далі скажу. Що ми зробили? Зробили команди.

Як виглядає команда? Це вже слайди з презентації, яку ми робили на нашу, внутрішню презентацію. Котики — це розробники, QA, бекенди, iOS-розробники і так далі. Поліцейський — це Scrum Master, і єдинорог — це Product Owner. Вона від команди до команди міняється, а поліцейських і єдинорогів — вони зазвичай по одному, деколи там єдинорогів буває два. Що виконує Product Owner? Формує стратегію команди, що вона робить, коли вона робить, навіщо вона це робить, відповідає за беклог, відповідає за пріоритизацію, допомагає іншим учасникам робити зміни там в той час, коли вони потрібні, ну, і взаємодіє з іншими командами. Бо все ще багато задач перетинається один з одним, і різні команди по-різному перетинаються. Що робить Scrum Master? Ну, це така більш процесна робота, робить дотримання узгоджень, про які ми домовилися, відстежує процеси, пропонує покращення, відповідає за пленінг та естімацію конфлікт- та ризик-менеджмент команди. На той момент, коли... Які ризики ми бачили? Конфлікт зон відповідальності, конфлікт ризик-менеджменту, перетин продуктових логік та спліт-тестів.

Ці перші три, вони виглядали як найкритичніші, бо, як я вже казав, у нас була та і є там, своєобразна культура в команді. І... Що таке перетин продуктових логік та спліт-тестів? У вас є дві команди, одна відповідає за гроші, друга за ретеншн. Як підняти гроші? Ми робимо paywall, який не можна зробити. Вуаля, гроші є, тільки ретеншну не буде. Ось. Ну і навпаки, так? Команда, яка відповідає за ретеншн, давайте зробимо все безкоштовно, там, закриємо paywall, у нас буде класний ретеншн, але не буде грошей. Особисто я за цей пункт, я не те, що переживав, я жити не міг. Бо я знав характер цих людей, я знав, як вони будуть вгризатися в свої цілі, я знав, як вони будуть сперечатися один з одним. І це був для мене, ну, прям, найсерйозніший ризик того, що ми це робимо. Я на той момент ще не знав, як ми будемо це розрулювати, як це буде відбуватися. Ну, там, знаєте, цей стан, коли це тягнеться рік, ця історія, і ти кожен день про це думаєш, там, о четвертій ранку прокидаєшся, такий, бля, не буде, не вигорить, не взлететь. Але знову ж таки, в точці тут і зараз можу сказати, що перші, конкретно в нашій команді, перші три ризики, вони не виправдалися.

Тому що, а саме чому, я зараз розкажу на наступному слайді. То, як ми поділили команди. Ми зробили чотири команди. Це Revenue Growth Team, Engagement Growth Team, Women Experience і Streams Growth Team. Що вони роблять? Ну, відповідно, перша команда відповідає за гроші, друга команда відповідає, там, за ретеншн, повернення юзерів, там, і загалом за юзер експірієнс. Четверта, відповідно, за експірієнс жінок на продукті. Бо, ну, як ви знаєте, на кожному дейтингу жінок менше, ніж чоловіків. Така стата, нічого з цим не зробиш. Ну, і відповідно, на кожну жінку в тебе є багато активності від чоловіків, яку треба там дозувати, порцувати, щоб жінці було приємно користуватися продуктом. Ну, і стрім у нас були, і ще трохи є такий функціонал, як стріми, і окрема команда їм займалася. Ось. Хтось з вас, хто дуже кмітливий, може сказати, що це не зовсім крос-функціональні команди. І він буде правий, насправді. Якщо дивитися в книжку, то це по-правильному називається стрім-алайн команди, бо є певні стріми, за які відповідають. Бо ми не змогли, ми думали, пробували, але не змогли поділити конкретно по функціоналу. Який, не як не поділити функціонал. Ну, тобто, там. Так. Тобто, ти відповідаєш тільки за меседжі, і всі задачі по меседжах проходити через тебе, там. Ну, коротше, ми бачили в цьому певні ризики.

І вирішили поділити по таких бізнес-напрямках, які будуть більш ширшими. Тобто, да, це не означає, що команда Revenue не може відправити пушку юзеру, да. Або зробити якийсь функціонал, який буде відправляти пушку. Їй треба йти в команду Engagement. Ні, вони це можуть зробити. Ніхто їм це не забороняє. Але воно має бути узгоджено. В кожній з команд є свої описи бізнес-процесів. Свої описи того, як у них влаштований той функціонал, яким вони працюють. Досить просто можна розібратися, подивитися, як в тої команди це робиться . Ну, якщо ти один раз вже додавав пушку, то, там, другий чи третій раз її додати, це вже не важко зробити. На мою думку, саме такий розподіл команд дозволяє нам не хвилюватися за цей третій ризик. Тому що, так, цілі у всіх стоять, але цілі досить широкі. І насправді там не все так однозначно, так. Популярна фраза останні два роки. Не все так однозначно, не все так, як сказати, не все так перетинається насправді, як ми думали на початку. Що ми маємо? На жаль, зараз лишилось тільки три з чотирьох команд. Команда ось ця четверта, яка називалась Stream Growth Team, розформована, тому що функціонал стрімів ми вирішили, що він нам не потрібен, і ми його будемо видаляти, він доживає свої дні, він тільки на саппорті, і як такова команда не потрібна.

Що ще додали? Додали ще системну команду. Я трошки пізніше розкажу про це. Що ми маємо? Команди допомагають генерувати гіпотези. Є продукти, які там формують глобальний весь беклог, але ж ми всі з вами, інженери, розуміємо, що крута ідея, вона десь на перетині між ідеєю і технологіями. Не завжди продукти знають, чи можна щось зробити, чи не можна, чи є там на цьому етапі певна інформація, чи немає. Коли команда маленька, всі залучені в створення беклогу, в створення задач, всі залучені в генерацію гіпотез, вони допомагають краще розкрити кожну з гіпотез, вони допомагають, розробники самі доповнюють те, що ми робимо. Тобто вони знають, окей, на цьому степі ми можемо показати там вже фотку там юзера, з яким ти змерчився там, а на цьому степі ми можемо показати там прев'ю меседжі там і так далі. Це насправді дуже круто працює. Я не знаю, чи це так, чи ні. Я не можу сказати, що там ми прям вирішили проблему беклога тим, що ми зробили ці команди. Ні, але ми якісно покращили гіпотези, які в нас є, які ми тестуємо, які ми генеруємо. У нас виросла кількість успішно закритих тестів. Ми весь функціонал викатуємо в вигляді АБ-тестів, ну майже весь, 99%. І відповідно там від того, як ми вирішуємо те, що ми робимо, як багато ти можеш робити тестів, так швидко буде рухатись твій бізнес. Тобто відповідно це досить така суттєва метрика, яка допомагає бізнесу швидше рухатись. Ну і Velocity команд зросло, кількість зроблених епіків також зросла. Трошки докладніше про це все.

Що таке системна команда? Все одно є якісь штуки, які не підпадають під жодний стрім жодної з команд. Як-то там legal задачі, проходити аудит GDPR-у, там я не знаю, якісь маркетинг штуки, які треба робити. Хто працює з мобільними додатками, знає, що трекінг інсталів та всього іншого - це окрема біль, така, яку теж потрібно комусь робити. Для цього ми відокремили системну команду, яка відповідає за ці задачі, що не підпадають під жоден стрім. Загалом, вона відповідає за перформанс системи і долучається інколи, коли ми виконуємо великі завдання, апгрейди, рефакторинги або інші великі фічі, заплановані на квартал. Ці задачі приєднуються до системної команди, щоб мати спецназ, який можна викликати, коли потрібна допомога чи вирішення інцидентів. Наш Velocity. Зліва, як було, а праворуч з 1 січня 2023 року ми вже повністю інтегрували всі ці команди (позначені зеленим), тобто змінили їх статус. Виглядає це краще і за візуальним сприйняттям, і за цифрами.

Що маємо? Зріст закритих задач і сторіпойнтів становить 43%. Кількість закритих експериментів (АБ-тестів) зросла на 37%. Success rate експериментів залишився тим же, тобто не змінився, але ми почали проводити більше експериментів. Кількість дефектів на задачу зменшилася приблизно на 20%. Висновки. Найважливіший слайд. Чому я взагалі тут? Коли ми розпочинали цей процес, мені було дуже стрьомно. Чому? Тому що я відповідаю за велику кількість людей, за бізнесові рішення, за те, щоб люди отримували зарплату і так далі. Це велика відповідальність. І коли хтось пропонує повністю змінити розробку, це викликає тривогу. Також, мені не вистачало інформації від тих, хто вже цим проходив. Тому я сподіваюся, що ця доповідь надихне тих, хто ще колеблеться. Мені не вистачало доповіді, де хтось ділиться своїм досвідом і розповідає, як це було. Тому ми розглянемо наш досвід і поділимося висновками.

Одна з важливих рекомендацій: не поспішайте. Я говорив, що наше впровадження зайняло рік. Це не так довго, як здається. Чим більше ви плануєте і розписуєте, тим більше ви врахуєте неочевидні сценарії, тим більше можливостей протестувати фічі, інструменти, підходи і т.д. Другий важливий момент: підготуйте команду до цього. Ви, як ініціатори змін, не будете робити це руками. Ваша команда буде втілювати зміни. Команда повинна розуміти, чому вони це роблять і як робити це правильно. Важливо, щоб всі були на одній хвилі, прочитавши одну літературу та розуміючи, як це правильно робити. Що стосується ролі Scrum Master - важливо мати чітке розуміння своєї ролі, цілей і взаємодії з іншими. Ми відвели рік для цього процесу, проводячи опитування, майстер-класи та презентації, щоб кожен у команді точно розумів свою роль.

Вибачте за тривалість, але це важлива інформація. Не поспішайте і готуйте свою команду до подібних змін. Навіщо потрібні цілі? Коли ви розпочинаєте цей процес, вас буде трясти, і це нормально. Вас буде трясти, ви будете думати: "О, можливо, це ще можна переробити, або тут зробити зміни в дизайні, або привернути маркетинг." Якщо у вас є чіткі цілі, вони завжди будуть вас направляти, утримувати вас в потрібному напрямку. Ви завжди зможете перевірити, чи сприяє переробка дизайну досягненню цієї цілі. Таким чином, ви можете вирішити, чи варто це робити чи ні. Не бійтеся цього. Зміни завжди важко впроваджувати, команди не завжди готові до змін. Наш мозок відчуває комфорт у відомому, і коли вводяться нові процеси, ролі чи команди, він спротивляється на 100%. Та не бійтеся, якщо у вас є ціль, і ви підготувалися належним чином, ймовірно, все пройде добре, включаючи команду. Можливо, ви почитаєте відгуки від наших колег, і вони, ймовірно, не наведуть на те, як було раніше. Вони, швидше за все, скажуть: "Було важко, був хаос, але зараз все чудово", і вони навіть не згадають, як було погано, бо супротив тривав всього лише рік, коли ми впроваджували ці зміни. Також, як запобіжний захід, якщо щось піде не так, навіть якщо все провалиться, ви завжди можете повернутися назад. Відмінити зміни - це не так важко, ви просто кажете: "Окей, ми відміняємо ці процеси", і все, ми повертаємося до старого. Найгірше, що може статися - ви втратите трошки часу, можливо, у ваших інженерних менеджерів чи лідів, але глобально це не є серйозною проблемою. Дякую за увагу.