Comments 53
Поэтому лично я готов нести ответственность за четко определенные зоны, но при этом и другие должны, ведь тогда и мотивация приобретает другой оборот.
И «недопущение плохих тасков» до разработчиков это не задача тимлида. Задача тимлида в том, чтобы у разработчика с плохой таской производительность по формальным параметрам не просела.
А код…
Код и производительность у тимлида контролировать нежелательно, иначе есть тенденция тимлида уменьшать себе нагрузку путём выборки из бэклога «хороших тасков».
— почему заниматься наставничеством не может Senior или группа Senior-ов?
За это ведь тоже готов платить бизнес, верно?
Что же касается фильтра от «плохих задач», то тут тоже вопрос, разве PM не должен их фильтровать?
Плюс к этому задачи, идущие от бизнеса, могут быть непонятны TL(так как он еще не там в полной мере) и TL может принять неверное решение о том, что задача «плохая», при этом тратя время на доказывания своей позиции.
Бизнес готов платить разработчику за наставничество над другими разработчиками??? О_О Это где Вы такой бизнес нашли? Киньте ссылки, пожалуйста.
Как вообще вы могли в просветленном 2018-м году предположить подобное?
Поддерживаю, хочу только еще добавить, что далеко не каждый программист(даже senior) поговорив с "бизнесом" поймет задачу, важность и зачем она нужна бизнесу. TL должен кроме прочего выступать связующим звеном, которое сможет выслушать/вычитать "поток сознания" бизнеса(менеджеров), переварить это дело, разобрать как его лучше сделать или может вообще лучше не делать или поменять местами порядок выполнения задач, что сократит "критический путь" достижения цели и изложить уже в понятной техническим людям(разработчикам) форме. Грубо говоря он должен защищать команду от менеджеров и давать им комфортно работать и выступать переводчиком с бизнес языка на технический язык.
Аналитик в лучшем случае сможет преобразовать объяснения бизнеса в технически поставленную задачу. Прояснить связи между задачами и расставить технические зависимости сможет разве что аналитик с очень хорошим опытом в разработке.
Мне доводится весьма нередко после аналитиков, задавать уточняющие вопросы по Acceptance Criteria, выправлять критерии которые невозможно измерить, указывать что новая story конфликтует с другой иногда уже закрытой пару лет назад. Указывать что в коде присутсвуют workaround, которые когда-то задолго до подключения к проекту закостыляла другая команда, а новый функционал делает этот workaround в дальнейшем безсмысленным и неплохо бы добавить sub-task на рефакторинг с его удалением.
Короче говоря, в контексте Scrum, Lead оценивает постановку задачи в user story и помогает ее разбить на sub-tasks. При высоком уровне зрелости каждого члена команды разработчики/тестировщики, Lead может быть и не нужен. Но по-моему опыту и исследованию знакомого психолога, большинство програмистов интраверты и не любят общаться с не техническими людьми. Вот те немногие программисты экстраверты, которые находят контакты с менеждментом и отлично подходят на роль лида, и они общаются за своих колег которые не хотят/могут построить это общение продуктивно.
А можно я Вам проще попытаюсь объяснить? Вы же программист, вот представьте себе, что у вас в программе функции будут переживать за свое название и место, а не за смысл.
Я к тому, что и тут — в каждой нормальной системе будет своя иерархия и набор ролей, в соответствии со здравомыслием, а не по КЗОТ (тем более, что и не прописаны такие должности свыше или в законах). Предложите начальству роль, в которой вы будете стараться мотивировать и защищать создателей, взвешивать решения (обычно архитектурные) и быть переводчиком и громоотводом для получателей. Или выберите набор по вкусу. А как оно такую роль-должность назовет — это дело третье. Лишь бы оно было нужно.
Знаете, мне вот, например, нравятся труды Клиффорда Саймака и Ивана Ефремова, но мой друг в целом считает, что они какой-то бред пишут, а вот Джон Толкин — наше все. Поэтому, на вкус и цвет...)
Вы определяете понятие TeamLead как некую непонятную ступень карьеры после ступени Senior Develop, что неверно. В повествовании присутствует начальник отдела. Какого отдела? Если отдела разработки ПО, то у вас не АйТи фирма и понятие TeamLead не применимо. Потому-что тим у вас одна и ей уже есть кому руководить. И описываемая ситуация как раз в таких конторах часто происходит. Начальник отдела хочет поощрить, поднять статус своего ведущего разработчика (если уж есть начальник отдела, то обойдемся без синьора)), а заодно и скинуть на него часть своих обязанностей. Да это как раз что вы описываете в начале, но это никакого отношения не имеет к роли TeamLead. Понимаете о чем я?
Вы определяете понятие TeamLead как некую непонятную ступень карьеры после ступени Senior Develop, что неверно.
Я как раз не определяю, а наоборот пишу о том что, по моему мнению, это не верно, и что многие(по крайней мере в моей практике) думают что это следующая ступень.
Поэтому, да, конечно я понимаю о чем Вы.
1) Большинство проблем которые описаны в статье возникли, похоже, от того, что должности team leader не было в организации.
2) Представление, что team lead — следующая ступень за senior developer/engineer — ошибочно.
P.S. Почему ТС считает, что архитектор, team lider, PM лучше чем Senior Developer?
Мне кажется это разные виды деятельности.
Хороший Developer может стоить дороже посредственного архитектора или PM :-)
На самом деле всё проще. Team leader нужен для упрощения управления, чтобы руководитель отдела и менеджер проекта общались с меньшим количеством людей.
Пример, приведённый в статье, эту задачу не решал.
Я вот наблюдаю подход, когда группа Senior разработчиков в команде и PM-ом со стороны бизнеса:
— фильтрует все как нужно и никаких «плохих» задач. Про плохо описанные, тоже вопрос, что это значит? если это все же Senior, то он вполне себе в состоянии понять задачи бизнеса и дописать задачу техническими деталями, так чтобы было понятно и Middl-у.
— между отделами, зафиксированы в задачах, — четкие критерии приемки что и когда и от кого и кто ожидает, в том числе не технические (
— встречи, т.е. стэндап митинги, демонстрации, ретроспективы и.т.д., также регламентированы и налажены в ходе работы
— ну а прочую бюрократию делят между собой Руководитель отдела, PM, HR, даже техно-PR (есть такой по ивентам и конференциям в том числе)
И такой подход тоже таки себе работает, плюс при этом всем понятно в какую зону ответсвенности можно перейти и надо ли.
Про то, что не каждый Senior справиться с бизнес-требованиями и с наставничеством, то просто может мы про разных Senior говорим. Я вот, например, про тех кому в среднем по больнице 30+ лет(ну 27+), потому как есть тогда, какой-никакой, жизненный опыт и по специальности 7+ лет опыта.
Вот об этом и речь, что хороший, действительно хороший, Senior, также отфильтрует и распишет тех.детали по «плохим» задачам и тем самым, как Вы и написали, «поднимет производительность своей команды».
Но, все же, я думаю проблема, по большей части, в опыте, не зря ведь народ говорит — «Все приходит с опытом», коллега)
Ну тут не могу с Вами согласиться, так как рассуждения слишком утопичны и скорее для мира роботов. Так, например, давайте затронем процесс в семье — тот еще проект/продукт, знаете ли)
Так вот, по Вашей логике и моей интерпретации получаем:
— Жена — ходила беременная и потом еще рожала (а-ля PM)
— Теща/Мама Жены — получает готового ребенка и «бизенс-задачи»от новоиспеченной мамы (а-ля TL)
— Муж — получает готового ребенка и какие-то задачи.
НО — вникать Мужу как раз таки надо, а то реализуется там что то такое, в чем потом его, Мужа, и обвинят)
Так что, почему таки Senior, если видит что и почему в задаче не так, не может это донести PM-у, мне вот не понятно. Зачем же это еще и транслировать через TL (чем больше звеньев тем быстрее рвется).
Стоп-стоп-стоп… В вашем примере, TL получает «продукт»? Ни требования, ни задачи, ни условия — именно «продукт»? Что-то тут не так)
Ну какой-же это продукт-то, новорожденный) Это в лучшем случае MVP и то скорее нет, а как раз таки требования с которыми ой сколько всего еще нужно сделать) Это я как отец троих детей, могу себе позволить авторитетно заявлять)
И далее исполнитель задач, вроде добычи той самой одежды, питания и.т.д. обычно все таки Муж. И тогда схема уже совпадает и с моей)
Но тут то просто аналогия, она про то что хороший Senior если видит и может, то должен сказать что не так, а повлияет или нет это на задачу — решает PM.
По части видения проекта/продукта в целом, ну уж если TL может — то Senior полагаю тоже может понять что за кусочки и в какую бизнес-задачу складываются и решается ли она таким вот образом который предлагается от TL или PM (решает ли проблему бизнеса).
P.S: я и не говорил о том что Senior должен ломать планы и вообще устраивать революцию. Весь мой поток мыслей о том, что, как мне кажется, не всем командам нужен TL, а возможно при четких и формализованных процессах в компании, можно и вовсе без этой роли (но это не точно) )
Тимлид, на мой взгляд, — это (примерно) зам руководителя. Разруливает, как и руководитель, вопросы почти любого характера. По сути нужен для того, чтобы руководитель не затрахался до смерти.
Однако при этом тимлид на общую стратегию влияет лишь опосредованно, поэтому с выводом в статье более менее согласен, тимлид — неблагодарная должность. Ты как бы и начальник и не начальник (ключевые решения просто так принять не можешь), отсюда батхерт вполне может быть.
К сожалению, должность руководителя отдела разработки — тоже далеко не сахар. Невозможно расслабиться даже ненадолго. Особенно если тимлид так себе ))
В противном случае он становится руководителем :-)
Поднимитесь еще на одну ступеньку и почувствуете что эта должность еще более неблагодарная ))) Определенности в обязанностях еще меньше, а конкуренция за позицию неожиданно суровая и т.п.
Фундаментальная ошибка, как мне кажется — считать, что наличие тим лидв делает что-либо лучше и является самоцелью. По моему опыту горизонтальная иерархия в разработке всегда эффективнее вертикальной, но у неё есть одна существенная проблема — перестаёт работать после определённого размера команды из-за затрат на общение каждого-с-каждым.
И вот именно в этот критический момент роста имеет смысл разбиваться на команды поменьше и заводить тим лидов — чтобы вся социальная система не рухнула под собственным весом. При этом продуктивнее от этого никто не станет, даже наоборот, и хороший руководитель должен это понимать.
В таком контексте единственная ключевая обязанность тим лида — служить точкой обмена информацией между командами, и ничего более. А ключевые навыки — широкое (но не обязательно глубокое) знание всех систем, за которые отвечает команда и умение эффективно организовывать внешнюю информацию для внутреннего потребления.
И как у всякого менеджера, его главная обязанность организация совместной деятельности группы людей необходимой для достижения некой цели.
Все остальное является побочными видами деятельности.
Он может быть одновременно разработчиком (или тестером, у тестеров тоже есть Team lead-ы) а может и не быть.
Он может совмещать роль архитектора или может доверить исполнение этой роли кому-то из своей команды.
Может быть самым квалифицированным специалистом своей команды, но это не обязательно.
Может быть самым умным, но если он будет опиратся при принятии решений в том числе на мнение более умных подчиненных, этого не требуется.
Чего он точно не может делать, это уклонятся от решения возникающих на пути к общей цели проблем.
Не может перекладывать отвественность за общие неудачи на другого.
Обязан добится приличной награды для подчиненного который снова сделал невозможное.
Ну а в целом про роль менеджера столько написано что нет смысла пересказывать.
Учите работы классиков и у Вас все получится )
Да, вы в целом правы, в том числе об этом и статья, что само по себе наличие TL не сделает команду лучше. И также она о том, что можно горизонтально развиваться.
Но опять же, почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи по улучшению команды и отдельных её членов, а также выстраивать коммуникации между отделами, кончено совместно с PM и Руководителем отдела(об этом уже писал выше в комментариях — habrahabr.ru/post/349386/#comment_10677342).
Но для этого как раз и необходим чёткий, формализованный процесс, который, кстати, поможет масштабировать такие команды. А вот масштабировать TL-Чудотворца это скорее фантазии и приемлемо для небольших, по численности департамента разработки, компаний (как найти 50+ крутых TL? а вдруг они не те кем себя называют, а зарплату им наверняка крутую надо платить сразу, а не потом).
Также про TL как менеджера, это, как по мне, тоже такой себе миф, так как у тех самых менеджеров часто есть KPI, завязанный на определенные метрики, т.е. то, что вот прямо можно взять и измерить из недели в неделю, месяца, квартала и.т.д. Поэтому, если у TL, о которых вы говорите, нет таких метрик, влияющих на мотивацию — то нет и ответственности в полной мере, а значит и результат в конце концов будет не в пользу бизнеса. Но если есть такие метрики — то да, ваш TL — менеджер.
почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи
Например, потому что я так не считаю :) Более того, в компании, где я работаю, вообще нет никакого строгого деления на ранги и никакого технического менеджмента, одни лишь только Software Engineer. При этом тим лиды есть, но они все — обычные разработчики, просто с дополнительными обязанностями. Впрочем, когда компания была меньше, не было даже их, и было ещё лучше.
Просто нужно нанимать людей, умеющих принимать решения самостоятельно — и изначально объяснять, что таких решений от них ждут.
какие
1) Быть контактным лицом, если кому-то что-то нужно от этой команды
2) Раз в неделю собираться на митинг тим лидов и озвучивать там важные для команды темы (и потом транслировать обратно результат)
почему у них
Потому что кому-то надо это делать :) Существенного влияния на зарплату это не оказывает.
у них есть метрики привязанные к зарплате
Нет, у программистов не существует никаких метрик. Но после больших факапов руководство может прислать грустный мейл о том, сколько это стоило компании и человеку будет очень стыдно :)
Суть должности Team Leader именно в том, как она называется. Дословно!
И это вообще не должность производственной структуры (скорее реверанс бизнеса в сторону программистов), и потому, у нее нет никаких «рычагов и полномочий» от руководства.
Если человек является по факту «лидером команды» — у него есть связанные с этим возможности. Не является — извините…
Поэтому должность Team Leader всегда совместительная. С Senior, PM или начальником отдела (лучше всего с Senior — меньше внутренних противоречий). Отсюда и путанница в обязанностях, «обязанности» — это по линии производственной структуры.
В чем-то Team Leader близок к профсоюзному лидеру (из тех областей, где профсоюзы реально работают), так же не дает официальной должности и так же опирается на личный авторитет. Просто IT такая отрасль, в которой бизнес без поддержки коллектива просто не может обойтись и бизнесу пришлось создать эту роль самому. Не дожидаясь…
Назначение человека TL может означать две вещи:
1. Признание сложившихся фактов.
2. Карт-бланш на формирование своей команды.
Иногда, первое и второе в смеси.
Почему удобнее всего совмещение с Senior? Потому, что TL всегда на стороне интересов команды! Даже когда уговаривает эту команду согласиться с требованиями бизнеса. Просто он видит ситуацию дальше и с большим количеством деталей. (Кроме того, когда он уговаривает бизнес признать требования команды, это обычно никто посторонний не видит.)
Хотя есть исключение — если речь идет о формировании команды под себя, лучше это делать совмещая с начальником отдела. (Правда потом это вызовет много сложностей. И лучше красиво сделать рокировку.)
Team lead это лидер комманды разработчиков. У любой комманды должен быть лидер, тот за кем последнее слово в решениях касающихся процессов разработки.
Плюс разработка плохо совмещается с другими тасками, и как правило КПД растет когда есть лид который разруливает все административные таски позволяя разработчикам сосредоточится на задаче, который знает каждого и подготавливает им задачи по душе. Который знает кто за что отвечает к кому идти по тому или иному вопросу итд. А еще он отличный специалист и всегда готов помочь советом когда разработчик зашел в тупик или ему трудно принять решение.
Имхо, тимлид нужен для того, чтобы разработчики делали свою работу не отвлекаясь на ерунду — неработающие виртуалки, нет креденшелов от третьей системы, в документации что-то неясно, и т.п. Тимлид решает эту ерунду (может лично, а может делегировать), а команда спокойно работает, не испытывая фрустрации.
Также ТЛ не пропускает плохой код во время ревью, раздает задачи и помогает, если разработчик застрял.
Думаю, этого уже достаточно для того, чтобы быть неплохим, или даже хорошим лидом, т.к. в хороших условиях команда рада работать.
Team Leader. Быть или не быть, вот в чем вопрос