Данную статью меня побудил написать тот скрытый и для каждого свой смысл должности/роли Team Leader. Многие хотят им стать, многим интересно что там, "под капотом", работы в этой должности. Поэтому кому интересно узнать еще одно мнение об этом всем безобразии, то прошу под кат.
По мере своего погружения в мир IT, я, наверное как и многие, размышлял и параллельно шел по пути своего развития примерно в следующем ключе:
- Вот я Junior...
- Надо фигачить код и вообще изучать все как можно больше
- Хм… но надо бы получше да поглубже понять “базу”
- Изучил вроде “базу”, ага, вот и новый инструмент/фреймворк/библиотека/подход — надо срочно применять это в проекте и вообще переписать все
- Рефакторинг, рефакторинг и еще...
- Так надо понимать какую задачу решаем...
- И напилить свое решение, ведь я могу-умею !
- Вот я Middle
- Так есть нюансы и тут и там, задача про одно вроде бы, а оно выходит про другое если разобраться...
- А вообще-то можно и переиспользовать что-то, зачем с нуля то писать
- Вон у меня сколько наработок уже
- Рефакторинг, рефакторинг и еще...
- А вообще-то уже есть решенные давно задачи и под них проверенные временем инструменты/фреймворки/библиотеки/подходы
- Ну и как бы клиенту хорошо бы объяснить что так не надо, а так вот надо
- Вот я Senior
- Безопасность кода, многопоточность, сложность алгоритмов, CAP теорема (сделай свой выбор...), графы… графы, масштабирование и высокие нагрузки, инвалидация кэша (чтоб ее), AWS,Azure,GCE, SQL vs NoSQL (ну уже понимаем — какую задачу решаем от того и..), второй+ язык программирования (другие парадигмы полезны) и.т.д
- Ну и что, что долго, зато бизнес выиграет от этой реализации столько-то
- Ну и что что не по фен шую, зато быстро и бизнес выиграет от этой реализации столько-то
- Так, ну надо в Team Leader-ы двигаться же, ведь там я буду...
Вот. И что я там буду то? Что делает TL?
Стоп. Спокойно, вообще-то, люди говорят такое:
- “TL вот знает как надо в техническом плане лучше других”. Хм… а кто тогда такой Senior ?
- “TL проектирует архитектуру проектов/продуктов и вообще у него есть вИдение проекта в целом”. Хм… а кто тогда такой Архитектор ?
- “TL же распределить может задачи по проекту/проектам и контролировать их выполнение и все такое”. Хм… а кто тогда такой PM ?
- “TL разрабатывает стратегию команды/отдела, мотивирует команду, создает настрой и задает эмоциональный фон команды, договаривается о конференциях с руководством и.т.д”. Хм… а кто тогда такой руководитель отдела ?
Это список конечно можно и продолжать, но думаю вы понимаете куда я клоню.
Плюс к этому все что я слышал от действующих TL, так это в целом что-то такое:
- “Ну да, я уже пишу код только 60-70% времени, потому что еще дела отдела всякие...”
- “Ага, почти вообще не прогаю, надо там проконтролировать, тут договорится, там помочь...”
- “Пишу код 10-15% времени, остальное это подготовка к ивентам и конференциям, по верхам изучаю новые темы, так сказать вширь росту короче, плюс надо всякими согласованиями заниматься, вроде отпусков, работы из дома и.т.д”
И этот список можно продолжать, но суть думаю также ясна.
Итого, выходит так, что TL как то занимается всем понемногу, но при этом четкого движения в какую-то сторону и нет. Оттачивание навыков в какой-то специализации или технологии также не происходит, но при этом расфокусировка и неизбежно сопровождающий ее стресс явно должен присутствовать при таком положении дел.
Отсюда получается что TL:
- Не Архитектор (мало времени уделяется теме проектирования, изучению построения инфраструктуры проекта/проектов, применению облаков и различных сервисов и инструментов и.т.д)
- Не PM (мало или вообще нет, общения с клиентами/заказчиками, ответственности за сроки, качество продукта/проекта и бюджет)
- Не Senior разработчик (мало времени уделяется написанию кода, погружению в технические глубины и “оттачиванию мастерства”)
- Не Руководитель отдела (так как над ним, обычно уже есть такой, а если и нет, то почти всегда TL сам не может ни увольнять, ни принимать, ни увеличивать/уменьшать (о ужас) зарплату, ни самолично принимать стратегические решения влияющие на бизнес компании и.т.д)
Мда… картина не очень как то. Но я не жаловаться тут собираюсь, а наоборот, рассуждая прийти к некому решению (хочется в это верить).
Итак, до этого я рассуждал о TL со стороны разработчика, который движется к коммунизму к светлой и прекрасной должности/роли TL, а теперь давайте посмотрим на это газами собственника бизнеса.
(!) Все события и герои вымышлены. Любые совпадения с реальными личностями случайны.
Итак, у собственника бизнеса есть прекрасный Senior разработчик — Евпсихий, который:
- делает Х фич в единицу времени, без багов (ух ты!)
- или делает Х, оплачиваемых заказчиком, часов в единицу времени (актуально для аутсорса)
Но вот Евпсихий принял решения двигаться дальше (так он думал) в TL, ведь это тот самый путь самурая, ведущий к просветлению! (да, так он думал).
Собственник — Акакий, не желая потерять такого комсомольца, спортсмена и просто хорошего специалиста, награждает Евпсихия должностью Team Leader-а и делает официальное объявление по всей Компании.
Занавес.
Евпсихий счастлив и горд, поэтому с радостью принимается за дела, в новом для себя и своих коллег, обличии.
Через какое-то непродолжительное время, собственник Акакий, просматривая очередные показатели в отчетах по компании видит следующую картину по TL Евпсихию, а именно тот теперь:
- делает Х-((от 10 до 100%)от X) фич в единицу времени и не всегда без багов (а раньше было без...)
- или делает Х-((от 10 до 100%)от X), оплачиваемых заказчиком, часов в единицу времени (а для аутсорса это прямое уменьшение дохода)
“Так...” — задумывается Акакий, и где-то в глубине своей предпринимательской души, уже начинает осознавать, что по части показателей так теперь будет продолжаться и дальше. И более того, TL Евпсихий, через +- пол годика нагрянет к нему с требованиями (даже не просьбами) о повышении уровня мотивации, размахивая аргументами о своей сверхзанятости и работой с людьми, и повышенным уровнем стресса и.т.д.
“?*&%#@” — говорит сам себе Акакий и прихватив папку с какими-то документами, под тяжестью пульсирующих мыслей, удаляется из своего просторного кабинета в скромный пентхаус на 22-ом этаже.
Антракт
Конечно после антракта есть как минимум второй акт, который включает в себя такие сцены как:
- Факапы в команде случаются, а кто все таки ответственный? TL говорит что у него нет “рычагов” для влияния на команду и вообще есть Руководитель отдела, поэтому какие к нему вопросы то, а еще команда “слабая”, и он бы таких не принял в команду, ну и что нужно взять сильных да лучших. Ну а бизнес говорит TL-у что: “… все же идет от продаж и пока что надо учится работать со специалистами вот такого уровня, но это и плюс и Твой челендж, так как Ты, как TL можешь прокачивать свои навыки кураторства/наставничества/менторства, а также оптимизировать работы таким образом, чтобы делать лучше, быстрее и.т.д...”
- Добавилось у TL административной работы, но бизнес почему-то не устраивает уменьшение процента написания кода TL, а еще надо подавать отчеты о том, что это за такие внутренние активности для команды проводились, вместо того чтобы решать задачи бизнеса, а еще надо объяснять бизнесу чем именно вот эта конференция важна для членов команды (вот же...)
- Ну и надо же процесс Performance Review выстроить у своей команды, чтобы росли же, но как мерять так чтобы оно связано было с теми самыми продажами, ведь “… все же идет от продаж и...”? (голос бизнеса в голове у TL)
- “У вас процессы — *авно !” — говорит TL на очередном митинге своему Руководителю, а тот ему апеллирует “… Евпсихий, будет тебе, пойми, все же идет от...”
В конечном счете TL начинает медленно (а может и быстро), но уверенно перегорать, не понимая что происходит, куда он движется и как так вообще можно, а собственнику надо думать как выходить из такой ситуации. Но бизнес есть бизнес и ситуация в принципе не такая и безнадежная, а даже вполне себе решаемая.
Как ?
В итоге, я для себя понимаю так, что роль/должность Team Leader, полезная и даже необходимая на определенных этапах развития как сотрудника так и бизнеса, но при этом, она, как бы промежуточная, после чего, как сотруднику так и бизнесу, нужно все таки выбрать вектор движения и уже следовать ему. Поэтому то самое решение, о котором я писал выше, может быть реализовано, например, следующими довольно банальными путями:
TL должен выбрать куда двигаться из следующих, действительно необходимых, бизнесу должностей/ролей:
- Стать Архитектором и взять на себя ответственность о принятых архитектурных решениях, углубляться в сторону способов реализации тех или иных архитектурных и инфраструктурных решений при этом понимая ожидания и задачи бизнеса
- Стать PM-ом и взять на себя ответственность за сроки, качество и бюджет проектов/продуктов, за лояльность заказчиков/клиентов и правильную коммуникацию со всеми заинтересованными лицами
- Вернуться в Senior-ы и продолжать нести ответственность за производимый результат по поставленным задачам, а также оттачивать свои знания, углубляясь в техническую сторону своей специализации
- Стать Руководителем отдела и взять на себя ответственность за формирование команды, эффективность работы отдела в целом (в том числе метрики экономического характера), стратегию развития отдела, формирование четких, понятных и масштабируемых процессов отдела и.т.д
Можно заметить что в решении выше, в каждом из пунктов, фигурирует слово ответственность и это неспроста. Собственнику в обязательном порядке необходимо четко зафиксировать ответственность для каждой из ролей/должностей выше, которые в таком же обязательном порядке должны быть завязаны на экономические показатели бизнеса. Тогда и Performance Review станет понятен и люди взявшие на себя описанные выше роли/должности будут понимать что они делают, как и чем за это отвечают и что, и при каких условиях им за это полагается.
В окончании хочу подчеркнуть что вышеизложенное это конечно же мое субъективное мнение, которое, тем не менее, подкреплено жизненным опытом, а также не руководство к действию ибо является всего лишь вершиной того айсберга, который именуется “Успешная Карьера для одних и Бизнес для других”.
Комментарии (51)
kruslan
18.02.2018 22:04Перечитал 2 раза. Поток мыслей, никак не связанных с реальностью.
TL — это управление разработчиками, если упрощенно. Его задача — поднять производительность разработчиков. Если у TL кода на 50% меньше, но у 5 подчиненных по +10% — это уже не плохо, верно? Ведь к этому, разруливается куча другой работы. А если по +15-20? Вот именно за это и готов платить бизнес.
Ну а если TL не увеличивает производительность команды — это просто плохой TL.
P.S.: повышение производительности — это не увеличение написанного кода, это увеличение решенных бизнес задач. Иногда за счет упрощения после PM, иногда за счет улучшения архитектуры после Архитектора, иногда за счет отказа от задач после руководителей, если эти задачи отнимут ресурсы, но не принесут результаты или если эти задачи можно реализовать намного проще, пусть и с ограниченным функционалом.
TL — человек, который стоит на страже, не допуская плохие таски до разработчиков и не выпуская от разработчиков плохой код. Чем лучше становится этот процесс — тем лучше для всех.
P.S.S.: и да, стресс у TL намного выше, чем у любого разработчика.
KoCMoHaBT61
18.02.2018 22:51Повышение производительности это не увеличение решённых бизнес-задач, а приведение в соответствие производительности команды и спускаемых сверху формальных параметров.
И «недопущение плохих тасков» до разработчиков это не задача тимлида. Задача тимлида в том, чтобы у разработчика с плохой таской производительность по формальным параметрам не просела.
А код…
Код и производительность у тимлида контролировать нежелательно, иначе есть тенденция тимлида уменьшать себе нагрузку путём выборки из бэклога «хороших тасков».
overall Автор
19.02.2018 06:54Спасибо за развернутый комментарий, но к сожалению этот поток мыслей у меня лично связан с реальностью. При этом я полностью с вами согласен, насчет того что TL увеличивает производительность команды или отдельных ее членов. Но вместе с тем у меня вопрос и к вам и вообще:
— почему заниматься наставничеством не может Senior или группа Senior-ов?
За это ведь тоже готов платить бизнес, верно?
Что же касается фильтра от «плохих задач», то тут тоже вопрос, разве PM не должен их фильтровать?
Плюс к этому задачи, идущие от бизнеса, могут быть непонятны TL(так как он еще не там в полной мере) и TL может принять неверное решение о том, что задача «плохая», при этом тратя время на доказывания своей позиции.
Daniil1979
19.02.2018 09:13-1Бизнес готов платить разработчику за наставничество над другими разработчиками??? О_О Это где Вы такой бизнес нашли? Киньте ссылки, пожалуйста.
overall Автор
19.02.2018 09:34Да вобщем-то много где, ивенты и подтягивание на проекте по гайдам, подходам проектирования, пониманию что такое рефакторинг и когда оно действительно нужно и.т.д «молодых»,- за это вот все у меня и у многих моих друзей и знакомых из зарплаты не срезают, а иногда наоборот даже) Если у вас не так, то наверное надо как минимум задуматься.
Singaporian
19.02.2018 10:43Я сейчас захлебнулся от негодования. Наставничество, если оно грамотное, дает повышение уровня результатов труда целой команды, что в конечной точке выливается в дополнительные деньги. Это как раз то, что [здоровому] бизнесу интересно.
Как вообще вы могли в просветленном 2018-м году предположить подобное?
kruslan
19.02.2018 13:21почему заниматься наставничеством не может Senior или группа Senior-ов?
1. Работа сеньора — код. Если он занимается чем-то другим — ему платят лишнее.
2. «Наставничество» — это далеко от кода и совсем не каждый «сеньор» с этим справится ;)
За это ведь тоже готов платить бизнес, верно?
Да, если это является задачей бизнеса и нет, если сеньор занимается этим вместо своих прямых обязанностей.
Что же касается фильтра от «плохих задач», то тут тоже вопрос, разве PM не должен их фильтровать?
А что вы подразумеваете под «плохими задачами»? Я говорил про такие, реализация которых отнимет много времени: плохо описанные, например.
Плюс к этому задачи, идущие от бизнеса, могут быть непонятны TL(так как он еще не там в полной мере) и TL может принять неверное решение о том, что задача «плохая», при этом тратя время на доказывания своей позиции.
И это нормально. TL отвественнен за команду, потеря времени на отстаивание интересов команды — важная часть работы TL.
Chelyuk
19.02.2018 13:47Поддерживаю, хочу только еще добавить, что далеко не каждый программист(даже senior) поговорив с "бизнесом" поймет задачу, важность и зачем она нужна бизнесу. TL должен кроме прочего выступать связующим звеном, которое сможет выслушать/вычитать "поток сознания" бизнеса(менеджеров), переварить это дело, разобрать как его лучше сделать или может вообще лучше не делать или поменять местами порядок выполнения задач, что сократит "критический путь" достижения цели и изложить уже в понятной техническим людям(разработчикам) форме. Грубо говоря он должен защищать команду от менеджеров и давать им комфортно работать и выступать переводчиком с бизнес языка на технический язык.
p909
19.02.2018 14:34Обычно таким занимается аналитик
Chelyuk
19.02.2018 15:08Аналитик в лучшем случае сможет преобразовать объяснения бизнеса в технически поставленную задачу. Прояснить связи между задачами и расставить технические зависимости сможет разве что аналитик с очень хорошим опытом в разработке.
Мне доводится весьма нередко после аналитиков, задавать уточняющие вопросы по Acceptance Criteria, выправлять критерии которые невозможно измерить, указывать что новая story конфликтует с другой иногда уже закрытой пару лет назад. Указывать что в коде присутсвуют workaround, которые когда-то задолго до подключения к проекту закостыляла другая команда, а новый функционал делает этот workaround в дальнейшем безсмысленным и неплохо бы добавить sub-task на рефакторинг с его удалением.
Короче говоря, в контексте Scrum, Lead оценивает постановку задачи в user story и помогает ее разбить на sub-tasks. При высоком уровне зрелости каждого члена команды разработчики/тестировщики, Lead может быть и не нужен. Но по-моему опыту и исследованию знакомого психолога, большинство програмистов интраверты и не любят общаться с не техническими людьми. Вот те немногие программисты экстраверты, которые находят контакты с менеждментом и отлично подходят на роль лида, и они общаются за своих колег которые не хотят/могут построить это общение продуктивно.
africaunite
18.02.2018 22:36А можно я Вам проще попытаюсь объяснить? Вы же программист, вот представьте себе, что у вас в программе функции будут переживать за свое название и место, а не за смысл.
Я к тому, что и тут — в каждой нормальной системе будет своя иерархия и набор ролей, в соответствии со здравомыслием, а не по КЗОТ (тем более, что и не прописаны такие должности свыше или в законах). Предложите начальству роль, в которой вы будете стараться мотивировать и защищать создателей, взвешивать решения (обычно архитектурные) и быть переводчиком и громоотводом для получателей. Или выберите набор по вкусу. А как оно такую роль-должность назовет — это дело третье. Лишь бы оно было нужно.africaunite
18.02.2018 22:44А впрочем, Вы и сами к этому почти пришли. К понятию ответственности.
overall Автор
19.02.2018 07:08Спасибо за хорошую аналогию, да все так, потому и написал что, вроде как по здравому смыслу и если говорить о бизнесе, т.е. получение прибыли после вычета расходов, то надо чтобы все роли были понятны и максимально задействованы в той самой получении прибыли, а иначе какой же тогда бизнес.
Alesh
19.02.2018 01:14+1Извините, но редкостный бред)
overall Автор
19.02.2018 07:01И на том спасибо)
Знаете, мне вот, например, нравятся труды Клиффорда Саймака и Ивана Ефремова, но мой друг в целом считает, что они какой-то бред пишут, а вот Джон Толкин — наше все. Поэтому, на вкус и цвет...)Alesh
21.02.2018 20:24Могу пояснить. в чем проблема со вкусом и цветом.
Вы определяете понятие TeamLead как некую непонятную ступень карьеры после ступени Senior Develop, что неверно. В повествовании присутствует начальник отдела. Какого отдела? Если отдела разработки ПО, то у вас не АйТи фирма и понятие TeamLead не применимо. Потому-что тим у вас одна и ей уже есть кому руководить. И описываемая ситуация как раз в таких конторах часто происходит. Начальник отдела хочет поощрить, поднять статус своего ведущего разработчика (если уж есть начальник отдела, то обойдемся без синьора)), а заодно и скинуть на него часть своих обязанностей. Да это как раз что вы описываете в начале, но это никакого отношения не имеет к роли TeamLead. Понимаете о чем я?
Alex_At_Net
19.02.2018 05:011) Большинство проблем которые описаны в статье возникли, похоже, от того, что должности team leader не было в организации.
2) Представление, что team lead — следующая ступень за senior developer/engineer — ошибочно.overall Автор
19.02.2018 07:05В компании была и есть должности TL, но вот понимание у каждого свое. И я как раз ни в коем разе не думаю и уж тем более не утверждаю, что TL это следующая ступень, просто так действительно многие думают, особенно в начале карьеры.
Singaporian
19.02.2018 10:47Не совсем. После senior'а хочется двигаться дальше. Те, кого прет от техники — двигаются в архитекторы. Кого от управления — в TL, а оттуда, если повезет, в PM (иерархическая позиция которого намного выше, чем обозначено в статье, так как он под собой «имеет» еще QA-шников, архитектора, бизнес-аналитиков и т.д.).
kruslan
19.02.2018 13:25Уверен, что вы ошибаетесь. Из отличных разработчиков, чаще всего, получаются отвратительные PM-ы. PM — это не ступень развития айтишника, это совсем другая область.
kozzztik
19.02.2018 14:37Развитие TL — директор департамента. PM никак не намного выше — это позиции одного уровня. В некоторых компаниях они даже совмещены, например в схеме «two in the box».
mad_nazgul
19.02.2018 06:52Все по принципу Питера. :-)
P.S. Почему ТС считает, что архитектор, team lider, PM лучше чем Senior Developer?
Мне кажется это разные виды деятельности.
Хороший Developer может стоить дороже посредственного архитектора или PM :-)
sshmakov
19.02.2018 08:35На самом деле всё проще. Team leader нужен для упрощения управления, чтобы руководитель отдела и менеджер проекта общались с меньшим количеством людей.
Пример, приведённый в статье, эту задачу не решал.
imgen
19.02.2018 12:26не только для руководства, лиды фильтруют всю входящую и исходящую информацию в задачах, налаживают взаимоотношение между отделами, организуют встречи и занимаются прочей бюрократией. Тем самым освобождая время разработчика, но он может в том числе и делегировать свою работу на команду, тогда команда будет больше в бюрократии и меньше в коде. Всё зависит от самого лида, одни создают больше условий для команды, но мало пишут или занимаются исключительно ядром/структурой проекта. Другие не пишут, но решают или стараются решать все вопросы по бумажкам. Оба подхода работают
overall Автор
19.02.2018 14:46imgen, kruslan
Я вот наблюдаю подход, когда группа Senior разработчиков в команде и PM-ом со стороны бизнеса:
— фильтрует все как нужно и никаких «плохих» задач. Про плохо описанные, тоже вопрос, что это значит? если это все же Senior, то он вполне себе в состоянии понять задачи бизнеса и дописать задачу техническими деталями, так чтобы было понятно и Middl-у.
— между отделами, зафиксированы в задачах, — четкие критерии приемки что и когда и от кого и кто ожидает, в том числе не технические (ну про формат API даже писать не хотел)
— встречи, т.е. стэндап митинги, демонстрации, ретроспективы и.т.д., также регламентированы и налажены в ходе работы
— ну а прочую бюрократию делят между собой Руководитель отдела, PM, HR, даже техно-PR (есть такой по ивентам и конференциям в том числе)
И такой подход тоже таки себе работает, плюс при этом всем понятно в какую зону ответсвенности можно перейти и надо ли.
Про то, что не каждый Senior справиться с бизнес-требованиями и с наставничеством, то просто может мы про разных Senior говорим. Я вот, например, про тех кому в среднем по больнице 30+ лет(ну 27+), потому как есть тогда, какой-никакой, жизненный опыт и по специальности 7+ лет опыта.imgen
19.02.2018 14:51Не всегда и всё работает шаблонам и по книжечкам, у нас есть Лиды, есть Аналитика, но нет PM и часть его работы делится между всеми участниками этой цепочки.
overall Автор
19.02.2018 14:59Конечно не всегда, но так может надо что-то предпринять, ну или у вас всем нравиться делать еще что-то кроме своей основной работы. А кстати если у вас делится между всеми роль PM, то если вдруг проект выполнен не в сроки/не в бюджет/с ненадлежащим качеством, то кто виноват и что делать?
imgen
19.02.2018 15:26Есть система штрафов, по которой всех сверху вниз наказывают, после пары наказаний всё встаёт на свои места. Сперва конечно был бардак, все разосрались, но некоторое время спустя всё само собой организовалось и ответственность рассосалась между всеми участниками. Пмов нет еще и по причине того, что заказчиком выступает Product Owner.
kruslan
19.02.2018 17:56Про плохо описанные, тоже вопрос, что это значит?
Это значит, что PM/аналитик описали не достаточно входных данных, например. Ну вот жизненный пример (упрощенный): задача от PM «сделать A/B-тест формы обратной связи». А какую именно метрику, почему эту метрику, характеристики и пр — отсутствуют. Плохой TL/хороший сеньор начнет разбираться, допытывать PM/аналитика, потратит кучу времени и сил, как своих, так и своего руководителя/подчиненных/PM/аналитика/etc… Хороший — вернет задачу PM-у/аналитику и возьмет другие бизнес-задачи, которые можно решать прямо сейчас. Тем самым — поднимет производительность своей команды. Как-то так ;)
Про то, что не каждый Senior справиться с бизнес-требованиями и с наставничеством, то просто может мы про разных Senior говорим. Я вот, например, про тех кому в среднем по больнице 30+ лет(ну 27+), потому как есть тогда, какой-никакой, жизненный опыт и по специальности 7+ лет опыта.
Не, говорим про одних и тех-же. Просто кому-то дано учить и он может из мидла сделать сеньора, а кто-то из джуна не сможет мидла сделать. Здесь проблема не в опыте, а во внутреннем расположении к обучению других.overall Автор
19.02.2018 18:25kruslan
Вот об этом и речь, что хороший, действительно хороший, Senior, также отфильтрует и распишет тех.детали по «плохим» задачам и тем самым, как Вы и написали, «поднимет производительность своей команды».
Но, все же, я думаю проблема, по большей части, в опыте, не зря ведь народ говорит — «Все приходит с опытом», коллега)kruslan
19.02.2018 18:32Вот об этом и речь, что хороший, действительно хороший, Senior, также отфильтрует и распишет тех.детали по «плохим» задачам и тем самым, как Вы и написали, «поднимет производительность своей команды».
Возможно мы о разных вещах говорим, но работа хорошего сеньора — код. Он не имеет права вернуть задачу PM-у, например.
Давайте для простоты (мое видение): pm видит проблему/улучшение/etc — выдает требования, tl получает требования — выдает задачу, разработчик получает задачу — выдает код. Не может (или не должен, кому как приятнее) разработчик уточнять требования или вносить в задачу изменения по своему усмотрению — он не знает дальнейшего видения/развития этой задачи.
Исходя из этого, сеньор, который «также отфильтрует и распишет тех.детали» — плохой сеньор, который тормозит работу команды.overall Автор
19.02.2018 18:43kruslan
Ну тут не могу с Вами согласиться, так как рассуждения слишком утопичны и скорее для мира роботов. Так, например, давайте затронем процесс в семье — тот еще проект/продукт, знаете ли)
Так вот, по Вашей логике и моей интерпретации получаем:
— Жена — ходила беременная и потом еще рожала (а-ля PM)
— Теща/Мама Жены — получает готового ребенка и «бизенс-задачи»от новоиспеченной мамы (а-ля TL)
— Муж — получает готового ребенка и какие-то задачи.
НО — вникать Мужу как раз таки надо, а то реализуется там что то такое, в чем потом его, Мужа, и обвинят)
Так что, почему таки Senior, если видит что и почему в задаче не так, не может это донести PM-у, мне вот не понятно. Зачем же это еще и транслировать через TL (чем больше звеньев тем быстрее рвется).kruslan
19.02.2018 19:09Ну тут не могу с Вами согласиться, так как рассуждения слишком утопичны и скорее для мира роботов.
Я и не предлагал соглашаться, лишь рассказал о своем опыте и о своем видении работы тимлидов и сеньоров.
Так, например, давайте затронем процесс в семье — тот еще проект/продукт, знаете ли)
Как отец 2х детей — знаю ;). Ну давайте…
— Жена — ходила беременная и потом еще рожала (а-ля PM)
Хм… Ну допустим, хотя уже не согласен с вашим видением.
— Теща/Мама Жены — получает готового ребенка и «бизенс-задачи»от новоиспеченной мамы (а-ля TL)
Стоп-стоп-стоп… В вашем примере, TL получает «продукт»? Ни требования, ни задачи, ни условия — именно «продукт»? Что-то тут не так)
НО — вникать Мужу как раз таки надо, а то реализуется там что то такое, в чем потом его, Мужа, и обвинят)
Ну так в вашем примере Муж === TL, а не сеньор. Сеньоров выступит производитель питания, одежды и пр. И тогда схема абсолютно полностью совпадает с моей:
1. PM (Мама) ставит требования: купить детское питание, купить памперсы.
2. Папа (TL) формализует задачу, выбирает исполнителя — конкретных производителей питания и памперсов. Причем, выбирает исходя из имеющихся ресурсов — кто-то может купить самого производителя, кто-то только его продукт ;)
Как видите, сеньор не влияет на продукт, он только покрывает бизнес-требования.
ак что, почему таки Senior, если видит что и почему в задаче не так, не может это донести PM-у, мне вот не понятно.
Если он видит, что в задаче что-то не так — он должен донести это тимлиду, а не PM-у. На то есть несколько причин:
1. Сеньор может не знать, что задача разбита на несколько более мелких задач и ему досталась именно одна из частей. А в сумме эти микро-задачи могут решать какую-то масштабную задачу, какое-то новое направление.
2. Сеньор мог не верно понять задачу и проблема не в самой задаче, а в плохом описании от TL, например.
3. Даже если сеньор что-то решит с PM-ом, последнему придется согласовывать это с TL, т.к. именно последний распределяет нагрузку, расчитывает время и стоимость каждой задачи и пр.
PS: везде, где я работал, всегда было основное правило — после того как таск выдан разработчику, таск не может быть изменен. Причин много — от оценки времени до фактических затрат. Повлиять на это всегда мог только TL и тогда отвественность за срыв сроков/затрат/etc была только на нем. PM-ы/аналитики/руководители отделов и всей компании никогда не могли ничего менять в процессе разработки. Очень странно слышать, что где-то сеньор может взять и поломать весь план на неделю/месяц/год…overall Автор
19.02.2018 19:30Стоп-стоп-стоп… В вашем примере, TL получает «продукт»? Ни требования, ни задачи, ни условия — именно «продукт»? Что-то тут не так)
Ну какой-же это продукт-то, новорожденный) Это в лучшем случае MVP и то скорее нет, а как раз таки требования с которыми ой сколько всего еще нужно сделать) Это я как отец троих детей, могу себе позволить авторитетно заявлять)
И далее исполнитель задач, вроде добычи той самой одежды, питания и.т.д. обычно все таки Муж. И тогда схема уже совпадает и с моей)
Но тут то просто аналогия, она про то что хороший Senior если видит и может, то должен сказать что не так, а повлияет или нет это на задачу — решает PM.
По части видения проекта/продукта в целом, ну уж если TL может — то Senior полагаю тоже может понять что за кусочки и в какую бизнес-задачу складываются и решается ли она таким вот образом который предлагается от TL или PM (решает ли проблему бизнеса).
P.S: я и не говорил о том что Senior должен ломать планы и вообще устраивать революцию. Весь мой поток мыслей о том, что, как мне кажется, не всем командам нужен TL, а возможно при четких и формализованных процессах в компании, можно и вовсе без этой роли (но это не точно) )
kruslan
19.02.2018 22:12Ну какой-же это продукт-то, новорожденный) Это в лучшем случае 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 и разбиения отдела на несколько команд — совсем никак. Иначе каждый разработчик будет заниматься кучей вещей, которыми не должен заниматься, тратить свое и чужое время, что отрицательно скажется на производительности, мотивации и финансах, в конце концов, всей команды.
kruslan
19.02.2018 18:33Но, все же, я думаю проблема, по большей части, в опыте, не зря ведь народ говорит — «Все приходит с опытом», коллега)
Уверен, что у меня хватает опыта и в качестве сеньора, и в качестве TL (и в качестве CTO, но это уже за рамками данного поста) ;)
varanio
19.02.2018 09:19Автор как минимум задает правильные вопросы, не надо писать, что это бред и т.д.
Тимлид, на мой взгляд, — это (примерно) зам руководителя. Разруливает, как и руководитель, вопросы почти любого характера. По сути нужен для того, чтобы руководитель не затрахался до смерти.
Однако при этом тимлид на общую стратегию влияет лишь опосредованно, поэтому с выводом в статье более менее согласен, тимлид — неблагодарная должность. Ты как бы и начальник и не начальник (ключевые решения просто так принять не можешь), отсюда батхерт вполне может быть.
К сожалению, должность руководителя отдела разработки — тоже далеко не сахар. Невозможно расслабиться даже ненадолго. Особенно если тимлид так себе ))mad_nazgul
19.02.2018 12:00Судя по вашим словам тимлид не может не быть «так себе».
В противном случае он становится руководителем :-)
andreylartsev
19.02.2018 17:23«Однако при этом тимлид на общую стратегию влияет лишь опосредованно, поэтому с выводом в статье более менее согласен, тимлид — неблагодарная должность. „
Поднимитесь еще на одну ступеньку и почувствуете что эта должность еще более неблагодарная ))) Определенности в обязанностях еще меньше, а конкуренция за позицию неожиданно суровая и т.п.
Dicebot
19.02.2018 14:56Фундаментальная ошибка, как мне кажется — считать, что наличие тим лидв делает что-либо лучше и является самоцелью. По моему опыту горизонтальная иерархия в разработке всегда эффективнее вертикальной, но у неё есть одна существенная проблема — перестаёт работать после определённого размера команды из-за затрат на общение каждого-с-каждым.
И вот именно в этот критический момент роста имеет смысл разбиваться на команды поменьше и заводить тим лидов — чтобы вся социальная система не рухнула под собственным весом. При этом продуктивнее от этого никто не станет, даже наоборот, и хороший руководитель должен это понимать.
В таком контексте единственная ключевая обязанность тим лида — служить точкой обмена информацией между командами, и ничего более. А ключевые навыки — широкое (но не обязательно глубокое) знание всех систем, за которые отвечает команда и умение эффективно организовывать внешнюю информацию для внутреннего потребления.
andreylartsev
19.02.2018 17:55+1По моему все просто — «Team lead» прежде всего менеджер, наверное менеджер самого низкого звена но все же менеджер.
И как у всякого менеджера, его главная обязанность организация совместной деятельности группы людей необходимой для достижения некой цели.
Все остальное является побочными видами деятельности.
Он может быть одновременно разработчиком (или тестером, у тестеров тоже есть Team lead-ы) а может и не быть.
Он может совмещать роль архитектора или может доверить исполнение этой роли кому-то из своей команды.
Может быть самым квалифицированным специалистом своей команды, но это не обязательно.
Может быть самым умным, но если он будет опиратся при принятии решений в том числе на мнение более умных подчиненных, этого не требуется.
Чего он точно не может делать, это уклонятся от решения возникающих на пути к общей цели проблем.
Не может перекладывать отвественность за общие неудачи на другого.
Обязан добится приличной награды для подчиненного который снова сделал невозможное.
Ну а в целом про роль менеджера столько написано что нет смысла пересказывать.
Учите работы классиков и у Вас все получится )overall Автор
19.02.2018 18:19andreylartsev, Dicebot
Да, вы в целом правы, в том числе об этом и статья, что само по себе наличие TL не сделает команду лучше. И также она о том, что можно горизонтально развиваться.
Но опять же, почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи по улучшению команды и отдельных её членов, а также выстраивать коммуникации между отделами, кончено совместно с PM и Руководителем отдела(об этом уже писал выше в комментариях — habrahabr.ru/post/349386/#comment_10677342).
Но для этого как раз и необходим чёткий, формализованный процесс, который, кстати, поможет масштабировать такие команды. А вот масштабировать TL-Чудотворца это скорее фантазии и приемлемо для небольших, по численности департамента разработки, компаний (как найти 50+ крутых TL? а вдруг они не те кем себя называют, а зарплату им наверняка крутую надо платить сразу, а не потом).
Также про TL как менеджера, это, как по мне, тоже такой себе миф, так как у тех самых менеджеров часто есть KPI, завязанный на определенные метрики, т.е. то, что вот прямо можно взять и измерить из недели в неделю, месяца, квартала и.т.д. Поэтому, если у TL, о которых вы говорите, нет таких метрик, влияющих на мотивацию — то нет и ответственности в полной мере, а значит и результат в конце концов будет не в пользу бизнеса. Но если есть такие метрики — то да, ваш TL — менеджер.Dicebot
19.02.2018 18:53почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи
Например, потому что я так не считаю :) Более того, в компании, где я работаю, вообще нет никакого строгого деления на ранги и никакого технического менеджмента, одни лишь только Software Engineer. При этом тим лиды есть, но они все — обычные разработчики, просто с дополнительными обязанностями. Впрочем, когда компания была меньше, не было даже их, и было ещё лучше.
Просто нужно нанимать людей, умеющих принимать решения самостоятельно — и изначально объяснять, что таких решений от них ждут.
overall Автор
19.02.2018 19:03Вот, уже хорошо) Так, а теперь, если не трудно, еще хотелось бы знать, у тех TL, которые есть и у которых какие-то там дополнительные обязанности(какие и почему у них ?), у них есть метрики привязанные к зарплате(выше писал)?
Dicebot
19.02.2018 21:58какие
1) Быть контактным лицом, если кому-то что-то нужно от этой команды
2) Раз в неделю собираться на митинг тим лидов и озвучивать там важные для команды темы (и потом транслировать обратно результат)
почему у них
Потому что кому-то надо это делать :) Существенного влияния на зарплату это не оказывает.
у них есть метрики привязанные к зарплате
Нет, у программистов не существует никаких метрик. Но после больших факапов руководство может прислать грустный мейл о том, сколько это стоило компании и человеку будет очень стыдно :)
AlexSoff
20.02.2018 15:05Вопросы поставлены правильные. Я сам их себе задавал, когда получал эту должность в разных организациях… первые два раза. :) Потом нашел ответ — он тривиален.
Суть должности Team Leader именно в том, как она называется. Дословно!
И это вообще не должность производственной структуры (скорее реверанс бизнеса в сторону программистов), и потому, у нее нет никаких «рычагов и полномочий» от руководства.
Если человек является по факту «лидером команды» — у него есть связанные с этим возможности. Не является — извините…
Поэтому должность Team Leader всегда совместительная. С Senior, PM или начальником отдела (лучше всего с Senior — меньше внутренних противоречий). Отсюда и путанница в обязанностях, «обязанности» — это по линии производственной структуры.
В чем-то Team Leader близок к профсоюзному лидеру (из тех областей, где профсоюзы реально работают), так же не дает официальной должности и так же опирается на личный авторитет. Просто IT такая отрасль, в которой бизнес без поддержки коллектива просто не может обойтись и бизнесу пришлось создать эту роль самому. Не дожидаясь…
Назначение человека TL может означать две вещи:
1. Признание сложившихся фактов.
2. Карт-бланш на формирование своей команды.
Иногда, первое и второе в смеси.
Почему удобнее всего совмещение с Senior? Потому, что TL всегда на стороне интересов команды! Даже когда уговаривает эту команду согласиться с требованиями бизнеса. Просто он видит ситуацию дальше и с большим количеством деталей. (Кроме того, когда он уговаривает бизнес признать требования команды, это обычно никто посторонний не видит.)
Хотя есть исключение — если речь идет о формировании команды под себя, лучше это делать совмещая с начальником отдела. (Правда потом это вызовет много сложностей. И лучше красиво сделать рокировку.)overall Автор
21.02.2018 07:45Спасибо за развернутый комментарий, в принципе об это и речь, а именно «быть или не быть» )
BlackSCORPION
21.02.2018 20:42Team lead это лидер комманды разработчиков. У любой комманды должен быть лидер, тот за кем последнее слово в решениях касающихся процессов разработки.
Плюс разработка плохо совмещается с другими тасками, и как правило КПД растет когда есть лид который разруливает все административные таски позволяя разработчикам сосредоточится на задаче, который знает каждого и подготавливает им задачи по душе. Который знает кто за что отвечает к кому идти по тому или иному вопросу итд. А еще он отличный специалист и всегда готов помочь советом когда разработчик зашел в тупик или ему трудно принять решение.overall Автор
21.02.2018 20:49Я и не против лидера, но почему он именно обязан быть 100%(выше уже, в принципе, договорились что не обязан, но так, якобы проще).Также последнее слово, например, может и быть у него (хотя тоже спорно), но тогда какова ответственность за то самое слово? Выше как раз некоторое писали что если что, то «будет стыдно», но это в детском саду такой уровень ответственности, а не у взрослых людей.
musuk
Вам нужно сначала определить, какие обязанности у роли Team Leader. И тогда всё встанет на свои места. Вот очень хорошая статья про это: habrahabr.ru/post/293334
overall Автор
Спасибо, прочитал статью но кроме обязанностей и общей ответственности еще бы и осязаемую ответственность определить. В статье описано за что в целом может быть ответственен TL/CL, но что будет ему если он не справился с ответственностью? Например у менеджеров по продажам обычно минимальный оклад и потом только бонус от продаж — все понятно и честно. А тут, то что я обычно наблюдаю — «это не я дурак, а вот люди не такие, процессы не такие, времени мало, стресса много и.т.д.».
Поэтому лично я готов нести ответственность за четко определенные зоны, но при этом и другие должны, ведь тогда и мотивация приобретает другой оборот.