Осенью я был на митапе, посвящённом scrum'у. И услышал там интересный тезис: в слаженной скрам-команде роль тимлида/техлида минимальна, потому что все участники команды в той или иной степени являются носителями знаний и прекрасно самоорганизовываются благодаря скраму.
Дисклеймер
В этой статье я не пытаюсь убедить, а скорее рассуждаю на тему и приглашаю к обсуждению в комментариях. И да, я недавно выгорел как тимлид, что придало тексту соответствующий эмоциональный окрас, так что не стоит судить строго.
Team leader, тимлид, ведущий разработчик — это специалист (программист, дизайнер, тестировщик и т.п.), который взял на себя обязанность руководить командой специалистов в той же области.
Однако, на практике, тимлид может заниматься и аналитикой, архитектурой, тестированием выполненных задач, проектированием интерфейсов. И швец, и жнец, и на дуде игрец. Мне доводилось видеть тимлида, который следил за отзывами на приложения в Google Play, App Store и отвечал на отзывы, то есть по сути занимался поддержкой пользователей. При этом хорошим тоном для лида считается непосредственное участие в разработке.
Из этого можно сделать вывод, что тимлид — это сеньор, который предпочёл основной своей деятельности менеджмент и другие активности. Для одних рост в тимлиды — это глоток свежего воздуха, удовлетворение амбиций и, возможно, способ избежать выгорания. Для других тимлидство — бремя, которое естественным образом свалилось как на самого опытного участника команды (впрочем, вместе с прибавкой к зарплате) и наоборот приводит к выгоранию.
Обязанности тимлида размыты и меняются от команды к команде, от компании к компании. Но объединяет все эти активности одно: в современной разработке эти обязанности, так или иначе, можно распределить между участниками команды, снизив необходимость в лидере.
Руководитель
В скраме есть три основные роли: владелец продукта, scrum-мастер и исполнители (дизайнеры, тестировщики, разработчики и т.п.). Причём роль scrum-мастера обычно отводится одному из исполнителей, либо владельцу продукта, что не так правильно.
Кто же в данном случае является руководителем команды? Владелец продукта — это скорее инициатор созвонов, источник задач, заказчик, принимающий работу. Scrum-мастер — модератор созвонов для груминга, оценки задач, ретроспективы, демо и т.п. Исполнители — исполнители. Скрам подход не выделяет какую-то роль как главенствующую, все роли одинаково важны. Куда же мы «воткнём» нашего руководителя-тимлида? Кажется, что место ему среди исполнителей, но в чём будет заключаться руководящая роль?
Формулирует задачи владелец продукта, за техническое наполнение задач отвечает аналитик, декомпозицией задач, выяснением деталей занимается команда во время груминга. Оценкой задач занимается команда, ретроспектива — чисто командная движуха, демо проводит один-два участника команды. Распределить задачи между собой вполне способна сама команда. Кем же и чем же руководит тимлид? Есть такая профессия «руками водить».
Хранитель знаний
Допустим, тимлид является самым компетентным специалистом в команде, носит в своей голове большой объём технических знаний и к нему приходят за этими знаниями другие участники.
Во-первых, это роль техлида. Во-вторых, и техлид не нужен: бизнесу куда полезнее, когда все технические знания распределены между членами команды, а не находятся у одного человека. Это снижает бас-фактор, делает коллективную оценку времени выполнения задач точнее, позволяет быстрее и проще масштабировать команду.
Учитывая современную тенденцию нанимать в проект лидов со стороны, а не выращивать их в команде, среднестатистический тимлид уже и не является хранителем технических знаний.
Связующее звено
Сейчас модно отводить тимлидам роль связующего звена (в просторечии «передаста») между бизнесом и разработчиками. В этой ипостаси тимлид отстаивает позицию команды и/или бизнеса. В целом, работа заключается в бесконечных созвонах, а главным рабочим инструментом вместо среды разработки становятся календарь и почта.
Но разве конфликт между заказчиком и исполнителем не должен решаться во время груминга, на котором исполнители могут доходчиво объяснить, почему реализация конкретной задачи займёт слишком много времени? Именно во время груминга происходит диалог бизнеса и исполнителя, именно тут должен рождаться компромисс.
В процессе решения задачи, если у исполнителя возникают какие-то вопросы, гораздо эффективнее обсудить проблемы лично с дизайнером/тестировщиком/менеджером, чем общаться через лида — это ненужный посредник.
Администратор
Тимлид обычно наделён административными правами: выдача доступов, решения о найме/увольнении, решения о премировании, повышении зарплаты и т.д.
Наверное, это единственная по-настоящему полезная функция тимлида, т.к. в теории лид является персонажем, максимально приближенным к команде. Кроме того, за счёт наличия административных прав тимлид получает безусловный авторитет и позицию начальника в отношениях «начальник-подчинённый».
При этом наличие начальника — это не только способ контроля исполнителей, но и раздражающий фактор для них же. Потому что при отлаженных процессах, взаимной ответственности и здоровой атмосфере в коллективе тимлиду, как контролирующей инстанции, не остаётся работы, всё функционирует и без него.
Что касается найма сотрудников, то рекомендацию о найме должны давать интервьюеры на основании результата собеседования. Конечное решение вполне может на себя взять технический директор.
Процессы выдачи доступов, по-идее, должны инициироваться при трудоустройстве и осуществляться системными администраторами.
Премирование, повышение зарплаты, увольнение — такие решения удобно принимать менеджменту/техническому директору на основе оценки 360 градусов.
Тестировщик, аналитик, архитектор
Заголовок говорит сам за себя — это отдельные роли для отдельных специалистов. Однако, в компании не всегда есть выделенные специалисты для этих активностей. Если у лида есть чувство повышенной ответственности за проект, то он может по доброй воле взять на себя работу, для которой нет выделенной должности. В результате чужие, по сути, обязанности закрепляются за должностью лида. Члены команды, менеджмент, руководство, насмотревшись на такой пример, будут считать, что и любой другой лид должен исполнять эти обязанности.
Исследователь и инноватор
Раз тимлид в связи со своими активностями освобождается от обязательного написания кода в рамках спринтов, то в редкие моменты между созвонами, он может посвятить себя написанию чего-то фундаментального, решению какой-то сложной проблемы, до которой у других не доходят руки, либо написанию статьи на Хабр.
Но решением сложных проблем, написанием рокет-сайенс кода должен заниматься R&D специалист. А писать статьи на Хабр должны все те члены команды, кто хочет этим заниматься, проявляет инициативу.
Ну, допустим. А куда расти?
Немного расскажу о своём опыте тимлидства. У меня, как тимлида, всегда стояла задача собирать команду с нуля и в этой роли основателя было комфортно. Но когда начиналась работа с командой, я каждый раз немного выгорал. В основном из-за того, что мне приходилось отвлекаться от своего любимого программирования на работу с людьми, удовольствия от которой я не получал.
Каждый раз, когда я увольнялся, говорил себе, что «больше не буду тимлидом, это не моё». Но получалось становиться лидом впоследствии органически — когда появлялась необходимость в команде.
Но последнее место работы стало исключением — я пришёл лидом в уже слаженную сильную команду, а моя деятельность сводилась к созвонам и коммуникации в чатах. Это позволило мне словить, пожалуй, самый большой синдром самозванца за всю карьеру и выгореть как лиду окончательно.
Передо мной встал вопрос: а куда расти, если я для себя окончательно решил не быть лидом? За ответом далеко идти не приходится. Можно качать экспертизу, можно писать статьи, вести блог, можно участвовать в опенсорсе, можно самому основать какой-то проект, можно плотнее заняться хобби. Если вы упёрлись в потолок по зарплате как специалист, совсем необязательно перетекать в менеджмент в поисках большего дохода. Доход можно увеличить и другими способами. И точка.
P.S. Не лишним будет сказать, что у меня есть Telegram-канал «IT Монах», приглашаю подписаться :)
Комментарии (31)
ijsgaus
29.01.2023 18:08+1Только хороший тимлид знает что и как можно выжать из комманды. Как пилот формулы один. А попытка посадить на место пилота бригаду из двигателя и карбюратора под диктатом спонсора комманды - ну может и доедут до финиша...
it_monk Автор
29.01.2023 18:11-3что и как можно выжать из комманды
С такой формулировкой тимлид кажется соковыжималкой, которой пользуется бизнес. К слову, приходилось видеть и тимлидов, которые в первую очередь лояльны к команде, и тимлидов, которые лояльны к бизнесу.
stackjava
29.01.2023 18:10+3Плюсую статью, интересная точка зрения.
Работал там где тимлид = нач отдела. Он не вмешивался в процесс разработки, но занимался чистой административкой + кодил в одной из скрам команд.
И был интересный момент в одной из организаций, когда уволились каких то 2 рук центров... И за 2 года так и не нашли замену... Что самое интересное эти 2 года все отлично работали))))
barloc
29.01.2023 18:57+3И за 2 года так и не нашли замену... Что самое интересное эти 2 года все отлично работали))))
Это вот самое интересное в оценке руководителей. Или эти 2ое были гениальными руководителями, создавшие отличные команды. Или наоборот, они были лишними на этом празднике жизни и особо не парились, наживаясь на самодостаточных командах.
Какую оценку поставите вы.
stackjava
30.01.2023 10:49Честно говоря я ни раз видел похожее на разных уровнях.
Когда менялись лиды ( при мне в одной организации 3 шт сменились), а процесс не меняелся, отличий в работе не наблюдал.
Менялись так же 2 нач управления, вицепрезидент и даже президент организации, и то же я не увидел разницы, может именно на моем уровне не заметно.
Видел в другой конторе как уволнялся лид и все думали(и я думал), что будет мощнейшая просадка, ведь он понимал заказчика, он был фильтром, он нарезал задачки по способностям подчиненных. В итоге он уволился и вопреки всем страхам, ничего не встало, не просело, а задачи лида плавно размазались внутри команды.
Честно признаюсь еще ни разу не встречал среди моих руководителей сверх неординарных людей... Все были легко заменяемы и особых новшеств не вносили, то ли из-за бюррократии, то ли просто не хотели.
barloc
29.01.2023 19:04+7Лид не нужен в профессиональных командах, которые понимают куда идет продукт и делают все, что положено для этого.
Профессионально - это не только про скилы, но и про отношения в команде, и про понимание задач команды, и про общение с заказчиками.
Если есть провалы в квалификации, общении, внутренние конфликты "у кого больше" - необходимо давление авторитетом.
Или может быть это должен быть прожект-менеджер. Или может быть ресурс менеджер. Или инжиниринг менеджер... И еще сверху столько народу наплодили.
sshikov
29.01.2023 21:10А откуда берутся такие команды? Я вот не верю, что они самозарождаются, во всяком случае где попало. Как правило лидер в человеческом смысле в этом случае всегда есть.
AllexIn
29.01.2023 20:41+6Ни разу в жизни не видел команды, где был бы отдельный архитектор.
Архитектор в принципе не может быть в одном ряду с исполнителями, потому что у него решающее право голоса по принципам построения продукта. А если он принимает такие решения... Он внезапно уже не архитектор, а тех лид. А если он еще и команду хорошо знает... Вот он уже и тим лид.
"Дкомпозиция командой на созвоне" - в мире единорогов это замечательно звучит. В реальном мире, где у нас разноуровневые спецы, уровень которых понимает как раз именно тим лид - и именно он может поставить точку в том или ином вопросе.
Да, тим лид это роль, которая совмещает в себе несколько ролей. "И шнец, и жнец, и на дуде игрец." - это точное описание тим лида. Это универсал, который за счет своего опыта и знания команды может разрулить противоречия внутри команды и может заменить любую роль. Именно поэтому вы видели как тим лид "отвечает на отзывы в гугле" или "проектирует скелет проекта". Потому что если некому - это делает тим лид. Он спец, который может много чего, в том числе заткнуть дыру в компетенциях.
Команда без такого спеца любой кризис будет переживать очень жестко.
ozzyBLR
30.01.2023 09:40+1Тут всё в кучу. Думаю, это и является причиной выгорания. Когда ты "и жнец, и швец" в рамках ЛЮБОЙ роли, ты выгоришь. Точка.
Давайте попробуем разобраться и навести порядок.
Сначала поговорим про скрам. Считать скрам-мастера сугубо "модератором митингов" и говорить, что "это чаще всего кто-то из исполнителей" - это уже маленечко выстрел себе в ногу. СМ может и не участвовать на митингах, например. А ещё он помогает идентифицировать и устранять преграды, предлагает улучшения процессов, работает с обратной связью внутри команды. Важно понимать, что настоящего скрама без СМ не бывает. А значит если команда работает по всамделашнему скраму, то "функции СМ" не обязаны прилипать к тимлиду. А в компаниях, где больше 2-3 проектов, это и вовсе маловероятно.
Теперь конкретно о тимлидах в скраме. Да, такой роли там не описано. Но там и роли CEO компании нет, и бухгалтера нет, и уборщицы. Это означает лишь то, что для тимлида скрам не прописывает каких-то конкретных полномочий или ответственности.
Должен ли тимлид быть архитектором, тестировщиком, кем там угодно ещё? Это уже вопрос организации работы внутри компании. И тут давайте сделаем отсылку к структуре компании. У вас может быть всего один продукт - тогда одна команда и есть вся компания. У вас может быть аутсорс, где работают сотни человек на десятках проектов. Очевидно, что это будет влиять на наполнение роли тимлида. Я не буду углубляться в разделение обязанностей между тимлидом и эйчаром, что является довольно частым случаем, а лушче скажу, что сам подразумеваю под тимлидом.
Для меня тимлид - это прежде всего техлид. Человек, отвечающий за развитие основной технической компетенции своих подопечных (которые строго говоря не обязательно его подчинённые). Техническое совершенство продукта за авторством команды в этом случае - производная. Тимлид это не ультра-сеньор с кучкой вечных джунов за спиной. Это ревьер и ментор. Сильный тимлид растит специалистов. Он может, но не обязан участвовать непосредственно в разработке, построении архитектуры. Что бы он ни делал, его верхреуровневая цель заключается в том, чтобы научить подопечных делать это самим.
Если подытожить, то роль "Тимлид" в описании вакансии на сегодня столь же туманна, как и "Менеджер". Что за этим скрывается - загадка. Заранее задать все вопросы и чётко обозначить рамки - это снизить вероятность выгорания.
Sadovikow
30.01.2023 12:28Не понимаю почему в самом начале статьи, где вы описываете кто такой Teamlead, через запятую приводите как синоним - Ведущий разработчик.
Ведущий разработчик != Тимлид
Ну и вообще в классическом скраме нет такой роли, как тимлид.
Но вообще было интересно почитать, и многое откликается.
По моему мнению, популярное "выгорание тимлидов" связано как раз с тем, что у многих людей на этой позиции невероятная любовь к программированию, без чего человек вообще не может.
HellWalk
30.01.2023 12:29Для меня тимлид этот тот, кто не позволяет оторванные от реальности задачи с неадекватными сроками спускать напрямую к программистам.
Тот, кто понимает, что если дать волю менеджерам, с их главным подходом "пофигу на техдолг, на хороший код - главное побыстрее зарелизить новую фичу!" - проект довольно быстро умрет.
BugM
Вношу альтернативное предложение: Уволить скрам мастеров, а на груминг собачку отвести.
Менеджеры решающие какие премии выдавать разработке это худшее что вы можете сделать. Они не отвечают за качестве кода и не понимают что такое рефакторинг. Ваш проект довольно быстро превратится в болото. Лиды и их техническое руководство должны раздавать премии разработке. А менеджеры могут постоять сбоку и поагитировать за тех разработчиков которые им фичи сделали.
Общение всех продуктовых людей напрямую с разработчиками часто ведет к хаосу. Джуны и заметная часть мидлов не понимают что от них хотят. И делают что-то. Вместо утрясания и формализации требований к фиче. А еще бывают токсичные сеньоры. Это очень ценные кадры, но людям снаружи их показывать не стоит.
И да всякий найм, онбординг, присмотр за джунами и разговоры по душам чтобы у вас полкоманды внезапно не уволилось это тоже обязанности лида. Они прилично времени забирают. Сюда же идут разговоры со следующими уровнями руководства. Мол команда недовольна. Давайте поправим вот это и это. Это может быть все. От пайплайна CD до менеджеров чаек.
В итоге лиды это первое звено над разработкой. Которое заменяет недостаток софт скилов типичного разработчика и при этом пишет код. И они же оценивают разработчиков и выдают им премии.
it_monk Автор
Вашу позицию я хорошо понимаю, сам был свидетелем как внедрение скрама рушило устоявшиеся процессы разработки.
Благодаря оценке 360 рекомендации по премированию и повышению з.п. формируются за счёт отзывов коллег-разработчиков, а менеджеры просто аппрувят эти рекомендации.
BugM
Коллеги разработчики ненавидят писать отзывы на своих коллег. И относятся к этому процессу максимально формально. Получить полезный сигнал из таких отзывов крайне сложно. Я видел этот процесс в живую, он почти не работает.
AllexIn
Откуда коллеги вообще что-то знают о работе других?
Я как только с ревью ушел - полностью потерял представление о том, чем занимаются коллеги. Даже не смотря на ежедневные митинги, где каждый рассказывает о том что делал.
it_monk Автор
Если в команде ребята не знают чем занимаются коллеги, видать, команда не очень дружная. Вина ли в этом тимлида? )
ikostruba
Нередко это следствие природы задач, которые делает команда. Я довольно часто видел ситуации, когда некий проект или фичу невозможно делать более чем вдвоём, и этот проект вообще никак не пересекается с остальными проектами. В результате команда разбивается на группки из одного-двух человек, каждая из которых состредоточена на своём, и им объективно нет дела до того, что делают другие. Скрам-ритуалы, а особенно дэйли, в таких случаях оставляют гнетущее впечатление абсолютно пустой траты времени, потому что зачем слушать, что делают коллеги, если никак не можешь им помочь, и на твою работу это опять же не влияет никак.
aktuba
А почему команда должна быть "дружная"? Она должна выполнять командные задачи, запросы, требования и пр. Быть дружной - нет, не должна.
И да, я был лидом много лет и последние год-два разработчик - лиды нужны, но нормальных лидов практически нет. Большинство "я был сеньором, меня сделали лидом - я круче вас" или "ой, меня сделали лидом, чего делать-то?!". Построить план развития джуна или (почти не реально) миддла-сеньора - могут 0.5 лида из 100. А уж составить kpi по smart и того меньше...
it_monk Автор
Как же я был джуном, когда мне никто не строил план развития...
aktuba
Без инструктора можно научиться не плохо водить. Только аварий будет сильно больше.
AllexIn
Для меня "дружная" команда - это где все друг другу готовы помочь, научить, дружелюбны, не токсичны.
Ни один из этих пунктов не способствует получению знания о том, что делают другие.
Наверно такому знанию способствует курилка и постоянные перерывы на покурить. Но это уже мало отношения к реальности имеет.
it_monk Автор
По мне так это противоречащие понятия )
AllexIn
А по мне так нет.
Обратилась коллега, её поставили переносить из одного проекта в другой фичу, которую я когда-то делал. Спросила, где что лежит. Я ответил. Дружелюбно и без токсичности.
Дало мне это хоть толику информации о том, каким проектом она занимается и зачем им фича, которую я делал? Нет.
Arhammon
Курилка, как бы не был против минздрав, действительно помогает решать некоторые вопросы.
AllexIn
Речь не о минздраве. Речь об отсутствии физического контакта. Удаленка, иными словами.
ProFfeSsoRr
Чтобы команда была дружной, достаточно быть уверенным, что коллеги занимаются рабочими задачами и что они не чудаки. А знать, чем там условный Петя занят сегодня, обычно не требуется, если вы не пилите связанные друг с другом задачи.
dabrahabra
Зачастую под внедрением скрама получается внедрение сРама.