Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
/offtop Скажите, а Василиса Версус - это настоящее имя или псевдоним? И если псевдоним, то почему вы пишете, что вас так зовут? Кто-то вас зовёт не по настоящему имени, а по вымышленному?
Я бы сказал что обязанности на одной и той же позиции могут отличаться и очень даже сильно в разных компаниях. Причем относится это к любому грейду: джун, мидл, синьор, лид и т.д.
Большая часть того что описано выполняют agile couch /delivery manager, project manager и прочие господа кто работает над процессами и метриками
В моем представлении em это скиловый инжинер который делиться всеми возможными способами этим с командой чтобы качество их сервисов было лучше, а иначе это очередной процессник коих уже не сосчитать
Строить карьеру для карьеры на мой взгяд неправильно. Я понимаю, что автор приводил способы и механизмы карьерного роста, которые потенциально улучшают процессы и способствуют развитию команд, предприятий и отрасли, но какой то осадок все равно остаётся. Из перечисленного мне близок лишь один пример, когда карьерный рост необходим для продвижения своего мнения о направлении развития - без адм статуса тебя могут игнорировать.
Но много ли тех, кому карьерный рост реально необходим для инноваций?) Вряд ли. А если так, то весь этот пиар механизмов карьерного продвижения неконструктивен и часто даёт для отрасли негативный эффект. Инженер всё таки должен оцениваться по его вкладу в профессии. А если инженерные достижения можно заменить работой с руководством и какими то kpi, то значит в этом где то собака порылась)
Боже, каким мерзотным новоязом написана статья! Явно писало её GPT.
И вот это вот вообще за гранью добра и зла:
head of инфраструктуры или разработки
Это как если бы американец писал:
Главный по infrastructure or development
Недавно я писала про свой путь от TL к EM. Подписывайся на мой паблик в тг, там такого будет много, а мы начинаем.
Вот на этом лучше бы и закончили.
Тимлид - это примерно тоже самое что и дедовщина в армии, должности как таковой нет. Но если ноявляются новобранцы в команде, "старички" начинают называть себя тимлидами и пытаются изображать из себя "руководителя". Если появились в команде тимлиды, это признак незрелости компании, дизорганизации и отсутствия налаженных руководством рабочих процессов. Поэтому и начинают проявлятся животные инстинкты в команде. Слабый проектный менеджер, он же слабый офицер, и поэтому появляются деды, лиды и прочая живность.
Во-первых, должность есть. Во-вторых, часто её никто сам занимать не хочет, на неё назначают. В-третьих, назначают на неё обычно того, к кому вся команда естественным образом начала ходить за помощью и советом.
Серьезно? И в штатном расписании и в трудовой? А пока что я видел поголовно тимлидов, ни к которым вся команда ходит за советом, а кто "первый халат надел тот и доктор", первый зашел на проект тот и тимлид, лень программировать или не вытягивает. И начинает просить набрать команду, причем старается набирать не выше своего уровня... на всякий случай... А менеджеру, как правило, по барабану, так как он вообще ничего не понимает в управлении программистами
Серьёзно, и в штатке, и в трудовой. Если надо было обязательно назвать должность по классификатору, например для оформления брони, то писали "ведущий программист" или "руководитель группы".
Видимо, не везло вам с местами работы и командами.
Ну вот видите, сами подтвердили, что тимлида как должности официально нет. А руководителей проектов или проектных менеджеров у Вас никогда не было что ли?
В современных командах иерархия по технической ветке обычно такая:
Техлид / Техдир
Тимлид / Ведущий разработчик
Сеньор / Старший разработчик
Мидл / Разработчик
Джун / Младший разработчик
Менеджеры, включая РП - это бизнесовая ветка. Они для разработчиков не начальство, а внутренний заказчик.
А если в команду приходит разработчик с сильными скилами и опытом, вы его не берете? или предыдущего понижаете? Куда он попадает по вашей иерархии? Или два "тимлида" у вас будет?
Вы из средних веков пишете что ли? Уже десятилетия как есть горизонтальный рост, а на каждом уровне иерархии может быть несколько членов. Если человек силён хардскилами и хочет заниматься именно разработкой, будет одним из сеньоров, если хочет быть лидом, и в том есть потребность у компании, сформируют под него команду, выдадут этой команде часть микросервисов, снизив нагрузку на остальные команды. Если хочет быть лидом, но в компании больше нет соответствующих вакансий, то будет так же, как и 50 лет назад, когда должности тимлида не существовало - придётся искать другого нанимателя.
Да... что то не догоняю... поясните пожалуйста... Вот получает команда задачи от бизнес аналитика или там рп. Планируем обсуждаем декомпозируем, каждый по своему стеку... ... задачи на пару недель... делаем... стыкуем модули... тестируем... выкатываем релиз, показываем тому же рп "ака внутреннему заказчику"... как понять, кто из нас тимлид?
Фактически тот, кого больше всего уважают в команде и к кому все ходят за советом, формально тот, кого им оформили по штатке, в идеале тот, кто совмещает первое и второе.
Да вроде все одинаково уважаемые и каждый спец в своей области. Ну допустим, разработчики, каждый своим модулем занимается, они просто согласуют общие точки взаимодействия, и каждый важен по своему. Разве у вас в команде есть малоуважаемые разработчики и те кто без совета работать не может? Прямо по штатке пишете "уважаемый лидер команды"? А в должностных обязанностях "дает советы всем"?
Похоже, вы не истину хотите выяснить, а доказать, что не существует иной правды, кроме вашей. В чём вы меня хотите убедить? Что тимлидов не существует, так я вам уже написал, что они существуют в подавляющем большинстве команд. Что они не нужны, так они нужны, иначе бы не было соответствующих вакансий, не было бы соответствующих атрибутов в формах работных сайтов, не писались бы об этом статьи на Хабре и т.д. и т.п. Да, мне изредка встречались "самоорганизующиеся" команды, в которых не было ни лидов, ни вообще грейдов, все якобы равны. Это мой личный опыт, конечно, на эффективность работы таких команд была на много ниже, чем у команд с классической иерархией.
Ни в чем не убеждаю просто интересуюсь. Как сказать, мини соцопрос. тут на хабре куда только "тимлидов" не определяют, и все по-разному пишут и рп, и менеджер, и старший, и техлид.. вы смотрю его в ведущие разработчики засунули... хотя он, по вашему мнению, только на уважении работает и советы раздает... сомнительная польза конечно, но если команда слабенькая, то ок.. сойдет..
Team lead буквально переводится "ведущий команду" [программистов], то есть "ведущий программист" или "руководитель группы" [программистов]. Конкретное название должности зависит только от нюансов кадрового учёта в отдельной компании и сути не меняет.
путанно обьясняете... он программирует код или руководит? И вроде бы говорите должности то тимлид нет... а суть его функций каждый по своему понимает...вот что странно, дичь какая то... чуть чуть программист, чуть чуть кадровик, чуть чуть руководитель, а по факту ни то ни се... рп у вас вообще куда то пропали в заказчики...
Я же говорю они имеют место быть, но когда все путанно и процессы не налажены, на первое время сойдет...
Это большая боль у ребят кто пытается идти в эту сторону, а особенно не застрять на пол пути. Я сам прошел схожий путь, поэтому поделюсь своими мыслями после прочтения. Возможно, это будет полезно тем, кто сейчас думает о том: "а куда дальше?".
В общей картине разработка больше про людей и взаимодействие между ними, что, безусловно, входит в зону ответственности ЕМ.
Забавно, люди и их взаимодействие являются узким местом в разработке, а не технологии.
С этой точки зрения конечно все зависит от продукта, но очень часто EM, может прийти к выводу, что для выполнения своих обязанностей надо сначала команду построить из кучи людей (то бишь быть TL). Отсюда кстати как по мне и путаница.
А вот когда TL сделал свою работу, или у тебя есть команда, которая поддается изменением уже можно и начать задачи EM выполнять.
Предлагаю рассмотреть гипотетический путь от инженера к TL и потом к ЕМ
Если у тебя нет команды, сначала построй её. Это частый путь для разработчика через team lead. Кому-то повезёт: всё готово, и можно сразу переходить в ЕМ.
TL может совмещать работу PM, но для ЕМ это необычно и неправильно.
"Код" — это продукт для разработчиков, а разработчики — его пользователи. Их работа (coder story 🤣) — менять его. Значит, тут должен быть product owner. Эта метасистема — больше, чем архитектура, она про скорость изменений и про то, насколько более сложные задачи команда может решать на базе существующего кода. Вот EM и развивает этот метапродукт
Обосновывай переход выгодой для твоего руководителя и компании.
Это очень важно. Часто люди на этом спотыкаются. Когда разбираешь это с ними, они удивляются: "О, это так просто! Я вообще не так думал, всё усложнял и спорил."
Четвёртый пункт — про поиск вакансии внутри компании и продажу себя.
У C-level всегда проблема найти человека, готового взять на себя хоть маллую часть ответственности. Как только ты начнёшь это делать, система сама будет тебя продвигать. Такие кадры в дефиците, и всегда найдётся, чем их занять. Иногда достаточно просто помочь коллеге из другого отдела настроить Google Sheets, когда в фичу не делали год для него, сэкономив время и проявив неравнодушие.
Спасибо за статью!
Ого! Спасибо за такой огромный и развернутый комментарий ❤️🔥код есть мета-продукт как идея мне очень близка, хотя кажется сложным это сформулировать так, спасибо ☺️
Про EM сразу в обход TL тоже согласна, но встречала только в англ. мире. Надеюсь на ру рынке тоже так однажды будет.
А вот с тем что СТО всегда ищут кого-то, в моем мире также, но я очень много комментариев с неуверенностью получала и встречала, у меня сильные сомнения в том что они на пустом месте возникли. Как нибудь обязательно проведу исследование на эту тему, ведь круто звучит опросить хэдов и директоров на вопрос как они будут реагировать на инициативу… но тут еще бы придумать методологию, чтобы исключить случаи лести к себе и компании. Боюсь много руководителей некомпетентных 🫨 но если у тебя будут идеи как это можно сделать — буду рада!
Еще раз спасибо за развернутый комментарий 🔥
Классная статья, мне было интересно мнение)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Team Lead VS Engineering Manager