Вы определяете понятие TeamLead как некую непонятную ступень карьеры после ступени Senior Develop, что неверно.
Я как раз не определяю, а наоборот пишу о том что, по моему мнению, это не верно, и что многие(по крайней мере в моей практике) думают что это следующая ступень.
Поэтому, да, конечно я понимаю о чем Вы.
Я и не против лидера, но почему он именно обязан быть 100%(выше уже, в принципе, договорились что не обязан, но так, якобы проще).Также последнее слово, например, может и быть у него (хотя тоже спорно), но тогда какова ответственность за то самое слово? Выше как раз некоторое писали что если что, то «будет стыдно», но это в детском саду такой уровень ответственности, а не у взрослых людей.
Стоп-стоп-стоп… В вашем примере, TL получает «продукт»? Ни требования, ни задачи, ни условия — именно «продукт»? Что-то тут не так)
Ну какой-же это продукт-то, новорожденный) Это в лучшем случае MVP и то скорее нет, а как раз таки требования с которыми ой сколько всего еще нужно сделать) Это я как отец троих детей, могу себе позволить авторитетно заявлять)
И далее исполнитель задач, вроде добычи той самой одежды, питания и.т.д. обычно все таки Муж. И тогда схема уже совпадает и с моей)
Но тут то просто аналогия, она про то что хороший Senior если видит и может, то должен сказать что не так, а повлияет или нет это на задачу — решает PM.
По части видения проекта/продукта в целом, ну уж если TL может — то Senior полагаю тоже может понять что за кусочки и в какую бизнес-задачу складываются и решается ли она таким вот образом который предлагается от TL или PM (решает ли проблему бизнеса).
P.S: я и не говорил о том что Senior должен ломать планы и вообще устраивать революцию. Весь мой поток мыслей о том, что, как мне кажется, не всем командам нужен TL, а возможно при четких и формализованных процессах в компании, можно и вовсе без этой роли (но это не точно) )
Вот, уже хорошо) Так, а теперь, если не трудно, еще хотелось бы знать, у тех TL, которые есть и у которых какие-то там дополнительные обязанности(какие и почему у них ?), у них есть метрики привязанные к зарплате(выше писал)?
kruslan
Ну тут не могу с Вами согласиться, так как рассуждения слишком утопичны и скорее для мира роботов. Так, например, давайте затронем процесс в семье — тот еще проект/продукт, знаете ли)
Так вот, по Вашей логике и моей интерпретации получаем:
— Жена — ходила беременная и потом еще рожала (а-ля PM)
— Теща/Мама Жены — получает готового ребенка и «бизенс-задачи»от новоиспеченной мамы (а-ля TL)
— Муж — получает готового ребенка и какие-то задачи.
НО — вникать Мужу как раз таки надо, а то реализуется там что то такое, в чем потом его, Мужа, и обвинят)
Так что, почему таки Senior, если видит что и почему в задаче не так, не может это донести PM-у, мне вот не понятно. Зачем же это еще и транслировать через TL (чем больше звеньев тем быстрее рвется).
kruslan
Вот об этом и речь, что хороший, действительно хороший, Senior, также отфильтрует и распишет тех.детали по «плохим» задачам и тем самым, как Вы и написали, «поднимет производительность своей команды».
Но, все же, я думаю проблема, по большей части, в опыте, не зря ведь народ говорит — «Все приходит с опытом», коллега)
andreylartsev, Dicebot
Да, вы в целом правы, в том числе об этом и статья, что само по себе наличие TL не сделает команду лучше. И также она о том, что можно горизонтально развиваться.
Но опять же, почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи по улучшению команды и отдельных её членов, а также выстраивать коммуникации между отделами, кончено совместно с PM и Руководителем отдела(об этом уже писал выше в комментариях — habrahabr.ru/post/349386/#comment_10677342).
Но для этого как раз и необходим чёткий, формализованный процесс, который, кстати, поможет масштабировать такие команды. А вот масштабировать TL-Чудотворца это скорее фантазии и приемлемо для небольших, по численности департамента разработки, компаний (как найти 50+ крутых TL? а вдруг они не те кем себя называют, а зарплату им наверняка крутую надо платить сразу, а не потом).
Также про TL как менеджера, это, как по мне, тоже такой себе миф, так как у тех самых менеджеров часто есть KPI, завязанный на определенные метрики, т.е. то, что вот прямо можно взять и измерить из недели в неделю, месяца, квартала и.т.д. Поэтому, если у TL, о которых вы говорите, нет таких метрик, влияющих на мотивацию — то нет и ответственности в полной мере, а значит и результат в конце концов будет не в пользу бизнеса. Но если есть такие метрики — то да, ваш TL — менеджер.
Конечно не всегда, но так может надо что-то предпринять, ну или у вас всем нравиться делать еще что-то кроме своей основной работы. А кстати если у вас делится между всеми роль PM, то если вдруг проект выполнен не в сроки/не в бюджет/с ненадлежащим качеством, то кто виноват и что делать?
imgen, kruslan
Я вот наблюдаю подход, когда группа Senior разработчиков в команде и PM-ом со стороны бизнеса:
— фильтрует все как нужно и никаких «плохих» задач. Про плохо описанные, тоже вопрос, что это значит? если это все же Senior, то он вполне себе в состоянии понять задачи бизнеса и дописать задачу техническими деталями, так чтобы было понятно и Middl-у.
— между отделами, зафиксированы в задачах, — четкие критерии приемки что и когда и от кого и кто ожидает, в том числе не технические (ну про формат API даже писать не хотел)
— встречи, т.е. стэндап митинги, демонстрации, ретроспективы и.т.д., также регламентированы и налажены в ходе работы
— ну а прочую бюрократию делят между собой Руководитель отдела, PM, HR, даже техно-PR (есть такой по ивентам и конференциям в том числе)
И такой подход тоже таки себе работает, плюс при этом всем понятно в какую зону ответсвенности можно перейти и надо ли.
Про то, что не каждый Senior справиться с бизнес-требованиями и с наставничеством, то просто может мы про разных Senior говорим. Я вот, например, про тех кому в среднем по больнице 30+ лет(ну 27+), потому как есть тогда, какой-никакой, жизненный опыт и по специальности 7+ лет опыта.
Да вобщем-то много где, ивенты и подтягивание на проекте по гайдам, подходам проектирования, пониманию что такое рефакторинг и когда оно действительно нужно и.т.д «молодых»,- за это вот все у меня и у многих моих друзей и знакомых из зарплаты не срезают, а иногда наоборот даже) Если у вас не так, то наверное надо как минимум задуматься.
Спасибо, прочитал статью но кроме обязанностей и общей ответственности еще бы и осязаемую ответственность определить. В статье описано за что в целом может быть ответственен TL/CL, но что будет ему если он не справился с ответственностью? Например у менеджеров по продажам обычно минимальный оклад и потом только бонус от продаж — все понятно и честно. А тут, то что я обычно наблюдаю — «это не я дурак, а вот люди не такие, процессы не такие, времени мало, стресса много и.т.д.».
Поэтому лично я готов нести ответственность за четко определенные зоны, но при этом и другие должны, ведь тогда и мотивация приобретает другой оборот.
Спасибо за хорошую аналогию, да все так, потому и написал что, вроде как по здравому смыслу и если говорить о бизнесе, т.е. получение прибыли после вычета расходов, то надо чтобы все роли были понятны и максимально задействованы в той самой получении прибыли, а иначе какой же тогда бизнес.
В компании была и есть должности TL, но вот понимание у каждого свое. И я как раз ни в коем разе не думаю и уж тем более не утверждаю, что TL это следующая ступень, просто так действительно многие думают, особенно в начале карьеры.
И на том спасибо)
Знаете, мне вот, например, нравятся труды Клиффорда Саймака и Ивана Ефремова, но мой друг в целом считает, что они какой-то бред пишут, а вот Джон Толкин — наше все. Поэтому, на вкус и цвет...)
Спасибо за развернутый комментарий, но к сожалению этот поток мыслей у меня лично связан с реальностью. При этом я полностью с вами согласен, насчет того что TL увеличивает производительность команды или отдельных ее членов. Но вместе с тем у меня вопрос и к вам и вообще:
— почему заниматься наставничеством не может Senior или группа Senior-ов?
За это ведь тоже готов платить бизнес, верно?
Что же касается фильтра от «плохих задач», то тут тоже вопрос, разве PM не должен их фильтровать?
Плюс к этому задачи, идущие от бизнеса, могут быть непонятны TL(так как он еще не там в полной мере) и TL может принять неверное решение о том, что задача «плохая», при этом тратя время на доказывания своей позиции.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Я как раз не определяю, а наоборот пишу о том что, по моему мнению, это не верно, и что многие(по крайней мере в моей практике) думают что это следующая ступень.
Поэтому, да, конечно я понимаю о чем Вы.
Ну какой-же это продукт-то, новорожденный) Это в лучшем случае MVP и то скорее нет, а как раз таки требования с которыми ой сколько всего еще нужно сделать) Это я как отец троих детей, могу себе позволить авторитетно заявлять)
И далее исполнитель задач, вроде добычи той самой одежды, питания и.т.д. обычно все таки Муж. И тогда схема уже совпадает и с моей)
Но тут то просто аналогия, она про то что хороший Senior если видит и может, то должен сказать что не так, а повлияет или нет это на задачу — решает PM.
По части видения проекта/продукта в целом, ну уж если TL может — то Senior полагаю тоже может понять что за кусочки и в какую бизнес-задачу складываются и решается ли она таким вот образом который предлагается от TL или PM (решает ли проблему бизнеса).
P.S: я и не говорил о том что Senior должен ломать планы и вообще устраивать революцию. Весь мой поток мыслей о том, что, как мне кажется, не всем командам нужен TL, а возможно при четких и формализованных процессах в компании, можно и вовсе без этой роли (но это не точно) )
Ну тут не могу с Вами согласиться, так как рассуждения слишком утопичны и скорее для мира роботов. Так, например, давайте затронем процесс в семье — тот еще проект/продукт, знаете ли)
Так вот, по Вашей логике и моей интерпретации получаем:
— Жена — ходила беременная и потом еще рожала (а-ля PM)
— Теща/Мама Жены — получает готового ребенка и «бизенс-задачи»от новоиспеченной мамы (а-ля TL)
— Муж — получает готового ребенка и какие-то задачи.
НО — вникать Мужу как раз таки надо, а то реализуется там что то такое, в чем потом его, Мужа, и обвинят)
Так что, почему таки Senior, если видит что и почему в задаче не так, не может это донести PM-у, мне вот не понятно. Зачем же это еще и транслировать через TL (чем больше звеньев тем быстрее рвется).
Вот об этом и речь, что хороший, действительно хороший, Senior, также отфильтрует и распишет тех.детали по «плохим» задачам и тем самым, как Вы и написали, «поднимет производительность своей команды».
Но, все же, я думаю проблема, по большей части, в опыте, не зря ведь народ говорит — «Все приходит с опытом», коллега)
Да, вы в целом правы, в том числе об этом и статья, что само по себе наличие TL не сделает команду лучше. И также она о том, что можно горизонтально развиваться.
Но опять же, почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи по улучшению команды и отдельных её членов, а также выстраивать коммуникации между отделами, кончено совместно с PM и Руководителем отдела(об этом уже писал выше в комментариях — habrahabr.ru/post/349386/#comment_10677342).
Но для этого как раз и необходим чёткий, формализованный процесс, который, кстати, поможет масштабировать такие команды. А вот масштабировать TL-Чудотворца это скорее фантазии и приемлемо для небольших, по численности департамента разработки, компаний (как найти 50+ крутых TL? а вдруг они не те кем себя называют, а зарплату им наверняка крутую надо платить сразу, а не потом).
Также про TL как менеджера, это, как по мне, тоже такой себе миф, так как у тех самых менеджеров часто есть KPI, завязанный на определенные метрики, т.е. то, что вот прямо можно взять и измерить из недели в неделю, месяца, квартала и.т.д. Поэтому, если у TL, о которых вы говорите, нет таких метрик, влияющих на мотивацию — то нет и ответственности в полной мере, а значит и результат в конце концов будет не в пользу бизнеса. Но если есть такие метрики — то да, ваш TL — менеджер.
Я вот наблюдаю подход, когда группа Senior разработчиков в команде и PM-ом со стороны бизнеса:
— фильтрует все как нужно и никаких «плохих» задач. Про плохо описанные, тоже вопрос, что это значит? если это все же Senior, то он вполне себе в состоянии понять задачи бизнеса и дописать задачу техническими деталями, так чтобы было понятно и Middl-у.
— между отделами, зафиксированы в задачах, — четкие критерии приемки что и когда и от кого и кто ожидает, в том числе не технические (
ну про формат API даже писать не хотел)— встречи, т.е. стэндап митинги, демонстрации, ретроспективы и.т.д., также регламентированы и налажены в ходе работы
— ну а прочую бюрократию делят между собой Руководитель отдела, PM, HR, даже техно-PR (есть такой по ивентам и конференциям в том числе)
И такой подход тоже таки себе работает, плюс при этом всем понятно в какую зону ответсвенности можно перейти и надо ли.
Про то, что не каждый Senior справиться с бизнес-требованиями и с наставничеством, то просто может мы про разных Senior говорим. Я вот, например, про тех кому в среднем по больнице 30+ лет(ну 27+), потому как есть тогда, какой-никакой, жизненный опыт и по специальности 7+ лет опыта.
Поэтому лично я готов нести ответственность за четко определенные зоны, но при этом и другие должны, ведь тогда и мотивация приобретает другой оборот.
Знаете, мне вот, например, нравятся труды Клиффорда Саймака и Ивана Ефремова, но мой друг в целом считает, что они какой-то бред пишут, а вот Джон Толкин — наше все. Поэтому, на вкус и цвет...)
— почему заниматься наставничеством не может Senior или группа Senior-ов?
За это ведь тоже готов платить бизнес, верно?
Что же касается фильтра от «плохих задач», то тут тоже вопрос, разве PM не должен их фильтровать?
Плюс к этому задачи, идущие от бизнеса, могут быть непонятны TL(так как он еще не там в полной мере) и TL может принять неверное решение о том, что задача «плохая», при этом тратя время на доказывания своей позиции.