Привіт всім, дякую за те, що обрали саме цю презентацію. Я Вадим Святой, інженер та менеджер українського мобільного банкінгу PUMB Online . Протягом декількох років я працював над тим, щоб зі застосунку, створеного однією невеликою командою, розширити цей стан до платформи. При слові "платформа" зазвичай уявляються SDK, купи документації, фреймворки API, мультимодовні рішення, архітектура, комплексні підходи по кашуванню, хайлоад, мікросервіси. Проте сьогодні ми не будемо говорити про це. Я хочу поділитися тим, чому нам знадобилося рости, як ми з однієї команди створили 20, за якими принципами вони постійно реалізуються одночасно.

Давайте спочатку трошки контексту. Декілька років тому, у 2020 році, PUMB Online вже був на ринку. Перша версія була розроблена за півроку, і саме сьогодні день народження – перший публічний реліз був 19 листопада. Ціль була проста: створити мобільний сервіс, який надасть віддалений доступ до найпопулярніших продуктів банку, щоб люди не ходили у відділення, а використовували мобільний застосунок. Успіхом визначили, що якщо 95% поточних клієнтів будуть користуватись мобільним сервісом, незважаючи на веб та відділення, то це добре. Це означало, що ми задовольняємо ключові потреби. Процес розробки був простий: одна команда, декілька мобільних та бекенд-інженерів, архітектор, аналітик, кіо, дизайнер, піо. Ця команда працювала за простим скрамом, з беклогом на місяці вперед.

Однак з часом змінилися умови. Беклог тільки зростав, і він вже не був настільки прозорим та пріоритизованим, як раніше. Раніше було просто: депозити, перекази, картки. Тепер стало складніше визначити, що робити раніше, оскільки всі продукти і операції стали важливими. З'явилася необхідність розвивати більше продуктів паралельно. Так з'явилися нові команди – більше 15 продуктових сервісних технічних напрямів. За кожним з них є своя команда, яка вирішує власні завдання. Цей підхід дозволяє нам реалізовувати різні продукти одночасно та ефективно.

І таким чином, PUMB Online став майданчиком для того, щоб різні команди, різні бізнес-напрями могли розміщувати там все, що потрібно саме їх клієнтам. Чому навчилося за таку трансформацію, таке масштабування? Ну, спочатку взагалі про цілі, які взагалі бувають. Можна створювати більше. І розвивати свій продукт більш різностороннім. Чи, навпаки, можна створювати щось швидше. Тоді кожну задачу можна зробити на маленькі шматочки і окремими командами це робити. Чи може це культурний розвиток? Наприклад, на ринку з'явилися інноваційні компанії з проривним підходами до роботи і культури. І варто шукати там людей, щоб принесли свіжу кров і знання. Ну і... Банально розвивати стійкість систем чи нові ринки. Що ми для себе обрали?

З цього всього... Стало зрозуміло, що ці цілі чудово конфліктують між собою. І треба щось обрати. Тобто, я прошу, якщо ви візьмете 10 команд з окремими беклогами, то одна окрема задача швидше робитись не буде. Скоріше за все, навіть довше буде робитись. І навпаки, можна взяти всі команди і сказати, ви всі працюєте над напрямом: реєстрації, другого клієнта. Але на цей час тоді розвиток інших напрямків стане. Тут... Ціль більше і швидше прямо конфліктує. І про це, окей, заздалегідь говорити. У нас, наприклад, не одразу у всіх було розуміння, чому ми при інвестували купу часу і грошей, а тайм-то-меркет окремої задачі не покращився. Але ми для себе вирішили, що хочемо працювати, як серійні міні-стартапи у вигляді команд, що самостійно розвиваються. Розвиваються і напрямок, і відповідають за те, що зробили. Цілі було дві організаційних: мати змогу фокусуватись на багатьох напрямах і розвивати культуру міні-стартапів на базі мобільного банку. Тому тут дуже прості висновки.

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

І окремий лід окремої такої компонентної команди може проєктувати все в рамках своєї системи самостійно. Давайте просто додамо їм людей. Окей. Додали. Тепер же очікування, що маємо робити більше. Але що стається? Якщо більше людей, і треба одночасно робити більше задач, то в один компонент буде одночасно заходити задач трошечки більше, ніж там людей. Ну, бо ви ж можете зробити ще і це, і це. У вас там задачки поки тестуються. Чи ви там чекаєте інший компонент, наприклад, дизайну. Це перша історія. З'являється багато вхідних задач. Друга частина. Це залежність з іншими компонентами. Тобто вже мало узгодити пріоритети беклога. І між розробниками компоненту розділити ці задачки. Треба ще узгодити плани. І зрозуміти, коли буде готовий дизайн. Коли бекенд. Коли iOS. Коли Android. Щоб все це разом вийшло в єдиному релізі. Тобто, якщо коротко, то картинка малюється для компонентної команди. Робити треба все. Новий дизайн. Новий продукт. Манібокс. Перекази за кордон. Новий бюджет. Інтеграцію з DIA. Окрім цього, треба і старе пофіксувати. Виконати регулятор. Звичайні вимоги. Комплайнс. Перейти на нову архітектуру. Ну, і продукт фіксити.

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

