Як драйвити ефективну роботу різних технічних команд

Досить складно виокремити універсальний підхід до роботи з різними командами, який міг би швидко впливати на їх ефективність та покращувати результати. В залежності від спеціалізації команди, потрібні індивідуальні методики та практики.

Які інструменти й чому допомогли розвивати ефективність команди, а відтак і поліпшувати бізнес-показники компанії, у своїй колонці для AIN.UA розповідає Павло Приходько, Engineering Manager компанії Uklon.

Хто такий Engineering Manager?

Навряд чи ви зустрічали однаковий перелік обовʼязків Engineering manager. Річ у тому, що серед продуктових компаній це порівняно нова позиція, тому скоуп може відрізнятися. Потреба в такій позиції зʼявилась еволюційно. Зі стрімким ростом компанії обсяг завдань у тімліда також росте – people management, процеси й технічна складова. Якісно закривати ці сфери одночасно доволі складно, тому природно позиція та зони відповідальності поділились на двоє – Tech Lead та Engineering Manager. Перший фокусується на технічних аспектах: коді, його якості, технологіях та хайлоад, в той час, як Engineering-менеджер на управлінні: процесах, людях, ефективності. 

У нас ця позиція зʼявилась також відносно нещодавно – десь 1,5 року тому. У ході роботи, змінюються потреби й команди змінюють організаційні методи. Компанія пропонує процеси, а я, як Engineering-менеджер, підганяю їх індивідуально під кожну команду. 

Чим займається та ні Engineering Manager?

На своєму прикладі можу виділити ось такі основні напрямки:

Планування розробки. Під час планування кварталу потрібно враховувати комунікації між сервісами та послідовність передачі завдань. EM допомагає розвʼязати питання комунікації між командами. 

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

Прогнози та контроль ефективності роботи. Щоб вчасно оцінювати швидкість релізів та контролювати показник time-to-market, будь-який бізнес має передбачати, наскільки швидко працює його команда, та який обсяг реалізованих нею функцій. Engineering-менеджер відповідає за те, як формуються та проводяться релізи.

Побудова довіри та комфортної атмосфери в команді. Важливо, щоб члени команди могли вільно висловлювати свою думку, ставити один одному незручні питання, вести обговорення проблем та разом знаходити методи їх вирішення.

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

У організаційній ієрархії Uklon Engineering-менеджер є сполучною ланкою між топменеджментом та розробниками. Це дає бізнесу розуміння того, чим дихають програмісти, а останні орієнтуються у поточній ситуації, і чому важливе виконання тих чи інших завдань в певні терміни.

Що не робить Engineering-менеджер? У всіх по-різному, але, наприклад, в моїй компанії EM не пише код, а більше сконцентрований на людях та процесах. Мені допомагає таке правило: «Щойно відчуваєш, що хочеш щось зробити руками, значить, ти зробив щось неправильно, і це потрібно делегувати».

Також EM не відповідає за продуктові рішення та пріоритети нового функціоналу. При цьому, допомагає продакт-менеджерам опрацювати скоуп робіт та спланувати реалізацію. І, звісно, налагодити комунікацію між командами.

Які бувають типові команди та підходи до роботи з ними

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

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

Наприклад, команди, які розробляють мобільні додатки найбільші через те, що готують рішення для двох платформ — Android та iOS. Там релізи проходять через перевірку Google Play та Apple Store, що затримує вихід нової версії. Всередині кожна команда має три технічні напрями (back-end, ios та android), вони постійно комунікують як всередині, так і кроскомандно та домовляються, які є контракти. Відповідно, проблеми, що виникають у таких командах, найчастіше розв’язують за допомогою структуризації, додавання процесів і організації прозорих комунікацій. Схожі команди я називаю екстравертними, адже їх робота зав’язана на комунікації, модерації та розв’язанні кроскомандних задач. 

З іншого боку, деякі з back-end команд концентруються на складних завданнях, що вимагає створення комплексних алгоритмів і проведення дослідницьких робіт. Учасникам таких команд потрібно більше простору, скорочення кількості нарад. Але при цьому важливо підтримувати творчу атмосферу, підвищувати згуртованість, щоб команда почувалася єдиним цілим. Такі команди відносимо до інтровертних.

Ось кілька корисних інструментів для екстравертних команд:

Реліз-менеджмент зустрічі, де збираються ліди команд та менеджери продукту. У кожної команди свій темп випуску релізів, тому тут індивідуально визначаються терміни та тип функціональності. 

Систематизація комунікацій між командами. Після будь-якого мітингу мають бути чіткі та зрозумілі follow-ups. Це особливо допомагає у великих командах або зараз з перебоями світла, коли не всі учасники мають можливість брати участь у зустрічах.

Дейлі-мітинги у різних командах можуть проводитись по-різному, і тут теж варто використовувати індивідуальний підхід. 

• Формат Walk the wall, де замість класичних статусів, ми проходимо по близьким до релізу задачам. Цей формат більш ефективний для великих команд, бо кожен розказує про свої задачі, у якому вони стані, що їх блокує. 
• Класичний формат статусів зручний, коли невелика команда й кожен може ще розказати про свої активності та комунікації.
• У одній з команд я комбіную ці формати: спочатку ми проходимось по статусу, а потім по всіх задачах, які могли десь застрягнути, чи по релізах та блокерах. Можна також поекспериментувати з цим, ви справді побачите різницю. Це додає більше підзвітності, розуміння чим зайняті твої тім-мейти та дозволяє не втрачати фокус щодо важливих задач та блокерів.

