Тімлід – це керівник групи однієї компетенції: розробників, або дата-інженерів, або тестувальників тощо (далі я говоритиму саме про розробників – для наочності). Він відповідає за всю розробку продукту і частково бере на себе менеджерські обов’язки.
Обов’язків і ролей у тімліда багато. Але умовно їх можна розділити на кілька частин.
- Перша – формування своєї команди: співбесіди, технічний онбординг, розвиток своїх співробітників.
- Друга – розподіл завдань між своїми розробниками. Сюди входять декомпозиція та оцінка цих завдань, планування робіт, дотримання термінів проєкту.
- Третя – участь у проєктуванні разом із власником продукту, архітектором або техлідом. Тімлід вирішує, як перевести бізнес-завдання в код, і, за можливості, сам його пише – особливо, якщо завдання дуже складне і термінове.
Нарешті, тімлід виконує роль координатора – наприклад, між своєю групою розробки та іншими членами команди (тестувальниками, аналітиками, DevOps-інженерами).
У різних компаніях у тімліда можуть бути різні обов’язки та ролі (я працював у місці, де тімлід поєднував свої обов’язки з функціями техліда, архітектора і власника продукту). Усе залежить від розміру команди. Для групи від 5-7 осіб точно потрібен окремий лід без додаткових ролей.
Які навички потрібні тімліду
Що ж, які навички потрібні тімліду?
Хард скіли
З хард скілами все просто. Тімлід – це провідний фахівець. Він знає, як правильно писати код і створювати сервіси, навчає цьому інших розробників, за потреби може сам вирішити поставлене завдання.
Крім того, він розуміє суміжні технічні галузі – DevOps, тестування, архітектуру тощо (залежить від проєкту). Хоча б на базовому рівні. Чому це важливо?
Припустимо, ваша команда вирішила використовувати мікросервісну архітектуру для нового продукту. Щоб правильно поставити завдання на розробку сервісів, вам доведеться розібратися і в цій архітектурі, і в тонкощах розгортання мікросервісів, зрозуміти всі нюанси і складнощі. Інакше припуститеся помилки. Тоді доведеться переписувати код, і терміни реалізації всього проєкту зірвуться.
Софт скіли
Зі софт скілами складніше. Для зручності розділимо їх на кілька груп.
Лідерство
Хороший тімлід має вміти формувати команду, керувати нею, мотивувати в потрібний момент. Він відповідає за створення довірчої атмосфери – коли всі працюють і вчасно виконують завдання, вчасно йдуть у відпустку, не вигоряють і конструктивно спілкуються один з одним. Без токсичності.
Планування і тайм-менеджмент
Щоб стати тімлідом, людина обов’язково має керувати і своїм часом, і часом своєї групи, грамотно планувати час виконання завдань, вміти фокусуватися на одному завданні і швидко перемикатися, коли це потрібно.
Чому це важливо? У тімліда дуже багато завдань, не пов’язаних одне з одним. Провідний розробник, у теорії, може спокійно писати код два дні, зосередившись тільки на одному завданні. Але тімліду доводиться часто відволікатися: стежити за прогресом виконання завдань своєї групи, розв’язувати технічні проблеми або взаємодіяти із замовником, ходити на безліч зустрічей тощо.
Мені для планування подобається діаграма Ганта. А для пріоритизації – матриця Ейзенхауера, вести яку можна в Excel. Але можна використовувати Jira, Trello, Google календар – усе залежить від особистих уподобань.
Комунікативні навички
Комунікабельність – критична навичка, яка сильно впливає на продуктивність команди. Без неї не вдасться вибудовувати стосунки зі співробітниками і допомагати їм розвиватися, взаємодіяти із замовниками та експертами з різних відділів.
Тімлід повинен чітко, грамотно і простою мовою пояснювати, що він хоче від співробітників, правильно ставити завдання. А також вести переговори, вміти доносити і відстоювати свою позицію, коли це потрібно, вирішувати конфлікти, проводити зустрічі, давати зворотний зв’язок тощо.
Емпатія і раціональність
Ці дві навички йдуть поруч. З одного боку, тімлід повинен володіти емпатією: прислухатися до співробітників, співпереживати їм і допомагати розбиратися з проблемами. Без цього неможливо бути хорошим наставником.
Крім того, без емпатії, атмосфера всередині команди може легко стати токсичною – а це призводить до низької продуктивності, вигоряння, плинності кадрів.
З іншого боку, щоб стати хорошим тімлідом, необхідно бути вимогливим і грамотно реагувати на конфлікти, що виникають. Інакше можливі проблеми в роботі, наприклад, зриви термінів.
Ці навички особливо проявляються на one-to-one зустрічах, де тімлід дає зворотний зв’язок. Емпатична людина зайде не з позиції “я начальник, ти дурень”, а розбере досягнення і помилки, спробує зрозуміти, чому співробітник не виконує завдання або виконує їх не так, допоможе знайти рішення, виробити план розвитку.
Наведу приклад зі своєї практики. У нашу команду прийшов новий розробник, сильний і досвідчений. Я доручив йому розробити сервіс. Але він не виконав завдання вчасно, пояснивши проблему і сказавши, що з усім розібрався і скоро закінчить.
Це повторилося кілька разів. І я вирішив провести з ним зустріч. Ми проговорили проблему, з’ясували, чого йому не вистачає. Виявилося, що він був не знайомий з одним із застосовуваних фреймворків, але соромився про це сказати. І не до кінця зрозумів реалізовану бізнес-логіку.
У підсумку йому дали додатковий час на вивчення, скоригували терміни, ближче познайомили з аналітиками, які давали завдання. І справа пішла.
Як усе це прокачувати
Перший етап – теорія. Можна читати книжки, слухати курси та подкасти, ходити на лекції – як зручно людині. Я раджу чергувати різні формати.
Другий етап – практика, без цього знання не перетвориться на вміння. Беремо методики, які дізналися з джерел, і потихеньку використовуємо їх у повсякденних завданнях. Помиляємося, розбираємо, що не вийшло і чому, використовуємо знову. Так доводимо вміння до автоматизму, тобто перетворюємо його на навичку. І переходимо до освоєння нового.
У мене є свій метод навчання, який допомагає поступово розвивати найслабші та найважливіші скіли. Я складаю особистий план розвитку:
- Виписую всі компетенції, які мені потрібно вивчити.
- Визначаю поточний рівень володіння кожною і вказую пріоритетність – наскільки вона мені важлива.
- Описую дії, які потрібно виконати, щоб освоїти компетенцію.
- Ставлю дедлайн.
Припустимо, у вас прогалини в архітектурі. Додаєте в план розвитку компетенцію – архітектура. Ставите пріоритет А – максимальний, рівень знання – 1, мінімальний. Призначаєте дію – прочитати книжку з архітектури. І повторюєте для кожної навички.
Після прочитання книжки застосовуєте отримані знання на практиці, знижуєте пріоритет, підвищуєте свій рівень володіння за цією компетенцією і переходите до наступної, чергуючи хард- і софт-скіли.
Як стати тімлідом
Спершу потрібно дорости мінімум до провідного фахівця і почати розвивати технічні знання вшир: вивчати архітектуру, тестування, DevOps тощо.
Потім варто розібратися в бізнес-частині та повному циклі створення продукту – щоб розуміти що, навіщо і для кого ви робите. Можна попросити власника продукту долучати вас до зустрічей з обговорення архітектури та бізнес-фіч із замовниками.
Також важливо дізнаватися якомога більше про свій продукт, вивчати предметну область. Наприклад, займаєшся проєктом зі страхування – дізнайся, як працюють страхові компанії. Це допоможе краще зрозуміти поставлене завдання, скоротить час на його реалізацію. Можливо, ти зможеш запропонувати свою ідею і привнести в продукт щось нове.
Наступний етап – брати на себе відповідальність за загальний результат і супроводжувати розробку на всіх етапах життєвого циклу.
Я став тімлідом саме після того, як узяв на себе відповідальність за один із наших проєктів. Тоді я був провідним розробником і курирував усю розробку на продукті. А також допомагав DevOps-інженеру вибудовувати релізний процес, і разом із тестувальниками складав план тестування. Загалом, включався в роботу на всіх етапах.
У підсумку керівник запропонував мені посаду тімліда (але, звісно, можна і самому звернутися до керівника і зазначити, що для вас важливо дорости до тімліда й уточнити, що для цього потрібно).
Замість висновку
Тим, хто хоче стати тімлідом, важливо розуміти, що це зовсім інша робота, ніж провідним розробником.
Перша складність, з якою доведеться зіткнутися колишньому розробнику, – менеджмент. Багато менеджменту. Тільки вчора ти писав код, у тебе все класно виходило, а тут з’являється коло нових обов’язків. І потрібно швидко до них звикати, освоювати відсутні скіли, вибудовувати потрібні комунікації.
Інший момент – психологічний. Тімліду варто міркувати категорією бізнес-фіч, а не завдань, вчитися дивитися на продукт загалом. І писати набагато менше коду, делегуючи це команді. Не всі це розуміють і приймають. Я знаю багатьох тімлідів, які пишуть код за своїх підлеглих.
Ще важливо вчитися розмовляти і домовлятися, приділяти багато часу софт скілам, приміряти на себе безліч ролей – від “тренера, що грає” до медіатора в конфліктах. І все встигати.
