Pull to refresh

Comments 39

Тут много зависит от здоровья команды и самого себя.
Мне повезло с двумя вещами, адекватным ПМ и тем что я команду собрал сам почти с 0.
В таком случае мне проще было работась с ребятами. За 5+ лет, из пришедших 20 человек, ушло 2 по причине переезда семей и ни одного глубокого конфликта.

ПМ изредка предлагает мне окунуться полностью в дев на итеррацию-две. Беря мои задачи на себя.
А почему участники дискуссии представлены однобоко, только те, кто не хочет быть тимлидом?
Это ж не прописная истина, а дело вкуса. Кому-то подходит, кто-то не готов ещё к этому, а кто-то никогда и не будет.

Мне кажется, как минимум, интересно было бы послушать мнение не только тех, кто отверг идею быть тимлидом, но и считает её правильным путём развития для себя.
Уверен, что трансляция будет максимально не предвзята по отношению к роли тимлида. Участники дискуссии побывали продолжительное время на обоих фронтах: были и отличными разработчиками, и эффективными тимлидами. Плюс будет техническая возможность любому желающему подключиться с видео и принять участие в дискуссии, мы будем только рады!
UFO just landed and posted this here
Зачастую это не так, заказчикам выделяется ПМ(если это бизнес) и с технической части БА. Тимлид — ориентирован на команду, решение задач и достижения целей. Люди с высокой квалификацией точно так-же нуждаются в тимлидах потому как часть команды. У меня в команде есть два разработчика, которые пишут очень сложные вещи, но абсолютно не любят коммуникацию или брать ответственность за весь проект. Тимлид видит проект полностью, знает температуру в команде и коммуницирует с ПМ. Это позволяет не принимать шлак в иттерацию и фокусироваться на реальных бизнес кейсах, не выводить команду за красные линии и так далее.
А разве высокая квалификация предполагает общение с вышестоящим руководством, заказчиками, поставщиками услуг (программных или аппаратных, внешних или внутренних — из других отделов), разрешением конфликтов и тому подобными делами?
Если тимлида начинает заменять качественный спец, то это означает что спец вырос в тимлида, а тимлида в этом моменте (особенно если полномочия растут и таких спецов уже несколько с разных направлений) автоматически выкидывает уже в менеджерскую позицию. Или не выкидывает. Так тоже бывает.
Работать с людьми – это сложно. Именно людьми «целиком»: не коллегами, не инженерами, не подчиненными и не начальниками – это только верхушки айсбергов. Этому не научиться за «полгодика на проекте», как какой-то технологии (хотя и для технологии это маловато). И тут нельзя останавливаться думая, что «ну ок, теперь я знаю людей». Это бесконечный процесс.
Я до сих пор учусь этому уже несколько лет и мне это до сих пор нравится. И в этом «кайф» определенный (а иногда бесит жутко, что уж тут) – никогда нельзя точно настроить всё и наладить на 100% (хотя иногда кажется, что получается), как с «инфраструктурой как кодом», например.
Хотя может это я сейчас так говорю, потому что в саббатикале и навалили философские мысли

Из статьи непонятно, как можно «подружиться со скрам-мастером». Скрам-мастер — это не человек, это роль, которая в здоровом скраме ротируется между всеми участниками. Если не ротируется, это был какой-то ненастоящий скрам.

Хорошее замечание. Речь о человеке, который отвечал за процессы разработки во всей компании, он принес туда скрам и периодически назначался скрам-мастером на разные спринты в разные команды. Потом эту роль подхватывали и другие ребята, посмотрев как он это делает. В общем, подружился я с «главным по скраму».
«Смешались в кучу кони, люди»… У автора данного поста, olegsklyarov, существует непонимание процесса разработки Scrum. Впрочем, возможно, это более общая тенденция «симуляции скрама» в одной, отдельно взятой компании (или стране :) ).

В scrum-разработке нет никаких «тимлидов» и «техлидов»; более того, сам scrum задизайнен специально для того, чтобы избежать (переложить ответственность) микро-менеджмента. Автор поста часто ссылается на «чистый скрам» и даже приводит обложки книжек; но, видимо, прочесть их он не удосужился.

В Scrum-е нет «тимлидов» и «техлидов» (а также project managers etc.), а есть Scrum master, и Product owner. Скрам-мастер может не быть экспертом в используемых технологиях выбранного стека разработки; теоретически, он вообще не обязан уметь программировать вообще. Он должен досконально знать технологию разработки Scrum, и обеспечивать применение данной технологии командой. Связь с заказчиками/пользователями берет на себя product owner — само название говорит о том, что в его обязанности входит полное ассоциирование себя с продуктом и реальными потребностями заказчиков, т.е. для команды product owner должен выглядеть, как «идеальная проекция» заказчика на реальный мир, полностью лояльная к команде.
Что-то я не понял статью. С позиции получать больше за час «реальной» работы — тим-лид лучше или нет. Или разница не очень большая, а работать нужно больше?

Разница не очень большая, иногда не в пользу тимлидства, а работать нужно больше.

Что значит *реальной работы*? Тут разные типы работ в принципе.
Ну когда вы что-то делаете что отнимает вашу энергию. Опять же непонятно почему надо работать больше — делегируй все задачи, а сам иди к примеру после обеда на рыбалку, периодически проверяя почту и делая форвард емейлов.

Это вы из личного опыта?

Ну я работал под управлением такого. В целом было нормально, все проблемы решались, плюс полная свобода действий
Хорошая статья, полностью согласен.
Разве что не думаю, что обязательно, чтобы тим-лид был лучшим разработчиком (ведь все-же тим-лидерство — это «параллельная вселенная», как Вы упомянули), но если это так сложилось — это дополнительный бонус.

Отмечу, что бывают случаи, когда тим-лидом ставят не разработчика, но специалиста, умеющего читать и понимать код. При этом он справляется с возложенными на него функциями.
Вопрос конечно остаётся открытым, насколько он будет эффективен по сравнению с лидом-разработчиком.

Думаю эффективность в таком случае будет зависеть от профессиональной и личностной зрелости и опытности как разработчиков (состава команды) так и ее лида, а также от того, на что такой лид мотивирован — собственная карьера и потребность в самовыражении или эффективность работы команды в целом и удовлетворенность своей работой каждого человека в команде (понятно, что совершенства нет, приходится балансировать и стремиться к нему). Как я упоминал — это «параллельная вселенная» скилов, по отношению к программной инженерии, но не абстрагированная от нее. Лиду-программисту может быть легче, чем не-программисту, но нет гарантии.
UFO just landed and posted this here
Так а как вы будете мерять эффективность? В статье же есть пример того что было сделано(раздел «Изучать темы»), выглядит не так чтобы это прям запуск ракеты, просто экраны с кнопками. Неужели даже с плохим тимлидом несколько хороших разработчиков не способно такое создать?
Тут важнее понимание кода, структуры проекта и алгоритмов. Ну и процессов разработки, git flow, testing tools, etc. Если это есть, то даже без написания кода можно говорить с разработчиками на их языке.
У нас, в кровавом ынтерпрайзе, людей, которые рассказывают, как на позапрошлом месте хотели быть менеджерами и добились, а на прошлом решили опять стать Ъ-исполнителями, в основном, отсеивают на собесе с НR.

Трусость и безответственность, какие они есть
Нельзя быть чуть-чуть менеджером и чуть-чуть исполнителем. (Хотя людям хочется именно так.)
Суть в том, что менеджером хочется быть, когда «а вот я бы сказал/изменил/не допустил». А когда ты сказал и тебе ответили, изменил, но не к лучшему, не допустил одно за счет другого, то хочется быть простым исполнителем, как Олегу на новом месте.

Хуже нет, чем опальный менеджер: и амбиции остались, и сбежит, если что.
Это только в «кровавом ынтерпрайзе» нельзя быть чуть-чуть менеджером и чуть-чуть исполнителем. Возьмем например главу семьи. Когда он ремонтирует дома проводку или рыбачит — он исполнитель. А когда оплачивает ребенку обучение или планирует отпуск всей семьей — он уже менеджер.
В целом, когда человек ищет себя, пробует разные роли — это на мой взгляд про развитие. А высший пилотаж — это найти в себе силы сделать шаг назад, когда понял, что в тупике.
Если отталкиваться от данного примера, то в данном случае менеджер-отец решает более не оплачивать обучение ребенку, потому что это не его, и пойти на охоту — попробовать что-то новое.

А если серьезно, то ни один менеджер не может просто сказать «мне очень понравилось, но я ухожу». После этого человек уже не менеджер, ибо менеджер несет ответственность не только за себя, но и за подчиненных, проект, компанию (частично).
Должны быть четкие обоснования любого своего действия. И не в момент ухода, а начиная с самого первого раза, когда кто-то из подчиненных спросил: а почему так, а не как я хочу. И если у человека за годы в менеджменте этого понимания нет, то скорее всего, он просто замещал должность (aka «держал задницей кресло»), пока HR не закрыл вакансию.
Хуже нет, чем опальный менеджер: и амбиции остались, и сбежит, если что.

