Expert JS React Developers for TUI wanted. Join Ciklum and get a $4000 sign-on bonus!
×Закрыть

Team Lead vs Senior Developer

Привет, форумчанин! Собственно вопрос, что бы ты выбрал — должность Team Lead’a, с его ответственностью за жизнь проекта или позицию Senior dev’a, как одного из ключевых разработчиков, но не основного человека на проекте?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Лучшие комментарии пропустить

Давайте разберемся с терминами.
1. Разработчик — низкий уровень ответственности, зарплата не зависит от показателей проекта. Лучший вариант, если хотите спать спокойно.

2. Тех лид. Тоже что и разработчик, только ещё присматривает компонентами и/или проектом в целом (с технической точки зрения). Помогает с выбором технологий. Отличный выбор, если хочется спокойно спать, но пользоваться повышенным уважением.

3. Тим лид. Основная задача — управление командой (сроки, владение кодом, ротация, отпуска). Как правило — совмещает ещё и функции тех лида или девелопера. Начиная с этой должности, становится очень важным навык умение слушать (и слышать!) других.

4. Проджект Манагер. Отвечает (иногда и материально) за проект в целом. С одной стороны — сделанный проект — это заслуга ПМ, с другой стороны — этого никто не признает :). Впрочем, то, что заваленный проект — это вина ПМ, соглашаются все.

Ну и самое главное: «тимлид» — это не лучше чем «девелопер» или «PM». Это просто другое.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Каждому свое, а я бы выбрал Software Architect. Это следующая ветка после TL.
Позиция TL — это такой себе передых от многих лет кодинга, чтобы дать себе возможность социально не деградировать, общаться с людьми, ибо как известно большинство девелоперов замкнутые товарищи и поговорить с ними кроме как на темы «железа», «технологий», в общем «по работе» — не о чем.
Лидами становятся грамотные девелоперы, те девелоперы, которые либо:
— общительные девелоперы, и балансировали между технарем и гуманитарием
— грамотные, но замкнутые технари, которые решили «выйти в люди»
В том или ином случае у лица должно присутствовать лидерское качество.

Team Lead — это Senior developer с организаторскими способностями. И да, он и немного HR, и архитектор, и бизнесаналист, и developer. Это тот самый зам руководителя (PM), который реально работает с людьми и с техникой, по аналогии с сержантом в армии или прорабом на стройке. Дальнейшая эволюция для тимлида — это Delivery manager, т.е техническое управление проектом в 20-30-40-50 человек, с делегированием непосредственного выполнения задания тимлидам. Для чего нужен PM без знания технической части — бюджет с заказчиком обсуждать, я полагаю.

Senior девов частенько назначают тимлидами, поруководить 2-3 разработчиками. Происходит это в уже устоявшихся структурах. Единственная их функция — обсуждать (или разжовывать) детали задач с подчиненными. Столкнувшись с ситуацией невыполнения сроков или проблемами в коллективе, такие «тимлиды» быстро сливаются. Настоящими тимлидами становятся те, кто готов наводить порядок в бардаке и заботиться о подчиненных. Тим лидер является звеном в цепочке управления, создающим условия для работы разработчиков всех уровней компетентности — от джуниоров до лидов.

офигеть тимлид тимлидов расхвалил :) дам свое определение, тл — низший менеджер, часто не очень хороший программист, но умеющий хорошо поговорить с начальством

Тимлид — это бригадир, управляет группой людей, оставаясь ее частью. Часто самый опытный, уважаемый член группы. Выполняет роль представителя команды и выразителя ее интересов.

Может ли плохой программист быть хорошим тимлидом — это вопрос. Тимлид часто не самый лучший программист в группе, но сказать что, он плохой программист... Плохой программист не будет пользоваться уважением членов комнды, а учитывая ЧСВ программистов, они в грош не будут ставить его советы, команды или приказы.

они в грош не будут ставить
И тут начинает работать старое-доброе «я начальник — ты дурак». Или в более современном варианте — «насяльника!»

Забыл еще добавить — тимлид умеет разговаривать не только с начальством (что верно) но и с подчиненными. Насчет не очень хорошего программиста — это зависит от человека, а не от должности. Так же учтите, при команде человек в 8 у тимлида останется в лучшем случае 1.5-2 дня на свою деятельность как программиста, и то придется постоянно отвлекаться.

но и с подчиненными
у нас такие люди пугливые, что быстрее язык проглотят чем что-то поперек скажут человеку с хотя бы номинальной властью, так что фидбек нечестный, а сам себя не оценишь
Так же учтите, при команде человек в 8 у тимлида останется в лучшем случае 1.5-2 дня на свою деятельность как программиста, и то придется постоянно отвлекаться.
вот именно, разве хороший программист согласится отказаться программировать с пользу разговоров?

Не понятен твой вопрос, ибо по карьерной лестнице после TL идут следующие 2 ветки: PM и Architect.

Разве в архитекторов разве после тимлидерства выростают? мне всегда казалось что тим-лид это первая ступенька уже в ветке менеджера. А до архитектора качаются через сеньор-дев -> тех-лид -> архитектор.

Компании схитрили, они сейчас экономят и на позиции TL хотят 2 в одном, непосредственно сам Team Lead и Tech Lead.
Я за все время видел только несколько вакансий тех лида, не вспомню компании, но кажется это были компании, которые действительно могут себе позволить отдельного спеца, который будет заниматься сугубо технической частью.
Tech Lead, как я это вижу, это аналог Junior Software Architect.

Забыл уточнить,
2 в одном -> Team Lead + Tech Lead = Team Lead
ибо тим лиды сегодня кодят и занимаются архитектурными вопросами, помимо основных обязанностей

