Комментарии 19
Зачем делать в команде какую то геймификацию? Это создать типа пытается заставить быть разрабов проактивными? А какой им Профит от этого?
А какой им Профит от этого?
мотивация лучше выполнять свою работу?
с принципом я не я и лошадь не моя, делаю работу строго по ТЗ ни шагу влево-вправо, далеко не уедешь
я например одному такому блокировал просьбу на повышение ЗП
Должна быть понятная тогда мотивация для разработчикоа
Должна быть понятная тогда мотивация для разработчика - повышение ЗП или по должности итд. А то если просто играть в геймификацию и ничего с этого не получать, то по идее это должно вызывать наоборот - демотивацию!!
чтобы человек нормально работал ему надо постоянно повышать зарплату и должность? а если он устроился на работу и ему не повышать каждые полгода зарплату то он может с честной совестью начать итальянскую забастовку? ;)
геймификация это упрощение рутины в первую очередь и для упрощения работы всем, чтобы человек если чтото делает, немного головой думал
а то у меня есть коллеги из соседней команды, они например могут запросто пушить в прод изменения которые ломают чужие сервисы (вот такая у нас кривая архитектура)...они это отлично знают но им просто плевать им сказали, они сделали, надо им зарплату увеличить чтобы им стало не плевать? или повысить сеньоров до лидов, а миддлов до сеньоров? думаете это так работает?
Название — это, конечно, отсылка к треку Бритни Спирс I'm Not a Girl, Not Yet a Woman.
Вы решили поменять компанию и теперь уже сразу ищите позицию именно тимлида. Когда вы начинаете поиск работы на тимлидерскую должность, то обнаруживается один лаг в найме. Везде вас будут проверять как senior‑разработчика в первую очередь, а уже во вторую очередь ваши тимлидерские скилы.
О, как раз мой случай: с тимлида перешел на мидла.
На самом деле все даже интереснее.
Во-первых, тимлид в некой компании одного продукта для внутреннего рынка и тимлид в аутсотигне или просто на международном рынке - это вообще могут быть совершенно разные профессии, требующие не то что разных навыков - разных людей.
Правда, не все так безнадежно. Если компании нужен чистый тимлид, то мне показалось, что они таки готовы закрыть глаза на тех навыки (уровень мидла их устравивает) но только при условии абсолютно релевантного опыта: сходный продукт, сходные процессы и т.д. В моем случае это совпадение маловероятно.
Во-вторых здесь интересно, что справиться с работой синьора на самом деле не проблема. "Год не присал код" - это не много, такое никого не волнует, я почти не программировал 7 лет. Но опыт так просто не пропьешь, пару ночей посидел, гдялишь, дело пошло и уже всех синьоров обогнал. Но вот показать знания синьора на собесе - это намного сложнее.
В итоге я не нашел другого выхода, кроме как заходить в индустрию по новой начиная с мидла. Дальше нужно надеяться что у команды будет синьорская работа и нужно эту работу на себя активно тянуть, чтобы снова стять синьором. По ощущениям молодому (я имею ввиду до 45) и активному на это нужен год. Такому как я старому и выгоревшему, похоже года 2. Стоит ли опять после этого метить в тимлиды, хороший вопрос.
Личное мнение - идти в тимлиды - тупиковая ветвь развития для программиста. Зачастую, ищут тимлида, где Продакт менеджер не обладает техническими компетенциями. Пришел из бизнеса. За клиента. Но проблема с базой: метрикой, инструментами, процессами разработки, безопасность кода и инфраструктуры, сети, почему мы должны платить за git/intellij/любой-инструмент-который-делает-процесс-разработки-быстрее. А еще каждый раз доказывать ему, что ты не шланг, так как на выходных, друг или родственник айтишник, рассказал, что в другой компании, они все делают по другому.
Лучше всего, развиваться как Senior Dev. Не тот синьор-помидор, который за 3 года и в лиды. Синьором и на пенсию выйти не стыдно. А еще быть таким Синьором, который может мотивировать и вести за собой команду, погрузится в предметную область, контрибьютить в библиотеки с которыми работает, может декомпозировать задачи - одним словом, быть 10х Dev, который просто на опыте и на мудрости спасает команду, мыслит вне рамки кода.
И новую работу найти будет просто. Искать не надо. Такого рекомендовать будут всегда. И удовольствие от работы больше, так как четко понимаешь, за какой фронт работы несешь ответственность, и где твои результаты.
Боюсь, тут наблюдается непонимание роли управляющего продуктом. Эта роль не подразумевает управление процессами разработки.
Жаль, что в локальных IT-компаниях стран СНГ обычно или идти в тимлиды, или Senior Dev до пенсии. Была бы чуть больше развита культура роста в техническом направлении выше Senior Dev - уверен, было бы гораздо меньше тимлидов не на своих местах.
2 направление – технический бэкграунд. Развитие в этом
направлении в меньшей степени улучшит твои позиции на текущем месте. Но
без хардов тебе не найти новое место. Если на собеседовании ты скажешь,
что уже год не писал код, то для большинства компаний это будет скорее
красным флагом.
Не понимаю как может технический бэкграунд рассматриваться только с точки зрения поиска новой работы. Если тимлид давно не писал код, у него и на текущей работе будут проблемы. Со временем он растеряет навыки и к нему будут приходить программисты за помощью, а он не может решить их проблемы и потеряет авторитет. Ну и если сам не попробует новый фреймворк, язык программирования или новую технологию, как он может понят нужно ли это использовать команде в разработке
Как раз-таки проблема в том, что часто представление того, что нужно от тимлида, очень расплывчатое. Ему приписывают и то, что он должен быть самым крутым разработчиком в команде, к которому все ходят за помощью, и то что он должен быть архитектором, который утверждает все подходы и технологии. Но на самом деле же тимлид это про другое - про управление командой и умение делегировать. Я знал случаи, когда команду программистов успешно тимлидит человек с бэкграундом вообще не с теми языками программирования, на которых пишется проект.
Очень похоже на мою историю. Много лет разработки, сделали тимлидом и не понимал, что происходит. Потом опять ушел на год в разработку, но уже в очень крупную компанию, где увидел что значит быть хорошим и плохим тимлидом. Перешел в следующую компанию и уже как нормальный тимлид, но роль достаточно быстро трансформировалась в что-то иное.
И да, есть проблема с разработкой - в нее тянет. Решил для себя совместить с развитием, изучаю новый стек, поддерживаю технические знания, постоянно развиваюсь во всех направлениях (разработка, архитектура, менеджмент).
В компаниях, которые ищут тимлида, действительно часто встречается непонимание, чем занимается тимлид. Для одних это просто бейджик для senior разработчика, другие ищут начальника, через которого хотят коммуницировать с разработкой. С другой стороны и те, кто приходят собеседоваться на тимлидов - это часто просто разработчики, которым когда-то доверили отвечать за разработку команды, а каких-то специфических скиллов типа проведения 1-на-1 или построения карты персонального развития сотрудников они в жизни не делали.
Спасибо за статью.
Для себя я вывел такую формулу: Тим лид - прежде всего хороший технический специалист, с прокачанными софт скилами.
Мой кейс: из крупной известной компании, перешёл с позиции сеньер дев, на тимлида в более мелкую, но тоже достаточно известную компанию.
В крупной компании, я не мог закрыть свои потребности влиять на продукт, делаешь задачи и все, ревьюишь код. Да это конечно влияние на продукт, тк ты вносишь в него изменения, но ты ограничен рамками и сроками задач которые тебе ставят. Интересно было, когда давали задачи, что-то последовать, оптимизировать. В общем то это минус работы в любой крупной компании, которая продаёт известный и большой продукт.
В новой компании на позиции тимлида, я уже непосредственно влияю на архитектуру, на решаемые командой задачи и пишу код. Но теперь чувствуется нехватка масштаба проекта, который был в крупной компании. В целом я удовлетворен сделанным выбором. Быть тимлидом в крупной компании, постоянно разруливая всякие ситуации, организуя всякие встречи, как то пока не хочется.
Но я теперь точно знаю ответ на вопрос, чем бы хотел заниматься: делать то, что нравится. А что мне будет нравиться в будущем разработка или управление, уже не особо важно )
Думаю, что мне сильно повезло с опытом. Работал около полутора лет в одной большой компании в эталонной по процессам команде. Получил много знаний как выстраивать процесс внутри команды, как быстро и безболезненно погружать новичков.
Ушел за длинным рублем в другую большую компанию изначально думал, что разработчиком. Но на рынке голод. Я был в команде подрядчиков один который работал на основной офис. И так вышло, что в один день всех подрядчиков сократили. Из разработки остался только я, и в команде был ещё аналитик.
Итого, мне выдался шанс с нуля собрать команду тех людей которых я считаю нужным. А нужными я считаю людей которые готовы не только писать код, но сопровождать задачи как эпик драйверы от формирования и утверждения требований до нарезания задач на команду. Поэтому технически мои собесы весьма простые: этап с код ревью, поверхностные вопросы по стеку, а дальше вопросы в ширь по смежным технологиями.
И в целом считаю эту стратегию выигрышной. Все ребята готовы тащить эпики, не боятся этого. А что до кода? Зачастую бизнес задачи это перекладывание и преобразование json'а. Поэтому не вижу смысла дрочить на алгоритмы.
И что в итоге вышло - команда практически избавилась от bus-фактора в лице меня, и готова перехватить задачи на любом этапе.
По поводу того, что стал меньше писать кода не рефлексирую ниразу. Я все ещё делаю потные ревью, и беру задачи которые нужно быстро решить (скорость достигается знанием проекта, как программист я считаю себя довольно посредственным).
Научился получать кайф от формализации задач. Также огромный кайф когда видишь, когда растут тиммейты или кто-то приходит за советом как лучше наладить процессы.
У меня ещё очень много мест где нужно вырасти, но мне кажется я нашел отличный баланс между встречами, написанием кода, исследованием проблем.
А, ну и справедливости ради надо сказать, что в команде у меня есть менеджер, который делает очень много работы по общению с клиентами. Но так или иначе 60-70% времени занимают встречи, письма, согласования.
Несколько раз проходил такие итерации, из разработчика в лиды и обратно. Сейчас пришел к тому, что тимлиды нужны менеджерам, которые не понимают как управлять разработкой. Назначив самого лояльного к бизнесу (менеджменту) разработчика (который делает задачи быстро (на самом деле с костылями), не возражает на неадекватные сроки/требования, и вообще на все говорит да) тимлидом, бизнес рассчитывает, что через него сможет рулить процессами разработки. И на самом деле так и происходит, менеджмент получают контроль над разработчиками, но это никак не влияет на перформанс команды в лучшую сторону. Разработчики перестают чувствовать персональную ответственность за свою работу, так как есть тимлид, который за все отвечает. Перестают самостоятельно разбирать проблемы, ведь есть тимлид - он должен решать сложные вопросы, иначе с хера ли он тимлид? В итоге общая мотивация в команде падает, а вся нагрузка ложится на лида, который выгорает и сваливает в другую компанию. Зато эти прекрасные год полтора менеджеры ощущали как они рулят командой. И кстати выгорание это про то, что человек осознает, что то, чем он занимается не приносит никакой пользы
Разработчики перестают чувствовать персональную ответственность за свою работу
им по большей части плевать кстати, они работу работают с 10 до 18, а чтобы чувствовать ответственность "надо денег побольше" и "я не готов этим заниматься, пойду в другую контору где такого не просят", "дайте акций и я буду может быть об этом думать"
Я вообще работал в компании без тимлидов...неформально сам им стал ;)) потому что "ой чото не работает, я письмо овнеру сервиса отправил что не работает, пойду погуляю в парке, он всёравно сегодня не ответит потому что дейофф взял"..да, а там прод лежит..не ну а чо..письмо написал..а чинить это не моя ответственность я тупо разработчик, МР заапрувили, пайплайн не упал...пусть QA сами постпрод тесты смотрят....ога...когда в сутки 30 релизов (CI/CD во все щели)...утром выкатили, вечером QA заметили что чтото упало
Я чет тогда прифигел от такого отношения и бегал сам всех пинал
Очевидный вывод из статьи. Тимлиды не нужны. Ну а что, код ревью могут сами разрабы друг другу делать. Ежедневные дейлики решают проблемы с помощью друг другу, если продукту надо делегировать декомпозицию, для этого есть проджект менеджер или скрам мастер(в отличие от пм может быть эстафетой). Тимлид как пятое колесо.
Уже не программист, но еще не менеджер