Комментарии 17
В целом толково, но вот с этим я бы поспорил:
Важно не путать его с проджект-менеджером, менеджером по продажам и другими позициями без подчиненных
С каких пор ПМ – должность без подчинённых? Может, и существуют такие структуры, но мне до сих пор не встречались. В частности, те самые тимлиды в норме и есть подчинённые ПМ.
Привет.
Это не совсем так.
Проектный менеджер и тимлид это роли. Они могут пересекаться, но чаще нет.
Так же нужно разделять функциональное и проектное управление.
Тимлидом/непосредственным руководителем для тимлида в разработке обычно является руководитель подразделения к которому он относится (Lead Backend, CTO и т.д.)
ПМ — это руководитель проекта, временная роль, существующая с момента инициации проекта до его завершения. Его зона ответственности — это проект, а не команда.
Он управляет сроками, качеством, скоупом проекта, рисками, может запрашивать ресурсы, но обычно не может их распределять единолично.
Он не отвечает за найм тимлида, обычно не занимается обучением (так как у него другой набор скиллов), он не отвечает за карьерный и профессиональный рост команды и тимлида, работа с мотивацией у него ограничена и т. д.
Часто в его ведении проектные бонусы, но основную часть зарплаты он не определяет.
Существуют варианты, когда ПМ выполняет роль тимлида. Это называется проектной оргструктурой (не путать с проектной организацией работы).
Она в основном характерна для консалтинговых компаний, в которых ПМ собирает команду контракторов под проект.
В компаниях по разработке ПО обычно матричная оргструктура. Тимлид разработки относится к ветке производства, а ПМ — к ветке бизнеса.
В рамках проекта ответственность между ПМ и тимлидом разделяется.
Да, по многим аспектам ПМ ставит цели тимлиду и отвечает за результат, но всё же это параллельные должности, а не функциональное подчинение. По завершению проекта они расходятся, тимлид остается с командой. ПМ идет руководить другим проектом.
В небольших компаниях, особенно в слабой матричной оргструктуре, на проекте может вообще не быть выделенного тимлида.
Руководством командой (выполнением роли тимлида) занимается руководитель подразделения.
При этом, в ветке ПМов есть свои тимлиды, обычно это CPO или Lead PM. У них есть подчиненные.
Я ПМ уже 7 лет, за это время 3 компании сменила - везде была как самостоятельная единица без подчинённых. На последнем месте вообще матричная орг структура, некоторые Лиды исполняли роль чисто согласовать заявку на доступ и подтвердить таймшит в системе, и особо не в курсе были, чем человек на проекте занимается. Таких лидов я привлекала только в случае решения каких-то орг моментов (например если есть проблемы с человеком или нужно было привлечь для решения конфликтный ситуации где мои компетенции заканчивались).
Я встречал в основном варианты, когда номинальным "начальником" выступает всё же ПМ. А ТЛ – первый среди равных. При наличии обеих ролей ПМ – точка входа для менеджмента, бизнеса, менее "технических" интересантов, других ПМ. А ТЛ – для архитекторов, программистов из других отделов. Отчего обязанности и ожидания разнятся от компании к компании. Хотелось бы в статье увидеть эту роль более очерченной, но увы, много реверансов в сторону "эти обязанности разделяются с ПМ, но на более высоком уровне" и без конкретики, об этом самом уровне. Еще сложнее получается с появлением техлидов, но это отдельная история.
В том то и проблема, что стандарта названий должностей нет. Но тот вариант, который вы упоминаете это скорее техлид.
Обычно в такой структуре управлением командой занимается руководитель подразделения. Управлением в рамках проекта ПМ. Он отвечает за технические аспекты и коммуникацию, но не управляет командой, а только влияет на нее.
Ну а разделение обязанностей - оно меняется от проекта к проекту. В продвинутых компаниях часто есть стандартное разделение, зафиксированное в виде матрице RACI и обычно компания ему следует, но даже в этом случае от проекта к проекту в ней могут быть нюансы.
Многие сильные разработчики мечтают стать тимлидами или менеджерами […]
Сильным разработчиком практически невозможно стать, если написание кода не доставляет удовольствия. Как следствие, сильные разработчики мечтают продолжать движение по своей карьерной лестнице, в Staff, Principal, Distinguished, Fella…
Тимлидами и менеджерами мечтают стать как раз плохие разработчики.
Удовольствие же доставляет написание "правильного" кода. И в этом же самая идея, что становясь тимлидом можно влиять на написание кода другими людьми и допустим внедрять практики которые нравятся вам конкретно, делая код более "правильным". Как бонус - еще и брать часть интерестных задач для себя(в большинстве компаний думаю от тим лида будут требовать 50 на 50 загрузки менеджер-исполнитель).
Вообще в статье бы неплохо упомянуть Teamlead Roadmap, по сути то там более полное описание https://tlroadmap.io/
становясь тимлидом можно влиять на написание кода другими людьми
Для этого не надо становиться тимлидом. Поверьте, у принципала это получается ничуть не хуже.
в большинстве компаний думаю от тимлида будут требовать 50 на 50 загрузки менеджер-исполнитель
Ну и нахрена мне эти 50 от менеджмента? Да еще и платят значительно меньше. Да еще и говорят, что делать примерно через раз (принципалов иногда просят помочь, а дальше по этой лестнице — вообще не трогают).
Поверьте, у принципала это получается ничуть не хуже.
это при хорошем тим лиде будет получаться ничуть не хуже. Т.е. если текущий процесс хорошо построен, действительно переходить в менеджемент имеет мало смысла.
А при плохом вам как наиболее опытному сотруднику могут к примеру поручать фиксить задачи написанные менее опытными другими людьми, при написании которых к примеру никто изначально не делал код ревью(ибо в команде так не принято). Становясь тим лидом, у вас появляется некоторый шанс это изменить
Спасибо за статью, с нетерпением жду продолжения цикла. У меня также есть вопрос: каким образом рядовой разработчик может стать тимлидом и как дать понять руководству, что тебе это интересно? В моей практике тимлидами зачастую становились по принципу стечения обстоятельств, например ушел прежний тимид - нужен новый. Практически всегда эту роль предлагали сумбурно и "вдруг" человеку, который иногда даже не представлял себя в этой роли и соглашался с целью не упустить возможность, а после иногда разочаровывался.
Спасибо за вопрос. Самое правильное и простое - поговорить с руководителем. Объяснить что хочешь расти в тимлида. Лучше сразу обсудить, не только название должности, но и что именно и почему хочется делать. Это важно, так как тимлид в конкретной компании это просто шильдик в резюме, важно какие обязанности за этим словом стоят. Так же важно спросить, на сколько ты соответствуешь желаемой должности с точки зрения руководителя и если чего-то не хватает, то совместно составить план развития, что бы улучшить недостающие навыки.
Позиция действительно часто возникает сумбурно и если если у вас она закрывается случайным человеком, то ваш руководитель будет только рад такому разговору. У него появится кадровый резерв в виде вас, особенно если вы действительно этого хотите и готовы потратить время и силы на свое развитие.
В такой ситуации возможно вы получите свою первую команду даже без ухода предыдущего тимлида. Компании растут и в них появляются новые позиции даже без увольнений.
Это все прекрасно в статье, но на практике на всех собесах на лида ищут сильного сеньора с функцией менеджера. В особенности в Яндексе. Ты проходишь все те же собесы, как и сеньор плюс еще одна менеджерская секция.
Кстати вопрос, за 8 лет работы, делали ли вы коммиты в Тимлид роадмап и использовали ли его сами? https://github.com/tlbootcamp/tlroadmap
Что-то очень похожее, чуть ли не дословно, я недавно читал в книге Карьера разработчика. Стафф - круче, чем senior. Интересно, если LLM скормить эту книгу и попросить написать статью для хабра....
Особенности задач тимлида, или Что именно значит «управлять командой»