Видать Вам некомпетентные лиды попадались. Если лид не очень хороший программист, то, простите, чем он вообще занимается в компании?

Если лид не очень хороший программист, то, простите, чем он вообще занимается в компании?
Ну кагбэ
он и немного HR, и архитектор, и бизнесаналист, и developer.
Собственно как и любой «полукровка» он не будет очень крут во всем, он будет посредственным (если это слово забивает ваше ЧСВ используйте словосочетание «достаточно компетентен») во всем.
Тут лид — это тим лид, а не тех лид.

Мне просто сложно представить ситуацию, в которой человек, который умеет немного HR-ить, общаться с начальством и анализировать требования, но при этом из алгоритмов сортировки знает только метод пузырька, вдруг резко строит архитектуру и руководит процессом.
Ну, или же у меня неправильное представление о том, чем я должен заниматься)) Так как процентов 80 своего рабочего времени занимаюсь именно техническими вопросами.

но при этом из алгоритмов сортировки знает только метод пузырька, вдруг резко строит архитектуру и руководит процессом
1) Архитектура и «управление процессом» — это слабо связанные вещи
2) Сортировки к обеим этим вещам имеют довольно слабое отношение (особенно к управлению)
.
Ну, или же у меня неправильное представление о том, чем я должен заниматься))
От тут то и проблема, поэтому, на сколько я понял, и возникла эта тема: вы занимаетесь одним (80% технические задачи), Sergey Petrov совсем другим, есть еще несколько других вариантов.

Не очень удачно я пример подобрал.
В любом случае, ваш ответ понятен: поскольку я смотрю на позицию лида сквозь призму своих ощущений, мне и сложно представить на этой позиции человека со слабым уровнем программирования.

у тебя аксиома «я крутой», и из этого следствие что тимлид — это венец эволюции, давай хотя бы следствие уберем, а то вообще получается очень высокомерно :)

Хм... интересно, из чего ж такой вывод? Я ни разу не считаю себя крутым, просто говорю о том, что твоя аксиома «тимлид — плохой программер» неверна. Точно так же можно утверждать «программист на [hated_language_name] — плохой программист».

ну а чего он будет хороший программит, если должность не техническая, а управленческая? бывают исплючения, но это теже самые исключения когда пм хороший программист

Эта должность не чисто управленческая, а гибридная. Затем, тут еще вопрос, что понимается под «плохой программер». Тим лид вполне может уже не знать каких-то частностей или нюансов определенной технологии, но я не могу себе представить тим лида, который бы плохо ориентировался в общих вопросах разработки ПО (написание хорошо читаемого кода, юнит-тестирование, плюсы-минусы технологий и архитектурных решений, оценка трудозатрат)

гибриды обычно уступают полным версиям, но компенсируют это универсальностью

ПМ хороший программист — да, исключение, потому как ПМ — это чисто управленческая должность. С лидами же всё зависит, видимо, от степени мутаций — если лид подался целиком и полностью в менеджмент, то он начнёт терять навыки и станет не очень хорошим программистом. Но тогда на проекте должен быть человек, ответственный за технические решения, потому как такой лид не сможет, как сказано выше, оценить плюсы-минусы технологий и архитектурных решений. В таких случаях появляются всякие тех-лиды, лид-девелоперы, проджек-лиды и т.д.
Судя по всему, проблема в том, что каждая компания понимает разное под этой должностью — отсюда и все споры.

Я бы даже сказал, довольно часто один и тот же человек совмещает две роли — тим лида (управленца с хорошим техническим бэкграундом) и архитектора

еще и полы моет перед работой :) у тебя очень занижены требования к кандидатам, раз такое часто бывает в твоем понимании

у тебя очень занижены требования к кандидатам, раз такое часто бывает

Не совсем понял про требования к кандидатам. На небольших проектах до 4-5 человек такое бывает сплошь и рядом в первую очередь потому, что чисто тимлидской работы на таких проектах пару часов в день от силы (обычно меньше), а «размазывать» тим лида по нескольким проектам — это автоматом значит понизить эффективность его работы на каждом из них. Совмещать роль тим лида и тех лида (архитектора) оказывается гораздо выгоднее.

мне показалось что ты написал что один человек совмещает роль архитектора и тим лида и это часто встречается, и это не забивание на одну из ролей, а обе на отлично, а вот теперь смотрю — просто совмещение, ну да... чего только не встретишь нынче

мне попадались тимлиды, которые программировали и больше ничего не делали :) а когда тычешь в их говнокод и говоришь: «так нельзя» — не нравится им :) тиллид не программист, а мелкий начальник программистов, программировать почти не должен, так с какой радости он будет хорошим программистом?

Дык, это не тимлиды — это люди с «синдромом вахтёра»: дали власть, так вот и нехер теперь мой код тут обсуждать))
Опять же, по моему личному опыту, программировать стал меньше — это да. Но не прекратил совсем, плюс читаю код коллег в особо интересных частях проекта, да и контрибьютингом в 3rd party занимаюсь в свободное время, чтобы в тонусе себя держать. Количество производимого мной кода стало меньше, но на счёт качества не думаю — оно ж с годами не уходит))

Мой лид на текущем проекте — блестящий программист, а по широте охвата знаний за рамками проекта вполне тянет на техлида. Но и менеджмент у него поставлен на хорошем уровне. Редкий случай отличного лида.

Чушь! Сколько людей, столько «конфигураций» тим лида.
Team Lead — это такая же абстракция, как и Продавец. Те или иные минимальные способности и ответственность лида зависят от масштаба компании и задач, решаемых на конкретном месте.

Team Lead — это Senior developer с организаторскими способностями. И да, он и немного HR, и архитектор, и бизнесаналист, и developer.
Для чего нужен PM без знания технической части — бюджет с заказчиком обсуждать, я полагаю.
Получается, ПМ (управляющий проекта) не занимается (не участвует) подбором нового персонала, не знает о проблемах в коллективе (которые могут повлиять на сроки и соответственно цену), не имеет представления об архитектуре (грубо говоря о качестве сделанного), не имеет отношения к анализу требований. И при этом при всем, будет обсуждать цену работ? А если ПМ (управленец) вовлечен во все эти моменты, то нах вам 2 __разных__ должности у которых болит про это все голова?
.
Собственно блеск и нищета гуаносорса:
Дальнейшая эволюция для тимлида — это Delivery manager, т.е техническое управление проектом в 20-30-40-50 человек
А в проектах, где задействано менее 20 человек, не нужно «доставлять» результат работы заказчику?
Еще есть классная формулировка «разработчик уровня тимлид» :)
Ситуация в общем простая:
Нормальных управленцев нет (очень мало), синьора с аж(!) 3 годами ОР надо куда-то повышать (шоб не свалил, шоб другие синьоры не начали требовать ЗП как у него и тд). От и придумывают 100500 должностей.
И при этом при всем, будет обсуждать цену работ?
Да. В промышленном подходе. Кустарщина, понятное дело, удел отечественных «лидов».
От и придумывают 100500 должностей.
Где-то так. На самом деле ситуация сложнее и дело именно в кустарщине. Никто не умеет готовить ни людей, ни процесс, ни проект. За продукт вообще молчу. Более или менее научились «пилить» заказчика: пользуясь случаем хочу передать привет агиле. Под этим же соусом — «гибкая разработка профессиональная команда профессиональных профессионалов в профессиональном процессе бла-бла-бла» — это всё подаётся как некая видимость таки реального процесса.

ЗЫ: причём это не только в программировании — это у здесь везде так. Чуть ли не единственная организация, реально поднимающаяся над всем этим болотом — не поверите, таки Макдональз.

Птицу видно по полету видно опытного человека. Я встречал компании вообще без PM. И ничего — работают, успешно. Размер небольшой — до 50 человек. В больших же компаниях, PM имел профильное образование (например, финансы), достаточное чтобы говорить с бизнесом на одном языке, и самое элементарное техническое.

Нормальных управленцев нет (очень мало), синьора с аж(!) 3 годами ОР надо куда-то повышать (шоб не свалил, шоб другие синьоры не начали требовать ЗП как у него и тд). От и придумывают 100500 должностей.

Все верно, еще сверху добавляется проэстимейтить «большую» задачу, и разтусовать ее помеж нескольких джунов/мидлов. Еще иногда могут дать поскрамить, вот.

Тян не нужны Тимлиды не нужны.
Команда должна работать как одно целое и сообща нести ответственность за проект. Делить членов команды на ответственных и неответственных — глупо.

К сожалению ответственность всегда несёт один, так уж сложилось в истории.

Угу.. вот так вот она сама собой и заработает...

Как показывает практика, команда сообща несет ответственность до первого факапа. А потом — виноват Петя — Нет Вася поздно скинул верстку — нет Вова мне дал плохой дизайн — Нет заказчик вообще мудак.

Ну да, особенно если устраивать разборки «кто виноват»

А таких разборок нет, только если и так понятно кто виноват. Например — ПМ/тимлид.

В случае же, если виновата абстрактная команда, то либо все забивают на эту «вину», и мы получаем коллективную безответственность, либо один из участников команды становится лидером, который собирает общие командные сборы, и устраивает показательную порку провинившемуся. Т.е. собственно команда сама приходит к понятию тимлида.

Бр-р-р. Что за ужас! Какие показательные порки? Зачем? Если есть проблемма — просто решайте её, это и есть работа начальника. Вот и всё. зачем нужна «вина и порки»

А пыточная значит простаивать будет? Палача, значит, уволить? А у него жена, два маленьких ребенка. Вам не стыдно, а?

P.S. Так уж устроены люди, что сначала выясняют «кто виноват», а потом уже (если хватит времени) — что делать. Именно для этого и придумали начальников — они априори виноваты, и поэтому первый шаг можно пропустить.

Лучше не «кто виноват» а «почему случилось» и «что дальше». Гораздо эффективнее и быстрее. А то делать виноватыми, искать мальчика для битья, пороть — неблагодарное занятие. Да и для работы совершенно бесполезное — разбегутся из такой команды норм. спецы.

да никто, это скорее рассуждения на тему :)

Единственный вариант коллективной ответсвенности придумали римляне, когда просто казнили каждого десятого в проштрафимшемся (лее написал это слово) легионе (но возможно и это сказка).

Что ты скажешь, когда разработчик заявит:’мне переработки не оплачивают’и уйдёт домой?

Ничего не говорить, сразу бить в бубен

ту що бубен буде ваш, а не його :))

Но люди по факту либо ответственные либо безответственные.
И очень быстро «ответственные» начинают хотеть получать больше чем «безответственные»

Если за ошибку в расчётах отвечает больше одного человека, виноватых не найти. © Мерфи

Команда должна работать как одно целое и сообща нести ответственность за проект

Что тянет за собой требование, чтобы все в команде были самомотивированными профессионалами с хорошими навыками командной работы. Наверное, где-нибудь в 37 Signals или Valve такое достижимо (т.к. конторы небольшие и очень придирчивы к нанимаемому персоналу), но в среднестатистической IT-компании заполучить такую команду со старта — это утопия.

Вырастить же самоорганизующуюся команду — можно, чем толковый тим лид и должен, в частности, заниматься. Причём, поначалу, может быть, придётся немного и поиграть в «насяльника», если с мотивацией и организацией все совсем плохо.

Все-таки неправильно поставлен вопрос. Выбор зависит от того сколько свободы в принятии решений имеет та или иная должность и как эта степень свободы согласуется с твоей зоной комфорта.

Самое противное в работе team lead-a это то что приходится увольнять людей.

Ага, много лучше отдуваться за невыполнение тасков и срыв проекта...

Нет уж, лучше уволить.

Конечно, я просто имел в виду что в контексте сравнения лида и просто программиста, второй пересекается с этим аспектом значительно меньше.

Самое противное в работе team lead-a это то что приходится увольнять людей.
Не совсем понятно нах тогда надо ПМ?
Или даже так: Ну теперь-то вы поняли зачем надо ПМ:)

ПМ в этом как и многих других это чисто формальная фигура. ТЛ смотрит за квалификацией, производительностью чела, и фактически решение принимает он, а ПМ только сообщает известие.

Чего же тут противного? так вообще лафа. во-первых делаеш полезное дело, во-вторых чужими руками.

Та мне лично пофиг чьими руками, меня больше смущает что увольняемый тоже человечишко, со своими надеждами и стремлениями, и семьей на шее.

Ну вы можете отдать ему часть своей з.п., а он пусть и дальше плохо работает, ведь семья — это святое! Вас устраивает такой подход?

Меня не устраивает, но как я сказал, я испытываю негативные эмоции от всего этого.

В США тратятся миллиарды долларов на помощь безработным трудоспособным людям (инвалидов и прочих я не беру), именно трудоспособных, которые просто не хотят работать, если им и так платят. Угадайте откуда идут эти деньги, когда в следующий раз будете рассуждать о налогах.

В штатах не социализм, на все (бедность, образование, медицина) идет 10% бюджета, или 4% от моих доходов en.wikipedia.org/...e_United_States. По сравнению с 25% на армию это понты.

Если вы готовы выделить часть своих денег на бездельников, то кто я такой чтобы вам запретить! Главное убедите себя что это правильно и хорошо и все так должны делать.

Я думаю это просто фича развитого общества, из-за автоматизации и эфективности и т.д. далеко не всем найдется рабочее место, и это ок кидать им 5% от бюджета на пропитание (если предположить что остальные 5% идут на нужды действительно нуждающихся, например степендии перспективных студентов).

Просто подумайте о том, что заказчик такой же человек, со своей семьей и прочим.
Но кроме всего прочего на продукте заказчика возможно будут кормиться десятки людей.

Так что пожертвовать одним медленным товарищем, который не желает или не может работать, чтобы помочь остальным — норма.

Повторю еще раз, я отлично понимаю правильность увольнения плохих сотрудников, но по прежнему испытываю неприятные ощущения от этого процесса. Не исключаю что есть люди которым это нравится.

Все верно, но мы ведь люди.
Впрочем, когда увольняешь такого себе программиста и конфликтного человека — то испытываешь только облегчение.

А вот когда увольняешь отличного человека, потому что он не справляется с работой — то чувствуешь себя крайне паршиво.

У меня это прошло после 4го увольнения.

В проектах всегда есть более сложные и менее сложные части. Последних более чем достаточно чтобы загрузить любого.
Если человек не справляется с сложными задачами ему можно отдавать на откуп простые и рутину.
Если не справляется и с этим, то возникает резонный вопрос — а зачем он тут собственно?

Важно просто не перенести личные симпатии/антипатии на работу.
Увольнять конфликтера, но который отлично работает я бы не стал.
Просто изолировать его от мест возможных конфликтов с другими, а уж конфликты со мной я как-нибудь переживу :)

а как к тебя в команду попадает человек, который не может решать простые задачи и рутину? вообще тех. собеседования нет?

хз. Я вот наример не люблю рутину и отвратительно перформлю на «простых задачах», собеседования прохожу на ура.

Полностью удаленная команда имеет свою специфику.
Технически человек может быть подкованным, но в плане дисциплины и производительности на тех или иных задачах откровенно плавать.

Человек — точно такой же инструмент, как язык, IDE, фрейворк, архитектура, процесс. То, что «насяльника ака тимлид» этого не понимает — всего лишь частное проявление более общего точно такого же непонимания ним языка, архитектуры, процесса, и прочих технических и организационных моментов.

Абсолютно верно. Поэтому правильный «насяльника» будет применять инструмент соответственно его назначения и возможностей и при необходимости менять на более подходящий.

Ну а вы можете продолжать забивать гвозди пуховой подушкой любой ценой.

не знаю как там где, а в украине до недавних пор это была не большая проблемма. Как правило увольняемые находят работу не хуже.

хотя с другой стороны бизнес ведёт себя часто не логично. Иногда тянет тех кого не надо тянуть, иногда увольняет чаще чем надо бы.

Не совсем так. Тимлид, как, правило, не парится финансовой составляющей, так что вариант «посадить тормоза на никому не нужные задачи» — для тимлида очень даже ок.

Выбирать кого уволить нужно будет только тогда, когда придет ПМ и скажет, что выросла цена разработки (и с этим нужно что-то делать).

ПМ в украинскорм аутсорсе, например, не занимается бюджетом.

Я точно не знаю чем аутсорс отличается от аутстаф, я имею в виду компании- посредники.

Тем что компания предоставляет.
В аутсорсе компания продает результат. В аутстафе — людей.

