Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Як продуктові команди Uklon зберігають ефективність і запускають нові сервіси у воєнний час

Привіт! Я  Сергій Гришков, CPO, моя задача розвивати tech продукти та продуктові команди в Uklon. З початку російського вторгнення ця задача перетворилась на задачу із зірочкою. Бо зберігати ефективність команд і випускати релізи тепер треба під гул сирен і нон-стоп марафон тривожних новин. У цій колонці ділюсь досвідом, як нам вдалось переналаштувати процеси в продуктових командах та зберегти 80% ефективності порівняно з довоєнним часом.

Як вдалось зберегти довоєнні темпи розробки

В перший тиждень війни всередині Uklon все ставало на нові рейки: ми дізнавались, хто куди переїхав чи досі перебував у дорозі, перевіряли доступ колег до інтернету та змогу працювати. А вже за тиждень продуктові команди повернули 80% довоєнної ефективності. Як нам це вдалось? В кінці минулого року ми перевели всі продуктові команди на kanban. Хто ж знав, що рішення, яке приймалось у форматі «давайте потестимо і якщо зайде  перейдемо», виявиться рятівним під час війни.

До kanban у нас був scrum. Двотижневі спринти не підходили нам з точки зору розвитку продукту. Оскільки Uklon вже знайшов свій product-market fit, нам було більше не цікаво закриватись на певний час і потім релізити певні фічі. Нашою задачею стало якомога швидше доставляти головні зміни в продакшн. Оскільки у нас різні команди відповідають за окремі сервіси в архітектурі продукту, то для запуску фічі дуже часто потрібні релізи двох, трьох, чотирьох команд. Коли ми рухались спринтами складалась наступна ситуація: все вже готово ➡️ але не виливаємо в прод ➡️ бо досі триває спринт ➡️ а реліз буде лише в кінці спринта.

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

У хаосі кінця лютого 2022, коли одні проекти зупиняємо/другі запускаємо/якісь залишаємо без змін, результат переходу на kanban показав себе у всій красі. Просто сіли і перетасували таски так, як нам це потрібно, а потім запустили їх в роботу. Таке «перегрупування» забрало у нас 3-5 дні, довелось внести зміни в половину нашого продуктового плану, порівняно з довоєнним.

Показники ефективності, які повернулись на довоєнний рівень: Cycle Time, Wasted Time, Throughput, Flow efficiency. Ці метрики були запущені не зараз, а на при кінці минулого року. Сьогодні складно було би керувати процесом без цих показників. Коли ти нічого не міряєш, не маєш цифр і даних, відповідно просто не розумієш, що відбувається.

Якби ми залишались на scrum, то витратили б значно більше часу і ресурсу, щоб перебудувати процеси і команди. Нам довелося б зупинити команди, переформувати спринти, підготувати скоуп задач, а потім знову  запустити спринти. Місяць відбувався б процесний хаос.

Проєкти: зараз потрібно тільки те, що дає швидкий результат

Під час війни kanban дозволив легко поставити на холд те, що не на часі, і навпаки — швидко запускати щось необхідне тут і зараз . Так, сервіс спільних поїздок Uklon Share заморозили, а ресурс цієї команди розподілили по іншим проєктам. Практично за півтора тижні викотили «Волонтер»

Продукт «Волонтер» — фактично маркетплейс. З однієї сторони — організації, яким потрібна допомога (доставка їжі, ліків, палива), з іншої — постачальники, які можуть все це забезпечити.

«Волонтер» реалізували на базі корпоративного аккаунту в додатку Uklon, доступ до якого віддаємо волонтерам, ТрО, медикам та іншим організаціям. В Uklon 60+ мікросервісів, кожен з яких виконує свою функцію — від прорахунку вартості поїздки до заторів на маршрутах. Для того, щоб зробити будь яку фічу у «Волонтері», нам потрібно було робити зміни в фронтенд і бекенд сервісах. А це від 10 до 15 релізів у різних частинах комплексу. Окрім цього потрібно було швидко сформувати команду під проєкт.

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

Як зберігаю власну ефективність

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

Вірю, що перемога 🇺🇦 зовсім близько і всі міста України стануть цілком безпечними. А класними українськими сервісами та продуктами буде користуватись все більше і більше людей.

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Привіт Сергій. На мою думку цікаво буде додати до статті приклади, які саме рішення приймалися відповідно показників (Cycle Time, Wasted Time, Throughput, Flow efficiency) і в які моменти (або періоди). Чи відбулось прискорення проходження RoadMap та якими метриками (формулами) це визначалось у порівнянні зі Scrum Sprints?

Микола, привіт! Після переходу від Scrum на Kanban відбулося незначне прискорення RoadMap, вимірюємо за допомогою time to market. Але найголовніша користь в тому, що це значно спростило процесс планування для наших 11-ти продуктових команд. Ми стали значно гнучкішими до будь яких змін, також зменшилась кількість регулярних мітингів.

На рахунок рішень щодо kanban-метрик, тут ситуація у кожної команди своя. Але найпоширеніше — це реагування на WIP-limit та балансування ресурсами команд (активно проявлялося на початку выйни, коли не всі могли працювати на навіть на 70%-80%)

Підписатись на коментарі