Привет, Хабр! На связи Марина Гончарова. Сейчас я занимаю роль старшего менеджера проектов в Купере и работаю над задачами, которые затрагивают по несколько подразделений сразу. Но до этого я долго была проджектом в кросс-функциональных командах. В этой статье я поделюсь мыслями о том, зачем тимлиду отказываться от кодинга, могут ли котов пасти другие звери и почему тимлидство — это не карьерный рост для разработчика.
Летом 2024 года я работала на стенде Купера на Saint TeamLead Conf++. У меня было несколько карточек с вопросами для обсуждения с тимлидами. Тот самый вопрос — «Должен ли тимлид кодить?» — вызывал самые увлекательные беседы. Примерно 50% из тех, с кем я разговаривала, изначально настаивали на том, что тимлид должен оставаться кодером, однако по мере дискуссии многие перетекали на тёмную сторону. Тогда я подумала, что мои аргументы могут быть полезными и для читателей на Хабре.
Дисклеймер: всё, о чём я пишу далее, — моё личное мнение, основанное на десяти годах в менеджменте. Если у вас другой опыт, буду рада обсудить его в комментариях :)
Подмена понятий
Для начала предлагаю вспомнить, какие менеджерские роли существуют в IT. Должности могут по-разному называться, обязанности могут делиться между несколькими ответственными или, наоборот, компоноваться в одних руках, но объём задач для каждой роли остаётся постоянным.
Продакт-менеджер решает, как будет развиваться продукт, над которым работает команда: определяет целевую аудиторию, анализирует конкурентов и юзеров, следит за метриками.
Техлид фокусируется в первую очередь на технических аспектах: принимает ключевые технические решения, определяет архитектуру и технические стандарты в продукте.
А вот с тимлидом и проджект-менеджером сложнее. По сути, эти две роли выполняют одни и те же функции: постановка и контроль целей, планирование и организация рабочих процессов, поддержка мотивации, синхронизация команды с остальной компанией. Как тимлид, так и проджект-менеджер распределяет задачи между сотрудниками и отвечает за результаты перед бизнес-заказчиком.
Когда в команде есть и проджект, и тимлид, тимлид — это на самом деле техлид, который берёт на себя техническую сторону реализации продукта и профессиональный рост команды разработчиков. Проджект тем временем отвечает за остальной менеджмент: цели спринта, расставление приоритетов и выполнение планов, удовлетворённость и единение команды, отсутствие конфликтов.
Только проджекта может не быть, и в такой ситуации тимлиду приходится совмещать менеджерские функции с разработкой.
Тяжела жизнь тимлида, который ещё и техлид
Заполучив роль тимлида, вы можете продолжить как разработчик погружаться в каждую задачу вплоть до крошечных мелочей, самостоятельно делать техническое дискавери, ревьюить код коллег. Но кто будет заниматься организацией работы, управлением командой и пипл-менеджментом?
Тимлиду, который вышел из разработки, нужно перестать воспринимать себя как разработчика, изменить отношение к своей деятельности и к её результатам.
Мне нравится теория, которую продвигает Слава Панкратов — бизнес-тренер и сооснователь школы для менеджеров и тимлидов «Стратоплан». Он говорит, что каждый человек, который находится у тебя в непосредственном подчинении, требует 20% твоего времени. Если под менеджером пять человек и каждый получает законный кусок внимания от руководителя, то всё, время кончается. Соответственно, кодинг, ревью и прочие технические задачи — это уже овертайм, который часто приводит к выгоранию. А если у тебя пять человек и ты не овертаймишь — эти пятеро недополучают твоего внимания, но ты не знаешь об этом.
Кроме того, менеджерская роль предполагает довольно много встреч: с руководителем, бизнес-заказчиком, соседними командами. Такие встречи могут занимать по полдня. «Вот сейчас закончу со встречами и пойду поработаю» — нет, во встречах и заключается бо́льшая часть нашей работы. Без них нет новых задач, нет контекста и возможности управлять ожиданиями бизнеса.
Из всего этого вытекает моя рекомендация: как только вас назначают на должность тимлида, выбирайте себе техлида в пару. Ещё лучше — сделать выбор, когда только начинаешь понимать, что можешь скоро перейти в управляющую роль. Жить будет проще, особенно если команда больше пяти-семи человек.
А как же разработческая хватка?
Многие тимлиды продолжают писать код по старой памяти, потому что боятся потерять хватку или перестать понимать, что происходит внутри архитектуры приложения. Такие опасения, на мой взгляд, не оправданы. Тимлид всё равно встречается с командой и знает, к каким решениям приходят разработчики, что остаётся в техническом долге и как это влияет на планирование.
Для этой статьи я опросила 20 тимлидов из Купера. Один из респондентов написал мне, что навык инженерного мышления атрофируется, если выполнять только менеджерские функции. Доля правды в этом присутствует: как главный врач, который принял последнего пациента 15 лет назад, вряд ли сходу качественно проведёт обследование, так и тимлид без практики провалит программирование на скорость. Но для поддержки мышления не обязательно тянуть за собой в тимлидство ворох кодинг-рутины.
Можно вытаскивать из закромов бэклога задачи без жёсткого дедлайна или задачи не в зоне приоритетов продукта — например, по оптимизации. Можно придумывать себе пет-проекты. Можно поглядывать в код-ревью, при этом не оставляя за собой право финального аппрува (иначе есть риск превратиться в узкое горлышко). Но оставаться в команде разработчиком — дело неблагодарное.
Ещё один респондент написал: «Когда тимлид продолжает писать код, возникает вопрос времени, уделяемого техническим задачам, и коммитов. Если время не регламентировано — как его учитывать в капасити команды? В одном спринте 40 сторипоинтов, в следующем — 10. В итоге производительность команды всё время плавает, и предсказуемость падает». Здесь я соглашусь: тимлид в любой момент может упасть в чисто менеджерские задачи и бросить код, который взял на спринт. Тимлида лучше не учитывать при распределении приоритетных задач.
Также во время опроса я получила мнение, что программирование помогает тимлиду сохранять свой авторитет. Безусловно, авторитет важен, но авторитет тимлида заключается как раз в управлении командой и процессами. За счёт программирования авторитет зарабатывает техлид.
Кто-то говорит, что тимлид должен иметь возможность купировать инциденты, проводить менторинг через код, транслировать наиболее современные и эффективные подходы к решению задач. Однако а) всё это может делать выбранный тимлидом техлид; б) тимлид не может быть хорош в любом стеке, соответственно — тимлид и техлид в одном лице подойдёт только команде с одним стеком. Если в команде не только разработчики разного стека, но и аналитики, дизайнеры, тестировщики — мы же не будем говорить, что тимлид должен профессионально менторить ещё и их?
А вот пара фраз из опроса, за которые я жму руки коллегам: «Если бы схема с играющим тренером была рабочей, мы бы чаще её видели в спорте»; «Инструмент тимлида — разработчик, а не текстовый редактор. Надо уметь пользоваться своими инструментами».
По моему убеждению, тимлид не должен писать код на работе, потому что это может навредить его полноценному функционированию в роли менеджера. Но можно писать код в свободное время, если это приносит удовольствие и никак не мешает тимлидству.
При этом, разумеется, если должность в конкретной компании и команде предусматривает объединение в себе двух ролей — тимлида и техлида, — то в рамках роли техлида неотъемлемой частью работы остаётся и программирование, и ревью, и финальные аппрувы.
Тимлид, который не умеет программировать
В Купере я ещё не встречала тимлида, который не умел бы программировать и не был бы выходцем именно из разработки. Тем не менее я считаю, что тимлидство — не ступень карьерной лестницы разработчика (в отличие от техлидства).
Стать из разработчика тимлидом — не вертикальный, а горизонтальный рост. Это превращение в специалиста другой профессии.
И, раз это другая профессия, стать успешным лидером для команды может даже тот, кто ни разу не открывал редактор кода.
Конечно, для работы в IT человек должен понимать азы: как работает бекенд и фронтенд, как работает тестировщик, как работает аналитик и т. д. Полезно знать, как задачи ранжируются по сложности и насколько что трудозатратно. Условно, если дизайнер говорит, что ему нужно три недели на отрисовку одной кнопки, надо смекнуть: что-то идёт не так. Да, пасти котов, то есть развивать хардовые скиллы сотрудников, могут только такие же коты; но единую и вдохновлённую команду из котов, собак и хомячков может сделать хоть кенгуру.
Основу роли тимлида составляют всё-таки развитые коммуникативные навыки, способности к планированию, многозадачность. Вдобавок управление приоритетами: надо понимать, чего хочет бизнес. Прямо ставить себя на место бизнес-заказчика и следить за тем, чтобы приоритеты команды учитывали его потребности.
Хорошие разработчики — это люди, которые привыкли быть сконцентрированными. Для них естественно потратить целый день, думая над одной задачей. Когда такой разработчик становится тимлидом, ему сложно сменить свою деятельность на всё это взаимодействие с бизнес-частью, пипл-менеджмент и ресурсное распределение, которое должно затрагивать много факторов.
Бывает, что разработчики не выдерживают и возвращаются в программирование, потому что не могут смириться с тем, что менеджмент требует совершенно других навыков. Эту смену группы мышц обязательно нужно осознавать, если вы начали путь к тимлидству.
Делегируйте с удовольствием
Хотите стать тимлидами из разработчиков даже после моей статьи? :) Напишите на всех возможных поверхностях вокруг себя слово «делегирование». Скорее всего, быстро изменить свои нейронные связи не получится, и вы будете пытаться работать с кодом, потому что это ваша привычная деятельность. Там подхватил ревью, здесь сел чистить код — день пролетел, а в основных задачах и конь не валялся.
Научитесь лениться, когда дело касается кода. У вас есть специально обученные люди, которым можно передать любую задачу технического характера. Забудьте фразу «Я сам(а)» и будьте просто коммуникатором. Ваша роль — сделать так, чтобы разработка шла по плану и была согласована с бизнес-целями, а заряженная команда показывала максимальный перфоманс. Кодить при этом для себя или нет — уже не так важно (опять же — если должность не объединяет в себе роли тимлида и техлида).
Комментарии (36)
AdrianoVisoccini
22.11.2024 09:06вся суть несогласия с озвученным в статье могу описать этой картинкой:
В чем заключается отличие тимлида от просто подкованного технически менеджера если он не тянет с нами(командой) одну лямку, не ест из одной плошки и не спит под дождем в одной траншее перед боем? Чтобы держать руку на пульсе тимы и понимать как управлять их мотивацией нужно быть погруженным в их быт, а значит участвовать в коде так или иначе.
Mgoncharova Автор
22.11.2024 09:06А если в твоей команде не только разработчики, а есть и аналитики, и тестеры, и дизайнеры? ты же не можешь быть погруженным в быт по всем направлениям? Суть мысли в том, что есть техлиды, которые тянут одну лямку, едят из одной плошки и спят под дождем в одной траншее перед боем, а есть тимлиды, которые объединяют всю команду целиком.
AdrianoVisoccini
22.11.2024 09:06Звучит как неверная трактовка понятия TeamLead, ну по моему мнению. Team leader - лидер команды. Ну не всей же, а команды бекенда например - человек ИЗ команды, который представляет вас всех на уровне менеджента. Такая практика между прочим есть не только в ИТ, а годами существует во всех отраслях. Бригадир, Мастер цеха, Руководитель группы отдела (например продаж). Это всегда обязательно человек ИЗ группы, который складывает ЧАСТЬ полномочий чтобы нести личную ответственность за общую деятельность группы. Таким образом он держит руку на пульсе группы, в курсе ежедневных чаяний и несет личный ответ за происходящее. Группа же в таком случае ассоциирует себя с представителем и ощущает ответственность перед ним, так как подставляешь ты брата по команде а не какого-то там зазнайку с менеджерского олимпа.
Тех лид же имеет свои абсолютно не пересекающиеся зоны ответственности, но тоже в рамках команды.Вы в примере к статье приводите 20 тимлидов, но они все из одной компании, ну т.е существуют в рамках одной системы. Чтобы опрос можно было посчитать релевантным стоило опросить 20 лидов из 20 компаний, например. Лиды из Купера как минимум подвержены давлению своей группы, раз все не пишут то и я не буду, ну просто как пример. Или вот ещё - а что если в Купере, просто предположим, огромная систематическая проблема, связанная именно с тем что лиды код не пишут? Они изнутри системы этого не видят, а вы к ним обращаетесь с уже сформированным личным мнением, т.е так или иначе подвержены "предвзятости подтверждения"(см confirmation bias). СбреМегаМаркет как раз показал ужасные результаты из-за чего и предпринял (как мне кажется абсолютно неудачный) ребрендинг, так может все из-за лидов, которые не пишут код?(я само собой утрирую)
DeskundigeICT
22.11.2024 09:06На самом деле, чёткой границы между этими профессиями не существует. Например, тестировщик может писать код для автоматизации тестирования программ. Дизайнеры в ИТ зачастую работают с HTML/CSS для создания интерфейсов. Аналитик должен мыслить как программист, чтобы грамотно составить техническое задание, которое, по сути, уже наполовину является решением задачи.
Я, как Corporate ICT Officer, занимаюсь обслуживанием внутренней ИТ-инфраструктуры. Иногда пишу код на PowerShell, чтобы оптимизировать рутинные процессы.
Но почему всё внимание сосредоточено на кодировании? Если я графически автоматизировал процесс в облаке Azure или Amazon, это тоже демонстрирует инженерное мышление. Уверен, что даже дизайнеры, работая в Photoshop, используют макросы для автоматизации определённых задач.
Поэтому предлагаю заменить термин "кодирование" на "автоматизация", поскольку он лучше отражает реальность.
bungu
22.11.2024 09:06Сейчас в вакансиях в основном пишут "тимлид/senjor", "играющий тренер" и прочий бред, лишь бы сэкономить на тратах на персонал. Если вдруг тимлид скажет что ему нужен еще техлид (а может и еще продакт), то там покрутят у виска и скажут что-то типа "У нас пока не заложен на это бюджет". Не знаю что там у вас в Купере, но обычных компаниях все эти позиции надо с боем выбивать. А пишет код тимлид в основном не потому что хочет не потерять "разработческую хватку", а просто потому что горят сроки или не хватает разработчиков
Mgoncharova Автор
22.11.2024 09:06У нас в Купере так же - политика компании такая, что тимлидами становятся разработчики, но и команды у нас чаще всего состоят из разработчиков одного стека. И проджектов, сидящих в команде, нет, поэтому тимлиды совмещают и техлидство, и тимлидство.
Я бы сказала, что всё зависит от того, как устроена структура команд в компании, ведь играющий тренер на самом деле - по факту сокращение капасити команды почти на одного человека
HSerg
22.11.2024 09:06Почему тимлидами в командах становятся разработчики? Чаще всего в командах никого кроме разработчиков нет.
Почему у тимлидов не хватает времени на написание кода? Команды недостаточно опытны и процессы через тимлидов выстроены.
Почему команды недостаточно опытны? Горизонтально масштабироваться проще всего через деление команд.
А как же аджайл-подходы? SoS и тимлиды как аватары команд. Они же тоже когда-то программировали и команды как раз однородны.
panzerfaust
22.11.2024 09:06как только вас назначают на должность тимлида, выбирайте себе техлида в пару
Это легко говорить из околосберовской конторы. Там только свистни - тебе сразу трех техлидов найдут. А там, где прибыли не триллионные, вопрос из заголовка как раз и стоит наиболее остро. И решается не в пользу тимлида. И погромировай, и управляй, и с созвонов не вылазь. И фару на лоб, как водится.
Mgoncharova Автор
22.11.2024 09:06Эх, если бы "околосберовские" конторы отличались:) у нас такие же ограничения и по финансированию, и по найму. Но осторожно смею предположить, что в таких конторах понимают, что если один человек будет "И погромировай, и управляй, и с созвонов не вылазь" - в конце концов это будет зомбик, которого придется отстрелить, если он до этого момента не отстрелится сам.
Grikhan
22.11.2024 09:06Если мы имеем не самоорганизующуюся команду профессионалов и оцениваем не по работающему продукту, то да - надо взять одного из членов команды,
кинуть в бочку с другим, а того, кто выживет, отправить обратно в роли тимлидазаставить его забыть всё что умеет и принудить делать работу руководителя проекта. Этот рецепт, безусловно, проще, чем нанять команду профессионалов и обеспечить их всем необходимым, найти РП, который знает что такое "руководить" и что такое "проект" в ИТ, а не в ЖЭКе. Но этот рецепт не про эффективность, а про то, как не утонуть и вообще доплыть хоть куда-то.
man55
22.11.2024 09:06Продакт - про то, куда развиваться, что болит у заказчика
Проджект - про то, как раздобыть ресурсы, как поженить снабжение, разработку, тестирование, рекламщиков ... , спланировать работу так, чтобы Группа 1 дала результат одновременно с Группой 2 и т.п.
Тимлид - про то, какой технологией лечить проблему клиента, какие стандарты разработки в команде, что дать Васе, что Пете и проверить, что оба не накосячили и не внесли ненужной отсебятины
В статье же попытка обосновать необходимость еще одной сущности. За 20 лет управленческой деятельности был на всех трех ролях, не считая собственно разработчика, и оглядываясь назад, не вижу нужды в четвертой.
summerwind
22.11.2024 09:06Тимлид - про то, какой технологией лечить проблему клиента, какие стандарты разработки в команде, что дать Васе, что Пете и проверить, что оба не накосячили и не внесли ненужной отсебятины
Это все верно только для маленькой команды каких-нибудь джунов или максимум мидлов. Когда команда более-менее большая и опытная - можно, конечно, продолжать заниматься микроменеджментом и контролировать каждую строчку, но уже в ущерб своим основным обязанностям, т.к. основные обязанности тимлида это все-таки эффективно организовывать, мотивировать и делегировать.
vic_1
22.11.2024 09:06Тимлид это капитан команды, играет ли капитан - конечно, иначе на кого молодым равняться, он не делает много грязной работы, но голы забивает. Как Овечкин в Вашингтоне :) А если он не играет, то это уже какой-то менеджер, завхоз, сервисмен
dph
22.11.2024 09:06Это опять про разницу между techlead и teamlead.
Техлид - да, тоже разработчик.
Тимлид - про процессы, людей, приоритеты, коммуникации, т.е. совсем другие компетенции.
Очень большая проблема процессов во множестве компаний - это смешивание техлида и тимлида в одном человеке. В результате ничего хорошего не получается.
Dartflame
22.11.2024 09:06Это же надо было так оскорбить тимлида, опустив его до уровня проджект менеджера?))
У разработчика есть два варианта развития - тех лид и тим лид, соглашусь, что совмещать и то и то это плохо. Но он в любом случае должен оставаться разработчиком - хорошо знать проект (от теории до непосредственно кода), должен уметь сам решать задачи любого уровня - хоть ТЗ написать, хоть тестировать, хоть разрабатывать (пусть хуже профильного специалиста, но уметь должен).
Таким образом тим лид это разработчик, который обладает достаточным опытом и знаниями и плюс к тому хорошими софт скиллами и авторитетом в команде. Ни один серьезный программист не станет слушать человека, который не умеет писать код или делает это крайне плохо)
К сожалению, сейчас в айтишку тащат все ублюдские практики ведения бизнеса из других сфер и начинают появляться "тимлиды", не умеющие писать код. Таких проектов стоит избегать)
Apoheliy
22.11.2024 09:06По-моему, автор лукавит и подменяет понятия.
Вопрос в заголовке статьи мог бы быть: Должен ли тимлид уметь писать код?
И (по-моему) ответ на этот вопрос должен быть утвердительным. Почему? Потому что здесь и содержится лукавство автора: когда все тимлиды умеют писать код, то можно и задуматься "а так ли это нужно?". А вот если бы они изначально не умели?
Очень хорошо об этом сказал Козьма Прутков (осовремененно):
Когда спросят тебя: что важнее луна или солнце, отвечай луна! Ведь солнце светит, когда и без того светло, а луна ночью.
И вопрос только в том, насколько ранее писавший тимлид умеет это делать и понимать в современных реалиях (ведь стеки меняются и выходят новые стандарты языков). То что раньше какие-то вещи делались легко и просто (например, через россыпь костылей с техническим долгом и спагетти-кодом), сейчас может потребовать больше времени. И, конечно же, наоборот: масса вещей делается сейчас легче и проще.
Но насколько проще? А тимлиду лучше знать! Но будет ли он это знать? А так может тимлиду писать код? Если не для продакшена, то хотя бы для понимания?
-
Прим: про "играющего тренера" можно возразить: но капитаны команд играют. Например, Игорь Владимирович Акинфеев. Да, наверное, если его поставить в нападение, то играть он будет не лучше, чем на воротах. Но он же играет.
amazingname
22.11.2024 09:06Должен и ещё как. Иначе за 5 лет для рынка он превратится в мидла и потом вообще непонятно что делать. На мидла не берут потому что овеквалифаед с таким опытом, на синьора не берут потому что стрёмно - навыки не актуальные.
Сам из такого выкарабкиваюсь и несколько таких собесил.
napolskih
22.11.2024 09:06Тимлид - это менеджер = другая профессия. Рост из разработчика в тимлида чаще это общая ошибка и боль отрасли.
BugM
22.11.2024 09:06Тимлид который не был сеньором это плохой тимлид. При этом ставить токсичного буку сеньора тимлидом нельзя, получится очень плохой тимлид.
Надо совмещать. И разработчиков понимать и уметь любой код написать и с менеджерами и смежниками на одном языке о продукте и сроках поговорить.
Код писать со скоростью сеньора и даже мидла конечно же не надо, но брать себе таски по которым нет дедлайнов и можно затянуть хоть на месяц-другой это правильно. Таски на переложить джейсон стоит брать только если хочется посмотреть что там с процессами или люди из команды начали на них жаловаться. Вдруг тесты на самом деле болят, а тестирование на самом деле ерундой занимается? Проверить на себе это лучший путь. А вот таски вида "ничего не понятно, но очень интересно" себе брать можно и нужно смело. И как код писать не забудешь и сроки никому не сорвешь.
Smartor
22.11.2024 09:06Просто в IT, как в относительно молодой отрасли, нет устоявшейся терминологии и общепринятого разделения обязанностей. Вот в промышленных коллективах, как уже упоминали выше - бригадир, мастер участка, начальник цеха - сразу всем понятно, кто чем занимается. А в IT кальки с английского языка наполняются своими смыслами, плюс подмешиваются термины всеми любимых "эффективных сов" и приёмы от них же, что в итоге приводит к размножению руководящих контуров...
maxzh83
Короче, лайфхак для вкатунов: идите сразу в тимлиды, там даже кодить не надо. Это шутка, но с долей правды
Mgoncharova Автор
Есть же масса примеров, и я в том числе, когда тимлидами становятся не бывшие разработчики, а бывшие аналитики и тестеры. Просто они в себе не совмещают две роли, а исполняют одну - управление командой (тимлидство)
AdrianoVisoccini
а чем отличается человек, который "просто управляет командой" от менеджера? Зачем называть его тимлидом в таком случае? В чем его лидерство заключается?
Mgoncharova Автор
Ничем, в этом и суть ) Вопрос в подмене понятий ) Лидерство в том, чтобы из группы людей сделать команду
AdrianoVisoccini
Я именно об этом и говорю - это подмена понятий. Не нужно делать разработчика менеджером, пусть будет тимлидом. А менеджером сделайте кого угодно, пусть будет менеджером. Тимлид должен быть интерфейсом команды через который осуществляется обратная связь с менеджером. Если у вас тимлид не участвует в разработке, то это просто менеджер.
И я это говорю не с неба взяв, у меня за спиной 10 лет менеджером(а сейчас бекендер), в том числе "руководитель группы отдела продаж" ну т.е буквально тимлид. Так сказать побывал с обеих сторон.
ermouth
Это тимбилдинг, и это не про лидерство.
Лидерство это про умение обеспечить доверие и поддержку людей для совместного достижения цели. Команду для этого строить желательно, но совершенно не обязательно.
И да, в команде разрабов не-разрабу получить нужное доверие будет очень непросто.
HSerg
Почему "очень непросто"? Если команда не из амбициозных джунов, то решающему проблемы клиента/проекта/команды и доверяющему команде в технической (и не только) части лиду все будут только рады.
domix32
Видимо только 40% знают, что в таком случае он будет тем самым мифическим продакт менеджером, а не тимлидом.
Dartflame
Я бэк разработчик. Если б мой тимлид был тестировщиком (или кем угодно кроме бэк разработчика) я бы искал другой проект. Проджект менеджер пожалуйста, но тимлид это всегда старший разработчик. Если ты не можешь посоветоваться с тимлидом по коду - какого ты дьявола вообще должен слушать этого человека?)
nameless323
Может конечно в россии не так, но по коду надо посоветоваться с тех лидом, по межкомандному взаимодействию, по задачам, по тому чтоб донести какиет проблемы менеджменту, что "у меня и так 100500 задач, я понимаю что Вася болеет но у меня уже bandwidth'a нет" и прочее в этом духе - это с тим лидом.
napolskih
По-моему эта путаница - это беда нашей отрасли. У команды должен быть менеджер = лидер, и это не обязательно технарь (лучше не технарь, хорошо если есть бекграунд). Это не лучший программист, это именно менеджер - другая профессия. Так же в команде должен быть старший программист / техлид, который имеет тех авторитет и к которому идут разработчики с техническими вопросами. Но лидер команды менеджер. Сейчас часто совмещают первого и второго и это большая беда.
0x131315
Менеджер не лидер, он вообще по отношению к команде внешняя сущность. И, как уже тут сказали, команда его не примет как одного из своих, он не погружен в реалии кода. Менеджер это управленец, он владеет конкретным продуктом, ведет учет, управляет потоком задач на высоком уровне, следит за бюджетом и учитывает интересы продукта. Команда это исполнительный блок, группа специалистов разной квалификации и специализации, она разбирает поток задач и выполняет эти задачи наиболее эффективным способом, с учетом доступных ресурсов и компетенций. Слаженная команда может принадлежать нескольким проектам, а в случае разногласий иногда и фирму покидает в полном составе, такие случаи история уже знает. Тимлид тут это просто старший опытный разработчик, знакомый со спецификой кода, с бизнес-процессами, с реалиями корпоративных игр вышестоящих товарищей. Лид способен быть интерфейсом между командой и бизнесом, это наиболее грамотный, и в техническом плане, и в бизнес-плане, человек, который понимает о чем говорят вышестоящие товарищи, понимает их реальные потребности, и реальные ограничения текущего кода, понимает проблематику сверху и снизу. Лид способен перевести технические подробности на язык бизнеса, и бизнес-потребности на язык технарей. Его задача быть клеем, и внутри команды, и внутри бизнеса, оптимизировать процессы, пресекать тупняки, находить короткие пути решения тех или иных проблем, не учитывая никакие зоны ответственности, на чем спотыкаются обычные разработчики. Его задача быть крайним в команде, замыкать все внутренние вопросы и проблемы на себе, не допускать их утечки вовне, не допускать нарушения зон ответственности. Именно его будут нагружать разработчики всякими проблемами и непонятками, и он их разрешает за считанные минуты, тем самым избегая серьезных простоев на ровном месте, потому что без лида в таких случаях начинается игра в "горячую картошку", никто на себя ответственность не берет, и простейший технический вопрос утекает наверх, покидает зону ответственности технарей, и летает по всяким менеджерам и управленцам, которые не понимают что от них хотят и причем тут они вообще, и летать он там может неделями, что выглядит просто дико. Также задача лида - тактические, оперативные решения, внутри его сферы ответственности: многие вопросы или проблемы можно решить внутри команды, без привлечения внешних , и тем самым сократить время на всякую бюрократию, увеличить эффективность процессов - время ответа человека за пределами команды может достигать недели-двух, а пинг до лида обычно менее часа. И его задача быть ориентиром, вдохновлять молодых - как ни крути, но внутри команды самый большой авторитет именно у лида, новички к лиду обычно относятся особенно трепетно, в их глазах это чуть ли не человек-легенда, на его авторитет работает и огромный опыт, и роль, и тот факт что с ним считается бизнес и он постоянно пропадает на совещаниях с большими людьми, ну и личный фактор конечно же, рано или поздно лид окажет помощь каждому из команды, решит его проблему.
dph
Хм, а ты не путаешь teamlead и techlead?
Впрочем, в нормальных процессах teamlead вообще не нужен, а вот techlead - да, старший разработчик.