Хочу стати Team Lead. Як зрозуміти, що це твоє, до чого готуватися і навчатися
Привіт, мене звати Анастасія-Нікіта Бансал, я директор Enterprise Solutions у SmartyAds — компанії, яка займається розробкою adtech-платформ для програматик-реклами.
Коли людина співпрацює з компанією вже довгий час, рано чи пізно вона замислюється над перспективами розвитку, і в багатьох випадках це можливість рухатись до менеджерської позиції. Іноді людина постає перед нелегким вибором, в яку сторону розвиватись краще — як тимлід, техлід, старший розробник. З часу, коли я приєдналася до команди SmartyAds, багато що змінилося в компанії, ми реструктурували та реорганізували команду.
Тож у цій статті я поділюся своїм досвідом розвитку до позиції тимліда, реорганізації команди. Я розповім про те, хто такий тимлід і в чому його відмінності від техліда, чим займається тимлід, які навички повинен мати, як зростати до цієї позиції, а також як взагалі зрозуміти, чи тобі це дійсно підходить.
Хто такий тимлід і чим він відрізняється від техліда
Ці поняття часто плутають через те, що в деяких організаціях не вистачає фахівців і одна й та сама людина може виконувати декілька функцій одразу. Так, техлід може мати функції і старшого розробника, і тимліда, але ці позиції досить різні.
Техлід — це спеціаліст, який розв’язує проблеми в технічних процесах, проблеми перформансу самої системи загалом, розуміє слабкі місця продукту і ті, де необхідні покращення. Якщо ж команда на ще вищому рівні розподілення завдань, то в них є також технічний архітектор, що відповідає за архітектуру продукту, він/ вона функціонує самостійно, незалежно від тимліда або техліда.
Так, техлідом може стати, і найчастіше стає, досвідчений розробник, який не тільки оперативно справляється з власними завданнями, а й може допомогти колегам, беручи на себе додаткові технічні завдання та відповідальність за них.
Тимлід — це керівник групи розробників, який виконує менеджерську роль, а саме навчає та менторить спеціалістів, ставить завдання, перевіряє якість виконаних завдань тощо. Тимлід — насамперед робота з людьми та управління певною групою людей, яку він або вона менеджерить. Потрібно також займатися ресурсним плануванням, виявляти потреби бізнесу у спеціалістах з певними компетенціями. Якщо поточна команда не справляється з обсягом проєкту, то потрібно також бути залученим в оцінюванні, скринінгу та визначенні спеціалістів, які хочуть приєднатись до команди, а також до планування їхнього розвитку та мотивування.
І тимлід, і техлід можуть кодити та виконувати складні завдання для яких у звичайного розробника може бракувати досвіду. Однак тимлід — це більше про менеджмент людей, тоді коли техлід це про технічний менеджмент продукту і того, що в нього «під капотом».
Задачі тимліда і техліда
Тимлід |
Техлід |
Контролює дотримання стандартів якості та пріоритетів |
Визначає технологічний стек під кожне завдання чи конкретний проєкт |
Організовує командну роботу та комунікації — у команді та між відділами (з замовниками продукту) |
Вибудовує, впроваджує та розвиває інженерні процеси та практики |
Ставить зрозумілі завдання та окреслює проблему з погляду бізнесу |
Формулює стратегію технологічного розвитку продукту |
Відповідає за професійний ріст розробників у своїй команді та ставить їм цілі на розвиток |
Створює інфраструктуру, в якій розробники мають можливість розвиватися |
Розподіляє зони відповідальності у команді, навантаження, характер тасків та стежить за дисципліною |
Слідкує за дотриманням технічних стандартів виконання завдань |
Що означає бути тимлідом у вашій команді
В той час як розробник має обмежене коло спілкування, сформовану зону комфорту і конкретні задачі, тимлід повинен розв’язувати інші питання, що виникають. Наприклад, розробник несе відповідальність за створений програмний код, за виконання узгоджених термінів та діє за планом, створеним тимлідом. Якщо він виконав свою задачу з помилками, то відповідальність за погану реалізацію лежить вже і на розробнику, і на тимліді, що менеджерить його перформанс.
Від того, як чітко тимлід інтерпретує завдання і як добре вестиме контроль процесу розробки, залежить успішність проєкту та розвиток бізнесу:
- дотримання дедлайнів впливає на реалізацію, а отже і на час запуску продукту;
- правильне ресурсне планування дозволяє не вийти за рамки бюджету;
- регулярні комунікації зі стейкхолдерами дають розуміння, чи задоволені вони результатом і чи справджуються їхні очікування;
- Якість коду, яку контролює тимлід важлива, щоб користувач визнав продукт якісним.
На певному життєвому етапі розвитку нашого продукту ми зрозуміли, що однієї людини не вистачає, щоб якісно менеджерити і команду, і технічну частину продукту. Технічні питання звичайно мають стратегічну важливість, але і тимлідерські обов’язки дуже сильно визначають успішність співпраці в команді — необхідно щоденно менторити розробників, відповідати на питання, ставити задачі, переглядати особистий перформанс, мотивувати та складати план розвитку для кожного спеціаліста.
Розуміючи важливість впливу тимліда на бізнес, ми теж зробили певні висновки та роз’єднали позиції тимліда і техліда.
Які взагалі є шляхи розвитку для IT-професіонала
Як правило, якщо ти розробник, в тебе є декілька опцій подальшого розвитку у компанії, тому необхідно вчасно відчути, що більше тобі імпонує в діяльності. Те, який шлях професіонала ти обереш, буде значно залежати від твого власного скілсету, софтскілів, а також від того, які в компанії є можливості для розвитку та потреби в певних спеціалістах.
Наприклад, ти можеш стати старшим розробником і постійно розвиватись у цьому напрямку — вивчати нові мови програмування, фреймворки тощо. Також у цій ролі ти можеш бути наставником для новачків, які потребують гайдингу та онбордингу.
Є й інші варіанти: ти можеш переходити з проєкту на проєкт, і таким чином освоювати нові предметні області й технології. Можна взагалі переходити на інші позиції та займатись не софтом, а, скажімо, інфраструктурною частиною — серверами і т.д..
Інший варіант — рости до позиції техліда (те, про що ми говорили вище). Ну і, звісно, найпоширеніший варіант — стати тимлідом. Слід зауважити, що якщо ти просто розробник високого рівня, цього недостатньо для того, щоб автоматично стати тимлідом, бо дуже важливо мати наступні навички:
- Софт скіли. Оскільки потрібно відповідати за операційну роботу усієї команди розробників, комунікаційні навички тут важливі, перш за все.
Тимлід повинен чітко, грамотно і зрозуміло пояснювати, що хоче отримати від розробників, правильно ставити завдання. А також вести переговори, вміти доносити та відстоювати свою позицію, коли це потрібно, давати зворотний зв’язок та задавати розмові поточний курс так, щоб учасники мітингу не втрачали потрібний фокус розмови та вкладались в певні часові рамки.
- Планування. Необхідно вміти правильно ставити цілі та пріоритети.
Потрібно вміло працювати з великою кількістю завдань та питаннями про терміни реалізації, тому тимлід повинен знати, як узгоджувати вимоги з можливостями команди, систематизувати завдання та розбивати їх на простіші кроки, скласти оцінку виконання завдань та стежити за дотриманням дедлайнів. Помічником при плануванні, контролі та комунікаціях з бізнесом може бути проєктний менеджер.
- Давати фідбек. Тимлідерство передбачає те, що тобі потрібно не лише ставити задачі та слідкувати за дотриманням дедлайнів, а також проводити проміжну оцінку, а це охоплює і процес надання якісного фідбеку.
Так, тимлід повинен не лише дати оцінку роботи розробника, а також виявити слабкі місця, помилки та запропонувати шляхи їх вирішення. При цьому дуже важливим буде правильне і зрозуміле обґрунтування — у чому власне проблема, і чому її треба вирішити саме так. Тут може значно допомогти створення технічної та нормативної документації, на яку тимлід потім може посилатись.
- Менеджмент. Наприклад, з’ясувавши, куди розробник хоче розвиватися, тимлід визначає, як компанія може допомогти в досягненні цілей. Тимлід визначає KPI, виконання яких дасть бажані результати (підвищення, премія тощо).
Навіщо це потрібно? Це допомагає розвитку спеціаліста відповідно до його бажань та потреб компанії. Якщо ж спеціаліст не досягає потрібного результату, тимлід повинен у процесі спілкування з підлеглим виявити причину незадовільних результатів, запропонувати шляхи вирішення (зміни у роботі) та прослідкувати, чи призвели зміни до потрібних результатів.
Наприклад, буває проблема у тому, що професіоналу бракує певних навичок або його час займають якісь додаткові функції. Буває, що проблема криється у самому продукті та специфічною складністю роботи над ним. Необхідно виявляти справжню причину проблеми та цілеспрямовано працювати над її вирішенням.
Дорожня карта розвитку до позиції тимліда
Твій шлях починається з моменту, як ти проходиш інтерв’ю, а потім й випробувальний термін. З цього моменту ти починаєш виконувати задачі як розробник, набиратись досвіду, розвиватись аж доки ти не стаєш крутим спеціалістом, на якого завжди можна покластися. У певний момент ти починаєш не лише виконувати поставлені задачі і закривати їх, але й помічати проблемні місця і пропонувати покращення — це може стосуватись як організації процесу виконання задач, так і ідей стосовно продукту. Ти також можеш виявляти особисту зацікавленість допомогти тимліду виконати нові задачі, з якими компанія стикається вперше.
В нашій компанії ми також звертаємо увагу на природу такої ініціативності і виявляємо, чи розробник прагне більше взаємодіяти з людьми, або все ж таки виявляє цікавість більше до продукту. У мене, наприклад, був свій метод навчання, який допомагав поступово розвивати найслабші та найважливіші скіли. Я складала особистий план розвитку. Ось що можу порадити з власного досвіду:
- виписуєш усі компетенції, які тобі потрібно вивчити;
- визначаєш поточний рівень володіння кожною та вказуєш пріоритетність — наскільки вона важлива;
- описуєш дії, які потрібно виконати, щоби освоїти компетенцію;
- ставиш дедлайн (місяць/ пів року/ рік і т.д.).
Однак, хочеться зауважити, що компанія не має очікувати від розробників, що він/ вона гарантовано стане тимлідом після певного успішного періоду співпраці. Частіше за все потреба в тимліді виникає тоді, коли процеси ускладнюються і потребують централізованого підходу та систематизації.
Саме тоді багато компаній роблять помилку, намагаючись призначити на позицію тимліда старшого розробника (оскільки він більше за всіх розуміється на технології). Як показує практика, не кожен розробник бажає та згоден навчати, гайдити та комунікувати, а це — основне завдання тимліда.
Я знаю один кейс, який показав неефективність цього підходу. Після призначення старшого розробника тимлідом ефективність команди не зросла. Аналізуючи причини, команда виявила, що один із мідл розробників взяв на себе всі комунікації через те, що інші спеціалісти бачили в ньому лідера та звертались саме до нього і з ним було приємно співпрацювати. Тож, насамперед тимлідом повинна бути людина, з якою бажає співпрацювати команда. Це має бути спеціаліст, який добровільно бере на себе ініціативи і розвивається, а не той, кого навмисно призначили на цю посаду через досвід чи окремі знання. То які ж якості ідеального лідера?
Якості ідеального лідера
- Відкритість. Це дуже важлива складова. Тільки за умови, що тимлід відкрито та чесно спілкується з розробниками, у команді буде довіра.
- Інноваційність. Справжній лідер повинен бути в курсі різних практик керування командою і бути готовим експериментувати задля досягнення кращих результатів.
- Вміння давати зворотний зв’язок і менторство. Знову ж таки, все те, що ми казали про фідбек — потрібно вміти правильно і вчасно надавати відгуки про роботу команди та кожного її учасника.
- Вміння делегувати. Тимліду варто розмірковувати категоріями бізнесу, а не окремими завданнями, вчитися дивитися на продукт в цілому. Тимлід має писати набагато менше коду, делегуючи це команді, але не всі це розуміють та приймають. Я знаю багатьох тимлідів, які пишуть код за своїх підлеглих, що не є продуктивним.
- Навички ефективного розв’язання проблем та конфліктів. Важливо прокачувати емоційний інтелект — здатність усвідомлювати, правильно розрізняти свої та чужі емоції, щоб краще вирішувати конфліктні ситуації та легко комунікувати з командою.
Екосистема комунікації всередині команди
З одного боку, тимлід повинен мати емпатію: прислухатися до співробітників, співпереживати їм і допомагати розбиратися з проблемами. Без цього неможливо бути гарним наставником. Крім того, без емпатії, атмосфера всередині команди може стати токсичною — а це призводить до низької продуктивності, вигоряння.
З іншого боку, щоб стати хорошим тимлідом необхідно бути вимогливим і грамотно реагувати на складнощі, що виникають.
Ці навички особливо виявляються сам на сам, коли тимлід дає зворотний зв’язок. Наприклад, я, як керівник, ніколи не використовую позицію «я знаю краще з позиції тимліда», ми разом розбираємо досягнення та помилки, пробуємо зрозуміти, де потрібно прокачати скіли. Також у нас немає класичного підходу за ієрархією в цілому, яка насправді принижує заслуги певного фахівця замість того, щоб мотивувати його на більше.
При цьому важливо створити атмосферу та умови, за яких спеціаліст може почувати себе вільно, проявляючи ініціативу та покращення — моральні та матеріальні стимули тут теж відіграють важливу роль.
У великих компаніях, та в умовах віддаленої комунікації, з моральними стимулами буває складно, саме тому виникає необхідність підтримувати регулярний онлайн-зв’язок з командою для синхронізації цілей, а також для підтримання командного духу. Не треба забувати й про корпоративи й тимбілдінги — це теж реально крута можливість поспілкуватись неформально і познайомитись з членами своєї команди.
Ефективність команди, оцінка продуктивності і технології управління
Кожна команда індивідуальна, і принципи менеджменту при цьому будуть залежати від специфіки діяльності або предметної області. Наприклад, ad tech — це надзвичайно динамічна сфера, де тренди можуть змінюватись кожного місяця, тому це відображається й на спеціалістах, які повинні швидко засвоювати інформацію і вчасно реагувати.
Ми створили чіткий та зрозумілий воркфлоу та підтримку ефективності команди. Це значно спрощує управління та менеджмент для тимлідів, а також забезпечує стандартизацію процесів, а отже і якість виконання завдань. Також кожен член команди має власні KPI, які розробляються тимлідом на певний період, як правило, пів року — рік.
При цьому тимлід орієнтується на потреби компанії. Важливо давати чесні орієнтири — що саме (які технології та навички) треба розвинути, щоб зайняти бажану позицію. Знання якоїсь новомодної технології в принципі, яка не використовується у вашій конкретній компанії, скоріш за все, не дасть вам ніякої переваги перед іншими спеціалістами.
Щодо технологій, які ми використовуємо. У нас є таск трекери, а також додаткові тули, які дозволяють оцінити зайнятість розробника та продуктивність за певний період. Наприклад, в результаті такого аналізу тимлід може виявити, що якийсь розробник більшість часу приділяв створенню нових фіч, тоді як інший постійно був зайнятий виправленням багів. Це може перерости в тенденцію, однак такого не повинно бути, оскільки другий розробник, наприклад, може швидко вигоріти та покинути компанію. Цьому необхідно запобігати, правильно розподіляючи задачі, тому проджект-менеджер щодо цього часто радиться з тимлідом.
Саме злагоджена управлінська інфраструктура/ фреймворк дає розуміння, яких результатів треба досягнути і як це можна зробити. Крім того, для будь-якого спеціаліста важлива прозорість свого шляху розвитку у компанії та мотивація.
Наприклад, усі кажуть про те, що задачі повинні бути цікавими, щоб тримати спеціаліста у тонусі. Але у мене був кейс, коли розробник отримував цікаву роботу цілий рік. На мітингу виявилось, що цього йому вже недостатньо, і тому важливо було думати над наступним стимулом і пунктом його розвитку. Такі речі тимлід повинен обов’язково обговорювати разом зі спеціалістом аби забезпечити потім мотивацію на довгий час.
Проведення мітингів, де озвучуються потреби бізнесу — це теж дуже корисна практика. Наприклад, у нас було завдання автоматизувати певний процес, на мітингу розробник може зацікавитись такою можливістю та запропонувати свою участь.
Висновок
Посада тимліда включає цілий спектр ролей та обов’язків. Ви маєте знати програмування, розуміти продукт, розподіляти сфери відповідальності у команді та робити безліч інших речей. Тимлід відповідає за роботу колективу, якість продукту, а також швидкість виконання завдань членами команди та їх розвиток.
Не варто сприймати цю посаду як вінець кар’єри розробника, варто реалістично оцінювати власні скіли та схильності, прислуховуватись до власних бажань, адже і старші розробники, і техліди та інші спеціалісти можуть заробляти більше, і це теж гарні вектори для розвитку.
Якщо ви хочете спробувати, але не маєте впевненості, що впораєтеся — візьміть для початку на поточній позиції трохи більше відповідальності. Також дослідіть, які якості тимліда вже маєте, а які ще потрібно прокачати, створіть план особистого навчання, поставте реальні дедлайни та впевнено йдіть до своєї мети.
44 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів