«Спочатку 90% часу витрачав на мітинги і нічого не встигав»: тимлід appflame про те, як правильно керувати командою навіть під час війни

Тимлід iOS-команди в appflame Денис Рум’янцев тільки-но взяв на себе керування другою командою з незнайомою технологією, аж тут почалась війна і спеціалістів розкидало по всій країні. Та навіть за таких умов він налагодив роботу та вивів команду на 100% продуктивності.

Як йому це вдалось, він розповів журналістці Highload.

Про компанію

Продуктова IT-компанія appflame територіально знаходиться в Україні, реально — по всьому світу. Її команда розробила відомий застосунок Hily, що входить у найкращі 10 сервісів для знайомств у США та налічує понад 25 млн користувачів у світі. Частина компанії також працює над найбільшим у світі ЛГБТК+ застосунком Taimi. 

Про героя

Денис із середньої школи займався програмуванням як хобі. Після школи вирішив отримати вищу освіту з електромеханіки, але на четвертому курсі зрозумів, що IT йому все ж більше до душі. Тому 2014 року почав кар’єру з посади QA у «ПриватБанку», паралельно вивчаючи iOS-розробку. Сьогодні він тимлід двох команд у компанії appflame.

Далі — розповідь героя від першої особи.

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

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

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

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

Загалом, тимлід — нестандартизована зона відповідальності, тому в кожній компанії свої обов’язки. У той час нам потрібен був баланс між позиціями тех- і тимліда. Якщо до технічної частини праці я був готовий, то до роботи з людьми… Там було що вдосконалювати.

Тимлід — нестандартизована зона відповідальності, тому в кожній компанії свої обов’язки

Я думав, що доведеться розв’язувати технічні питання на платформі. Замість цього довелося працювати з людьми, зрощувати їх разом, підвищувати рівень сіньорності, ставити перед ними цілі, розв’язувати організаційні питання — навіть з приводу техніки. До цього я психологічно не був готовий на 100%, але мені було цікаво розвиватися в цьому напрямі.

Перші «проколи» і висновки

Факапи, звісно, були. Я намагався бути присутнім на всіх можливих мітингах, навіть якщо вони були мені не дуже потрібні. Тож виходило, що я майже 90% робочого часу витрачав на мітинги, а власні обов’язки виконувати не встигав.

Був ряд помилок, але вони досить життєві. Наприклад, небажання віддавати улюблену частину функціонала іншому розробнику, щоб він продовжив писати код. Так робити не треба — це проблема з початковим делегуванням. Набір «початкового менеджера» — це делегування та фідбек (як позитивний, так і негативний).

Якщо ти мізантроп, то позиція тимліда — дорога не туди. Тут треба мати бажання допомагати людям та емпатію, бо якщо їх немає, то нічого не вийде. То буде якась диктатура. І треба позбуватися в собі «чайка-менеджементу», коли ходиш і нескінченно питаєш: «Шо там?»

У мене труднощів з командами не було, просто з кимось контакт налагодили за тиждень-два, з кимось — за місяць-півтора. Головне — довести людині, що ти їй не ворог, не «начальник», а лідер і ви йдете в один бік. Якщо всім кльово, то кльово і проєкту, і бізнесу, і компанії загалом.

Начальник — більш директивний стиль керування: «Я так вирішив, а ти роби». Але ефективніше бути для команди прикладом і разом йти до поставленої мети.

«Золоті правила» ефективного менеджменту

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

Немає правильної відповіді, які методи Scrum та Agile працюють, які — ні

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

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

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

Коли час подвоїти навантаження?

Я зібрав якісну команду й організував усю роботу, та згодом мені стало «удобнєнько» на своєму місці. Це стало сигналом, що прийшов час брати на себе більшу зону відповідальності, щось новеньке. Я вирішив взяти під керування людей з іншої, незнайомої мені платформи. У цей час компанії був потрібен Android-тимлід. Ним став я.

Призначили мене, бо люди в команді мене вже знають, тобто вже є довіра до мене і простіше налагодити контакт — усі погодились, що це оптимальний варіант. Наразі можна сказати, що все добре, по перформансу ми не впали (враховуючи похибку початку повномасштабного вторгнення), уже з кожним членом Android-команди проставляємо оновленні цілі та рухаємось до них. Тож можна працювати з командою і робити все, щоб робота йшла краще, навіть якщо ти не знаєш технічного боку платформи. Треба налагодити контакт так, щоб члени команди навчились об’єктивно оцінювати поточний стан платформи і ви разом працювали.

Так сталося, що я став тимлідом Android-платформи на початку січня, а наступного місяця почалась широкомасштабна війна. У момент вторгнення ми всі знаходились у Києві, де працює компанія appflame. А після територіально команду «розкидало» по Україні — хто в столиці, хто на заході України, хто де. Ця ситуація принесла ускладнення.

Робота в умовах війни: як відновити ефективність

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

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

Першого тижня продуктивність упала відсотків на 80%

Усі були дуже шоковані, тому робота йшла в’яло. Але то не про всіх: один хлопець з iOS-команди 25 лютого закрив завдання і питає: «Що там, коли тест буде?» Така індивідуальна реакція. Десь за тижні 3–4 продуктивність роботи піднялась з 20% до 80%, а зараз працюємо на довоєнному рівні, плюс дуже гарно закрили квартал за показниками.

Що допомогло? Ми направили думки команди на роботу через планування і цікаві задачі. У нас в командах немає людей, що просто полюють за гроші — вони в першу чергу цікавляться розробкою та розвитком нашого проєкту. Тому робота була способом відволіктися від того пекла, що коїться в нашій країні. Згодом продуктивність вирівнялась.

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