Я работаю тимлидом уже несколько лет и с уверенностью могу сказать, что это направление развития мне очень нравится. А помню, я чуть не запорол свою карьеру тимлида в самом начале, на переходном этапе разработчик - тимлид. Я тогда работал разработчиком в большой компании и, в общем, работа мне нравилась. У нашей команды был номинальный тимлид - хороший, душевный человек, которому очень нравилось ковыряться в своих железках, а в жизни команды его участие ограничивалось только вопросами на дейлике “как дела?”. В общем, проблемы в команде копились, и никто ими не занимался, и меня это беспокоило. В итоге мне предложили попробовать себя тимлидом. Я эту историю рассказываю к тому, что я начинал свой путь с огромным воодушевлением, но уже через 3-4 месяца я почти выгорел и хотел вернуться в разработку или вообще уволиться. Поразмыслив тогда, я решил, что не могу так бесславно уйти и должен попытаться разобраться в ситуации и найти другое решение. Я сформулировал 4 основные причины такого быстрого выгорания, которое случилось со мной на этом переходном этапе. Мне удалось найти решение этих возникших трудностей и продолжить работу.
Итак, четыре проблемы начинающего тимлида:
#1 По-прежнему пытаться выполнять роль разработчика
Когда разработчик становится тимлидом, это значит, что в вашей команде теперь на одного разработчика меньше. Это ключевой момент, который нужно четко уяснить в своей голове, а также обязательно обсудить с бизнесом. Тимлиды могут по-разному относиться к написанию кода: кто-то пишет много кода (играющий тренер, хотя я не разделяю этот подход), кто-то пишет немного, а кто-то вообще не пишет. Но, в любом случае, большая часть ваших обязанностей уже не связана непосредственно с разработкой. Понятно, что кодить хочется, потому что мы все-таки технические специалисты. Но вы больше не должны брать на себя задачи из разработки, у которых есть жесткий дедлайн. Когда у вас есть свободное время от основных обязанностей (уже теперь лидовых), можно кодить техдолг, баги, архитектуру на перспективу, еще что-то, у чего нет ограничения по времени выполнения. Дело в том, что ваш рабочий день становится непредсказуемым: можно просидеть весь день на звонках, на аварийных ситуациях и т.д. Если вы будете брать на себя разработку, настанет время, когда вы завалите дедлайн, или команда фактически останется без лида, потому что вы будете только кодить, как раньше. У меня хватило ума брать на себя не так много задач, как когда я был разработчиком, но все равно я не успевал и мне приходилось много перерабатывать, чтобы закрывать задачи вовремя, что в результате привело к усталости. Сейчас я вообще не беру бизнесовые задачи, не пытаюсь замещать разработчиков и т.д., все задачи планируются исходя из текущего ресурса разработчиков. Кстати говоря, в проекте начинаешь находить много вещей, которые можно покодить, но на которые не обращаешь внимание, будучи заваленным бизнес задачами.
#2 Думать, что ты ничего полезного не делаешь
Когда я только начал работать тимлидом, я стал замечать, что бывают дни, когда вообще непонятно, а что, собственно, я сделал за день. Начинаешь анализировать, понимаешь, что весь день проторчал непонятно где, и занимался непонятно чем. Т.е. в конце рабочего дня нет ощутимого результата. И меня эта мысль очень беспокоила, мне казалось, что я ничего не делаю или делаю, но бесполезные вещи. Когда пишешь код, все просто: результат твоей работы очевиден. В общем, нужно просто принять идею о том, что у вас не всегда будет ощутимый результат проделанной работы в конце рабочего дня или даже недели. И это нормально. Результат вашей работы отразится на команде и продукте в целом лишь спустя некоторое время.
#3 Не заниматься планированием
Как только вы становитесь тимлидом, вы начинаете взаимодействовать с бОльшим количеством других участников, которым всем что-то нужно от вас. Это нормально, потому что, как правило, тимлид - это входная точка в команду, и все пойдут с вопросами именно к нему. Я помню свои первые недели в роли тимлида. Для меня было открытием, сколько ещё людей вместе со мной работает на проекте. Я бегал, как ужаленный, чтобы помочь всем с их вопросами и проблемами, но все равно не успевал обработать за день все “входящие заявки”, а помимо этого у меня копились дела моих непосредственных обязанностей в команде.
Решить эту проблему мне помогло осознание того, что мне теперь нужно планировать свое время. А 99% вопросов, которые стекаются ко мне, не требуют немедленного ответа.
Я завел себе отдельную доску для своих дел, входящих вопросов, мыслей и т.д. Это, своего рода, личный бэклог, с которым я работаю, регулярно чищу и приоритезирую.
Что я веду своем бэклоге:
Список дел. Этот список у меня представлен в виде простой канбан доски: сделать, в работе, готово.
Входящие вопросы - это просто список карточек, которые отсортированы по дате создания. Еще эту колонку я называю “distractions list” - список отвлечений. Когда ко мне приходят с каким-то вопросом или просьбой, если я сейчас занят, то копирую целиком сообщение в карточку, а собеседнику отвечаю, что посмотрю чуть позже, если это не срочно. Когда у меня появляется свободное время, я прохожусь по этому списку и решаю, что делать. Могу сразу вернуться к коллеге, который этот вопрос задал, или завести задачу в свой список дел, делегировать и т.д. Этот distractions list позволяет мне не отвлекаться на “внешние запросы” от текущих дел (я могу быть на совещании, собеседовании, проводить ревью и т.д.), но при этом не забывать, а решать эти вопросы в подходящее время и подходящими ресурсами. Кстати, у меня есть distractions book и для личных целей. Я туда записываю всякие идеи, которые то и дело всплывают у меня в голове, но которыми нет возможности заняться в текущий момент. Это очень помогает не забыть и подумать на досуге над возникшей идеей.
Идеи и мысли. Обычно сюда я заношу некоторые соображения, над которыми нужно будет подумать или поделиться в подходящее время, например на ретроспективе.
Это что касается дел, не привязанных ко времени. Чтобы управлять своим временем нужно вести календарь. Я выделил в своем рабочем календаре слоты под свои задачи, командные встречи и т.д. Вся моя занятость отражена в календаре. Если кто-то хочет мне назначить встречу, он просто смотрит свободные слоты в моем календаре. Личные слоты помогают мне не копить “внутренние дела”, которые касаются только меня и моих разработчиков. Сейчас у меня выделено 2 часа ежедневно на личные задачи, это 10 часов в неделю, плюс 6 часов в неделю на регулярные встречи в команде. Получается 16 часов в неделю для команды и 24 часа на “внешние” вопросы. Конечно, не всегда и не все 24 часа забиваются “внешними” встречами, но все же обычно мой календарь забит очень плотно, и без личных слотов многие вещи я бы не успевал сделать, как это было до того, как я начал вести календарь.
#4 Быть узким горлышком для команды
Когда я только начинал, то пытался контролировать всё и вся. Такой контроль выливался в переработки, стресс и т.д. Я глубоко погружался во все задачи разработчиков. Без моего аппрува никто не мог ничего сделать. В результате я много времени тратил на погружение в детали, на построение архитектуры, код-ревью и т.д. А команда была беспомощной, частенько простаивала и не развивалась. Я считал, т.к. я теперь несу ответственность, то должен все тщательно проверять и контролировать. А про делегирование задач я и слышать не хотел. При таком подходе страдают все: тимлид не может расслабиться и забывает, что такое отпуск, а разработчики перестают развиваться, начинают скучать и уходить. Особенно остро я ощутил эту проблему, когда команду нужно было расширять. Когда ты лид небольшой команды (2-3 человека), все контролировать еще получается. Но когда команда вырастает и становится 10+, ты попадаешь в аврал, потому что такой подход с гиперопекой не масштабируется. Сейчас моя главная задача - это развитие команды, которая всегда способна масштабироваться. Я больше не погружаюсь в детали задачи, если нет острой необходимости, а многие технические решения оставляю за разработчиками, что положительно сказывается на их скиллах и ответственности. В идеале, команда может работать и без лида. В книге “Делай, как в Google” это как раз очень хорошо описано. Рекомендую почитать.
Небольшой совет около этой темы:
Постарайтесь в первые 6 мес. выбрать из команды своего заместителя, который будет заменять вас в отпуске или во время болезни. Хочу отметить, что назначение заместителя ничего не имеет общего с делегированием задач. Можно делегировать любую задачу любому разработчику (например, отправить вместо себя на встречу). Заместитель должен уметь поддерживать функционирование команды в ваше отсутствие, чтобы задачи делались, а релизы выпускались. Кого поставить заместителем, решать вам, посоветую только не забывать синхронизировать ваши отпуска.
Собственно, и все. Решение этих проблем позволило мне перестроиться на новую роль и начать развиваться в этом направлении в спокойном рабочем режиме.
//Upd. Спасибо @Metotron0за исправления ошибок в тексте.
Комментарии (69)
ednersky
20.04.2023 19:33+14Когда разработчик становится тимлидом, это значит, что в вашей команде теперь на одного разработчика меньше. Это ключевой момент, который нужно четко уяснить в своей голове, а также обязательно обсудить с бизнесом.
Не согласен. Сколько Тимлидов за жизнь перевидал — вынес следующее: Лучший Тимлид — "Играющий тренер".
smartello
20.04.2023 19:33+20Тимлид вообще странная позиция и непонятно чего от неё ждут. Я всегда думал что это мечта программиста пока не попробовал - в моём случае это была какая-то смесь сеньора, архитектора и менеджера. Ничего хорошего в этом нет, по сути это попытка сделать менеджера понимающего продукт до малейших мелочей, но на выходе в лучшем случае средненький техлид и средненький менеджер.
MVS366
20.04.2023 19:33+7Сколько Тимлидов за жизнь перевидал — вынес следующее: Лучший Тимлид — "Играющий тренер".
Я тоже таких видал. Понедельник, а он перед командой хвастается, как вёслами работал все выходные. Ему дали хлыст для управления командой, а он с прежней привычкой ещё усерднее веслом машет.
karon
20.04.2023 19:33+3Играющий тренер - Это скорее сеньер с правами на управление тасками.
Filyushin
20.04.2023 19:33-1Ёмко сказано. Такой же подход в команде: обсуждаем задачи, планируем вместе, какие-то задачи в любом случае приходиться забирать на себя. Убрать сеньора - получится голый менеджер с вопросами "когда будет готово и сколько осталось ещё сделать?".
Ksoo
20.04.2023 19:33-5Я кстати наоборот, считаю что для бизнеса лучший тимлид это тот, который даже не знает технологию на которой пишет команда. И его задача сформировать команду, которая сможет работать без его технической экспертизы.
DMGarikk
20.04.2023 19:33+3И его задача сформировать команду, которая сможет работать без его технической экспертизы.
не всегда бизнес такое может себе позволить
вот я тимлид, у меня 4 миддлов и 2 джуна, постоянно норовят начать чертовщину какуюто кодить в сторону от архитектуры проекта… а сеньора найти пока не могут
на прошлой работе у меня в команде было 3 сеньора… вот это было прям счастье великое, там я реально почти не кодил
Kanut
20.04.2023 19:33+9На мой взгляд это уже тогда не тимлид, а скажем менеджер. Тимлид, даже если сам не пишет код, должен быть как минимум в состоянии в этом самом коде разобраться.
cat_chi
20.04.2023 19:33+2Неудивительно, что заминусовали. На Хабре бОльшая часть аудитории – не со стороны бизнеса, а с другой стороны баррикад. Те самые коты, которых нужно пасти.
А я бы сказал, что идея неплоха, но слишком идеалистична. А в реальности... Как такой тимлид будет нанимать людей? Делегирует это техлиду или кому-нибудь из сеньоров? Ок. А как он будет оценивать производительность и квалификацию команды? Опять делегировать? Ладно. А участвовать в планировании, оценивать риски, оценивать техдолг и "продавать" руководству задачи на рефакторинг этого техдолга и т.д. и т.п.? Тоже, видимо, делегировать. И в конце концов останется вопрос, а чем этот человек вообще занимается, и почему мы называем его тимлидом.
Я думаю, для тимлида крайне важно знать и предметную область, и технологии, в которых работает команда. Но не потому, что он должен сам писать код. Просто эти знания невероятно облегчат его работу.
P.S. И где бы ещё столько сеньоров найти, чтобы всё разделегировать. А то, как выше писали – в реальности-то команда может быть из мидлов и джунов. И как-то надо с этим жить. Поэтому очень многие тимлиды сочетают обязанности тимлида, техлида, архитектора, ментора и даже простого разработчика...
cat_chi
20.04.2023 19:33+4Играющий тренер – это техлид.
Конечно, техлид намного "круче", чем любой тимлид, с точки зрения разработчика. Ведь это такой же бро-разработчик, только очень мощный. Но с точки зрения бизнеса всё не так однозначно.
Многие тимлиды так называются только по должности, а по факту являются техлидами, или даже просто остаются сеньорами.
Sild
20.04.2023 19:33+7Хорошие советы, вспомнил свои первые пол года - столкнулся ровно с тем же
Я бы поспорил с названиями. Что значит не занимайтесь планированием? Планированием то заниматься как-раз теперь надо. Но планированием, а не разбором поддержки и техдолга. И желательно даже не приоритезацией.
А четвертый пункт лучше было бы обозначить "научитесь делегировать".
"Не быть узким горлышком" можно и работая по 20 часов в сутки, но через пол года бизнесу придется искать нового тимлида - это не очень выгодный обмен
fshp
20.04.2023 19:33+5не занимайтесь планированием?
Вас только этот заголовок смутил? В заголовках сказано что не нужно делать. Не нужно не заниматься планированием.
Sild
20.04.2023 19:33+4О как. Ну я уточка, мне сложно в двойные отрицания =)
В таком случае четвертый пункт надо назвать "не учись делегировать"
ar2code Автор
20.04.2023 19:33По-разному пробовал сформулировать :) 4 проблемы - не занимаТЬся планированием. Подумаю над своими формулировками, спасибо.
mrise
20.04.2023 19:33+2Вы не занимаетесь планированием
Я не занимался планированием
Первый может быть воспринят подсознанием как обвинение, второй намекает на бо́льшее ИМХО.
Но оба имеют достаточный контекст, чтобы напомнить читателю, какую статью он читает).
0x131315
20.04.2023 19:33+2Кстати да, некоторые на руководящих должностях стараются все замыкать на себя, а потом рвут попу пытаясь отбивать возросший поток запросов, становясь узким горлышком во всех процессах. Встречал мнения что такое бывает от неуверенности и по глупости: неуверенные так пытаются стать незаменимым звеном.
Tarnella
20.04.2023 19:33+1Ну не обязательно глупости, просто управлять и исполнять это две разные профессии, чел может быть крутым исполнителем и никудышным руководителем, продолжая быть исполнителем после повышения роли. Срабатывание принципа Питера на первой ступени.
Сам кстати встречал множество таких случаев.
wantmakegames
20.04.2023 19:33А как же пункт "помогать всем и вся одновременно"?
ar2code Автор
20.04.2023 19:33Идея, что так не надо делать, прослеживается в пунктах 3 и 4. Я писал, как я пытался обработать абсолютно всех и сразу, и это была плохая идея, нужно планировать и поддерживать некоторый SLA по входящим вопросам.
Sun-ami
20.04.2023 19:33+7Сколько времени тимлид может и должен уделять кодингу — зависит от размеров команды и опытности разработчиков в команде. Если вся команда — 4 человека — тимлид не может не кодить. А если 16 человек — не может кодить. И чем менее опытны разработчики — тем больше времени тимлид должен уделять управлению ими.
Tarnella
20.04.2023 19:33+14Ощущение что мало кто понимает что такое тимлид, чем он отличается от проектменеджера. Хотя это вроде как то, с чего надо начинать. Как можно определить свои обязанности, не понимая что ты должен делать? Как можно назначать человека на должность не понимая, какую роль она выполняет?
Я когда-то достаточно комфортно для себя определил понимание что это такое через генезис тимлида в команде как самостоятельной роли. Есть небольшая команда из одного разработчика, у него есть ПМ и архитектор. Разработчик кодит, остальные подкидывают ему задачи на вход: архитектор говорит что и как должно получиться на выходе, ПМ что и к каком сроку должно быть сделано, планирует ему загрузку, все прекрасно. Объем задач в единицу времени возрастает и в какой-то момент разработчику перестает хватать физического времени все сделать. Он легко может написать разные участки кода на один продукт, но в один момент он может сделать только что-то одно из. Тогда мы берем и добавляем ему дополнительную голову и пару рук, в виде второго кодера, который сможет писать эти отдельные участки кода параллельно с первым. С первого снялась задача писать часть кода, но появилась задача админить второго: ставить ему конкретные задачи какие куски писать, сроки, контролировать выполнение. Для выполнения того же объема работ администрирвоание второго занимает значительно меньше времени, чем собственно написание кода. И админство это совсем другая работа: ты должен контролировать старт и финал того куска, который отдаешь второму кодеру. С довеском: надо контролить компетентность второго, оценивать риск его ошибок, предпринимать меры к их минимизации и исправлению.
Далее мы масштабируем первого кодера до тех пор, пока ему не остается больше ничего, кроме как админить команду, непосредственно под его руководством пишущую код.
То есть тимлид это такой своего рода размноженный смасштабированный кодер, который координирует написание кода так, как если бы писал его сам, но сбрасывая непосредственное написание на рядовых кодеров, коллективный кодер из вышеупомянутой схемы с ПМа и арзитектора. И коммуницирует он с внешней командой как тот самый, первый, одинокий разраб в самом начале, изолируя непосредственных исполнителей от этой задачи.
Отсюда и следуют требования к нему.
SWATOPLUS
20.04.2023 19:33-2Из этого следует, то что простые разработчики общаются только между собой и тимлидом. Простые разработчики не хотят на созвоны с ПМами и прочими паразитами. Это тимлид должен создавать задачи по написанию кода и думать о том как выполнять их параллельно.
А ПМ должен вести переговоры с бизнесом (выступать в роли БА) или самому генерировать требования.
Здесь ПМ - это ПРОДУКТ менеджер, который отвечает за коммерческий успех продукта.
Сюда может добавиться бизнес аналитик, который будет заниматься документированием требований. И вот когда его нет, обязанности аналитика делятся между ПМ и Тимлидом.
Все недопонимание происходить из-за того, что некий глава этого продукта не хочет или не может полностью за него отвечать, а вместо того, что бы нанять ПМ/БА скидывает это все на ТимЛида
Либо другой вариант, ПМу нечем заняться и от интересуется что там с задачами создает и двигает карточки, созывает бесполезные созвоны.
Brrastak
20.04.2023 19:33Интересная модель. Но про тимлида хоть что-то разумное нагуглить можно. А я, к примеру, тут уже месяц мутирую из эмбеддера в инженера проекта, и пока вообще непонятно, про что это всё
staticY
20.04.2023 19:33+4А еще с конторой надо на берегах договориваться о том, что для них "тимлид"
Я пытался стать им 3 раза, и всегда это были "и жнец и чтец и на дуде игрец".
Я думал, всегда, что тимлид пишет код своими и чужими руками. И только. Но доходило и до постоянных поездок к заказчику, чтобы "выпросить у него открыть tcp порт"
И совещания по 5 раз с менеджерами заказчиков, которые одно и то же говорят по 5 раз.
И даже покупание всяких странных софтин и переговоры с отделом продаж!А еще мне как-то подсунули рандомного парня и сказал - "ты его будешь теперь обучать"
А я сказал, что я не буду его обучать, потому что 1) Он мне не нужен и я не просил 2) Я не курсы по программированию
Ndochp
20.04.2023 19:33Ага, и чем он отличается от начальника отдела. У нас на отдел из 10 человек + начальник бизнес хочет выделить 2 тимлидов по направлениям ТП и разработки. Причем именно выделить, а не нанять, то есть и так задач чуть больше, чем сделать можем, а теперь еще двоих в руководство перевести.
Это кажется от того, что они понимают, что начальника отдела умахали совещаниями и рисованием графиков выполнения задач за/на прошлый/будущий квартал и на работу с сотрудниками у него времени нет.Tarnella
20.04.2023 19:33+1Усложнение иерархии это всегда потери КПД для отдела, и идти на него можно (нужно) только тогда, когда объем задач вырастает (или их характер усложняется) достаточно, чтобы потери на их индивидуальное администрирование суммарно начинают превосходить потери на выделение отдельного администратора/координатора процессов. Если большинство времени рядовых сотрудников идет на непосредственное решение задач, а не на их обеспечение, значит структура отдела для такого объема сбалансирована. Выделять начальника это всегда вырезать чистое время исполнения из общего вала, которое он выполнял, будучи исполнителем.
Другими словами, если производительность падала из-за внутреннего хаоса и неразберихи, такое решение может быть эффективно. А если нет, то нет.
Если же ваше предположение верно, то меньшим злом было бы выделить ему одного исполнительного зама вместо двух тимлидов, которые на самом деле не тимлиды. Хоть минус один, а не минус два.
TatianaLi
20.04.2023 19:33Отличная статья, узнаю себя в ней. Особенно первый пункт. Относительно недавно стала продактом и мне до сих пор страшно забыть как кодить;(
mklochkov
20.04.2023 19:33+5Очень хорошо всё расписано, немного дополню.
По п. 1 — кодить всё равно приходится, но нужно брать только те задачи, которые невозможно делегировать. Как правило, это самые «мутные», плохо сформулированные задачи. Как только задача стала яснее (например, её удалось декомпозировать) — нужно постараться сразу отдать хотя бы часть.
По п. 2 — есть примерно такая формулировка: «Инструменты разработчика — компилятор, IDE, линтер и т. п., инструменты тимлида — прежде всего другие разработчики, а потом уже компилятор, IDE, линтер и т. п.». Музыканты ещё говорят, что дирижёр — это такой музыкант, который играет «на оркестре».
По п. 3 — планирование всегда больной вопрос. Во-первых, на планирование надо выделять отдельное время. Например, полчаса с утра для того чтобы подвигать задачи на своей личной канбан-доске. Во-вторых, рекомендация для других людей «планировать встречи, глядя в ваш календарь» — очень спорная. К сожалению, некоторые коллеги страдают болезнью «скучно? собери совещание!», и ты вдруг понимаешь, что у тебя вообще весь календарь расписан какими-то непонятными встречами. И поэтому в-третьих, следует приучить коллег, что вопросы надо решать в порядке приоритета - коротким сообщением в мессенджер, письмом, звонком, и если только не получается договориться - собирать совещание.
В порядке обмена опытом — если задачи не выстраиваются «друг за другом», т. е. их взанимное влияние неочевидно, вместо канбана (или в дополнение) хороша техника «ментальных карт» (mind maps). Особенно полезна при сложных миграциях, где надо обеспечить непрерывность сервиса.
По п. 4 — да, всё так, стоит тимлиду расслабиться, и проектная команда начинает вешать на него принятие всех мелких и не очень мелких решений. Нужно уметь «возвращать» вопрос, т. е. спрашивать «а что бы сделал ты? а почему так? а какие вообще ты здесь видишь варианты? какие из них лучше?» Именно так сотрудники и развиваются. Также нужно учить сотрудников «не держать информацию в себе» — сообщать тимлиду о проблемах — немедленно, другим участникам проекта — какие решения приняты и почему.
enree
20.04.2023 19:33+1В мутных задачах и разбираться долго и мутно. Точно не стоит вешать на себя, если ты тимлид. Потому что становишься бутылочным горлышком, а тебе ещё на остальные свои дела время надо. Лучше выделить достаточно умного разработчика с предложением решить как-нибудь, а в процессе решения добавить ясности.
mklochkov
20.04.2023 19:33+4Мутная задача — прежде всего плохо поставленная задача. Разделить её на понятные, т. е. которые можно делегировать подчинённым «по S.M.A.R.T.» — это и есть задача тимлида. Парадокс, но иногда для этого надо немного покодить :)
Paskin
20.04.2023 19:33Ваш п.2 только подтверждает п.1. Любой дирижер сам умеет играть, а то и на нескольких инструментах - но его функция в оркестре совсем другая.
Busla
20.04.2023 19:33если задачи не выстраиваются «друг за другом», т. е. их взанимное влияние неочевидно, вместо канбана
если задачи выстраиваются друг за другом и их взаимное влияние очевидно, то почему канбан, а не диаграмма Ганта?
mklochkov
20.04.2023 19:33Ну автор в статье упоминал канбан, я так понял, ему «зашло». Диаграмма Ганта — она скорее для оценки времени выполнения целого проекта или большого этапа проекта, а канбан — для структурирования входящих запросов и выстраивания приоритетов.
Ndochp
20.04.2023 19:33Потому, что она нифига не влезает на печть. Логично что упорядоченный столбик удобнее читать, чем диагональ.
Enfriz
20.04.2023 19:33+1Я тимлид уже пару лет, и меня до сих пор фрустрируют моменты от "не особо много пишу код" до "бывают дни, когда не ясно, что за результат". В этом плане статья прям в точку попала.
BugM
20.04.2023 19:33+2Глобально ошибок две:
Не делегировать когда это надо делать
Делегировать когда это не надо делать
А вот понять когда что это сложно.
JohnRambo
20.04.2023 19:33+1Нет четкого определения кто такой тимлид и что должен делать. Поэтому много вопросов на этот счёт. По нашему это называется руководитель группы разработки. Т.е. очевидно, человек должен руководить процессом разработки в своей группе. В зависимости от типа компании, состава команды, специфики заказчиков, типа проектов, процесс разработки может быть сильно отличающимся. Задача руководителя разработки сделать так, чтобы работа была сделана как можно качественнее за как можно меньшее время. Он должен уведомлять вышестоящее руководство о проблемах, которые требуют их участия, например, нехватка программистов, нехватка компетенций, проблемы с аналитикой тестированием и т.п. Если для решения этих задач ему надо программировать, он должен программировать. Не вижу противоречий. И не могу представить тимлида который сказал бы что не хочет ни в коем случае писать код. Например, он решил что надо попробовать новую либу или новый подход. Он может поручить исследование разработчику. Если разработчики заняты, может исследовать сам, почему нет. Если ему постоянно приходится выполнять роль обычного разработчика делая задачи спринта большую часть своего времени, значит в команде не хватает разработчиков, его задача послать сигнал руководству. В конце концов, сами смотрите что надо делать, конечная задача ясна.
white_crow
20.04.2023 19:33-1>Постарайтесь в первые 6 мес. выбрать из команды своего заместителя,
>который будет заменять вас в отпуске или во время болезни. Хочу
>отметить, что назначение заместителя ничего не имеет общего с
>делегированием задач.Надеюсь, это "назначение" не принудительно, а по согласию? )
Надеюсь, за это приплачивают? )>Можно делегировать любую задачу любому
>разработчику (например, отправить вместо себя на встречу).А вот такое я лично не люблю. С таким же успехом можно попросить окна помыть или сбегать за пивом. Тут надо сразу на берегу оговорить обязанности подчиненных. В зрелых компаниях есть четкая должностная инструкция и/или что-то типа матрицы компетенций/обязанностей. Понимаю, что все трудно учесть и формализовать, но требовать от разрабовать выполнять ваши "лидерские" задачи...ну, такое...)
ar2code Автор
20.04.2023 19:33+1Назначение скорее добровольное, потому что обычно есть, чем заинтересовать разработчика побыть и.о.
Делегирование задач разработчику - так, чтобы окна помыть или забор на даче поправить, не бывает) Обычно я отправляю вместо себя разработчика, если вопрос и так его затронет и нужна его экспертиза или если это поспособствует его развитию.
Делегировать нужно аккуратно, тут я согласен.
Lazy-max
20.04.2023 19:33Интересно, чем можно заинтересовать разработчика побыть и.о.?
ar2code Автор
20.04.2023 19:33+1Обычно в команде есть кто-то, кому интересно брать на себя ответственность за команду, релизы. Основной и единственный мотиватор: пробовать себя в роли лида и развивать управленческие и софт скиллы. Это все выясняется и обсуждается на 1то1 встречах.
Upd. Добавлю контекста)
Вы же разработчика не бросаете на растерзание менеджеров. Перед своим уходом своего разработчика нужно погрузить в текущие задачи, добавить на необходимые встречи и т.д. Т.е. нужно все подготовить так, чтобы и.о. по минимуму трогали всякие управленцы, и он был сосредоточен на команде и предстоящем релизе. Т.е. и.о. работает в лайт режиме.
Обычно, это интересно коллегам. Но если нет, то могут просто по-дружески заменить, если в коллективе хорошие отношения.
mx-yh
20.04.2023 19:33+1В статье отсутствует упоминание какое количество людей в команде. На старте и сейчас.
На самом деле, для того чтобы управлять командой требуется профильное образование. Образование руководителя. Образование менеджера. И какими-то 'курсами менеджеров' это не закрыть. И как не печально это осознавать, у подавляющего большинства руководителей отделов в России это образование отсутствует. Полностью отсутствует.
Дальше вопрос где это образование получить. Есть множество ВУЗов специализирующихся на подготовке управленцев разных направлений. Как правило это элитные специальности с дорогим обучением. Дальше тоже печальная ситуация, подавляющее большинство идут на эти специальности для получения корочек, а не знаний, и любыми способами стараются купить зачеты и экзамены, а не сдать.
Отсюда получается что ВУЗы готовят огромное количество управленцев, а в реальных компаниях управленцев катастрофически не хватает, при чем, на любом уровне управления.
Lazy-max
20.04.2023 19:33+4Тимлид - это дополнительный головняк практически за те же деньги что и у девелопера. Слово "карьера" слишком громко звучит для данной позиции.
pavelsc
20.04.2023 19:33Техлид или тимлид - это просто наименее аутичный юнит в команде с лычками сеньера и связной речью )) Основная их роль быть точкой входа для бизнеса. В скраме это будет техлид, в ватерфолл это будет тимлид. Второстепенная роль - недоархитектор и недоменеджер соответственно
Batalmv
20.04.2023 19:33+1Если просто, то тимлид - это прораб. Основная личная задача, которая именно на нем - рабочий процес разработки. Если человек еще не понял, как это сделать - он максимум сеньор.
Остальное - по желанию/возможности. Есть gap в части архитектуры - заполняй. Есть время кодить - бери тикеты.
remendado
20.04.2023 19:33Выглядит как будто рабочие пчелы обсуждают обязанности Королевы улья)) Де-факто тимлид - точка входа к прогерам. Что такое техлид, я даже и представить боюсь. Но можно с натажкой представить, что это тот, кто когда-то назывался "начальник отдела эксплуатации"
А де-факто все зависит от того, насколько формальные коммуникации на проекте совпадают с неформальными. И вот это зависит чаще всего от техдира, реже - от фаундера или owner'а.
Ivan22
20.04.2023 19:33точка входа для кого? или для чего?? Вопросы денег и сроков входят к прожект менеджеру. Вопросы бизнес-требований входят к бизнес-аналитикам. Разве что какие-нить вопросы от других ИТ команд.
mrozov
20.04.2023 19:33+1В целом, основная проблема рассуждений про обязанности лидов - в крайне расплывчатой формулировке этого понятия, которое очень сильно различается от компании к компании.
К примеру - есть два созвучных термина, ТимЛид и ТехЛид. Это одно и то же или это разные вещи? Большинство компаний просто выбирают один из этих терминов и не парятся по поводу деталей. Сама же идея того, что команде нужен технический руководитель, мягко выражаясь, не нова, вот и берётся современный термин для старой, как IT, концепции.
Лучше всего, в теории, на этот вопрос могли бы ответить компании, которые в штатном расписании имеют и тех и других. Я знаю две таких компании.
В первой команды разрослись до неприличных размеров и их реорганизовали, добавив дополнительный уровень иерархии. "Большую" команду возглавляет ТимЛид, а "маленькие", из которых состоит "большая", возглавляет "техлид". Но с таким же успехом можно было бы объявить "большую" команду - "отделом" или "направлением", которую возглавляет "руководитель направления", это было бы даже честнее.
Во второй компании использовали post-spotify матричную модель, в которой ТимЛиды возглавляли команды, а ТехЛиды - технические направления (backend, frontend, devops и т.п.). Эти товарищи просто использовали термин "ТехЛид" для обозначения относительно новой роли, которую правильнее было обозвать "лидерами профессий" или, опять же, "руководителем технического направления", в зависимости от предназначения.
Как правило же используется только один термин из двух, но если мы считаем их разными, то как этот выбор влияет на процессы? Как компании заполняют выпадающую экспертизу и ответственность?
К примеру, мы можем решить, что TeamLead это TechLead+. Т.е. это такой техлид, который дополнительно отвечает за организационные вопросы (скажем, найм, увольнение, распределение премий, мотивацию и развитие). Тогда компании, в которых есть только техлиды, перекладывают эти обязанности на руководителей направлений/отделов.
Однако это, в свою очередь, поднимает другой вопрос - откуда берутся ТимЛиды, эти сверхчеловеки, как они ухитряются поддерживать профессионализм в нескольких слабо связанных направлениях одновременно, откуда черпают мотивацию для столь высокой работоспособности и почему мы все не можем такими быть?
Или мы можем решить. что TeamLead это TechLead +/-, т.е. это технарь, который отвечает за организационные вопросы, но при этом не несёт основной ответственности за архитектуру и принятие технологических решений.
В этом случае ответственность за подобные решения несёт... кто-то ещё. Кто-то вводит роль архитектора направления/отдела, реже команды (тогда это техлид?). Кто-то полагает, что техническую экспертизу должны предоставлять ведущие разработчики (а иначе зачем они вообще нужны?), а в случае, если они не могут прийти к единодушному решению, то его принимает ТимЛид (а иначе зачем нужен он и его технарское прошлое?).
И только определившись с терминологией и, так сказать, штатной организацией, можно серьёзно разговаривать о конкретных обязанностях и проистекающих из этого затруднениях.
Sun-ami
20.04.2023 19:33Техлид — это разработчик, который первым осваивает новые технологии до уровня, достаточного для перевода на них основных проектов, и помогает это сделать всей команде. Это человек, который пишет библиотеки, которые потом использует вся команда, отвечает за кодовую базу, разрабатывает протоколы. А тимлид отвечает прежде всего за решение задач — строит и согласовывает планы вместе с менеджерами, распределяет задания, детализирует задачи до нужного конкретному разработчику уровня, контролирует выполнение задач, решает спорные ситуации в разработке. Во вторую очередь он отвечает за подбор и развитие, и мотивацию разработчиков. В небольших командах тимлид может также выполнять функции техлида, в больших — работает над технологиями совместно с одним или несколькими техлидами, во многом полагаясь на них.
mrozov
20.04.2023 19:33Техлид — это разработчик, который первым осваивает новые технологии до уровня, достаточного для перевода на них основных проектов
Возможно, в вашей компании всё так и есть. Но я вот не согласен с таким определением - на мой взгляд, это определение ведущего разработчика, они для этого и нужны.
Больше того - нет никаких причин, по которым таких "техлидов" в команде не могло бы быть несколько. И даже больше того - в кроссфункциональной команде их и должно быть несколько (в общем случае).
Но так как единого ГОСТ-а с определениями нет, то каждая компания вправе изобретать свои собственные определения и наполнять их своим смыслом. И всё бы ничего, но при переходе из компании в компанию такие штуки порождают множество wtf-ов с обеих сторон. :)
0HenrY0
20.04.2023 19:33Если так нравится кодить и не получает грамотно управлять людьми, почему бы не вернуться в разработку?
Первоклассный программист намного лучше посредственного управленца.
Навскидку приходит только один ответ: меркантильность и нарциссизм. Пусть буду больше вредить компании, зато получать на 3 серебряника больше.
Ksoo
Еще подстветил бы важный момент: узнать у бизнеса чего они ожидают от тимлида, какие роли берет на себя эта должность. Я четыре раза становился из разработчика тимлидом, и все четыре раза это была разные тимлиды.
ar2code Автор
Да, это важный момент, но когда я начинал, я и сам не знал, что от меня требуется и такой проблемы не было. Но сейчас, если проходишь собеседование на лидовую позицию, то это главный вопрос к интервьюерам. Спасибо.
scruff
Большинство бизнес-оунеров вам никогда не скажут что они хотят от тимки, т.к. в принципе не знают что сказать.
Enfriz
Скорее скажут, что хотят всё: и код пиши, и архитектуру строй, и командой управляй, и планируй, и на созвонах сиди.
Gradiens
Не только от бизнеса, но и от технического руководителя.
Кстати, как к бизнесу, так и к технарям желательно приходить со своим видением. Вполне возможно, они его одобрят с некоторыми корректировками, и вы будете заниматься тем, что озвучили.
А потом регулярно синхронизироваться, чтобы понять, а в одну ли сторону мы все гребем?