Ну, є нові питання. Якщо всі умовно junior-розробники знаходяться в різних командах, то що буде з кодом через рік? Хто підтримує стандарти розробки? Хто рев'юває код? Хто керує техборгом? Хто шукає нових розробників? Хто їх онбордить? Хто їх розвиває? Один з варіантів відповіді на це питання дає підхід компанії Spotify і їх реалізація відомої матричної структури. Так у нас є роль інженерного ліда або чаптер-ліда. Ця людина знаходиться в одній з команд, працює руками кожен день. Але десь, на 50%, інший час вона приділяє розвитку людей своєї компетенції і допомагає їм реалізовувати свої задачі ефективно і консистентно, в межах системи організації.

Але тут треба обережно. Існує думка, що така людина може ефективно працювати з 8 чи 12 людьми в своєму чаптері. Дехто навіть каже про 20. Ми на практиці бачимо, що це 4-8. Вісім – це максимум і тільки тоді, коли процеси в загальному вже налагоджені. Це перше. Технічна консистентність та розвиток людей. Друге. А хто беклогом керує? Тут відповідь простіша, product owner. Якщо команди згруповані навколо фокусного напряму, то у цього фокусного напряму є беклог, є людина, яка цим керує. Тому, якщо підсумувати, навколо стратегічних напрямів побудували кросфункціональні команди. Але, до речі, залишилось багатокомпонентних, як технічних, так і не технічних. Наприклад, є компонентні команди навколо декількох корсистем банку, наприклад, процесінгу.

Деякі кросфункціональні команди мають видільних людей, що можуть туди щось доробляти. Але вони живуть разом з командою в рамках тих задач, що є в команді. В цілому в індустрії є багато порад. Як треба, як не треба. Що має бути кросфункціональним, що компонентним. Але це завжди якийсь баланс. Не буває абсолютного рішення. Наприклад, команда безпеки в нас залишилась компонентною. Але на кожній умовні 5 команд є виділена людина, яка є єдиною точкою входу по всім питанням безпеки для функціоналу цих команд. Так зроблено, бо жодній команді на 100% такий спеціаліст не потрібен. Та й на так їх взагалі багато.

Далі, наступний Learning. Product Owner і беклог. Холіварна тема в індустрії, але це просто інструмент. Скільки їх потрібно, відповідає стратегія компанії. Скільки напрямів хочуть розвивати однчасно. Якщо їх 15, нехай буде 15 ПІО, 15 беклогів і ще більше команд навколо них. З мінусів, якщо команда об'єднана навколо свого беклога, куди складніше і операційно, і мотиваційно об'єднати ці декілька команд навколо однієї спільної задачі. Але все одно можливо. Періодично робимо.

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

І останній висновок про культуру масштабування команд. Ми спробували два варіанти. Перший – взяти досвідченого technical lead, product owner декілька HR і нехай будують, шукають команду повністю під себе і свій напрямок. З плюсів – швидко приймається рішення, можна вирішувати, можна одним днем давати офери. Люди зазвичай наймаються ті, що по софт-скілам саме цим людям підійдуть. З мінусів – люди, яких вони наймають, працюють повністю в новій команді в них зовсім немає горизонтальних зв'язків з іншими колегами аналогічних компетенцій. Ця комунікація вона йде через ліда, отримаємо таке собі королівство в королівстві. Там з'являються власні стандарти коду, механіки релізів тощо. Ця команда не використовує переваги великої компанії, кожен день будує свої велосипеди, технічні, процесуальні. Для спільного продукта це шкідливо, хоча в команді деякий час окей. Зрозумівши це, ми зазвичай практикували історію, коли ліди ПІО нової команди наймали людей в якусь вже існуючу команду, разом з учасниками такої команди. І на якийсь короткий час існуюча команда таким чином зростала десь вдвічі. Потім звідти просто відділялась команда, наслідуючи культурні цінності та інженерні практики. Дуже схоже на розподілку клітин.

