Комментарии 53
Вам нужно сначала определить, какие обязанности у роли Team Leader. И тогда всё встанет на свои места. Вот очень хорошая статья про это: habrahabr.ru/post/293334
Спасибо, прочитал статью но кроме обязанностей и общей ответственности еще бы и осязаемую ответственность определить. В статье описано за что в целом может быть ответственен TL/CL, но что будет ему если он не справился с ответственностью? Например у менеджеров по продажам обычно минимальный оклад и потом только бонус от продаж — все понятно и честно. А тут, то что я обычно наблюдаю — «это не я дурак, а вот люди не такие, процессы не такие, времени мало, стресса много и.т.д.».
Поэтому лично я готов нести ответственность за четко определенные зоны, но при этом и другие должны, ведь тогда и мотивация приобретает другой оборот.
Поэтому лично я готов нести ответственность за четко определенные зоны, но при этом и другие должны, ведь тогда и мотивация приобретает другой оборот.
Перечитал 2 раза. Поток мыслей, никак не связанных с реальностью.
TL — это управление разработчиками, если упрощенно. Его задача — поднять производительность разработчиков. Если у TL кода на 50% меньше, но у 5 подчиненных по +10% — это уже не плохо, верно? Ведь к этому, разруливается куча другой работы. А если по +15-20? Вот именно за это и готов платить бизнес.
Ну а если TL не увеличивает производительность команды — это просто плохой TL.
P.S.: повышение производительности — это не увеличение написанного кода, это увеличение решенных бизнес задач. Иногда за счет упрощения после PM, иногда за счет улучшения архитектуры после Архитектора, иногда за счет отказа от задач после руководителей, если эти задачи отнимут ресурсы, но не принесут результаты или если эти задачи можно реализовать намного проще, пусть и с ограниченным функционалом.
TL — человек, который стоит на страже, не допуская плохие таски до разработчиков и не выпуская от разработчиков плохой код. Чем лучше становится этот процесс — тем лучше для всех.
P.S.S.: и да, стресс у TL намного выше, чем у любого разработчика.
TL — это управление разработчиками, если упрощенно. Его задача — поднять производительность разработчиков. Если у TL кода на 50% меньше, но у 5 подчиненных по +10% — это уже не плохо, верно? Ведь к этому, разруливается куча другой работы. А если по +15-20? Вот именно за это и готов платить бизнес.
Ну а если TL не увеличивает производительность команды — это просто плохой TL.
P.S.: повышение производительности — это не увеличение написанного кода, это увеличение решенных бизнес задач. Иногда за счет упрощения после PM, иногда за счет улучшения архитектуры после Архитектора, иногда за счет отказа от задач после руководителей, если эти задачи отнимут ресурсы, но не принесут результаты или если эти задачи можно реализовать намного проще, пусть и с ограниченным функционалом.
TL — человек, который стоит на страже, не допуская плохие таски до разработчиков и не выпуская от разработчиков плохой код. Чем лучше становится этот процесс — тем лучше для всех.
P.S.S.: и да, стресс у TL намного выше, чем у любого разработчика.
Повышение производительности это не увеличение решённых бизнес-задач, а приведение в соответствие производительности команды и спускаемых сверху формальных параметров.
И «недопущение плохих тасков» до разработчиков это не задача тимлида. Задача тимлида в том, чтобы у разработчика с плохой таской производительность по формальным параметрам не просела.
А код…
Код и производительность у тимлида контролировать нежелательно, иначе есть тенденция тимлида уменьшать себе нагрузку путём выборки из бэклога «хороших тасков».
И «недопущение плохих тасков» до разработчиков это не задача тимлида. Задача тимлида в том, чтобы у разработчика с плохой таской производительность по формальным параметрам не просела.
А код…
Код и производительность у тимлида контролировать нежелательно, иначе есть тенденция тимлида уменьшать себе нагрузку путём выборки из бэклога «хороших тасков».
Спасибо за развернутый комментарий, но к сожалению этот поток мыслей у меня лично связан с реальностью. При этом я полностью с вами согласен, насчет того что TL увеличивает производительность команды или отдельных ее членов. Но вместе с тем у меня вопрос и к вам и вообще:
— почему заниматься наставничеством не может Senior или группа Senior-ов?
За это ведь тоже готов платить бизнес, верно?
Что же касается фильтра от «плохих задач», то тут тоже вопрос, разве PM не должен их фильтровать?
Плюс к этому задачи, идущие от бизнеса, могут быть непонятны TL(так как он еще не там в полной мере) и TL может принять неверное решение о том, что задача «плохая», при этом тратя время на доказывания своей позиции.
— почему заниматься наставничеством не может Senior или группа Senior-ов?
За это ведь тоже готов платить бизнес, верно?
Что же касается фильтра от «плохих задач», то тут тоже вопрос, разве PM не должен их фильтровать?
Плюс к этому задачи, идущие от бизнеса, могут быть непонятны TL(так как он еще не там в полной мере) и TL может принять неверное решение о том, что задача «плохая», при этом тратя время на доказывания своей позиции.
Бизнес готов платить разработчику за наставничество над другими разработчиками??? О_О Это где Вы такой бизнес нашли? Киньте ссылки, пожалуйста.
Да вобщем-то много где, ивенты и подтягивание на проекте по гайдам, подходам проектирования, пониманию что такое рефакторинг и когда оно действительно нужно и.т.д «молодых»,- за это вот все у меня и у многих моих друзей и знакомых из зарплаты не срезают, а иногда наоборот даже) Если у вас не так, то наверное надо как минимум задуматься.
Я сейчас захлебнулся от негодования. Наставничество, если оно грамотное, дает повышение уровня результатов труда целой команды, что в конечной точке выливается в дополнительные деньги. Это как раз то, что [здоровому] бизнесу интересно.
Как вообще вы могли в просветленном 2018-м году предположить подобное?
Как вообще вы могли в просветленном 2018-м году предположить подобное?
почему заниматься наставничеством не может Senior или группа Senior-ов?
1. Работа сеньора — код. Если он занимается чем-то другим — ему платят лишнее.
2. «Наставничество» — это далеко от кода и совсем не каждый «сеньор» с этим справится ;)
За это ведь тоже готов платить бизнес, верно?
Да, если это является задачей бизнеса и нет, если сеньор занимается этим вместо своих прямых обязанностей.
Что же касается фильтра от «плохих задач», то тут тоже вопрос, разве PM не должен их фильтровать?
А что вы подразумеваете под «плохими задачами»? Я говорил про такие, реализация которых отнимет много времени: плохо описанные, например.
Плюс к этому задачи, идущие от бизнеса, могут быть непонятны TL(так как он еще не там в полной мере) и TL может принять неверное решение о том, что задача «плохая», при этом тратя время на доказывания своей позиции.
И это нормально. TL отвественнен за команду, потеря времени на отстаивание интересов команды — важная часть работы TL.
Поддерживаю, хочу только еще добавить, что далеко не каждый программист(даже senior) поговорив с "бизнесом" поймет задачу, важность и зачем она нужна бизнесу. TL должен кроме прочего выступать связующим звеном, которое сможет выслушать/вычитать "поток сознания" бизнеса(менеджеров), переварить это дело, разобрать как его лучше сделать или может вообще лучше не делать или поменять местами порядок выполнения задач, что сократит "критический путь" достижения цели и изложить уже в понятной техническим людям(разработчикам) форме. Грубо говоря он должен защищать команду от менеджеров и давать им комфортно работать и выступать переводчиком с бизнес языка на технический язык.
Обычно таким занимается аналитик
Аналитик в лучшем случае сможет преобразовать объяснения бизнеса в технически поставленную задачу. Прояснить связи между задачами и расставить технические зависимости сможет разве что аналитик с очень хорошим опытом в разработке.
Мне доводится весьма нередко после аналитиков, задавать уточняющие вопросы по Acceptance Criteria, выправлять критерии которые невозможно измерить, указывать что новая story конфликтует с другой иногда уже закрытой пару лет назад. Указывать что в коде присутсвуют workaround, которые когда-то задолго до подключения к проекту закостыляла другая команда, а новый функционал делает этот workaround в дальнейшем безсмысленным и неплохо бы добавить sub-task на рефакторинг с его удалением.
Короче говоря, в контексте Scrum, Lead оценивает постановку задачи в user story и помогает ее разбить на sub-tasks. При высоком уровне зрелости каждого члена команды разработчики/тестировщики, Lead может быть и не нужен. Но по-моему опыту и исследованию знакомого психолога, большинство програмистов интраверты и не любят общаться с не техническими людьми. Вот те немногие программисты экстраверты, которые находят контакты с менеждментом и отлично подходят на роль лида, и они общаются за своих колег которые не хотят/могут построить это общение продуктивно.
А можно я Вам проще попытаюсь объяснить? Вы же программист, вот представьте себе, что у вас в программе функции будут переживать за свое название и место, а не за смысл.
Я к тому, что и тут — в каждой нормальной системе будет своя иерархия и набор ролей, в соответствии со здравомыслием, а не по КЗОТ (тем более, что и не прописаны такие должности свыше или в законах). Предложите начальству роль, в которой вы будете стараться мотивировать и защищать создателей, взвешивать решения (обычно архитектурные) и быть переводчиком и громоотводом для получателей. Или выберите набор по вкусу. А как оно такую роль-должность назовет — это дело третье. Лишь бы оно было нужно.
Извините, но редкостный бред)
И на том спасибо)
Знаете, мне вот, например, нравятся труды Клиффорда Саймака и Ивана Ефремова, но мой друг в целом считает, что они какой-то бред пишут, а вот Джон Толкин — наше все. Поэтому, на вкус и цвет...)
Знаете, мне вот, например, нравятся труды Клиффорда Саймака и Ивана Ефремова, но мой друг в целом считает, что они какой-то бред пишут, а вот Джон Толкин — наше все. Поэтому, на вкус и цвет...)
Могу пояснить. в чем проблема со вкусом и цветом.
Вы определяете понятие TeamLead как некую непонятную ступень карьеры после ступени Senior Develop, что неверно. В повествовании присутствует начальник отдела. Какого отдела? Если отдела разработки ПО, то у вас не АйТи фирма и понятие TeamLead не применимо. Потому-что тим у вас одна и ей уже есть кому руководить. И описываемая ситуация как раз в таких конторах часто происходит. Начальник отдела хочет поощрить, поднять статус своего ведущего разработчика (если уж есть начальник отдела, то обойдемся без синьора)), а заодно и скинуть на него часть своих обязанностей. Да это как раз что вы описываете в начале, но это никакого отношения не имеет к роли TeamLead. Понимаете о чем я?
Вы определяете понятие TeamLead как некую непонятную ступень карьеры после ступени Senior Develop, что неверно. В повествовании присутствует начальник отдела. Какого отдела? Если отдела разработки ПО, то у вас не АйТи фирма и понятие TeamLead не применимо. Потому-что тим у вас одна и ей уже есть кому руководить. И описываемая ситуация как раз в таких конторах часто происходит. Начальник отдела хочет поощрить, поднять статус своего ведущего разработчика (если уж есть начальник отдела, то обойдемся без синьора)), а заодно и скинуть на него часть своих обязанностей. Да это как раз что вы описываете в начале, но это никакого отношения не имеет к роли TeamLead. Понимаете о чем я?
Вы определяете понятие TeamLead как некую непонятную ступень карьеры после ступени Senior Develop, что неверно.
Я как раз не определяю, а наоборот пишу о том что, по моему мнению, это не верно, и что многие(по крайней мере в моей практике) думают что это следующая ступень.
Поэтому, да, конечно я понимаю о чем Вы.
1) Большинство проблем которые описаны в статье возникли, похоже, от того, что должности team leader не было в организации.
2) Представление, что team lead — следующая ступень за senior developer/engineer — ошибочно.
В компании была и есть должности TL, но вот понимание у каждого свое. И я как раз ни в коем разе не думаю и уж тем более не утверждаю, что TL это следующая ступень, просто так действительно многие думают, особенно в начале карьеры.
Не совсем. После senior'а хочется двигаться дальше. Те, кого прет от техники — двигаются в архитекторы. Кого от управления — в TL, а оттуда, если повезет, в PM (иерархическая позиция которого намного выше, чем обозначено в статье, так как он под собой «имеет» еще QA-шников, архитектора, бизнес-аналитиков и т.д.).
Уверен, что вы ошибаетесь. Из отличных разработчиков, чаще всего, получаются отвратительные PM-ы. PM — это не ступень развития айтишника, это совсем другая область.
Развитие TL — директор департамента. PM никак не намного выше — это позиции одного уровня. В некоторых компаниях они даже совмещены, например в схеме «two in the box».
Все по принципу Питера. :-)
P.S. Почему ТС считает, что архитектор, team lider, PM лучше чем Senior Developer?
Мне кажется это разные виды деятельности.
Хороший Developer может стоить дороже посредственного архитектора или PM :-)
P.S. Почему ТС считает, что архитектор, team lider, PM лучше чем Senior Developer?
Мне кажется это разные виды деятельности.
Хороший Developer может стоить дороже посредственного архитектора или PM :-)
На самом деле всё проще. Team leader нужен для упрощения управления, чтобы руководитель отдела и менеджер проекта общались с меньшим количеством людей.
Пример, приведённый в статье, эту задачу не решал.
не только для руководства, лиды фильтруют всю входящую и исходящую информацию в задачах, налаживают взаимоотношение между отделами, организуют встречи и занимаются прочей бюрократией. Тем самым освобождая время разработчика, но он может в том числе и делегировать свою работу на команду, тогда команда будет больше в бюрократии и меньше в коде. Всё зависит от самого лида, одни создают больше условий для команды, но мало пишут или занимаются исключительно ядром/структурой проекта. Другие не пишут, но решают или стараются решать все вопросы по бумажкам. Оба подхода работают
imgen, kruslan
Я вот наблюдаю подход, когда группа Senior разработчиков в команде и PM-ом со стороны бизнеса:
— фильтрует все как нужно и никаких «плохих» задач. Про плохо описанные, тоже вопрос, что это значит? если это все же Senior, то он вполне себе в состоянии понять задачи бизнеса и дописать задачу техническими деталями, так чтобы было понятно и Middl-у.
— между отделами, зафиксированы в задачах, — четкие критерии приемки что и когда и от кого и кто ожидает, в том числе не технические (ну про формат API даже писать не хотел)
— встречи, т.е. стэндап митинги, демонстрации, ретроспективы и.т.д., также регламентированы и налажены в ходе работы
— ну а прочую бюрократию делят между собой Руководитель отдела, PM, HR, даже техно-PR (есть такой по ивентам и конференциям в том числе)
И такой подход тоже таки себе работает, плюс при этом всем понятно в какую зону ответсвенности можно перейти и надо ли.
Про то, что не каждый Senior справиться с бизнес-требованиями и с наставничеством, то просто может мы про разных Senior говорим. Я вот, например, про тех кому в среднем по больнице 30+ лет(ну 27+), потому как есть тогда, какой-никакой, жизненный опыт и по специальности 7+ лет опыта.
Я вот наблюдаю подход, когда группа Senior разработчиков в команде и PM-ом со стороны бизнеса:
— фильтрует все как нужно и никаких «плохих» задач. Про плохо описанные, тоже вопрос, что это значит? если это все же Senior, то он вполне себе в состоянии понять задачи бизнеса и дописать задачу техническими деталями, так чтобы было понятно и Middl-у.
— между отделами, зафиксированы в задачах, — четкие критерии приемки что и когда и от кого и кто ожидает, в том числе не технические (
— встречи, т.е. стэндап митинги, демонстрации, ретроспективы и.т.д., также регламентированы и налажены в ходе работы
— ну а прочую бюрократию делят между собой Руководитель отдела, PM, HR, даже техно-PR (есть такой по ивентам и конференциям в том числе)
И такой подход тоже таки себе работает, плюс при этом всем понятно в какую зону ответсвенности можно перейти и надо ли.
Про то, что не каждый Senior справиться с бизнес-требованиями и с наставничеством, то просто может мы про разных Senior говорим. Я вот, например, про тех кому в среднем по больнице 30+ лет(ну 27+), потому как есть тогда, какой-никакой, жизненный опыт и по специальности 7+ лет опыта.
Не всегда и всё работает шаблонам и по книжечкам, у нас есть Лиды, есть Аналитика, но нет PM и часть его работы делится между всеми участниками этой цепочки.
Конечно не всегда, но так может надо что-то предпринять, ну или у вас всем нравиться делать еще что-то кроме своей основной работы. А кстати если у вас делится между всеми роль PM, то если вдруг проект выполнен не в сроки/не в бюджет/с ненадлежащим качеством, то кто виноват и что делать?
Есть система штрафов, по которой всех сверху вниз наказывают, после пары наказаний всё встаёт на свои места. Сперва конечно был бардак, все разосрались, но некоторое время спустя всё само собой организовалось и ответственность рассосалась между всеми участниками. Пмов нет еще и по причине того, что заказчиком выступает Product Owner.
Про плохо описанные, тоже вопрос, что это значит?
Это значит, что PM/аналитик описали не достаточно входных данных, например. Ну вот жизненный пример (упрощенный): задача от PM «сделать A/B-тест формы обратной связи». А какую именно метрику, почему эту метрику, характеристики и пр — отсутствуют. Плохой TL/хороший сеньор начнет разбираться, допытывать PM/аналитика, потратит кучу времени и сил, как своих, так и своего руководителя/подчиненных/PM/аналитика/etc… Хороший — вернет задачу PM-у/аналитику и возьмет другие бизнес-задачи, которые можно решать прямо сейчас. Тем самым — поднимет производительность своей команды. Как-то так ;)
Про то, что не каждый Senior справиться с бизнес-требованиями и с наставничеством, то просто может мы про разных Senior говорим. Я вот, например, про тех кому в среднем по больнице 30+ лет(ну 27+), потому как есть тогда, какой-никакой, жизненный опыт и по специальности 7+ лет опыта.
Не, говорим про одних и тех-же. Просто кому-то дано учить и он может из мидла сделать сеньора, а кто-то из джуна не сможет мидла сделать. Здесь проблема не в опыте, а во внутреннем расположении к обучению других.
kruslan
Вот об этом и речь, что хороший, действительно хороший, Senior, также отфильтрует и распишет тех.детали по «плохим» задачам и тем самым, как Вы и написали, «поднимет производительность своей команды».
Но, все же, я думаю проблема, по большей части, в опыте, не зря ведь народ говорит — «Все приходит с опытом», коллега)
Вот об этом и речь, что хороший, действительно хороший, Senior, также отфильтрует и распишет тех.детали по «плохим» задачам и тем самым, как Вы и написали, «поднимет производительность своей команды».
Но, все же, я думаю проблема, по большей части, в опыте, не зря ведь народ говорит — «Все приходит с опытом», коллега)
Вот об этом и речь, что хороший, действительно хороший, Senior, также отфильтрует и распишет тех.детали по «плохим» задачам и тем самым, как Вы и написали, «поднимет производительность своей команды».
Возможно мы о разных вещах говорим, но работа хорошего сеньора — код. Он не имеет права вернуть задачу PM-у, например.
Давайте для простоты (мое видение): pm видит проблему/улучшение/etc — выдает требования, tl получает требования — выдает задачу, разработчик получает задачу — выдает код. Не может (или не должен, кому как приятнее) разработчик уточнять требования или вносить в задачу изменения по своему усмотрению — он не знает дальнейшего видения/развития этой задачи.
Исходя из этого, сеньор, который «также отфильтрует и распишет тех.детали» — плохой сеньор, который тормозит работу команды.
kruslan
Ну тут не могу с Вами согласиться, так как рассуждения слишком утопичны и скорее для мира роботов. Так, например, давайте затронем процесс в семье — тот еще проект/продукт, знаете ли)
Так вот, по Вашей логике и моей интерпретации получаем:
— Жена — ходила беременная и потом еще рожала (а-ля PM)
— Теща/Мама Жены — получает готового ребенка и «бизенс-задачи»от новоиспеченной мамы (а-ля TL)
— Муж — получает готового ребенка и какие-то задачи.
НО — вникать Мужу как раз таки надо, а то реализуется там что то такое, в чем потом его, Мужа, и обвинят)
Так что, почему таки Senior, если видит что и почему в задаче не так, не может это донести PM-у, мне вот не понятно. Зачем же это еще и транслировать через TL (чем больше звеньев тем быстрее рвется).
Ну тут не могу с Вами согласиться, так как рассуждения слишком утопичны и скорее для мира роботов. Так, например, давайте затронем процесс в семье — тот еще проект/продукт, знаете ли)
Так вот, по Вашей логике и моей интерпретации получаем:
— Жена — ходила беременная и потом еще рожала (а-ля PM)
— Теща/Мама Жены — получает готового ребенка и «бизенс-задачи»от новоиспеченной мамы (а-ля TL)
— Муж — получает готового ребенка и какие-то задачи.
НО — вникать Мужу как раз таки надо, а то реализуется там что то такое, в чем потом его, Мужа, и обвинят)
Так что, почему таки Senior, если видит что и почему в задаче не так, не может это донести PM-у, мне вот не понятно. Зачем же это еще и транслировать через TL (чем больше звеньев тем быстрее рвется).
Ну тут не могу с Вами согласиться, так как рассуждения слишком утопичны и скорее для мира роботов.
Я и не предлагал соглашаться, лишь рассказал о своем опыте и о своем видении работы тимлидов и сеньоров.
Так, например, давайте затронем процесс в семье — тот еще проект/продукт, знаете ли)
Как отец 2х детей — знаю ;). Ну давайте…
— Жена — ходила беременная и потом еще рожала (а-ля PM)
Хм… Ну допустим, хотя уже не согласен с вашим видением.
— Теща/Мама Жены — получает готового ребенка и «бизенс-задачи»от новоиспеченной мамы (а-ля TL)
Стоп-стоп-стоп… В вашем примере, TL получает «продукт»? Ни требования, ни задачи, ни условия — именно «продукт»? Что-то тут не так)
НО — вникать Мужу как раз таки надо, а то реализуется там что то такое, в чем потом его, Мужа, и обвинят)
Ну так в вашем примере Муж === TL, а не сеньор. Сеньоров выступит производитель питания, одежды и пр. И тогда схема абсолютно полностью совпадает с моей:
1. PM (Мама) ставит требования: купить детское питание, купить памперсы.
2. Папа (TL) формализует задачу, выбирает исполнителя — конкретных производителей питания и памперсов. Причем, выбирает исходя из имеющихся ресурсов — кто-то может купить самого производителя, кто-то только его продукт ;)
Как видите, сеньор не влияет на продукт, он только покрывает бизнес-требования.
ак что, почему таки Senior, если видит что и почему в задаче не так, не может это донести PM-у, мне вот не понятно.
Если он видит, что в задаче что-то не так — он должен донести это тимлиду, а не PM-у. На то есть несколько причин:
1. Сеньор может не знать, что задача разбита на несколько более мелких задач и ему досталась именно одна из частей. А в сумме эти микро-задачи могут решать какую-то масштабную задачу, какое-то новое направление.
2. Сеньор мог не верно понять задачу и проблема не в самой задаче, а в плохом описании от TL, например.
3. Даже если сеньор что-то решит с PM-ом, последнему придется согласовывать это с TL, т.к. именно последний распределяет нагрузку, расчитывает время и стоимость каждой задачи и пр.
PS: везде, где я работал, всегда было основное правило — после того как таск выдан разработчику, таск не может быть изменен. Причин много — от оценки времени до фактических затрат. Повлиять на это всегда мог только TL и тогда отвественность за срыв сроков/затрат/etc была только на нем. PM-ы/аналитики/руководители отделов и всей компании никогда не могли ничего менять в процессе разработки. Очень странно слышать, что где-то сеньор может взять и поломать весь план на неделю/месяц/год…
Стоп-стоп-стоп… В вашем примере, TL получает «продукт»? Ни требования, ни задачи, ни условия — именно «продукт»? Что-то тут не так)
Ну какой-же это продукт-то, новорожденный) Это в лучшем случае MVP и то скорее нет, а как раз таки требования с которыми ой сколько всего еще нужно сделать) Это я как отец троих детей, могу себе позволить авторитетно заявлять)
И далее исполнитель задач, вроде добычи той самой одежды, питания и.т.д. обычно все таки Муж. И тогда схема уже совпадает и с моей)
Но тут то просто аналогия, она про то что хороший Senior если видит и может, то должен сказать что не так, а повлияет или нет это на задачу — решает PM.
По части видения проекта/продукта в целом, ну уж если TL может — то Senior полагаю тоже может понять что за кусочки и в какую бизнес-задачу складываются и решается ли она таким вот образом который предлагается от TL или PM (решает ли проблему бизнеса).
P.S: я и не говорил о том что Senior должен ломать планы и вообще устраивать революцию. Весь мой поток мыслей о том, что, как мне кажется, не всем командам нужен TL, а возможно при четких и формализованных процессах в компании, можно и вовсе без этой роли (но это не точно) )
Ну какой-же это продукт-то, новорожденный) Это в лучшем случае MVP и то скорее нет, а как раз таки требования с которыми ой сколько всего еще нужно сделать)
Ну так и есть «новорожденный продукт», который еще долго будет развиваться. Именно поэтому не MVP — нельзя перекроить на первых итерациях ;)
Это я как отец троих детей, могу себе позволить авторитетно заявлять)
Странные заявления, с учетом моего замечания выше ;)
И далее исполнитель задач, вроде добычи той самой одежды, питания и.т.д. обычно все таки Муж.
Верно. А исполнитель требований PM-а — TL, а не сеньор-разработчик. Разработчик сдает свои задачи TL-у. Упрощенно:
1. PM создает требования (фичи)
2. TL переводит фичи с гуманитарного на технический (создает таски) и распределяет по исполнителям. При этом сами фичи продакту сдает именно TL.
3. Разработчик создает код по таскам.
И тогда схема уже совпадает и с моей)
А я вроде-бы не отрицал это. Лишь указал, что схема расписана не полностью и в полном виде совпадает с тем, что я написал ранее ;)
Но тут то просто аналогия, она про то что хороший Senior если видит и может, то должен сказать что не так, а повлияет или нет это на задачу — решает PM.
Про это тоже сказал. Просто я не согласен (а точнее — я категорически против) что разработчик имеет дело с PM.
По части видения проекта/продукта в целом, ну уж если TL может — то Senior полагаю тоже может понять что за кусочки и в какую бизнес-задачу складываются и решается ли она таким вот образом который предлагается от TL или PM (решает ли проблему бизнеса).
Только при условии, что он участвует в задаче от создания до сдачи. Т.е. присутствует на всех встречах продактов/менеджеров/дизайнеров/аналитиков/etc по какой-то фиче/эпику/etc. А если это так — значит он не пишет в этот момент код, отвечает за реализацию и пр., что автоматически делает его TL-ом, а не разработчиком.
Если-же мы говорим про разработчиков — вряд-ли хоть один из них имеет полную картину по конкретному направлению. А значит на то, чтобы разобраться полноценно, уйдет очень много времени, которое он мог потратить на код и увеличить производительность как команды, так и отдела в целом. Если-же он тратит это время на попытки вникнуть в работу PM/TL — он получает свои деньги зря) Как-то так…
я и не говорил о том что Senior должен ломать планы и вообще устраивать революцию.
Хм… «также отфильтрует и распишет тех.детали по «плохим» задачам» как-бы намекает, что вместо своей прямой обязанности этот «сеньор» будет заниматься чужой работой, что поломает график работы, который построил его TL. Разве я не прав?)
Весь мой поток мыслей о том, что, как мне кажется, не всем командам нужен TL
Если в компании 1 не сложный проект и команда состоит из 3-4х разработчиков — да, наверное TL не нужен. Но как только появляется несколько направлений, пара-тройка PM/аналитиков — без TL и разбиения отдела на несколько команд — совсем никак. Иначе каждый разработчик будет заниматься кучей вещей, которыми не должен заниматься, тратить свое и чужое время, что отрицательно скажется на производительности, мотивации и финансах, в конце концов, всей команды.
Но, все же, я думаю проблема, по большей части, в опыте, не зря ведь народ говорит — «Все приходит с опытом», коллега)
Уверен, что у меня хватает опыта и в качестве сеньора, и в качестве TL (и в качестве CTO, но это уже за рамками данного поста) ;)
Автор как минимум задает правильные вопросы, не надо писать, что это бред и т.д.
Тимлид, на мой взгляд, — это (примерно) зам руководителя. Разруливает, как и руководитель, вопросы почти любого характера. По сути нужен для того, чтобы руководитель не затрахался до смерти.
Однако при этом тимлид на общую стратегию влияет лишь опосредованно, поэтому с выводом в статье более менее согласен, тимлид — неблагодарная должность. Ты как бы и начальник и не начальник (ключевые решения просто так принять не можешь), отсюда батхерт вполне может быть.
К сожалению, должность руководителя отдела разработки — тоже далеко не сахар. Невозможно расслабиться даже ненадолго. Особенно если тимлид так себе ))
Тимлид, на мой взгляд, — это (примерно) зам руководителя. Разруливает, как и руководитель, вопросы почти любого характера. По сути нужен для того, чтобы руководитель не затрахался до смерти.
Однако при этом тимлид на общую стратегию влияет лишь опосредованно, поэтому с выводом в статье более менее согласен, тимлид — неблагодарная должность. Ты как бы и начальник и не начальник (ключевые решения просто так принять не можешь), отсюда батхерт вполне может быть.
К сожалению, должность руководителя отдела разработки — тоже далеко не сахар. Невозможно расслабиться даже ненадолго. Особенно если тимлид так себе ))
Судя по вашим словам тимлид не может не быть «так себе».
В противном случае он становится руководителем :-)
В противном случае он становится руководителем :-)
«Однако при этом тимлид на общую стратегию влияет лишь опосредованно, поэтому с выводом в статье более менее согласен, тимлид — неблагодарная должность. „
Поднимитесь еще на одну ступеньку и почувствуете что эта должность еще более неблагодарная ))) Определенности в обязанностях еще меньше, а конкуренция за позицию неожиданно суровая и т.п.
Поднимитесь еще на одну ступеньку и почувствуете что эта должность еще более неблагодарная ))) Определенности в обязанностях еще меньше, а конкуренция за позицию неожиданно суровая и т.п.
Фундаментальная ошибка, как мне кажется — считать, что наличие тим лидв делает что-либо лучше и является самоцелью. По моему опыту горизонтальная иерархия в разработке всегда эффективнее вертикальной, но у неё есть одна существенная проблема — перестаёт работать после определённого размера команды из-за затрат на общение каждого-с-каждым.
И вот именно в этот критический момент роста имеет смысл разбиваться на команды поменьше и заводить тим лидов — чтобы вся социальная система не рухнула под собственным весом. При этом продуктивнее от этого никто не станет, даже наоборот, и хороший руководитель должен это понимать.
В таком контексте единственная ключевая обязанность тим лида — служить точкой обмена информацией между командами, и ничего более. А ключевые навыки — широкое (но не обязательно глубокое) знание всех систем, за которые отвечает команда и умение эффективно организовывать внешнюю информацию для внутреннего потребления.
По моему все просто — «Team lead» прежде всего менеджер, наверное менеджер самого низкого звена но все же менеджер.
И как у всякого менеджера, его главная обязанность организация совместной деятельности группы людей необходимой для достижения некой цели.
Все остальное является побочными видами деятельности.
Он может быть одновременно разработчиком (или тестером, у тестеров тоже есть Team lead-ы) а может и не быть.
Он может совмещать роль архитектора или может доверить исполнение этой роли кому-то из своей команды.
Может быть самым квалифицированным специалистом своей команды, но это не обязательно.
Может быть самым умным, но если он будет опиратся при принятии решений в том числе на мнение более умных подчиненных, этого не требуется.
Чего он точно не может делать, это уклонятся от решения возникающих на пути к общей цели проблем.
Не может перекладывать отвественность за общие неудачи на другого.
Обязан добится приличной награды для подчиненного который снова сделал невозможное.
Ну а в целом про роль менеджера столько написано что нет смысла пересказывать.
Учите работы классиков и у Вас все получится )
И как у всякого менеджера, его главная обязанность организация совместной деятельности группы людей необходимой для достижения некой цели.
Все остальное является побочными видами деятельности.
Он может быть одновременно разработчиком (или тестером, у тестеров тоже есть Team lead-ы) а может и не быть.
Он может совмещать роль архитектора или может доверить исполнение этой роли кому-то из своей команды.
Может быть самым квалифицированным специалистом своей команды, но это не обязательно.
Может быть самым умным, но если он будет опиратся при принятии решений в том числе на мнение более умных подчиненных, этого не требуется.
Чего он точно не может делать, это уклонятся от решения возникающих на пути к общей цели проблем.
Не может перекладывать отвественность за общие неудачи на другого.
Обязан добится приличной награды для подчиненного который снова сделал невозможное.
Ну а в целом про роль менеджера столько написано что нет смысла пересказывать.
Учите работы классиков и у Вас все получится )
andreylartsev, Dicebot
Да, вы в целом правы, в том числе об этом и статья, что само по себе наличие TL не сделает команду лучше. И также она о том, что можно горизонтально развиваться.
Но опять же, почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи по улучшению команды и отдельных её членов, а также выстраивать коммуникации между отделами, кончено совместно с PM и Руководителем отдела(об этом уже писал выше в комментариях — habrahabr.ru/post/349386/#comment_10677342).
Но для этого как раз и необходим чёткий, формализованный процесс, который, кстати, поможет масштабировать такие команды. А вот масштабировать TL-Чудотворца это скорее фантазии и приемлемо для небольших, по численности департамента разработки, компаний (как найти 50+ крутых TL? а вдруг они не те кем себя называют, а зарплату им наверняка крутую надо платить сразу, а не потом).
Также про TL как менеджера, это, как по мне, тоже такой себе миф, так как у тех самых менеджеров часто есть KPI, завязанный на определенные метрики, т.е. то, что вот прямо можно взять и измерить из недели в неделю, месяца, квартала и.т.д. Поэтому, если у TL, о которых вы говорите, нет таких метрик, влияющих на мотивацию — то нет и ответственности в полной мере, а значит и результат в конце концов будет не в пользу бизнеса. Но если есть такие метрики — то да, ваш TL — менеджер.
Да, вы в целом правы, в том числе об этом и статья, что само по себе наличие TL не сделает команду лучше. И также она о том, что можно горизонтально развиваться.
Но опять же, почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи по улучшению команды и отдельных её членов, а также выстраивать коммуникации между отделами, кончено совместно с PM и Руководителем отдела(об этом уже писал выше в комментариях — habrahabr.ru/post/349386/#comment_10677342).
Но для этого как раз и необходим чёткий, формализованный процесс, который, кстати, поможет масштабировать такие команды. А вот масштабировать TL-Чудотворца это скорее фантазии и приемлемо для небольших, по численности департамента разработки, компаний (как найти 50+ крутых TL? а вдруг они не те кем себя называют, а зарплату им наверняка крутую надо платить сразу, а не потом).
Также про TL как менеджера, это, как по мне, тоже такой себе миф, так как у тех самых менеджеров часто есть KPI, завязанный на определенные метрики, т.е. то, что вот прямо можно взять и измерить из недели в неделю, месяца, квартала и.т.д. Поэтому, если у TL, о которых вы говорите, нет таких метрик, влияющих на мотивацию — то нет и ответственности в полной мере, а значит и результат в конце концов будет не в пользу бизнеса. Но если есть такие метрики — то да, ваш TL — менеджер.
почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи
Например, потому что я так не считаю :) Более того, в компании, где я работаю, вообще нет никакого строгого деления на ранги и никакого технического менеджмента, одни лишь только Software Engineer. При этом тим лиды есть, но они все — обычные разработчики, просто с дополнительными обязанностями. Впрочем, когда компания была меньше, не было даже их, и было ещё лучше.
Просто нужно нанимать людей, умеющих принимать решения самостоятельно — и изначально объяснять, что таких решений от них ждут.
Вот, уже хорошо) Так, а теперь, если не трудно, еще хотелось бы знать, у тех TL, которые есть и у которых какие-то там дополнительные обязанности(какие и почему у них ?), у них есть метрики привязанные к зарплате(выше писал)?
какие
1) Быть контактным лицом, если кому-то что-то нужно от этой команды
2) Раз в неделю собираться на митинг тим лидов и озвучивать там важные для команды темы (и потом транслировать обратно результат)
почему у них
Потому что кому-то надо это делать :) Существенного влияния на зарплату это не оказывает.
у них есть метрики привязанные к зарплате
Нет, у программистов не существует никаких метрик. Но после больших факапов руководство может прислать грустный мейл о том, сколько это стоило компании и человеку будет очень стыдно :)
Вопросы поставлены правильные. Я сам их себе задавал, когда получал эту должность в разных организациях… первые два раза. :) Потом нашел ответ — он тривиален.
Суть должности Team Leader именно в том, как она называется. Дословно!
И это вообще не должность производственной структуры (скорее реверанс бизнеса в сторону программистов), и потому, у нее нет никаких «рычагов и полномочий» от руководства.
Если человек является по факту «лидером команды» — у него есть связанные с этим возможности. Не является — извините…
Поэтому должность Team Leader всегда совместительная. С Senior, PM или начальником отдела (лучше всего с Senior — меньше внутренних противоречий). Отсюда и путанница в обязанностях, «обязанности» — это по линии производственной структуры.
В чем-то Team Leader близок к профсоюзному лидеру (из тех областей, где профсоюзы реально работают), так же не дает официальной должности и так же опирается на личный авторитет. Просто IT такая отрасль, в которой бизнес без поддержки коллектива просто не может обойтись и бизнесу пришлось создать эту роль самому. Не дожидаясь…
Назначение человека TL может означать две вещи:
1. Признание сложившихся фактов.
2. Карт-бланш на формирование своей команды.
Иногда, первое и второе в смеси.
Почему удобнее всего совмещение с Senior? Потому, что TL всегда на стороне интересов команды! Даже когда уговаривает эту команду согласиться с требованиями бизнеса. Просто он видит ситуацию дальше и с большим количеством деталей. (Кроме того, когда он уговаривает бизнес признать требования команды, это обычно никто посторонний не видит.)
Хотя есть исключение — если речь идет о формировании команды под себя, лучше это делать совмещая с начальником отдела. (Правда потом это вызовет много сложностей. И лучше красиво сделать рокировку.)
Суть должности Team Leader именно в том, как она называется. Дословно!
И это вообще не должность производственной структуры (скорее реверанс бизнеса в сторону программистов), и потому, у нее нет никаких «рычагов и полномочий» от руководства.
Если человек является по факту «лидером команды» — у него есть связанные с этим возможности. Не является — извините…
Поэтому должность Team Leader всегда совместительная. С Senior, PM или начальником отдела (лучше всего с Senior — меньше внутренних противоречий). Отсюда и путанница в обязанностях, «обязанности» — это по линии производственной структуры.
В чем-то Team Leader близок к профсоюзному лидеру (из тех областей, где профсоюзы реально работают), так же не дает официальной должности и так же опирается на личный авторитет. Просто IT такая отрасль, в которой бизнес без поддержки коллектива просто не может обойтись и бизнесу пришлось создать эту роль самому. Не дожидаясь…
Назначение человека TL может означать две вещи:
1. Признание сложившихся фактов.
2. Карт-бланш на формирование своей команды.
Иногда, первое и второе в смеси.
Почему удобнее всего совмещение с Senior? Потому, что TL всегда на стороне интересов команды! Даже когда уговаривает эту команду согласиться с требованиями бизнеса. Просто он видит ситуацию дальше и с большим количеством деталей. (Кроме того, когда он уговаривает бизнес признать требования команды, это обычно никто посторонний не видит.)
Хотя есть исключение — если речь идет о формировании команды под себя, лучше это делать совмещая с начальником отдела. (Правда потом это вызовет много сложностей. И лучше красиво сделать рокировку.)
Team lead это лидер комманды разработчиков. У любой комманды должен быть лидер, тот за кем последнее слово в решениях касающихся процессов разработки.
Плюс разработка плохо совмещается с другими тасками, и как правило КПД растет когда есть лид который разруливает все административные таски позволяя разработчикам сосредоточится на задаче, который знает каждого и подготавливает им задачи по душе. Который знает кто за что отвечает к кому идти по тому или иному вопросу итд. А еще он отличный специалист и всегда готов помочь советом когда разработчик зашел в тупик или ему трудно принять решение.
Я и не против лидера, но почему он именно обязан быть 100%(выше уже, в принципе, договорились что не обязан, но так, якобы проще).Также последнее слово, например, может и быть у него (хотя тоже спорно), но тогда какова ответственность за то самое слово? Выше как раз некоторое писали что если что, то «будет стыдно», но это в детском саду такой уровень ответственности, а не у взрослых людей.
Имхо, тимлид нужен для того, чтобы разработчики делали свою работу не отвлекаясь на ерунду — неработающие виртуалки, нет креденшелов от третьей системы, в документации что-то неясно, и т.п. Тимлид решает эту ерунду (может лично, а может делегировать), а команда спокойно работает, не испытывая фрустрации.
Также ТЛ не пропускает плохой код во время ревью, раздает задачи и помогает, если разработчик застрял.
Думаю, этого уже достаточно для того, чтобы быть неплохим, или даже хорошим лидом, т.к. в хороших условиях команда рада работать.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Team Leader. Быть или не быть, вот в чем вопрос