Ненудний банкінг: що стоїть за менеджментом фінтех-проєктів

Мене звати Артем Локтіонов. Я відповідаю за операційну роботу в Alty, і сьогодні я пропоную поговорити про команди: їхню цінність та процеси взаємодії.

У попередній статті про «ненудний банкінг» моя колега Діляра Асанова ділилася думкою про те, що стоїть за дизайном фінтех-продуктів. Я вирішив продовжити тему нетривіального банкінгу та обговорити принципи комунікації (як всередині компанії, так і з банківськими/ фінтех-клієнтами), методи управління проєктами та збереження мотивації у командах.

Як здати проєкт без розуміння суті завдань? Як навчитися писати довгі та безглузді ТЗ? Як непомітно уникнути відповідальності в роботі над IT-продуктом? Відповіді на ці питання ви не знайдете в сьогоднішньому матеріалі :)

Ця стаття буде корисна проджект менеджерам, керівникам операційних підрозділів і всім, хто в принципі працює не самостійно, а в команді.

Intro

Восени 2017 року ми тільки-но здали проєкт Monobank, і команда була окрилена. В той самий час я приєднався до компанії. Моїм першим завданням було зберегти цей драйв та подбати про результат на нових фінтех-проєктах, які після Mono йшли один за одним. Згодом, окрім забезпечення безперебійного флоу на проєктах, я почав думати й про те, чим зайнятися команді після їхнього завершення.

По суті, це був не мій прямий обов’язок, але реалії маленьких компаній такі: твоя роль завжди дещо ширша, ніж прописані функції в job description. Я почав допомагати СЕО планувати майбутні проєкти, брати участь у редизайні процесів роботи компанії, переймати на себе роботу з партнерами та підрядниками. Так поступово я став СОО. Хоча, як і раніше, намагаюся брати участь у житті проєктів, не заради мікроменеджменту, а заради причетності :)

Що спільного між банкінгом та Ісааком Ньютоном

У своїй ролі я маю чудову можливість порівняти наші підходи в роботі з підходами в інших сферах — від банкінгу до e-commerce. В той час, як технологічні компанії є гнучкими за природою та відкритими до різних експериментів, банківській структурі властива інерція (тобто здатність зберігати стан спокою чи рівномірного прямолінійного руху, якщо на тіло не діють інші тіла. Дякую Ньютону та його колезі Галілею за визначення).

Це спостереження прийшло з першим міжнародним банком у нашому портфелі. Ним виявився швейцарський приватний банк із більш ніж 45-річною історією. Мені він нагадує величезний крейсер, який рухається океаном з постійною швидкістю, і кожен маневр йому дається дуже неспішно. Таку машину не розвернеш на повному ходу на 180°, але й потопити її практично неможливо.

У швейцарському банкінгу звикли до розміреності та спокою у всьому — звикли до інерції. Тому, коли подібних «банківських крейсерів» наздоганяють та переганяють швидкі та маневрові фінтех-стартапи, першим доводиться переглядати свою стратегію. Згідно з дослідженням Forbes, 1 трильйон доларів США було інвестовано банками у цифровий банкінг по всьому світу за останні 5 років, щоб залишатися конкурентоспроможними.

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

Agile vs традиційні методології проєктного менеджменту

Попри те, що agile став трендом останнього десятиліття в бізнесі, банки звикли до чітких правил. Їм близька традиційна методологія проєктного менеджменту, де зафіксовано терміни, бюджет та обсяг робіт. Проте статистика свідчить, що у понад 70% випадків проєкти з традиційною методологією зазнають невдачі і відхиляються від запланованих обсягів, бюджетів чи термінів. Це відбувається не тому, що підрядник некомпетентний, а скоріше тому, що передбачити картину в деталях і усі сценарії на старті просто неможливо.

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

Відтак гнучкий туристичний маршрут у житті — це ітеративний підхід у роботі з банками. Суть цього підходу полягає в тому, що процеси тестування та звіряння виконуються протягом усього проєкту. Адже ми розуміємо, що банку важливо отримати не етапи, які були суворо зафіксовані на папері, а кінцевий продукт, що працюватиме і досягатиме бізнес-цілей у житті.

Але навіть в agile підході є одне важливе «АЛЕ». Якщо під час таких ітерацій пункт призначення постійно змінюється, є ризик, що ви туди так і не зможете дістатися, або ж дістанетеся за великих витрат. Тому завжди тримайте у фокусі свою мету та звіряйтеся з клієнтом.

Знайти свого Ікрана, або Коротка історія взаємодії з Product Owner

— Ти маєш обрати свого Ікрана. Якщо і він обере тебе, дій швидко. У тебе одна спроба. — А як я дізнаюся, що він обрав мене? — Він захоче тебе вбити.

Ця сцена з фільму «Аватар», де головний герой Джейк вирушає на пошуки летючого дракона Ікрана, нагадує мені реалії з життя проджект-менеджера, який повинен знайти свого Product Owner (PO). Спочатку PO хоче випробувати тебе на міцність :), а потім він створює всі умови для того, щоб ваш спільний «політ» (проєкт) був переможним.

На старті роботи з банком, — втім, як і з клієнтом з будь-якої іншої сфери, — дуже важливо познайомити команди. Необхідно зрозуміти, хто виконуватиме роль власника продукту (PО) на стороні клієнта, визначити формат та канали комунікації для обміну фідбеком та статусом виконання завдань. Вам дуже пощастить, якщо Product Owner виявиться організованою та впливовою людиною у своїй компанії та зможе синхронізувати подачу даних та фідбеку не тільки з ІТ-відділу, але й з інших департаментів, включаючи маркетинг, розвиток бізнесу та інновації.