Коли президента Форда і Крайслера репортер попросив розказати, як же йому вдалося вивезти компанію з кризи, попросив описати порядок кроків, то у відповідь той зареготав і сказав, що ніякого порядку не було. Робити треба було все одразу і зі швидкістю світу. Щось схоже відбувається і під час масштабування. Ця зміна охоплює всіх навколо і впливає дуже комплексно. Порядку тут не буде, але план потрібен. Тобто, після того, як ви зрозумієте, що ви хочете досягти стратегічно, вам потрібно спланувати структуру, які є компетенції, хто за них відповідає, хто розвиває, хто шукає нових людей, які ролі з'являються, а які софт-скіли і кому потрібно. Чому софт-скіли між командами розрізняються? Наприклад, одна команда звикла до челенджей і сама себе челенджить кожен спринт і бере більше, ніж може зробити. Їм це окей, це драйв. А їхні сусіди так не працюють. Їм важливий порядок, і вони повинні зробити все, що запланували, бо інакше вони не відчувають, що вони щось закінчили корисне. Це все треба враховувати. Питань безліч. Після питань людей, структур, стратегій не менш важливі питання технологічні.

А чи готові IT-системи? Чи готові до того, що в них будуть різні команди з різних сторін щось контриб'ютити? Як потім треба перейти на рівень команд? Це планування, реалізація роботи всередині? Як команди працюють з командами, синхронізуються на рівні груп команд, трайбів? І як потім ці групи команд бюджетуються, будують прогнози, синхронізують всі свої roadmapи і backlogи? Якщо тут робити все по порядку, ідеально, крок за кроком, то поки дійдеш до останнього пункту, перша вже застаріє, а ринок знову зміниться. Тому тут для себе я виніс три речі. Ця зміна має відбуватися швидко, дуже швидко. У нас був календар десь на пару місяців, де майже кожен день був дедлайн по якомусь питанню чи процесу. Ми розуміли, коли ми закриємо питання структури, коли намалюємо правила гри по взаємодії команд, коли вирішимо, що ми будемо робити з монолітними IT-системами. Це виглядає, як нормально запланована зміна, але в цій поіті половина рішень не буде досконалою або буде тимчасовою. Це і вносить елемент хаосу. Ми не навчились прогнозувати майбутнє, і тому з першого разу ідеальні правила не зробити. Тому внутрішній перфекціонізм приховали і, звісно, до якихось різних питань треба буде повертатися. До цього треба бути готовим. Останнє. Перший короткий період часу більшість учасників масштабування будуть мотивовані тим, що ми зростаємо, зможемо робити більше корисних речей, але цей етап не триває довго. Складнощі і час вбивають цю мотивацію. Тому важливо робити все швидко, поки команда мотивована і готова до змін.

Далі. Тепер хочу трошки докладніше пройтися по дизайну команд. Якщо подивитися на рекомендації Agile-коучів, Scrum-гайдів, все, що на це схоже, дуже часто є дві речі. Команди повинні реалізовувати свої задачі end-to-end, тобто мінімізувати залежності від інших. Друге, команди повинні бути невеликими і такими, які можна було б нагодувати двома піццями. Звучить круто і корисно, але трохи конфліктно. Давайте подивимось на типову задачу реєстрації клієнта. Які тут є кроки? Спочатку це маркетинг. Потенційного клієнта треба привести в застосунок, щоб він його завантажив. Далі. Фінтех - над регульована галузь. Є купа нормативних актів, які вам кажуть, що можна робити, що не можна. Чому інтеграція з дією більш достовірна, ніж фото ваших документів і NFC, наприклад. Далі. Треба порахувати, на який продукт приходить клієнт. Чому йому це корисно, який тут P&L. Надважливим кроком є рішення по кредитному ліміту. Половині клієнтів цікаве саме це. Коли все це склалося, треба зібрати все це воєдино та підписати договір і реалізувати підтримку цього продукту у мобільному застосунку. Якщо щось не так, то і підтримку десь у месенджерах. А якщо він захоче піти, треба якось пропрацювати механізм для повернення чи навіть уникання. Тобто, winback. І тільки на одній ідентифікації клієнта KYC для фінтеху, купа людей будує окремі бізнеси. І зробити це маленькою задачею однією end-to-end командою до восьми людей, це трохи нереально. Якщо, звісно, не хочемо це робити роками. Тому приходимо до того, що команди можуть бути різними і end-to-end, не означає зробити весь продукт. Ми для себе виділили три типи. По-перше, це можуть бути команди customer journey, які відповідають за якийсь шматочок шляху користувача. Це як залучення, і це маркетинг. Хтось відповідає за етап join, це той самий KYC та реєстрація. Хтось за те, як саме користувач використовує продукт або сервіс. Це менеджмент витрат, продуктовий сервіс, історія операції, що-небудь ще таке. І, якщо хтось вирішив піти, то команди з лівого крила мають повернути, активувати кешбеки, комунікації, реферальні програми. Далі, можуть бути продуктові команди. Це команди, які відповідають або за P&L і математику продукту, або за все разом, якщо це невеликий продукт і він може лягти на рейс вже зробленої мобільної платформи, мобільної чи взагалі технічної платформи в банку.