я бюджета действительно не знаю, но я знаю что не могу нанять просто так много людей на проект, а вот выгнать и нанять — запросто.

Ну это смотря в какой компании.. лично мой опыт говорит о том, что эта нелегкая задача ложится на плечи даже не ПМов, а руководителей отделов

А почему бы просто не промотивировать, например Кнутом, как это советовали в соседнем топике?

По себе заметил, если мне вдруг внезапно хочется становиться техлидом, тимлидом и вообще начальником, как бы это ни называлось, значит текущий со своей должностью не справляется (или же его просто нет по штатному расписанию), на проекте бардак и для сохранения нервов проще всего поменять работу. Вот ни разу не было еще, чтоб на проекте было все хорошо, начальство было адекватным и мне вдруг захотелось командующую должность.

Это прекрасный стимул для саморазвития. Я начинал на «унылом» проекте где мне изо дня в день приходилось лепить заплаты только для того, что бы завтра порвалось рядом.
Это подвигло меня «поднять голову» от кода и начать интересоваться рефакторингом, шаблонами, ООД. А когда я понял что внедрить на этом проекте подобное никто не даст — то начал читать и про правильные методики разработки (SCRUM, MSF, CMMI, RUP) и понял что водопад — зло. И что однажды накопив технический долг и став «гнилым» проект уже никогда не исправится — никто не захочет за это платить.
Со временем даже прочитал некоторые книги по менеджменту, вроде «Путь камикадзе». Это помогает понять мотивацию ПМов и трезво оценивать перспективы проекта. Очень нужно на собеседованиях: несколько вопросов и сколько бы ПМ не врал — сразу можно разгадать где заманивают на унылый, гнилой проект.
Сейчас при желании я легко мог бы выполнять роль ПМа (и выполнял, пока он был в отпуске) или тем более Тим-Лида (у нас таких «недо-МПов» в компании не держат). Но мне это не интересно. Хорошо, когда человек на своем месте — мое место это Тех-Лид (архитектов компания не может себе позволить).

А когда я понял что внедрить на этом проекте подобное никто не даст — то начал читать и про правильные методики разработки (SCRUM, MSF, CMMI, RUP) и понял что водопад — зло.
Если не называть водопадом водопад в стиле 70-х, с одной итерацией, то RUP, MSF — это и есть водопад, только не просто водопад, а водопад ® от IBM ® и Microsoft ® соответственно с кучей рюшечек ©. CMMI — вообще не процесс разработки (он может быть любым), а способ оценки его качества, тоже ®©.
Лично я довольно скептически отношусь к объявленными серебрянными пулями Agile и SCRUM (особенно с учетом того, что второй при объявлении себя наследником первого наплодил ритуалов чуть ли не больше чем какой-нибудь RUP) и всяким новомодным Kanban. Моя точка зрения совпадает с Макконеловской: хорошие команды делают качественные проекты с любой методологией, плохие команды смена методологии не спасает.

100% такая же ситуация была. На проекте бардак из говноспагетти, код постоянно повторяется, глючит... Лид не выполняет своих обязанностей, место как бы вакантное, но как только начинаешь что-то пытаться менять, как тебя сразу ставят на место.Поэтому из своего опыта лучше сразу менять работу, с кем поведешься того и наберешься.

позиция vs уровень квалификациии.
топикстаратер, у вас каша с терминологией.

Открою вам тайну — позиция Senior dev’a тож бывает.

А можно просто dev’а, без остальных лычек?:)

Senior однозначно.
Но постановка вопроса в целом не совсем корректна, т.к. Team lead — должность, Senior — во многом таки звание разработчика, Senior developer — просто одноименная должность. Вы никогда не видели бойких девочек или пацанчиков в костюмах с зализанными волосами на позиции TL ? Как они ими стали? Чтобы было яснее представьте, что Senior — капитан вооруженных сил, а Team lead — командир роты, так думаю будет понятнее. Представьте что командиром роты поставят чувака, который был пацифистом-полотером на гражданке и по факту умеет только бегать по штабу за обер-офицерами, а потом отправили роту на важное задание например границу охранять или хотя бы связь прокладывать?

В разных проектах у team-lead-ов бывает очень разный круг обязанностей как например: от тупого сидения в скайпе/на митинге до многостаночник всего и вся, т.к. дали тупых джунов. В целом у team-lead-а намного-намного-намного больше геморроя, начиная от планирования ресурсов, тасков, грызни с PM-ом за проект, коммуникациями со смежными отделами, обучение джунов и прочее-прочее. Во многих случаях на одного TL сваливается работа: senior-developer, PM, инструктор, секретарь, BA. Не многовато ли за одну з.п. ?

На senior-ов в Украине колоссальный спрос, раз в 10 больше чем на лидов. Без персоналий не обойтись — за последние 1,5 месяца мне прислали 16 предложений на senior-а и лишь 1 на лида. Хотя я нигде не выставлял свое резюме.

Почему я называю работу TL геморрой? Потому что ответственность и нервы без адекватной компенсации — геморрой, эдакая однобокая система. Разница з.п. senior -> TL составляет всего 400-800$ в пользу последнего, что при вилке для senior-а 2,5-3,5к$ является не такой значительной суммой как возросшая нагрузка. По-хорошему лиду надо платить x2 как senior-у или даже больше. Любой senior если ему нужны деньги легко может добрать +500 в той же фирме обучая джунов, участвуя на внутренних проектах, ивентах и прочем или дописав себе +1 часик во внутренний овертайм.

