Комментарии 31
Вношу альтернативное предложение: Уволить скрам мастеров, а на груминг собачку отвести.
Менеджеры решающие какие премии выдавать разработке это худшее что вы можете сделать. Они не отвечают за качестве кода и не понимают что такое рефакторинг. Ваш проект довольно быстро превратится в болото. Лиды и их техническое руководство должны раздавать премии разработке. А менеджеры могут постоять сбоку и поагитировать за тех разработчиков которые им фичи сделали.
Общение всех продуктовых людей напрямую с разработчиками часто ведет к хаосу. Джуны и заметная часть мидлов не понимают что от них хотят. И делают что-то. Вместо утрясания и формализации требований к фиче. А еще бывают токсичные сеньоры. Это очень ценные кадры, но людям снаружи их показывать не стоит.
И да всякий найм, онбординг, присмотр за джунами и разговоры по душам чтобы у вас полкоманды внезапно не уволилось это тоже обязанности лида. Они прилично времени забирают. Сюда же идут разговоры со следующими уровнями руководства. Мол команда недовольна. Давайте поправим вот это и это. Это может быть все. От пайплайна CD до менеджеров чаек.
В итоге лиды это первое звено над разработкой. Которое заменяет недостаток софт скилов типичного разработчика и при этом пишет код. И они же оценивают разработчиков и выдают им премии.
Вашу позицию я хорошо понимаю, сам был свидетелем как внедрение скрама рушило устоявшиеся процессы разработки.
Менеджеры решающие какие премии выдавать разработке это худшее что вы можете сделать.
Благодаря оценке 360 рекомендации по премированию и повышению з.п. формируются за счёт отзывов коллег-разработчиков, а менеджеры просто аппрувят эти рекомендации.
Коллеги разработчики ненавидят писать отзывы на своих коллег. И относятся к этому процессу максимально формально. Получить полезный сигнал из таких отзывов крайне сложно. Я видел этот процесс в живую, он почти не работает.
Откуда коллеги вообще что-то знают о работе других?
Я как только с ревью ушел - полностью потерял представление о том, чем занимаются коллеги. Даже не смотря на ежедневные митинги, где каждый рассказывает о том что делал.
Если в команде ребята не знают чем занимаются коллеги, видать, команда не очень дружная. Вина ли в этом тимлида? )
Нередко это следствие природы задач, которые делает команда. Я довольно часто видел ситуации, когда некий проект или фичу невозможно делать более чем вдвоём, и этот проект вообще никак не пересекается с остальными проектами. В результате команда разбивается на группки из одного-двух человек, каждая из которых состредоточена на своём, и им объективно нет дела до того, что делают другие. Скрам-ритуалы, а особенно дэйли, в таких случаях оставляют гнетущее впечатление абсолютно пустой траты времени, потому что зачем слушать, что делают коллеги, если никак не можешь им помочь, и на твою работу это опять же не влияет никак.
А почему команда должна быть "дружная"? Она должна выполнять командные задачи, запросы, требования и пр. Быть дружной - нет, не должна.
И да, я был лидом много лет и последние год-два разработчик - лиды нужны, но нормальных лидов практически нет. Большинство "я был сеньором, меня сделали лидом - я круче вас" или "ой, меня сделали лидом, чего делать-то?!". Построить план развития джуна или (почти не реально) миддла-сеньора - могут 0.5 лида из 100. А уж составить kpi по smart и того меньше...
Для меня "дружная" команда - это где все друг другу готовы помочь, научить, дружелюбны, не токсичны.
Ни один из этих пунктов не способствует получению знания о том, что делают другие.
Наверно такому знанию способствует курилка и постоянные перерывы на покурить. Но это уже мало отношения к реальности имеет.
Чтобы команда была дружной, достаточно быть уверенным, что коллеги занимаются рабочими задачами и что они не чудаки. А знать, чем там условный Петя занят сегодня, обычно не требуется, если вы не пилите связанные друг с другом задачи.
Зачастую под внедрением скрама получается внедрение сРама.
Только хороший тимлид знает что и как можно выжать из комманды. Как пилот формулы один. А попытка посадить на место пилота бригаду из двигателя и карбюратора под диктатом спонсора комманды - ну может и доедут до финиша...
Плюсую статью, интересная точка зрения.
Работал там где тимлид = нач отдела. Он не вмешивался в процесс разработки, но занимался чистой административкой + кодил в одной из скрам команд.
И был интересный момент в одной из организаций, когда уволились каких то 2 рук центров... И за 2 года так и не нашли замену... Что самое интересное эти 2 года все отлично работали))))
И за 2 года так и не нашли замену... Что самое интересное эти 2 года все отлично работали))))
Это вот самое интересное в оценке руководителей. Или эти 2ое были гениальными руководителями, создавшие отличные команды. Или наоборот, они были лишними на этом празднике жизни и особо не парились, наживаясь на самодостаточных командах.
Какую оценку поставите вы.
Честно говоря я ни раз видел похожее на разных уровнях.
Когда менялись лиды ( при мне в одной организации 3 шт сменились), а процесс не меняелся, отличий в работе не наблюдал.
Менялись так же 2 нач управления, вицепрезидент и даже президент организации, и то же я не увидел разницы, может именно на моем уровне не заметно.
Видел в другой конторе как уволнялся лид и все думали(и я думал), что будет мощнейшая просадка, ведь он понимал заказчика, он был фильтром, он нарезал задачки по способностям подчиненных. В итоге он уволился и вопреки всем страхам, ничего не встало, не просело, а задачи лида плавно размазались внутри команды.
Честно признаюсь еще ни разу не встречал среди моих руководителей сверх неординарных людей... Все были легко заменяемы и особых новшеств не вносили, то ли из-за бюррократии, то ли просто не хотели.
Лид не нужен в профессиональных командах, которые понимают куда идет продукт и делают все, что положено для этого.
Профессионально - это не только про скилы, но и про отношения в команде, и про понимание задач команды, и про общение с заказчиками.
Если есть провалы в квалификации, общении, внутренние конфликты "у кого больше" - необходимо давление авторитетом.
Или может быть это должен быть прожект-менеджер. Или может быть ресурс менеджер. Или инжиниринг менеджер... И еще сверху столько народу наплодили.
Ни разу в жизни не видел команды, где был бы отдельный архитектор.
Архитектор в принципе не может быть в одном ряду с исполнителями, потому что у него решающее право голоса по принципам построения продукта. А если он принимает такие решения... Он внезапно уже не архитектор, а тех лид. А если он еще и команду хорошо знает... Вот он уже и тим лид.
"Дкомпозиция командой на созвоне" - в мире единорогов это замечательно звучит. В реальном мире, где у нас разноуровневые спецы, уровень которых понимает как раз именно тим лид - и именно он может поставить точку в том или ином вопросе.
Да, тим лид это роль, которая совмещает в себе несколько ролей. "И шнец, и жнец, и на дуде игрец." - это точное описание тим лида. Это универсал, который за счет своего опыта и знания команды может разрулить противоречия внутри команды и может заменить любую роль. Именно поэтому вы видели как тим лид "отвечает на отзывы в гугле" или "проектирует скелет проекта". Потому что если некому - это делает тим лид. Он спец, который может много чего, в том числе заткнуть дыру в компетенциях.
Команда без такого спеца любой кризис будет переживать очень жестко.
Какая интересная ситуация. Всё время казалось, что слово придумывают для явления или сущностей. А тут наоборот: есть слово - пытаемся понять, что оно означает. Может перестанем пользоваться этим термином и проблема уйдёт?
Тут всё в кучу. Думаю, это и является причиной выгорания. Когда ты "и жнец, и швец" в рамках ЛЮБОЙ роли, ты выгоришь. Точка.
Давайте попробуем разобраться и навести порядок.
Сначала поговорим про скрам. Считать скрам-мастера сугубо "модератором митингов" и говорить, что "это чаще всего кто-то из исполнителей" - это уже маленечко выстрел себе в ногу. СМ может и не участвовать на митингах, например. А ещё он помогает идентифицировать и устранять преграды, предлагает улучшения процессов, работает с обратной связью внутри команды. Важно понимать, что настоящего скрама без СМ не бывает. А значит если команда работает по всамделашнему скраму, то "функции СМ" не обязаны прилипать к тимлиду. А в компаниях, где больше 2-3 проектов, это и вовсе маловероятно.
Теперь конкретно о тимлидах в скраме. Да, такой роли там не описано. Но там и роли CEO компании нет, и бухгалтера нет, и уборщицы. Это означает лишь то, что для тимлида скрам не прописывает каких-то конкретных полномочий или ответственности.
Должен ли тимлид быть архитектором, тестировщиком, кем там угодно ещё? Это уже вопрос организации работы внутри компании. И тут давайте сделаем отсылку к структуре компании. У вас может быть всего один продукт - тогда одна команда и есть вся компания. У вас может быть аутсорс, где работают сотни человек на десятках проектов. Очевидно, что это будет влиять на наполнение роли тимлида. Я не буду углубляться в разделение обязанностей между тимлидом и эйчаром, что является довольно частым случаем, а лушче скажу, что сам подразумеваю под тимлидом.
Для меня тимлид - это прежде всего техлид. Человек, отвечающий за развитие основной технической компетенции своих подопечных (которые строго говоря не обязательно его подчинённые). Техническое совершенство продукта за авторством команды в этом случае - производная. Тимлид это не ультра-сеньор с кучкой вечных джунов за спиной. Это ревьер и ментор. Сильный тимлид растит специалистов. Он может, но не обязан участвовать непосредственно в разработке, построении архитектуры. Что бы он ни делал, его верхреуровневая цель заключается в том, чтобы научить подопечных делать это самим.
Если подытожить, то роль "Тимлид" в описании вакансии на сегодня столь же туманна, как и "Менеджер". Что за этим скрывается - загадка. Заранее задать все вопросы и чётко обозначить рамки - это снизить вероятность выгорания.
Не понимаю почему в самом начале статьи, где вы описываете кто такой Teamlead, через запятую приводите как синоним - Ведущий разработчик.
Ведущий разработчик != Тимлид
Ну и вообще в классическом скраме нет такой роли, как тимлид.
Но вообще было интересно почитать, и многое откликается.
По моему мнению, популярное "выгорание тимлидов" связано как раз с тем, что у многих людей на этой позиции невероятная любовь к программированию, без чего человек вообще не может.
Для меня тимлид этот тот, кто не позволяет оторванные от реальности задачи с неадекватными сроками спускать напрямую к программистам.
Тот, кто понимает, что если дать волю менеджерам, с их главным подходом "пофигу на техдолг, на хороший код - главное побыстрее зарелизить новую фичу!" - проект довольно быстро умрет.
Нужны ли тимлиды?