І третій тип - це Enabler команди, які роблять життя інших команд простіше. Це може бути команда дизайн-системи, команда внутрішнього інструментарію, чи аналітична платформа. Їх мета полягає в тому, щоб зробити API чи Toolset навколо якоїсь складної чи перевикористовуємої інфраструктури. Тоді інші команди можуть це використовувати, не задумуючись про внутрішню складність, як воно там все влаштовано. Тому, які тут для себе висновки зробили? N2M буває різний. Якщо не вписується все в одну команду, не треба десь шукати якісь компроміси. Треба розділяти ці команди своєю метою та принципом побутові окремі команди. Далі. Разом з цим дуже важливо уникати просто команд навколо системи. Це дуже легко перетворюється на bottleneck і всі стають в чергу. У нас є такі приклади, з якими ми працювали і працюємо. У більшості випадків, ефективніше зробити з цієї команди не тільки руки, що для всіх навколо в своїй системі щось роблять, але й створити нормальне API та документацію про те, як саме будь-хто може доробити цю систему.

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

Далі. Багато сказав про команди, їх побудову, взаємодію, і хочеться щось ще технічне про квінтесенцію всієї технічної роботи, про релізи. Саме про релізи мобільних застосунків, яких один на команд багато. Коли була одна команда з релізами, все було просто. Мовно, модель ондемонт. Тобто, щось зробили, з чим клієнт може користуватися. Окей, давайте проведемо регресійне тестування і випустимо в реліз. Чи можливо так робити з 20 командами? Регресія може займати дні, рецензії в магазинах теж можуть займати дні. Користувачі не люблять отримувати оновлення кожен день, оскільки їхні додатки вже важкі. Так що, мабуть, неможливо. Ймовірно, часто будуть конфлікти. Якщо ондемонт не підходить, потрібно планувати релізи. І це виглядає так: перша команда завершила свою роботу, і далі. Інші можуть потребувати додатковий час, наприклад, 2 дні, щоб доробити щось важливе. Однак команді, яка вже працювала над терміновими вимогами регулятора останній місяць, може бути важко прийняти це. Також ті, хто вже запустив рекламну кампанію, не може дозволити собі затримок. Навіть за всім цим може стояти об'єктивна реальність, і через будь-що релізи можуть відкладатися. Навіть якщо вони вирішать, що повний регрес необхідний, робота з гідом максимально спрощена. Має бути тільки одна довгоживуча гілка, без основних функцій розробки. Ця гілка виходить в продакшн і забувається, вся інша робота відбувається в гілках, які живуть дуже короткий час - дні або години.

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

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

І останнє, трошки про платформу. Розуміючи, що багато команд має спільні виклики, такі як безпека, робота з даними, спільний UI/UX, стабільність спільних сервісів і т.д., важливо мати команду, яка відповідає за підтримку та розвиток цих аспектів. Розмазувати відповідальність за дизайн-систему чи стабільність спільних сервісів на всіх не працюватиме. Починати треба з малого - документації та гайдів, як користуватися спільними речами в коді. Це перша версія платформи. Поступово перевикористовуємо речі, обгортаємо їх у API. Таким чином, це як швидко, так і безкінечно. Наступне ключове питання - стабільність. Як забезпечити її, якщо ви не контролюєте всі запити та активності інших команд? Це питання вимагає окремої обговорення, але є кілька ключових висновків, які хочу підкреслити. Спробуйте ідентифікувати 5-10 запитів, які генерують 80% навантаження. Обробляйте їх у окремій платформеній команді для оптимізації та контролю. Також майте план на випадок, якщо все, що ви планували, не спрацює. Зовнішні події можуть спричинити сплеск навантаження, і вам треба буде реагувати швидко.

Кілька ключових висновків: за останній рік було зроблено більше 25 мобільних релізів, понад 50 нових фічей та мажорних оновлень, включаючи повністю нову архітектуру. Більше 15 команд та понад 150 людей працюють над цим, при цьому кількість активних користувачів зросла втричі. Все це для того, щоб зараз сказати, що можна підняти поточні результати втричі. Дякую всім за ваш час та увагу. З радістю відповім на питання тут або в дискорді.