В завершении хочу сказать, что все зависит от поставленных процессов в фирме от наличия туалетной бумаги и сахара и заканчивая стратегическим планированием у топов. Если хотя бы часть процессов идет через ж*пу, это вызывает цепную реакцию по всей организации, все начинают лодырничать и расхлябанно относится к своим обязанностям. В такой организации быть TL — значит быть камикадзе.

Но постановка вопроса в целом не совсем корректна, т.к. Team lead — должность, Senior — во многом таки звание разработчика
 — имелось в виду, что бы выбрал среднестатистический форумчанин — должность Team lead’а или должность Senior разработчика.
Разница в природе обязанностей между приведенными позициями думаю абсолютно очевидна.

Ну допустим будет 20 голосов senior и 8 лид или 15 senior 15 лид и какой в этом смысл? Это как расчет средней з.п. — настолько же бессмысленно.

Смысл? Всё очень просто — узнать мысли других людей на этот счёт.

відповідно правильна відповідь не сінйор, а тех лід, з лишанням більшості організаційних питань на ПМ, чи якщо такі існують — скрам мастера :)

Давайте разберемся с терминами.
1. Разработчик — низкий уровень ответственности, зарплата не зависит от показателей проекта. Лучший вариант, если хотите спать спокойно.

2. Тех лид. Тоже что и разработчик, только ещё присматривает компонентами и/или проектом в целом (с технической точки зрения). Помогает с выбором технологий. Отличный выбор, если хочется спокойно спать, но пользоваться повышенным уважением.

3. Тим лид. Основная задача — управление командой (сроки, владение кодом, ротация, отпуска). Как правило — совмещает ещё и функции тех лида или девелопера. Начиная с этой должности, становится очень важным навык умение слушать (и слышать!) других.

4. Проджект Манагер. Отвечает (иногда и материально) за проект в целом. С одной стороны — сделанный проект — это заслуга ПМ, с другой стороны — этого никто не признает :). Впрочем, то, что заваленный проект — это вина ПМ, соглашаются все.

Ну и самое главное: «тимлид» — это не лучше чем «девелопер» или «PM». Это просто другое.

3. Тим лид. Основная задача — управление командой (сроки, владение кодом, ротация, отпуска). Как правило — совмещает ещё и функции тех лида или девелопера. Начиная с этой должности, становится очень важным навык умение слушать (и слышать!) других.
У меня сложилось впечатление что Тим лид — это попытка сэкономить, объединив роли ПМа, Тех-лида и еще немного HRa в одном человеке.
Я думаю такая должность неплохо подойдет человеку, который знает всего понемногу: немного девелопил, немного «архитектил», читал про Скрам и другие методики, интересовался менеджментом. Синьор девелоперу, который много лет работал и углубленно изучал технологии стать Тим Лидом — это потерять половину своих знаний. Такое имеет смысл только если надоело девелопить и хочется стать менеджером.

Есть нюанс: у нас на тим лида очень часто завязаны решения уровня тех лида. Со всеми вытекающими из:

немного девелопил, немного «архитектил»

Нет попытки сэкономить. Есть реальные ситуации, когда три человека это еще много (они будут недозагружены), а ноль человек уже мало.

Альтернатива отдать часть вопросов на аутсорс, но это сложно и с непредсказуемым результатом, лучше всего сейчас это удается с обязанностями HR.

Чего чего? Обязанности HR на аутсорс? Это какие такие обязанности? чашку\футболку подарить раз в год? — такое действительно можно, а вообще лучше непосредственного начальника работу с персоналом не проделает никто... ИМХО её зааутсорсить не возможно, можно только болт не неё забить, что и происходит в 90% случаев.

Подобрать резюме и провести первичные (не технические) собеседования как минимум.

Хм. А причем тут лидская работа? Большой и неаутсорсимый кусок работы лида это работа по линни «человеческих ресурсов» с уже нанятыми людьми... Следить и за перфомансом, и за их развитием и за настроением, конфликты всякие там решать. Кверти там вверху правильно говорит — бывает такое, что и оно не надо, но я вот такого почти не встречал.

Именно потому и проблемно аутсорсить должности, а не конкретные задачи. С другими позициями еще сложнее.

И к тому же, большое ты получаеш удовольствие от этих первичных не технических интервью как кандидат? Пльзы от них, когда ХР не может ответить на простейший вопрос по проекту типа сапорт или девелопмент снуля, аутсорс или аутстаф, а кого конкретно вам всётаки надо?

А я, как кандидат, еще и оргазм от собеседования получить должен?

HR бывают разные, правда тех, что лучше обычно меньше :) как и всегда.

Нет, блин, Кандидат должен страдать! Иниче как же он поймёт, что «работать в нашей компании честь» :)

Кроме шуток, общаюсь с парой заграничных контор — они по-моему именно так и думают :)

Нет попытки сэкономить. Есть реальные ситуации, когда три человека это еще много (они будут недозагружены), а ноль человек уже мало.
Когда человек занимается чем-то, в чем имеет мало опыта, «в нагрузку», просто потому что некому — это плохо. Тим-лид, который еще вчера был девелопером и прочитал одну книгу по менеджменту, или еще вчера был QA и прочитал книжку про патерны.
У нас если проекты небольшие, то может быть один ПМ на 2 проекта. Но это опытный ПМ, а не скороспелый Тим-Лид.

Мы не живем в идеальном мире.

У меня сложилось впечатление что Тим лид — это попытка сэкономить, объединив роли ПМа, Тех-лида и еще немного HRa в одном человеке.

