💰🚀 USDT, BTC, ETH - це все просто купляється в Trustee Plus в пару кліків. Встановлюй 👉
Марія БровінськаРобота
27 липня 2022, 15:00
2022-07-27
Професії в IT. Хто такі тімліди, що вони мають знати та як їх оцінювати?
Більшість молодих айтішників з перших днів роботи мріють вирости до сеньйора та стати тімлідом, менторити джунів та допомагати команді вирішувати складні задачі. Проте якими саме компетенціями має володіти тімлід, що вміти та де вчитися — питання для багатьох відкрите. Аби прояснити ситуацію, ми поспілкувалися з Solutions Architect у компанії DataArt Дмитром Куперманом, який вже багато років займається асесментом тімлідів у компанії: проводить інтерв’ю та оцінює підготовку і досвід колег і кандидатів.
Більшість молодих айтішників з перших днів роботи мріють вирости до сеньйора та стати тімлідом, менторити джунів та допомагати команді вирішувати складні задачі. Проте якими саме компетенціями має володіти тімлід, що вміти та де вчитися — питання для багатьох відкрите. Аби прояснити ситуацію, ми поспілкувалися з Solutions Architect у компанії DataArt Дмитром Куперманом, який вже багато років займається асесментом тімлідів у компанії: проводить інтерв’ю та оцінює підготовку і досвід колег і кандидатів.
Ця стаття — спроба записати і впорядкувати висновки, які зробив Дмитро, відповідаючи на запитання колег:
Зміст
Дмитро Куперман
Хто такий тімлід?
Тімлід — це, вочевидь, керівник команди розробки. Для клієнтів — головний технар, точка входу для обговорення технічних питань. Для команди — людина, яка ухвалює технічні рішення та відповідає за них, а також за побудову команди й атмосферу в ній.
Тімлід і техлід — одне й те саме?
Не зовсім. Узагалі, чіткої межі, «де починається поліція і де закінчується Беня», немає. Рідко на якому проєкті працюють і PM, і тімлід, і техлід, і архітектор, і ВА. Там, де вони все ж є, найімовірніше, будь-які троє з цих п’ятьох можуть зробити всю лідську роботу, якщо вистачить здоров’я.
PM зазвичай є відповідальним більше за процеси, бюджети і стафінг. Він часто грає роль скрам-майстра на стендап-дзвінках.
Якщо у проєкті є окремий техлід, то це «головний сеньйор», відповідальний за технічні рішення.
Тімлід — десь посередині. Він має бути досить сильним інженером, здатним відповісти на будь-яке технічне запитання (неважливо, клієнта чи команди). Але йому потрібні й хороші знання методологій розробки, й розвинені софт-скіли, щоб виступати скрам-майстром та представляти команду на різних клієнтських мітингах. Найчастіше тімлід також виконує роль техліда, хоч мені доводилося бачити конфігурації команди, де це були різні люди.
Сам я був тімлідом у такій команді лише одного разу. Техлідом була інша людина — один із найкрутіших джавістів з усього DataArt, класичний програміст-інтроверт з анекдотів. Йому б завдання складніше, і щоб ніхто не чіпав. Я не ухвалював без нього технічних рішень, він не особливо спілкувався з клієнтами. Але що цікаво, якщо нам доводилося робити складний вибір, він міг радити й наполягати, але завжди залишав останнє слово за мною. Мовляв, з тебе запитають, ти й вирішуй.
Вимоги до тімліда
Тепер обговоримо докладніше, що саме має робити тімлід і чому в нього не залишається часу писати код.
Тімлідство тримається на чотирьох ногах:
Техлідство.
Менеджмент і процеси.
Спілкування з клієнтами та account management.
Спілкування з командою та people management.
Техлідство. Тут усе зрозуміло: треба бути досить крутим програмістом, щоб відповідати за технічні рішення. Навіть якщо у проєкті є окремий техлід, потрібно добре розумітися на коді, щоб допомагати команді та відповідати на запитання клієнтів. Тому тімлід завжди задіяний у код-рев’ю. Часто процес взагалі налаштовують так, що без апрува від тімліда не можна було вмерджити пул-реквест, навіть якщо його вже переглянула вся команда.
Та й для авторитету в команді важливо бути на рівні. Добре, коли тімлід може сісти на місце будь-якого з розробників і зробити його роботу не гірше, а то й краще.
Якщо і ти сам, і команда у цьому впевнені, прислухатимуться до тебе набагато охочіше, ніж до теоретика, який сам код не пише, але мудрує. Сам я, пішовши з тімлідів у архітектори, якраз і перетворився на такого теоретика.
Я багато писав на Java до 7 версії, тому в моїй картині світу немає ані стримів, ані лямбд. Тобто я все це знаю, спробував і оцінив, але не набив на них руку до потрібного рівня. Кілька разів був висміяний командою за пропозиції великих шматків коду, замість яких сьогодні можна написати три рядки. Особливо глузував мій колишній практикант. (Щоправда, він нещодавно теж став архітектором, подивлюся на нього за кілька років!) Відтоді намагаюся, пропонуючи рішення, описувати алгоритм, а не спосіб його реалізації.
Менеджмент і процеси. Тімлід — не завжди скрам-майстер, але у будь-який момент має бути готовий його підмінити. Крім того, він залучений до всіх процесів життєвого циклу спринта й скрам-церемонії (хто не згадав п’ять скрам-церемоній — швидко пішли гуглити!). Тому теорію з основних методологій розробки, а наразі це різні похідні Agile, потрібно знати і вміти застосовувати. На одному PM команда не виїде.
Тімлід разом із PM вибудовує зручний для команди і клієнта процес (навіть якщо процес спочатку нав’язаний клієнтом, його можна підтюнити).
Крім того, він не лише вчить команду працювати відповідно до цього процесу, а й стежить, щоб його дотримувався клієнт. Думаю, багатьом знайома ситуація, коли невдовзі після визначення скоупу спринта клієнт починає вимагати додати до нього ще кілька дуже важливих завдань. Бажано нічого зі спринта не викидаючи.
Спілкування з клієнтами та account management. Тімлід спілкується з клієнтом постійно — щодня і багато разів. Бере участь у технічних дискусіях і обговоренні вимог. Рекламує успіхи команди, повідомляє про проблеми, відповідає перед клієнтом за провали. Та обов’язково несе клієнту головний меседж сучасної розробки: «Ми не просто старанно пишемо код, а розуміємо бізнес-потреби замовника і задовольняємо їх». Можливо, зовсім не так, як уявляв сам замовник.
Поки тімлід не зрозуміє, що потрібно клієнту на виході, він від клієнта не відстає. Поки розробник не зрозуміє, для чого клієнту потрібна ця фіча, він не починає писати код. І так, прищепити таку культуру команді — теж завдання тімліда.
Якщо ми бачимо, що клієнту чогось не вистачає, не мовчимо: про це потрібно повідомити і клієнта, і нашу Account Management команду. Не тому, що так ми продамо клієнту більше наших послуг і заробимо більше грошей (хоч і це теж важливо), а тому, що він і сам нам потім не буде вдячний.
Ми декілька місяців переконували Product Owner, що у проєкті потрібна система real-time-моніторингу. Причому саме бізнесова, де поряд із кількістю помилок показувалися б графіки продажів за день. Зате потім приїхали до них у відрядження, а наш дашборд на великих екранах на стінах офісу світиться, щоб усі бачили, як ідуть справи.
Представляючи команду перед клієнтом, тімлід її від клієнта захищає, виступаючи «вухатою прокладкою». Якщо у клієнта сім п’ятниць на тижні, страждати від цього мають тімліди та PM, але не команда.
Наприклад, якщо клієнт затіяв багатоденне обговорення можливого scope change, команду до нього краще не долучати. Те саме стосується уточнення вимог завдання, що вже в роботі, або інших подібних ідей, що порушують плани. Велика кількість проміжних результатів лише нервує інженерів і заважає їм зосередитись.
Спілкування з командою та people management. Здебільшого основний обов’язок тімліда, який забирає більшу частину часу, — бути команді нянькою.
З технічною частиною зрозуміло: якщо команда не синьйорна, щодня доведеться опікуватися джуніорами і мідлами, які чогось не зрозуміли або не можуть із чимось впоратись.
Але важливе й інше: добре перформить лише дружна команда. Де по-доброму жартують на дзвінках і допомагають одне одному, де люди на одній хвилі, завжди є коректними і чесними. Побудова такої команди та підтримання атмосфери в ній — головне завдання тімліда. Безпосередньо на його плечі лягають усі аспекти роботи на цьому напрямі від добору людей до one-on-one-дзвінків і п’янок-тімбілдингів. Доведеться проводити інтерв’ю з новими учасниками команди, виключати невідповідних людей (неприємно, але іноді необхідно), насаджувати культуру клієнтоорієнтованої та командної роботи, вести душоспасні бесіди з роздовбаями-джунами, з яких потім виростуть круті сеньйори тощо.
Ну і, звісно, вирощувати собі заміну. У міру «дорослішання» команди, хтось із сеньйорів, а іноді навіть із мідлів, почне показувати схильність чи здатність до лідування.
Таким потрібно допомагати, віддаючи під повну їхню відповідальність реалізацію окремих фіч, особливо якщо над фічею працюють декілька людей. Звісно, приглядаючи, допомагаючи та підстраховуючи. На виході може вийти новий тімлід. Жарти жартами, але, коли я йшов із тімлідів у архітектори, команду очолив колега, який прийшов до нашої команди джуніором за два роки до того. Зараз ми з ним знову на одному проєкті — тепер він мій PM. І ще двоє з тієї славної команди перейшли до інших проєктів одразу на позиції лідів.
Якщо команда є досить великою, то з урахуванням усіх перелічених обов’язків часу на написання коду зазвичай не залишається. Тімлід за звичкою ще вішає на себе девелоперські завдання, нічого не встигає, нервує, сидить над ними у вихідні або, зітхаючи, перевішує на інших. Це нормально. Припинити працювати руками страшно, але досвід показує, що за потреби повернутися до активної розробки форму можна відновити за кілька місяців.
Як оцінювати тімліда
Формальних, детально розписаних критеріїв оцінки ми в компанії для тімлідів не використовуємо. Натомість я під час асесменту зазвичай ставлю кілька запитань за основними темами, переліченими вище, охоплюючи теорію і типові ситуації. За відповідями зазвичай стає зрозуміло, наскільки колега є зрілим і досвідченим в управлінні командою.
Техлідство. Пропускаємо, адже в нас не технічна співбесіда.
Менеджмент і процеси. Базова Agile теорія та запитання щодо досвіду її застосування. Наприклад:
Різниця між Scrum і Kanban.
Scrum ceremonies. Які існують узагалі, які застосовуються у вас? Якщо використовуються не всі, то чому?
Story points. Навіщо вони потрібні? Чи використовуєте ви їх? Якщо ні, то чому?
Capacity і Velocity. Що це і навіщо вони потрібні? Як співвідносяться між собою? Чи використовуються у вас? Ах, не використовуються? Як ви тоді взагалі плануєте?
Як не схибити з естімейтами?
Як реагувати на спроби клієнтів засунути у спринт незаплановану роботу?
Спілкування з клієнтами (account management). Як поводитись, якщо:
Ресурсів немає, а клієнту дуже потрібно.
Ми сильно накосячили, і клієнт про це знає.
Ми сильно накосячили, але клієнт ще не знає.
Клієнт намагається мікроменеджити наших розробників.
У клієнта змінилося керівництво.
Ми не погоджуємося з технічними вимогами клієнта.
Спілкування з командою (people management). Як поводитись, якщо:
Колега поводиться пасивно-агресивно.
Колега відмовляється виконувати нецікаве завдання.
У команду прийшов новачок, манера спілкування якого нервує інших.
Один із членів команди зовсім не тягне за хард-скілами.
Я намагаюся розтопити лід, але наші дзвінки все одно схожі на партзбори.
Кар'єрне зростання — куди далі?
Можливо, відсутність критеріїв і чітко сформульованих гайдлайнів обумовлена тим, що сама позиція тімліда є проміжною. Тобі вже тісно у кріслі розробника, ти можеш більше, софт-скіли дозволяють вийти на новий рівень взаємодії з клієнтами, але куди саме зростати, ще незрозуміло. Побувши декілька років тімлідом, тобто ще інженером, але вже з великим обсягом організаційної роботи, розумієш, чи хочеться тобі:
Далі заглиблюватись в організаційні активності, відходячи від технічних (шлях PM).
Плюнути на менеджмент і просто писати крутий код, попросивши всіх менше тебе турбувати (шлях технічного експерта або SME).
Менше організаційної роботи, більше — глибоко технічної, але високорівневої, без коду або майже без коду (шлях Technical Architect aka Systems Architect).
Менше організаційної роботи, менше коду — лише високорівнева архітектура та багато розмов із клієнтами для уточнення вимог і узгодження підходів (шлях Solutions Architect).
Нічого не змінювати, тому що саме так тобі добре (шлях насолоди поточним станом речей, який теж ніхто не скасовував).
Читайте головні IT-новини країни в нашому Telegram
УЧАСТЬ В АЗАРТНИХ ІГРАХ МОЖЕ ВИКЛИКАТИ ІГРОВУ ЗАЛЕЖНІСТЬ. ДОТРИМУЙТЕСЯ ПРАВИЛ (ПРИНЦИПІВ) ВІДПОВІДАЛЬНОЇ ГРИ.
Ліцензія видана ТОВ "СЛОТС Ю.ЕЙ." на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 15.09.23 (рішення КРАІЛ №245 від 31.08.2023); ТОВ "СЛОТС Ю.ЕЙ." – на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 26.04.2021 (рішення КРАІЛ №150 від 12.04.2021); ТОВ «СПЕЙСИКС» – на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 08.02.2021 (рішення КРАІЛ №34 від 02.02.2021); ТОВ «ГЕЙМДЕВ» – на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 16.02.2021 (рішення № 47 від 10.02.2021).
«Менеджмент не закінчується на словах Agile чи Kanban». Хто такий Project Manager та як ним стати
Бажаючих увійти в IT з кожним днем стає все більше. Проте більшість із потенційних айтішників опиняються перед складним вибором: ким стати, аби працювати у сфері інформаційних технологій. dev.ua започатковує нову рубрику, в якій розповідатиме, які спеціальності в українському IT є, що роблять конкретні спеціалісти та де вчитися, аби стати айтішником.
Сьогодні про професію Project Manager розповідає досвідчений PM в EPAM Яна Стрільчук,
Бізнес-аналітик в IT: хто він, що робить і як ним стати
Продовжуємо цикл матеріалів про ІТ-спеціальності. Кожну з них описує «типовий представник» — досвідчений фахівець. Ми сподіваємося, ці матеріали допоможуть школярам, студентам, перекваліфікантам, студентам вибрати спеціальність в ІТ, оцінити перспективи або просто звірити годинник з авторитетним колегою. Обговорюйте і доповнюйте матеріал в коментарях, щоб зробити його ще кориснішим.
Чим займаються бізнес-аналітики, якими різними вони бувають і яку користь приносять бізнесу, розповідає Юрій Гомон, BA Department Teach Lead в команді NIX.
У команді NIX разом з іншими лідами БА він відповідає за повний цикл професійного розвитку бізнес-аналітиків: навчання на початку кар'єри, розробку персональних планів розвитку, створення умов для зростання і менторство. За 9 років на його очах більш ніж 50 фахівців пройшли шлях від Trainee до Senior і знайшли своє покликання в нашій непростій, але динамічній і неймовірно захоплюючій професії.