Jira board є стандартом для багатьох, але не всі використовують функції сервісу на повну. Дошку можна підлаштувати під кожну команду так, щоб з одного погляду можна було оцінити поточний стан та виявити проблеми. Наприклад, можна зробити, щоб задачі, які виконуються довго, поступово червоніли. Можна додавати дошки для епіків та квартальних планів або для релізів, щоб бачити залежності між випуском версій різних продуктів.

У роботі з інтровертними командами діятимуть інші інструменти.

Найбільш актуальне завдання тут – це згуртування команди. В їх роботі не так багато комунікації між собою. У реаліях війни та тотального ремоуту обʼєднати людей складніше, тому непогано додати неформальні онлайн мітинги, наприклад, командну каву. Так вони матимуть змогу поспілкуватися не про роботу, обговорити теми, що хвилюють, поділитися емоціями та новинами зі свого життя.

Регулярний summary або review мітинг, де можна поділитись новинами, планами та показниками. Можна зробити у форматі шерінгу, де ми ділимося результатами та показуємо, як робота команди впливає на бізнес, користувачів. 

Наприклад, після того, як одна з команд випустила нову версію пошуку пункту призначення, ми отримали зменшення кількості випадків, коли в додатку не підтягувалась адреса користувача, у 5 разів. На додаток, у кілька разів скоротились відмови користувачів на екрані пошуку. Це дуже підвищує мотивацію.

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

Персональні зустрічі (1:1 та фідбек-мітинги) в мене займають до третини робочого часу. Тут важливо навчитися говорити відверто і давати чесний фідбек від себе. Ще важливіше та водночас складніше навчитися слухати, бо не всі люди говорять прямо, інколи вони не можуть одразу поділитися проблемними питаннями. До кожного потрібно знаходити індивідуальний підхід, так само як і до команд. Тут можу порекомендувати книгу Radical Candor від авторки Кім Скотт. Вона допомогла мені, можливо, буде корисною і вам. 

Nave — гарний інструмент для демонстрації метрик команди. Цей 3rd party сервіс для Jira дає можливість порахувати майже всі цікаві показники для Kanban команд. 

Метрики для підвищення ефективності команд 

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

• Метрика Flow Efficiency показує співвідношення часу перебування задачі в колонках «очікування» та «в процесі», тобто, як довго вона була у роботі, скільки тестували, і скільки потім перевіряли. 

Якщо виявиться, що процент часу очікування (колонки Waiting for merge, Waiting for QA, Waiting for Code review, Ready for deploy та інші) є завеликим, розуміємо, що в канбані є затримки, і команда працює неефективно. Щоб це пофіксити, ми з командою дивимось на колонки з максимальною затримкою та коригуємо процеси на ретроспективі.

Тут наведу приклад, коли в одній із команд ми побачили зниження показника flow efficiency на 20%. На ретроспективі виявилось, що багато завдань зависло на етапі code review. Отже, у технічного лідера просто немає на це необхідного ресурсу. Тому, після обговорення в команді, ми запровадили нову схему взаємодії та виділили частину команди на допомогу. У результаті процес пішов швидше, і ми одразу побачили це в метриці flow efficiency.

• Класичною, але важливою для бізнесу метрикою є Time-to-market або TTM. Вона показує, наскільки швидко ми випускаємо апдейти продукту. Умовно, що користувачам не доведеться місяць чекати, поки пофіксять баг або аж пів року для випуску нової фічі. ТTM показує темп релізів і те, наскільки ми гнучкі.
• Метрика Сycle time показує середній час від старту задачі до її випуску. Якщо показники метрик TTM та cycle time в моїх командах відрізняються більше ніж у два рази, це говорить про те, що релізи починають ставати занадто великими та пора їх дробити, щоб протестовані задачі не залежувались чекаючи випуску та не зростав час регресійного тестування.
• Throughput метрика показує кількість задач, які в середньому команда випускає за певний період часу. Поєднуючи статистику за декілька місяців по Throughput та Cycle Time можна розуміти приблизну узагальнену швидкість розробки команди.

Do’s & Don’ts на основі мого досвіду

На завершення хочу поділитися з вами поінтами з власного досвіду, які спочатку ускладнювали мою роботу, і як їх можна покращити. 

• Усім, хто починає роботу, раджу тісно «впилюватись» у сам продукт. Коли відповідаєш за комунікацію команди розробки, складно зробити її максимально ефективною, не розуміючи всіх нюансів продукту над яким вона працює.
• З самого початку краще обирати для себе позицію, яка метчиться зі стеком команди розробки. Коли сам можеш «провалитись» в код, краще розумієш нюанси, про які говорять учасники команд. Нехай Engineering-менеджер не пише код, але чим ближче він до стека, то швидше вийде зрозуміти, як команді працювати ефективніше.
• Оскільки кількість мітингів, у яких доводиться брати участь, досить велика, інколи просто фізично не можна всюди встигнути. Тому потрібно дуже круто прокачувати тайм-менеджмент, планування та делегування.

Підсумовуючи, Engineering Manager – важлива посада для IT компаній з 30+ людей. Контроль ефективності розробки, постійне покращення процесів, розвиток розробників та трансляція корпоративної культури в команду це must have для великих та середніх компаній, особливо в теперішніх remote-реаліях. Якщо у вас в IT департаменті понад 30 людей, потреба в EM буде очевидною – він допомагає підібрати підхід і допомогти зробити їх кроскомандну роботу максимально ефективною.

Автор: Павло Приходько, Engineering Manager компанії Uklon