Але, на жаль, так трапляється не завжди. Часто Product Owner не має достатньо компетенції та впливу в структурі компанії, і процес створення продукту може буксувати через складнощі з постановкою цілей і повільне узгодження результатів роботи.

Щоб цього уникнути, ми свого часу ініціювали формат воркшопів, під час яких ми «на березі» домовляємося про всі аспекти взаємодії із замовниками та формуємо очікування один від одного. Лише після обговорення та узгодження всіх деталей, ми розпочинаємо роботу над проєктом.

Модель Такмена і Дженсен

Роль та важливість присутності людини на стороні клієнта зрозумілі. Але буде нечесно сказати, що успіх проєкту залежить виключно від налагодження контакту із product owner. Налаштувати процеси у власній команді — ще більш відповідальне завдання. Зазвичай люди у вашій команді мають свій власний набір переконань, страхів та цінностей.

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

Ми орієнтуємось на чотириступеневу модель групової динаміки за Такменом: forming, storming, norming and performing (з англ. — формування, конфронтація, нормалізація, виконання), яка була переглянута в 1977 Мері-Енн Дженсен і доповнена ще одним етапом — adjourning (з англ. — розставання/ переформування).

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

А оскільки ми говоримо про менеджмент фінтех-проєктів, де є місце:

• передчасному вигорянню через велике завантаження в проєктах;
• стресу через роботу з безліччю засекречених даних;
• іншим викликам, —

побудовані процеси та відносини всередині команди допомагають впоратися з великим обсягом негараздів, що летять назустріч.

Однак і це допомагає не завжди. Як писав Фредерік Бакман у своїй книзі «Ведмежий кут»:

«Участь батьків — бути замаленькою ковдрою: як не намагаєшся всіх вкрити, все одно хтось мерзне.»

Так і в менеджменті: ти постійно намагаєшся подбати про своїх колег і зберегти в них почуття причетності, безпеки та підтримки, але виходить не завжди.

Fintech — is a new black

Скільки б викликів та перешкод не передбачала область фінтеху та банкінгу — ІТ-фахівці все частіше дивляться в цей бік. І невипадково. Платіжні інструменти розвиваються та стають базовою надбудовою у бізнесі. Непрофільні компанії запускають власні фінансові послуги та продукти. З глобальних — Amazon, Apple, Google та Facebook, з наших локальних — Fozzy Group, «Нова Пошта», LUN.

Зростання сегмента Fintech-as-a-Service призвело до того, що на перший план вийшла співпраця між різними видами бізнесу, залишивши осторонь жорстку конкуренцію. Є досвід, коли до нашої команди звертаються за експертизою у розробці продуктів з інших сфер. Подібні запити цікаві, тому що дозволяють розширювати горизонти та привносити кращий досвід з фінтеху до e-commerce, retail, educational, wellness tech, і навпаки.

На що звернути увагу під час роботи з фінтех-організаціями

На комунікацію. Від того, як комунікує ваша команда між собою та з клієнтом, залежить 80% успіху проєкту. Цитуючи вищезгаданого Ф. Бакмана:

«Коли у дитинстві я проливав молоко, батько завжди мене сварив. Спритнішим від цього я не став. Тільки почав боятися брати молоко до рук».

Якщо маємо якийсь форсмажор, то намагаємося об’єктивно підходити до його вирішення, без емоцій. Не знайти винного і покарати, а знайти спільне розв’язання проблеми, щоб більше не повторювати та, при цьому, не «боятися пролити молоко».

Наприклад, одного разу до нас надійшло замовлення на розробку UI/UX програми для одного відомого банку. Але ми не врахували той факт, що для нас розробка UI/UX — це одне, а для банку цей пункт виявився зовсім іншим у сприйнятті. Звідси непорозуміння, а з ним — дратівливість і так далі.

Після кількох випадків, пов’язаних з пробілами в комунікації, ми почали орієнтуватися на формулу, описану в книзі Юргена Апелло «Менеджмент 3.0»: ефективна комунікація = інформація * взаємини * зворотний зв’язок. Якщо щось одне з цього просідає, то комунікація буде страждати.

Порада тим, хто ще не працював з банками

Що варто врахувати перед тим, як почати роботу у фінтех-сфері:

1. Неможливо успішно працювати у фінтех/ банкінгу, якщо ти не маєш розуміння доменної області.
2. Неможливо працювати в команді, яка створює фінтех-продукт, без розуміння основних принципів комунікації та власної відповідальності.

По-перше, знання дуже важливі. Якщо фахівець обрав для себе цю сферу, йому варто бути готовим до того, що доведеться занурюватись у домен. По-друге, вміння працювати в команді є неодмінною частиною в роботі з фінтехом. Hard skills важливі, але і soft skills повинні бути прокачані до високого рівня.

Проводячи паралель з власним досвідом, скажу, що ми не заохочуємо мікроменеджмент і не маємо в команді погонича, який постійно говоритиме, що кому робити. Тут немає гравців, які, висловлюючись футбольним терміном, «грають на чистих м’ячах». Тут кожен робить свій внесок, щоб створити собі момент і перемогти.

А ми вже знаємо, що українці дуже добре вміють перемагати: як на полі бою, так і в тилу. Тож, перемог нам усім!