Не совсем так. У нас на проектах, кроме самых маленьких на 1-2 человека, как правило, есть и тимлиды, и ПМы. Разница, скорее, в том, что у тим лида обязан быть технический бэкграунд, знание процессов разработки, но вполне может не быть опыта стратегического планирования, бюджетирования, торговли с заказчиком. У ПМа же наоборот — может быть весьма слабая тех. подготовка (в «технике» он полагается на тимлида и тех. лида / архитектора), но «бухгалтерия» проекта, сроки крупных поставок и отношения с заказчиком — в очень большой степени на нём.

Смешались в кучу кони, люди... (к)

В поэзии не силён, извините

Давайте разберемся с терминами.
Давай так: где больше платят, а за один и тот же обьём работы?
«тимлид» — это не лучше чем «девелопер» или «PM». Это просто другое.
Однако, это путь от разработчика к ПМ-у, другими словами от рабочей скотинки к начальнику.
Однако, это путь от разработчика к ПМ-у, другими словами от рабочей скотинки к начальнику.
А оно вам надо? Там уже «ровно 8 часов» не поработаешь

Зато можно иногда работать меньше восьми часов :) Особенно будучи ПМ-ом в маленькой фирме. Задачи розданы, люди работают, вопросов не возникает. В случае чего телефон есть и емейл — сидеть на работе нет необходимости.
Только не рассказывай пожалуйста, что это мои фантазии: я лично это видел и неоднократно и не в одной фирме.

Если вопросов не возникает — это ещё не значит что все хорошо :).
У вас классическое ложное представление об управлении: достаточно сказать «сделай» — и все будет сделано. Это не так.

А, ну и да. У недозагруженного манагера зарплата не очень.

У недозагруженного манагера зарплата не очень.
Уж во всяком случае больше, чем у синьора в той же фирме :)
У вас классическое ложное представление об управлении: достаточно сказать «сделай» — и все будет сделано. Это не так.
Кто б сомневался, однако управление хорошо тем(и плохо тоже), что работа делается чужими руками. Соответственно, пока она делается можно расслабиться. Ну вот ничегошеньки не изменится, если я буду стоять у разработчика за спиной.
Уж во всяком случае больше, чем у синьора в той же фирме :)
Не факт. Знаю довольно крупную фирму (200+) где ПМ-ы получали меньше разрабов. А в мелких — так и подавно. (не путайте ПМ-а с владельцем)
Кто б сомневался, однако управление хорошо тем(и плохо тоже), что работа делается чужими руками
Нет. Управление — это решение проблем команды. Вы, конечно, можете заниматься пересылкой писем от заказчика к разрабам, но не ждите за это высокой зарплаты.
Управление — это решение проблем команды
А если у команды нет проблем? Достигается наймом хороших людей с которыми комфортно работать

Нет проблем только на кладбище. Для рабочего коллектива, решение постоянно возникающих проблем и конфликтов является перманентным состоянием.

Для рабочего коллектива, решение постоянно возникающих проблем и конфликтов является перманентным состоянием
Зачем же ты берёшь на работу конфликтных людей?

Потому что мертвые не умеют кодить.

Тут выступает на первое место навык подбора тех, с кем комфортно работать. В двух словах: задроты не нужны, они будут дёргаться, всем мешать и слёзно просить переписать всё вот с этим фреймворком.
С другой стороны, нужны уверенные в себе и дорогие. Они как правило не создают проблем

В двух словах: не конфликтуют только мертвые. И да, конфликт — это не швыряние мониторов по офису. Это просто два разных мнения по одному вопросу.

А уж «у команды нет проблем» — это из области «нанимать разработчиков, которые не делают ошибок и не срывают сроков»

не конфликтуют только мертвые. И да, конфликт — это не швыряние мониторов по офису. Это просто два разных мнения по одному вопросу.
На разрешение конфликтов такого рода не надо тратить всё время + люди могут договориться между собой самостоятельно

Из ваших слов можно делать вывод сто ПМом вы не работали, даже близко

Конфликт — это просто два разных мнения по одному вопросу.
Конфликт это не просто два разных мнения по одному вопросу. Это в первую очередь негативное отношение к субъекту, причем независимо от количества мнений.

Это ваше определение конфликта.

С подбором в команду тоже не всё так просто. С хорошими людьми конечно хорошо работать, вот только где их таких взять в промышленных масштабах, все как правило обычные попадаются. А подбирать с нуля вообще редко где возможно.

Вот недавно офер был начиналось с «ищем крутейшую команду для крутейшего проекта» а закончилось «есть два девелопера, к ним надо лида и можно стартовать»

Если проектов больше одного — не укладываешься даже в 8 часов :) + написание документации, отчетности и еще всяких манагерских штучек.

Я не думаю что вы со своими ЧСВ и Активной Гражданской Позицией сможете конструктивно решать конфликты в команде, распределять ресурсы и таски, а также общаться с кучей разных людей, в т.ч. не очень умных заказчиков, HR-ов и т.д. Ведь для этого нужно будет перешагнуть через пропасть своего эгоизма, чего вы 100% не сделаете.

Конечно не смогу, в данный момент, однако я занимаюсь на курсах и над собой работаю.

Человек на форуме и человек на работе и даже в жизни могут быть разными.

Не могу согласиться. ПМ это скорее часть команды, чем надзиратель. Просто ответственности больше.

Для начала решите для себя, нужен ли вам менеджмент вообще, потому как в менеджменте есть такие задачи, которые вам будут явно не сильно нравится, тем не менее, их придётся выполнять. Я бы на вашем месте просил секретаря-ассистента, который бы выполнял всю рутину, в таком случае у тим лида было бы оч. мало негативных сторон. Я бы пробовал в любом случае, но про технические скилы забывать нельзя.