Хуже нет, чем предвзятые HR. «Он блондин, а все блондины, которых мы брали на работу, оказывались подлецами, по этому ему сразу откажем»
Согласен.

Человеку нравилось программировать, скажем, 7 часов в день. Но потом он решил, хочет руководить людьми и процессами, а значит, уделять любимому программированию, скажем, 6 часов в день и 1 час менеджменту. Далее, ему так понравилось быть менеджером (это не сарказм — Олег весьма положительно отзывается о своей работе в качестве тимлида), что он решил, что будет уделять 7 часов в день программированию, а менеджмент — не его.

Блондин он или нет, но лично вы кем бы наняли Олега в свою компанию?
Как наскучили англицизмы типа team leader, ну везде они. А давайте по немецки. Business Leader это ведь Гешефт Фюрер если кириллицей (и это вполне ок. У моего руководителя в немецком варианте договора так и было написано, нет не в 19… а в 2000 каком-то тоду ). А слово гешефт в русском, благодаря идишу, имеет особый цимес (идиш, так идиш) :) Впрочем на идиш слово boss, тоже кажется неплохое — Махер.(я не силен в языках:))
В профессионально развитии тим лид может и паралельная ветка, а вот в карьерном — как раз следующая. В технической ветке должность senior практически потолок. Очень редко встречаются компании, в которых есть более высокая техническая позиция без менеджерских функций. А вот тим лид — это ступенька, там и зряплата больше, и дальнейшая карьера в менеджмент возможна. Так что если закрывать такски за условные 200к не предел мечтаний — то выбора особо и нет.
Если вы все измеряете деньгами-то возможно. Но Senior он разный тоже бывает, даже в FANG идет ведтка зарплат от условных 90k$ до 200+k$ для Senior. И там задачи уже другие, фичи пилить и закрывать таски за 200k это утопия. Там другой уровень абстракции будет.
Во первых я не думаю, что будет корректно транслировать буржуйский опыт на нашу постсовковую действительность. Нашему русскому senior разработчику Ивану, работающему в ынтырпрайзе или на какой-нибудь галерке условные 200к никакие FANGи и прочие Teslы/AMDы/Intelы не светят.

Во вторых не стоит ориентироваться на единичные случаи. Таких компаний и должностей на несколько порядков меньше, чем сеньеров, желающих получить это место. А что же делать остальным?
Ивану не светят перспективы только до тех пор, пока он с этим смирился. Мир состоит из миллионов возможностей, если начать их видеть. Посмотрите на пример моего коллеги из Брянска. Что делать? Прокачивать свои скилы, получать опыт, по-настоящему любить своё дело и становится с каждым днем лучшей версией самого себя.

В любой стране и во все времена ценятся лучшие профессионалы. Тогда в какой-то момент вы будите выбирать из десятка офферов, а не вас будет выбирать работодатель среди десятков кандидатов.
Не так сложно попасть в FAANG, надо только принять правила игры, и немного подготовиться.
Джим Келлер — инженер, специалист по микропроцессорам, работал в Tesla, AMD, Intel и Apple. И таких звезд много, если поискать. Никакого «потолка» в развитии настоящего инженера не существует, это иллюзия.
А вот тим лид — это ступенька, там и зряплата больше

Не факт.

В нашей компании была ситуация, когда срочно нужен был опытный Ruby-программист. В итоге у найденного (пусть он много и не проработал — а только вытащил проект из ж*пы) ставка в час была раза в 3-4 выше, чем у тим-лида (он с Ruby вообще не работал, по-этому конкретно в той проблеме ничем компании помочь не мог)
Ну это не полная занятость, а скорее удачное стечение обстоятельств.
Когда ты разработчик, каждый день у тебя есть скомпилированный билд, выполненная задача, новая фича на проде, — и в этом есть определенное удовольствие. Некий дзен: я сделал дело, можно вечером со спокойной душой идти отдыхать.

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

Не все так просто.

Для этого ты должен выстроить доверительные отношения с заказчиком

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

Вы много знаете разработчиков, которые мыслят масштабами проекта и бизнес ценностью этого проекта? Именно ценностью, а не фичами? Такие есть, но их единицы.

Sign up to leave a comment.