При всём уважении, это существенно разные профессии — инженерная и управляющая соответственно (кроме пограничных вариантов вроде Tech Lead’а). И не отвечает Team Lead за проект, для этого есть менеджер проекта — дело Team Lead’а координировать работу группы разработчиков и факторизовать информацию о состоянии дел в группе для передачи вышестоящему начальству. Расхожая традиция повышать инженеров до менеджеров противоестественна.

Что касается лично меня, то когда меня стали форсово тащить в управление на одном из предыдущих мест работы, я уволился. Я программист. Я не умею управлять людьми, я умею управлять железом.

И не отвечает Team Lead за проект, для этого есть менеджер проекта
-это зависит от уровня бюрократии на проекте, не везде все по книжкам, да по agil’y.

Я бы добавил уточнение об уровне бюрократии на проекте в исходный вопрос, если от него так много зависит.

на разных проектах в понятие тим лид вкладываються нимного разные вестчи.
Также как и в синьйор.

В таком случае вопрос стоило формулировать как «должность непойми кого с отпотолочным списком задач или должность непойми кого с отпотолочным списком задач?». Формализм на то и нужен, чтобы можно было вести дискуссию, не запутываясь в значении терминов.

Помниться тут были уже эпические обсуждения «тим лид» вс «тех лид» с попытками доказать что «тимлид» не нужен и прочее прочее. Но к знаменателю тогда ничкто и не пришел.
Мало того, насколько мне известно в некоторых конторах, на обычного синьйора ложиться список задач, которые я делал под тайтлом «тим лид», так что все, к сожалению, очень разплывчасто...

Бытует мнение, что достойным Senior Developer’ом стать намного проще чем Team Lead’ом. К тому же, в Украине на роли Team Lead’а числится очень много случайных людей. Это невелирует стоимость роли/должности, поэтому советую идти в Senior Developer’ы. 23-летним тим лидам очень тяжело опускаться с небес на землю, при смене работы.

нормальный тим лид стоит очень хорошо, одинаково сложно становится достойным лидом и синьором

Я всегда думал что достойный лид, он по умолчанию достойный дев.

Ключевое слово «нормальный».В тим лиды стоит идти когда просто девелопить надоело и хочется чего большего. Само собой, если есть соответствующий бекграунд и желание.
Под соответствующим бекграундом я понимаю в том числе и сеньйористость в умении разрабатывать. Человек, который ничего не достиг на поприще в разработки — вряд ли будет успешен как тим лид.

в Украине на роли Team Lead’а числится очень много случайных людей.
это 100%

Ну так лид тоже может всегда задаунгрейдится в простые девы. Я так делал много раз уже за последние 10 лет.

тоже когда-то так думал, потом с удивлением обнаружил что текучка среди «менеджеров среднего звена» и ХР-ов самая высокая в фирме, затем по списку шли лиды, и только за ними все остальные.

хе, хе. Кстати да, пили они как-то бодрее чем рядовые девы:)

А вообще по-моему это миф о том девелоперу легче поменять работу. Про тимлидов не уверен, имхо это существа в каком-то пограничном состоянии, а вот менеджерам повыше работу поменять врятли сложнее чем девелоперам. Да вакансий может быть и меньше, но и менеджеров таких тоже существенно меньше, особенно толковых и с релевантным опытом.+связи накопленные за годы помогают + часть из них таки могут иногда и в девелоперы вернутся.

Был тимлидом, при очередном смене места работы успешно «даунтшифтнулся» до обычного дева (без привязки к зп). Результатом — доволен.

Поскольку есть с чем сравнить, не поделишься «+» и «-» , тимлид -дева

Как было сказанно высше — зависит от конкретных имплементация данных тайтлов на конкретных проектах.
Из того что у меня было, по тим лиду, основное это фокусировка на «виденьи проекта», как со стороны конечной функциональности, так и со стороны архитектуры. Грубо говоря, если интересено вникать в проект со стороны бизнес сайда, взаимосвязей функций, пользовательской стороны, и при этом же, хорошо знать проект и принимать решения на архитектурном уровне, то ТЛ — это самое оно.
Зато минусы — куча отвецтвенности, нервотрепки как со стороны бизнеса, так и со стороны девелоперов, митенги митенги митенги омгубейтеменяктонибуть11, и тому подобное.

мои впечатления
Про тимлида:
+ офигительное чувство собственной значимости
+ Бабло (тимлиду обычно сходу прелагают больше. Собственно окончательно убедила идти лидить фраза ейчара с ЕПАМА «ну у нас есть такие зарплаты но не для Синьёр Инженеров»)
+ Лично у меня была малость к лидству склоноость, нравилось
+ Больше возможность выбора чем заниматся.... правда меньше времени на это
+ Больше доступа ко всяким корпоративным ништякам типа конференций (конкретно в случае той компании)
— надо сидеть одной жопой на двух стульях. (и техническом и организационном) Людей которые делают и то и другое по-настоящему хорошо я не встречал. У всех провалы либо там либо там.
— в моём случае была «угроза» перейти в нетехнические менеджеры. В наших реалиях мне такой переход кажется ошибочным.

Про девелопера:
+ Существенно меньше гемороя, я дважды уже уходил с лидской должности на просто инженерскую, каждый раз этому сопутствовало ощущение халявы
+ понятней что делать для роста. Понятнее как оценить этот рост.
— появился начальнег который знает какие таски тебе лучьше делать.

та же история.

Вообще в жизни попробовать нужно всё :) но мне ИМХО девом больше нравится.

Основной человек в проекте — инвестор. Всё упирается в бабло)

Подписаться на комментарии