Comments 176
Для всяких технических вещей в команде есть техлиды, а задача тимлида как раз в том, чтобы у техлидов было все необходимое, чтобы эти вещи реализовать.
Т.е. они предлагают переименовать тимлида в техлида, а тимлидом называть разновидность манагера? Зачем?
Так вроде давно уже так (по крайней мере в Сев Америке).
Team lead - буквально руководитель команды - кому какие таски, организация процессов в тиме, переводить с чистого менеджерского на язык команды и наоборот, контроль над выполнением/оценкой, и т.д. Фактически менеджерская позиция где понимание теха пригодится, но вот не прям особо критично.
Tech lead - буквально лид теха - человек в тиме который ответственный за то в какую сторону будет развиваться тех, формулирование тасков, помощь с разруливанием тех вопросов и т.д. Фактически высшая техническая должность в команде.
Руководитель - букв. разВодитель руками?
Имхо, не всегда смысл понятия отвечает своей дословной расшифровке
Что то мне подсказывает что это буквально "водитель за руку", но если например взять дирижеров, то они реально водят руками и управляют оркестром (хотя оно от фр. diriger).
Я про это и говорю. Когда-то это был "водитель за руку". Сейчас в буквальном смысле за руку не водят (вот прям в буквальном), а термин остался.
Хотя, возможно, в современном мире руководитель это на самом деле "водитель руками". Т.е. "дирижёр". Его работа указывать (не всегда руками) правильное направление))
и не только в США, во всех западных современных компаниях, за тех.решения отвечает техлид (за архитектурные кстати архитектор) а за менеджерские - менеджер. Решения - нанять, уволить, сроки, бюджеты, приоритеты, мотивация - все менеджерские.
p.s. менеджеры тоже есть разные. За приоритеты и бюджеты и прочее относящееся к создаваемому продукту - отвечает продукт менеджер. За найм-увольнение - совсем другие. За организацию тим-билдингов - вообще третьи.
давайте всегда говорить "за всех".
сколько компаний, столько и процессов, иногда абсолютно отличающихся друг от друга. Вы говорите про огромные организации, где для каждой микрозадачи есть специально обученный человек, эйчары делятся на эйчаров и рекрутеров, а среди офис менеджеров есть своя иерархия. Но айти не равно энтерпрайз
Если это всё действительно просто переименование -- то вполне очевидно для чего оно: чтобы поднять статус менеджера. Им всё труднее быть значимыми, особенно в технически сложных проектах, вот и переименовывают. Насильственное сращивание с командой, так сказать, а заодно и серьезное подспорье в избегании претензий со стороны технически более компетентных товарищей: одно дело не понимать, что от тебя требует менеджер (велика вероятность, что он сам не знает, чего хочет), другое -- не понимать тимлида (вроде как уже проблема оппонента, что он недостаточно умён).
В западном IT практикуется разделение работ на две карьерные ветки - "manager" и "individual contributor" aka IC. При этом тим лид считается младшей менеджерской позицией, которая как правило находится на том же уровне что и senior developer, но в ветке "manager" а не "IC". Уровнем выше может стоять "project manager" или просто "manager" в ветке менеджмента и "tech lead" или "expert" / "principal" в ветке IC (да, tech lead считается при этом более сложной и высокооплачиваемой работой чем team lead) и т.д. При этом в теории тимлид может вообще не разбираться в программировании, его задача - администрирование команды.
В России такого четкого разделения на две ветки часто нет и из-за этого team lead считается такой переходной позицией от разработки к менеджменту совмешающей в себе менеджмент и хорошие технические знания.
При этом тим лид считается младшей менеджерской позицией
Скорее это first line manager, а понятия тимлида просто нет.
Одно другому не противоречит. First line manager - это собирательное название для менеджерских позиций начального уровня. Тимлид в понимании "человек который менеджит 5-6 линейных сотрудников" явно к ним относится.
"человек который менеджит 5-6 линейных сотрудников"
Если (как это положено в нормальной компании) он явно находится на менеджерской линейке, прошёл соответствующие тренинги и т.д. - то это просто FLM. Понятие тимлид возникает скорее там, где нет чёткого разделения на девелопмент и менеджмент на нижнем уровне.
По моему опыту одинокого эникейщика тимлид не нужен. ) Но если подумать, то как быстро опытный программист потеряет связь с командой, если она не скачет со стека на стек, а пользуется известными, хорошо отработанными технологиями? Думаю не быстро. Другой вопрос: а почему бы тимлиду не пописать проект с командой, ведь не все же время заниматься стратегическим планированием, или чем они там занимаются? )
Когда-то работал как фулстек и на достаточно хорошем уровне мог сверстать страничку в этих ваших реактах или ангулярах. Спустя 2 года чистого бэка уже не могу. То есть саму суть работы веб приложения я понимаю, а вот как ИМЕННО надо этот редакс использовать уже хз. Так что навык можно потерять достаточно быстро.
Но, думаю, что если приспичит, то за пару недель освою обратно.
вот как ИМЕННО надо этот редакс использовать уже хз
Моё мнение после нескольких готовых проектов, в которых есть этот конкретно Redux - он нафиг не нужен.
Не поймите меня неправильно, я сам в своём сложном проекте в итоге накостылил работающее подобие стора, со всякими этими эффектами и экшенами. Но оно получилось в разы проще и быстрее для понимания, чем, к примеру, следующий философии Redux'а ангуляровский NgRx.
Сам паттерн единого стора имеет право на жизнь (хотя в последнее время от него стараются чуточку отходить), но он, блин, должен быть проще и требовать минимум кода. А не как в недевственном NgRx, где на хранение одного поля ты пишешь редьюсеры, экшены, слайсы, эффекты на ≈200 строк. Это смешно. Я, когда это увидел, офигел и обратно не выфигел. Притом несовпадения типов выдают эксепшены на 3000 строк, это невозможно отдебажить даже с Copilot - тупо контекста не хватает.
Резюмируя, скажу - ничего вы не потеряли, а наоборот, избежали совершенно лишней головной боли. Для простых случаев напишите что-то типа service locator и затем закостыльте под "типа стор". Как поймёте, что созрели - мигрируете на любую библиотеку, которая реализует Redux, но максимально просто и понятно.
На фронтенде такое ощущение все пытаются вписаться в какие-то тренды, пытаются использовать библиотеки из какого-нибудь треда "за последние 2 недели вышли 2 новых библиотеки! мастхэв для каждого! убийца angular/react/vue/etc! успей освоить сегодня!" :)
На полгода выпадаешь из индустрии и потом вкурить почему надо использовать это... начинаешь читать документацию и вроде что-то полезное, много чего пофиксили, добавили новых фич, но как-то сильно переусложнили ради случаев, вероятность возникновения которых стремится к 0%...
Получается что какой фреймворк не используй он устареет через пару лет и превратится в легаси :-) Напоминает запланированное устаревание.
Это, кстати, похоже на стереотип, который сформировался на этапе становления фронтовых фреймворков.
Не знаю как в стартапах, там свои приколы, но в больших кампаниях никто не бегает от одного фреймворка к другому. Сейчас используется реакт/ангуляр по мере необходимости, вью много не вижу (что, кстати, подтверждает тезис, что никто по фреймворкам не прыгает, т.к. вью последний появился).
Прыжки по либам/фреймворкам осуществляется только если это действительно дает профит и если кост прыжка не сильно большой
Конкретно redux и вообще state-management - это просто огромный шаг вперёд в построении толстых веб-клиентов
Согласен, только у нас, помимо чисто redux, все ещё было обильно обмазано сагами. В результате, чтобы работать со стором, приходилось писать какой-то невероятный объем кода, хотя, я всего лишь делаю store.SomeValue = value.
Аж вьетнамские флешбеки полезли.
Team Lead не должен писать код. Потому что он вообще не кодер. Это Team Lead, он всей командой руководит, в том числе маркетологами, дизайнерами, моделлерами(и кто там у вас еще в вашей сфере специфический есть).
Если мы говорим о Lead Developer/Programmer(должность которого существенно ниже Team Lead'a), то он писать код должен, хотя это и не его основная работа.
Опять же, возникает вопрос, почему Tech Lead у вас по рангу ниже Lead Developer'a.
В моей практике, как правило, Lead Developer руководит разрабами в конкретной команде. В то время как Tech Lead стоит над проектом, и реализует свою квалификацию на уровне всех проектов компании. То есть это авторитет, которые разруливает вопросы применяемых технологических решений и утверждает подходы для каждого проекта. У вас по описанию это просто рядовые разрабы, какие-то.... Что в вашей компании отличает техлида от рядового сеньора работающего над проектом?
Конкретнее. Сколько людей в подчинении у тимлида у вас?
Конкретно у нас около 50.
У нас, и, кажется, это традиционно, ГруппенФюрер - это самый мелкий начальник над группой "линейных" программистов от 1 до 8 человек (оба крайних варианта временные).
Респект, за знание младших командных должностей НАТО (Бундесвера в частности) )))
Я - ради страйкбола изучил (разные клубы реконструируют разные войска).
Это старый мем на самом деле :)
Полагаю, этот мэм примерно ровесник блока НАТО. Группенфюрер, он же тимлидер, - капральская (гефрайтерская) должность в армиях НАТО.
Группенфюрер
Оно еще с 20-х годов (прошлого века) в одной известной организации использовалось.
Причём, даже в двух. И значило в них совсем разное. Скажем, в Вермахте, группенфюрер - это была ДОЛЖНОСТЬ, примерно, как сейчас в Бундесвере. А в СС - группенфюрер - это одно из генеральских ЗВАНИЙ.
Сложно сказать на счёт 20-х годов. Должность группенфюрера наверняка была в Вермахте с самого начала. И, наверняка, существовала и до Вермахта. А вот в была ли в 20-х годах в СС собственная линейка званий, или она появилась уже вместе с войсками СС - я не уверен?
Если слово "группенфюррер" вызывает у Вас ассоциацию с НАТО, а не с Броневым, то я поинтересуюсь, Вы не засланный ли к нам?
Надеюсь, это была шутка. С каких пор военная грамотность стала признаком "засланного"?
UPD: Буду признателен, если Вы подскажете, где, кроме НАТО группенфюрер является синонимом (немецкоязычным) тимлидера (англоязычного). Персонаж Броневого, насколько я помню, тимлидером не был.
Конечно это шутка.
Только вот это слово не из военной грамотности, а из кинокультуры , например, из Штирлица.
Поэтому "...фюрер" нас веселит, а то как оно звучит на других языках - нет.
Поэтому и возникает вопрос о том, сколько Вам лет и в какой стране Вы провели детство, что не считывате такие отсылки.
Кинокультуру, я разумеется, знаю.
Но видите-ли в чём дело... Группенфюрер СС - это по-нашему генерал. Т.е. никак не "это самый мелкий начальник над группой "линейных" ", о котором писал @vkni.
Зато "самый мелкий начальник над группой "линейных" " называется в войсках НАТО по-английски "Team Leader" (ничего не напоминает?), а по-немецки - группенфюрер.
Строится вполне закономерная ассоциативная цепочка: "тимлид" -> "тимлидер" - "группенфюрер".
Её можно продолжить и до Броневого. Но в обход тимлидера к Броневому не придёшь, если только за уши не притягивать.
Потому я и подумал, что @vkniтоже что-то понимает в пехоте вероятного противника...
UPD: Буду признателен, если Вы подскажете, где, кроме НАТО группенфюрер является синонимом (немецкоязычным) тимлидера (англоязычного). Персонаж Броневого, насколько я помню, тимлидером не был.
Так всё же, где Вы провели детство и сколько Вам лет?
Потому что нейтив должен отличать аллюзии и каламбуры от логических построений.
Мне 39. Я всю жизнь прожил в Москве.
Дело в том, что никакой каламбур, если только не притянутый за уши (что убивает его ценность), не превратит тимлида в генерала.
А каламбур и не должен никого ни во что превращать.
Каламбур это шутка построенная на внешней схожести формы, а не содержимого. Более того, разница содержимого может быть не багом, а фичей - обеспечивая твист.
В данном случае твист состоит в том, что названия должностей становятся стилизованными про киношные.
Например, вот случайная картинка из интернета на эту тему.
Само собой, делать такие каламбуры на, например, испанском смысла нет - нет ассоциаций.
Надеюсь, это была шутка.
Как у вас могли возникнуть сомнения в этом? Team lead - это командир взвода примерно, то есть Zugführer.
Team Leader - это командир Fireteam. Это подразделение из 2-4 человек, входящее у них в состав отделения (section).
Командир взвода (squad) назвается squad leader.
А вот на счёт Gruppenführer я ошибся. Это оказался командир отделения Gruppe(de) == Section(en).
А Team(en) == Trupp(de) - соответственно.
Вы правы, отделения.
Файертим - это не отделение, а более мелкое подразделение. В нашей армии такого нет.
Я думаю «расчет» может быть аналогом файертим.
Расчёт в разных войсках имеет разное соответствие. У меня, например, расчёт был аналогом взвода.
Я не знаю, как у пехоты и миномётчиков, но, насколько я слышал, все структуры меньше отделения у нас не отражены в штате, а существуют только в виде порядка взаимодействия бойцов. Например - гранатомётчик с помощником гранатомётчика. У НАТО подобная пара, скорее всего, была бы записана как фаертим (по аналогии с фаертимом ПЗРК "Стингер" - из двух человек).
Кстати, у них пехотный фаертим делится на пары, которые не отражены в штате.
группенфюрер является синонимом (немецкоязычным) тимлидера (англоязычного).
У немцев же есть вполне однозначное Teamleiter, и безо всяких отсылок ко временам художника )
Есть ощущение, что вы тимлидом называете совсем иную роль в компании, чем ваши собеседники.
У вас эта команда в 50 человек что ли больше не делится на меньшие команды со своими лидами? Вот так по 50 человек и ходите на проектные встречи?
Вообще для штата в 50 человек уже всякие SAFe и LeSS придумали, чтобы выравнивать командЫ между собой, потому что одна плоская единая команда в 50 человек - это как-то... необычно.
SAFe это у нас для 700 человек. Для,50 норм 1 тимлид, я,например таким являюсь. Но у нас (конкретно в мой команде) дейли нет ибо бессмысленно. 2 раза в неделю общая встреча с жестким таймингом 30 минут. Естественно, не 50 человек над задачей работает, под конкретные задачи динамически формируются. В них нет выделенных должностей, просто обьединение на одну задачу. А так (почти) все со всеми работают. И да, дел у меня хватает и без кодирования, хотя и умею (не на всех стеках которые есть в команде). Я даже задачи не распределяю, это координатор делает, он же примерную трудоемкость оценивает, за мной только нетиповые случаи. Если бы я и код писал я очень быстро стал одновременно говнокодером и говноменеджером одновременно.
50?? Тогда у нас точно разница в терминах. У тимлида обычно 3-9 человек. Если больше, то это Х, это начальник второго уровня и под ним тимлиды.
P.S. Гугл находит такой размер группы у тимлида: 3-7 или 5-7.
Зачем группе 5 человек выделеный лид?! Это какой то неправильный подход
Знаете, я ничего не имею против вас и вашего подхода. Но может быть если у всех вокруг так, а у вас - иначе, может быть это у вас подход не такой?
Ну то есть ваш подход явно работает, никто не спорит. Но во всех местах, которые я знаю - тимлид это главный программист для команды в 3-7 человек. Он пишет код, занимается планированием задач, думает над архитектурой и работает связующим звеном между менеджментом и программистами. И судя по комментам, в основном тимлид именно такой, а не такой как у вас. Так что может у вас термины перепутались?
Это самый стандартный подход во всем мире. И предполагается, что он тоже пишет код (10-30%)
Все зависит от размера кампании, если в компании 20 человек, то на 5 человек тимлид - это нормально.
Это не вопрос подхода, это вопрос терминологии.
Исторически в самоорганизованной команде появляется её лидер, который не только пишет код, но и что-то организует и коммуницирует, его называли тимлидом раньше. Сейчас кого только так не называют, в том числе и линейных менеджеров.
Team Lead не должен писать код.
Давайте сделаем так. Тимлид не обязан писать код, а не не должен.
Он руководит не всей командой, а своим набором девелоперов. Тимлид маркетологов рулит маркетологами, тимлид дизайнеров - дизайнерами.
Если у вас фича-команда, то он будет обязан разбираться во всем, поэтому зачастую фича команды существуют в виде "девелопер-дба-qa", а не все эти маркетологи и так далее.
Tech Lead не стоит над проектом. Это просто ключевой технический человек в конкретной команде девелоперов или маркетологов или QA. Над проектом стоит архитектор.
Lead Developer это вообще не позиция, ну по крайней мере не самая популярная
То, что вы описываете под термином Tech Lead - напоминает "главного инженера" из еще советской штатки НП-предприятий. А Lead Developer, в данном случае, это аналог ГИПа (главного инженера проекта).
Имея столь долгую ретроспективу вопроса - можем поговорить об эффективности. В итоге, позиция главного инженера на большинстве предприятий выродилась во что-то совсем не инженерное, а главная их обязанность - визирование техдокументации. При этом, детально разбираться во всем многообразии технических вопросов предприятия (применительно ко всем его проектам одновременно) - довольно сложно для одного человека, а с учетом потери квалификации как инженера - их виза и вовсе теряет смысл, превращаясь в формальность. Тем самым, они просто снимают часть ответственности с гендиректора.
А поделитесь секретом, как вам удается писать код когда в день 4 созвона на 3 часа с зазором в 30 минут + вопросы в чате которые нужно порешать + поправить какой-то конфиг + исследовать проблемы на стенде + еще всякая мелочевка. У меня не получается вот никак.
Вот именно по этому я и начал задумываться об уходе на пенсию ;)
Кмк, сама по-себе, жёсткая структура не очень хорошо отражает краткосрочные софтовые проекты. Вот у нас в текущей группе ТЛ и 3 рядовых сеньора; при этом проекты ведут сеньоры. Соответственно, если кто-то выполняет часть чужого проекта, он должен переподчиниться временно, что ли? Очевидно, что ведущий проект обладает большей компетенцией по проекту, чем временный помошник. Но через месяц будем подтягивать другой проект, там будет другой ведущий.
Именно так у меня организовано. Я лид у группы в примерно 50 человек среди которых и формируются команды, причем в разных задачах главным в рамках задачи становится тот кто в конкретной задаче, вчерашний главный в другой задаче может стать подчиненным, в том числе синьор у джуна, и никаких проблем
Вот кто главный в описываемых Вами командах, те и тимлиды, а если под вами несколько таких команд, то вы не тимлид, скорее тимлид тимлидов, но более правильное название Engineering Manager.
Обычно нижняя структура фиксируется, при этом менеджер нижнего уровня называется Team Lead по традиции. Некоторое время назад это был «играющий тренер», «первый среди равных», но сейчас это всё больше и больше вырождается в менеджера среднего звена. При этом проекты падают на сеньоров, которые и организуют что-то гибкое, как вы описываете.
по вечерам, выходным итд
А ты что думал?
как вам удается писать код когда в день 4 созвона на 3 часа
Ну вы сами обозначили то, что съедает основное время.
А все ли эти созвоны являются обязательными для вашего проекта? Точно нельзя их пропустить?
А можно сделать покороче то, что пропустить нельзя? Концентрироваться только на важном. Не отступать от агенды. Все, что вылезло, не обсуждать сразу же, а запарковать и (возможно) поручить другим людям.
Ок, допустим все важно и короче сделать нельзя. Тогда делегируйте.
Это тех встреча? Делегируйте синьору или системному аналитику или архитектору. Потом за 5-10 минут он вам расскажет все о чем договорились на часовой встрече.
Это бизнес встреча? Делегируйте бизнес аналитику.
Вам некому делегировать? Растите спецов в команде.
Если вы и БА и СА и архитектор и менеджер и еще конфиги правите - ну, не удивительно, что времени не хватает.
Делегирование - наше все!
Хороший план, если я все делегирую то работы останется на пару часов в неделю, кто б мне еще за это полную зарплату платил, эх. PS. Написание кода я делегировал в первую очередь)
Если вы успешно все делегируете без потери контроля и производительности - то вам не просто зп будут платить. Вас повысят, чтобы вы масштабировали опыт и принесли больше пользы.
Пока на вас завязаны все процессы - никто вас не повысит. Ведь вы не вырастили никого, кто вместо вас сможет по 3 часа в день совещаться и все разруливать.
Вы знаете, этому сильно помогает таймзона. Я понимаю, что для многих это не вариант, просто как факт. У меня пересечение с основным контингентом в компании примерно 3-3.5 часа в день, и впихнуть 4 созвона на 3 часа (это кстати любовь исключительно отдельных людей такое кол-во времени) это уже не моя проблема. Плюс все чаты и почта это примерно 2-2.5 часа в день (не просто прочитать-ответить, а ещё проанализировать и понять).
Да, мне становится проблема, когда мне надо минут 15-20 от человека, чтоб найти у себя свободные эти минут в периоде 3-3.5 часа и одновременно у человека который мне нужен.
Кстати подобное заметил не только я, у кого подобное пересечение.
Редактировано: Дополнительно что вспомнил, некоторые люди в своём календаре забивают по 2-4 часа в день на "само-митинг" и делают в эти часы что они хотят сделать. В принципе тоже самое что и разница в таймзоне.
Очень просто. Садишься и пишешь, когда есть свободные 15 минут. Один из навыков тим-лида - уметь постоянно переключаться между задачами
Я тимлид и не пишу код как минимум 3 года. Я нанял достаточно хороших разработчиков в команду чтобы они это делали.
Если вы не пишете код, то утрачиваете техническую квалификацию. А если вы не обладаете технической квалификацией, то по-факту вы не являетесь тимлидом
Так я хочу дальше в CTO расти. Нахрена мне этот код нужен. Руководство хочет результаты - они их получают, а кто там писал код им уже нкиакой разницы нет.
Если вы не пишете код, то утрачиваете техническую квалификацию.
Да и хрен с ним. Я хочу решать высокоуровневые задачи, например, найти разработчика на рынке труда. Если захочу код написать то лучше pet-проект сделаю. Простите, но всю жизнь писать код я не планировал.
Наняла разработчиков всё же фирма. Или вы ее владелец?
CTO который забыл как писать код - так себе CTO в софтверных компаниях. Как минимум не надо забывать навыки чтения)
Зачем CTO читать код, если у него не синдром Илона Маска? Чтобы что?
Что бы понимать где херню делают а где хорошо работают. Иначе не понятно зачем в его должности буква Т. И не вижу ничего плохого равняться Илона.
Индустриия ещё не придумала объективных метрик качества, которые бы позволяли оценить код без его чтения.
Вы можете привести пример того, как это по-вашему должно происходить на практике? CTO выбирает случайный комит из десятков (а то и сотен или тысяч) за день и смотрит насколько хорошо код оформлен?
Когда у какой-то команды что-то долго не получается, хотя ему кажется что там все должно легко быть, он залезает в код и пытается понять смог бы он сам это сделать, если нет то почему и т.п. А лучше даже заранее иногда посматривать, что-бы упредить такое развитие ситуации.
А дальше делает выводы о компетенциях тех кто эту часть системы проектировал и разрабатывал. Если архитектура г. - значит техлид той команды слаб. Если архитектура норм, но реализация компонентов паршивая - значит команда не может набрать нормальных разрабов (или управлять ими). А может у них все хорошо - но какая-то смежная команда насоздавала проблем в связанных частях системы и из-за этого все плохо.
CTO выбирает случайный комит
Нет, CTO скорее решает, какие языки использует и поддерживает организация (и, скажем, в какие комитеты по стандартизации стоит войти), а для этого читать код (необязательно написанный в самой организации) всё таки стоит.
Вы и автор что-то слишком драматизируете. Я 10 лет не писал на PHP, но вполне себе бегло могу просмотреть код. Так что потеря навыка после нескольких лет разработки мне кажется это вообще из области нереального
Я не совсем такой (но действую так же). Мне тупо нравится писать код, я это делаю. В нерабочее время. В рабочее делаю как и Вы
>>Руководство хочет результаты - они их получают, а кто там писал код им уже нкиакой разницы нет.
По сути, вы занимаетесь "продажей" руководству результатов труда разработчиков.
тут вопрос терминологии. Вы себя называете тим лидом, хотя по сути являетесь менеджером среднего звена, пришедшему из программирования. И, т.к. воспоминания об основной профессии в вас еще слишком свежи, вы хотите называть себя тимлидом и "первым среди равных", хотя равным уже, скорее всего, не являетесь, и чем дальше - тем больше будете отдаляться от разработчиков, терять с ними общий язык, и уходить в мир бордов, карточек и отчетов.
Ни в коем случае не осуждаю этот выбор, все профессии нужны, и если вы успешно справляетесь со своими задачами, руководство вас ценит и т.п. вы приносите пользу бизнесу - значит так и нужно, но я бы все же назвал вашу позицию не тим лидом, а <выберите удобную приставку> менеджером
Если сохраняет возможность писать качественно - пусть пишет. А если это уже входит в конфликт с менеджерскими обязанностями, то лучше не надо. Я как-то за карьеру уже наелся этих приколов: типа тимлид там наговнякал какую-то идею в коде, а ты иди доводи до ума. Сделано наспех - сделано на смех. Возьми лучше и задачу в трекере грамотно распиши, чем говнокодерством заниматься.
Тут уже тимлиду в какой то момент необходимо принять решение о том, куда ему дальше развиваться. Либо идти по пути классического карьерного роста в сторону менеджмента среднего звена и дальше в топ менеджеры. Тогда надо переставать писать код, переходить на позицию менеджера проекта, и на своё место ставить толкового паренька из команды. Либо начать расти "вширь", и углублять техническую квалификацию. Тогда нужно выбить на проект этого самого пресловутого менеджера проекта, и всю менеджерсую баламуть спихнуть на него.
Тогда нужно выбить на проект этого самого пресловутого менеджера проекта, и всю менеджерсую баламуть спихнуть на него.
Так музыку-то не тимлид заказывает. Мелкие и средние компании просто не тянут сразу 2 ставки эксперта и менеджера проекта. Отсюда и все эти "играющие тренеры".
Отсюда и все эти "играющие тренеры".
Последнее время часто вижу этот термин в вакансиях. Обычная экономия. Так же сейчас ищут разработчика и девопса в одном лице и тп
Мелкие и средние компании просто не тянут сразу 2 ставки эксперта и менеджера проекта. Отсюда и все эти "играющие тренеры".
В реальности дело обстоит ровно наоборот. "Играющий тренер" - это очень справедливое и выгодное предложение.
Вот как вы думаете, что происходит с проектом (если он не разваливается конечно), когда тимлид уходит в секретарши, и перестает выполнять все те функции, которые я описал в статье?
А происходит следующее. Один или несколько инициативных разработчиков берут эти функции на себя. И по факту получается, что такой инициативный разработчик продолжает на 100% тянуть лямку разработчика а вдобавок неофициально тянет лямку тимлида. А, так так официальных полномочий у него нет, ноша тимлида оказывается раза эдак в 2 тяжелее обычной. Т.е. получается, что он за ту же самую зарплату работает за троих. А потом секретарша просыпается, вспоминает, что она таки тимлид, и начинает бить этого самого инициативного разработчика по рукам.
Разработчик весь этот балаган какое то время терпит, а потом просто увольняется и идет уже на официальную позицию играющего тренера. И там он уже может вздохнуть с облегчением. Выкладываться на 100% как разработчик не надо, можно тратить 50% времени на разработку. Полномочия тимлида официальны, партизанить не надо, в подполье прятаться не надо, соответственно функции тимлида начинают выполняться легко и играючи. Плюс чисто психологически проще - никто тебя не пресует и не бьет по рукам. Вот и получается, что за зарплату 1.5x такой разработчик начинает работать в 3 раза меньше да еще и в комфортной психологической обстановке.
Должен ли Линус Торвальдс писать код, да еще и низкоуровневый?
Должен ли заведующий кафедрой преподавать?
Должен ли Илон Маск подавать молоток рабочему, если он его попросит ненароком?
Думаю, зависит от сочетания желания и нагрузки.
А так, если опыт был приобретен, то Team Lead должен скорее читать код, чем писать. Читать документацию, следить за развитием технологий. Составлять документацию по проектам. Писать код - отдельная работа, требующая много времени. Пилить свои задумки в фоне, ставить микро эксперименты - почему нет, что-нибудь да и пойдет в продукт, не сейчас, так через год-два.
Итого: если Team Lead не пишет продуктовый код, ничего страшного.
Коротко: да
Должен ли Линус Торвальдс писать код, да еще и низкоуровневый?
Да, если хочет остаться Линусом Торвальдсом
Должен ли заведующий кафедрой преподавать?
Хотя бы иногда, если не хочет остаться чисто администратором.
Должен ли Илон Маск подавать молоток рабочему, если он его попросит ненароком
По-настоящему - ни в коем разе, если хочет остаться Илоном Маском! Для PR - можно.
да кому нужны будут эти "задумки в фоне", от человека, который не занимается разработкой, тем более через год-два. Пошли в менеджмент - идите до конца.
Торвальдс ценен именно как программист и визионер низкого уровня, если бы в 90-х годах он стал менеджером линукса, то в 2005 не родился бы Git.
Если вы не пишете код, то утрачиваете техническую квалификацию. А если вы не обладаете технической квалификацией, то по-факту вы не являетесь ...
Эта логика должна работать вплоть до СТО или как? Где граница?
Очень хороший вопрос. У меня, к сожалению, нет на него ответа. На мой взгляд CTO - это вообще растрельная позиция. С одной стороны нужно обладать широкими (но, часто не глубокими) техническими знаниями. C другой стороны, поддерживать себя в форме, продолжая писать код, на такой позиции скорее всего нереально.
Я поэтому всегда осознанно отказывался от позиций такого уровня. Потому что просто не знаю, как на них выживать. Если найдутся люди, которые поделятся своим опытом выживания в роли CTO, то будет просто замечательно.
Граница там, где вы перестаете работать с непосредственными исполнителями.
Начальник должен хорошо понимать работу исполнителя. Быть в контексте. Уметь (может лучше, а может хуже - вопрос дискуссионный) делать эту самую работу.
Когда вы MoM, то есть в нашем случае менеджер лидов, вам нужно понимать работу лида. Код для этого не нужен
То есть, стратегически планировать и всё такое, по сути не зная технологий, а лишь читая полупопулярные обзоры и хвастливые презентации?
Да, стратегически планировать, обладая общим бэкграундом и опираясь на оценку нижестоящих.
А в какой другой области по-другому?
Менеджмент среднего звена делает другую работу. В частности, управление рисками.
Топ-менеджмент вообще модет быть другой специальности. И это даже хорошо. Ему не код писать надо, а управлять предприятием. Что является отдельной дисциплиной.
Судя по комментариям, тимлидом в разных компаниях называют СИЛЬНО разную сущность.
Написание кода - это удивительный и чарующий процесс.
Особенно когда всё уже делается на автомате, независимо от языка. Руки пишут всё сами, а глазам остаётся только делать код-ревью. Предполагаю, что у автора это так и получается.
Для тимлида написание кода может быть вообще одним из немногих доступных видов отдыха после бесконечных созвонов-митингов-плэнингов.
Надеюсь, не придется столкнуться с ситуацией как в нашем сельском хозяйстве: в 90 и 0 хлынули военные (ведь они управляют подразделениями, значит и предприятием смогут!) ну как бы так себе идея. Потом ближе к 10 началось полицейско-милицеское нашествие, основная тема- контроль (всего на свете). Сейчас пришли банкиры и прокуроры, даже актеры и журналисты и все это не рядовые позиции, это менеджмент, это замы и генеральные. Я к тому , что руководитель должен быть в теме, он может и не писать код, но знать отрасль и как устроены языки (чем например Питон от С# отличается или от 1С) он должен. Это мое мнение.
Еще раз убеждаюсь что в тимлиды (да и в целом в руководство) идут чтобы работать - меньше работать, а получать больше)
Я недавно сформулировал для себя правило эффективного найма независимо от роли - фактически из мира схемотехники. Есть пассивные и активные элементы. Активные обеспечивают выполнение бизнес-задач, а пассивные выполняют согласующие, демпфирующие и стабилизирующий функции. Так вот, применение активных элементов в схеме должно быть оправдано - человек в соответствующем месте должен принимать решения или действия, модуль денежного эквивалента которых многократно превышает стоимость его рабочего времени для компании за тот же период. То есть, если ты - транзистор, то твой h21 должен быть >> 1.
Как выше уже было сказано - роль тимлида сильно зависит от компании. Где то это просто техлид, где то занимается people менеджментом, где то отвечает за зарплаты, где то является solution архитектором, у кого-то в подчинени 5 человек, у кого-то 35. И вот от набора этих самых является и зависит должен ли тимлид писать код или нет.
У нас в компании считается что тимлид не должен писать код при этом если он его пишет - это не возбраняется, но лишь при условии что остальные «обязательные» активности не страдают.
Сам я с мнением автора насчет потери квалификации не согласен, вполне можно регулярно читать код своей команды и оставаться «в тренде», выполняя функции технического менеджера.
Как-то интересно у вас получается, чёрно-бело: как только человек перестал писать код, он сразу же "выпадает из темы", теряет квалификацию, забывает весь свой бэкграунд, разучивается понимать трудоёмкость...
Но это же, простите, глупость. Вот я тимлид. Я писал когда-то на фреймворке версии 7.3, потом стал тимлидом, после этого моя команда перешла на тот же фреймворк, но версии 8.1. Если я сейчас полезу писать код, то я однозначно наговнокодю, потому что я буду писать в привычном стиле (для версии 7.3). Поэтому я код не пишу. Вопрос: почему в этой ситуации должны пострадать все те навыки, что вы перечислили - в любом из ваших списков?
Ну, я намеренно написал статью в несколько провокационном стиле. У вас есть полное право не соглашаться с моим мнением. Но, я надеюсь, что благодаря моей статье вы задумаетесь, и сами себе зададите вопрос - "А правильной ли дорогой я иду? Это точно то, чего я хочу от этой жизни?" На этот вопрос тоже нет правильного или неправильного ответа. Просто возможно вам этот вопрос поможет понять, что вы свернули куда-то не туда. И вовремя исправить ошибку. Или наоборот - окончательно убедиться в том, что выбранный вами путь лично вам хорошо подходит.
писал когда-то на фреймворке версии 7.3, потом стал тимлидом, после этого моя команда перешла на тот же фреймворк, но версии 8.1.
Гораздо хуже, если бы это был "фреймворк" версии 7.7 и переход на 8.3
Вы же сами пишете, что после перехода команды на новый фреймворк наговнокодите. Значит, квалификация устаревает. И забывается. Да, не за день. И не за год. Бэкграунд просто так не пропьешь.
Но в любом случае, с течением лет, технические навыки пострадают. Взамен разовьются другие навыки. И это - нормально
эта ситуация возникает, когда в компании нет возможности расти, не становясь менеджером. когда заколочена установка, что надо быть начальником, чтобы прибавлять в зарплате. так хорошие программисты, которым нравится писать код, становятся плохими менеджерами, потому что обнаружили что от секса заводятся дети и ипотека. тогда TeamLead будет фокусироваться на постановке задач, контроле и улучшении процессов, а TechLead будет совершенствоваться в технических высотах. Хорошей практикой, которую стоит перенять у зрелых компаний, является практика высоких корпоративных грейдов для крутых спецов - вплоть до ранга вице-президентов с соответствующей зарплатой
А можно начать текст с определения термина тимлид?
А то может это как с "котлета", которую в России понимают по одному, а во Франции - по другому?
Нет хуже обиженного программиста, чем программист, которому 46 лет... очень жаль, что вам попался такой тимлид, который не научил уважать себя, свою сферу деятельности и своего тимлида. Если ваш текущий тимлид вас не устаивает, то найдите другую работу.
Не просто должен, а обязан. Это синонимично старой песне про микроменеджмент: понабирают по объявлениям велеричивых читателей книг про успешный успех в плохом переводе с ангельского и они начинают рассказывать бизнесу, что руководитель не должен ничего делать сам т.к. это убивает его эффективность. Пока у компании есть деньги, чтобы руководители водили руками - это длится, но затем оказывается, что для "убийства эффективности" надо чтобы было что убивать. А "убивать" уже нечего. Никто вообще не понимает что и как работает. И даже: работает ли хоть что-то - тоже)))
По моему опыту - конечно должен, но не на проекте которым он руководит.
>>Почему секретарша является самым дорогим ресурсом в команде?
Очевидно, потому что эта секретарша общается с вышестоящим начальством.
С точки зрения типов профессионального роста, программисту расти до начальника обычно смысла нет - он растёт квалификационно, в лестнице не поднимаясь выше того же техлида (хотя сколько человек подчиняются его решениям, не определено - могут быть и миллионы).
Зато для QA карьера до тимлида и выше - самое оно: сохраняя принципиальную техническую компетентность, он её только улучшает от такого роста. (Разумеется, если это грамотный разносторонний QA, а не просто тестер.)
Для принятия принципиальных решений вроде какую архитектуру выбрать - у него есть возможность заслушать разных экспертов. Так работает уже давно за пределами IT, где не важно, например, что начальник подразделения может не знать сам какие-нибудь параметры твёрдости конкретной марки стали.
Понабрались англицизмов и запутались в них. Тимлид это просто начальник. Когда управление меняли на менеджмент всем ясно и четко объясняли что начальником может быть дурачок. Самое главное чтобы он не импровизировал и действовал по выданному скрипту. Многие приняли правила игры, а многим здравый смысл не дает покоя.
По логике компетентность в области падает с ростом должности. Директор может быть нулем в технике. Мне не повезло увидеть человека умного в технике и управлении одновременно. Возможно такие есть, но те что видел лажают из-за профдеформации. Во всяких НИИ начальство выбиралось из инженеров. При госплане они делали что требовалось. Когда сказали "крутитесь сами" оказалось что найти заказ и организовать продажи не способны. Все держится только на связях в оборонке. Влезть в гражданский рынок не способны. Например было все чтобы создать свои мобильники. Потом пришли аффективные менеджеры и лучше не стало. Какая там должна быть золотая середина не знаю. Может быть есть целые науки про это, но в моем пузыре признаков их существования не наблюдаю.
зы. Судя по комментам у многих карго культ :-)
Классическая путаница.
Тимлид должен уметь писать код, но совершенно необязательно должен писать код для проекта, командой которого он руководит. По моему опыту наличие 7+ программистов уровня middle в команде приведет к тому, что тимлид вообще перестанет код писать.
Тимлид обязательно должен читать код, чтобы понимать что делают его подчинённые.
Тимлид, очевидно, должен поддерживать квалификацию, чтобы его умение писать, читать и понимать код не устарело. Поэтому очень даже неплохо если тимлид таки пишет иногда код своего проекта, иначе ему придется еще как-то в нерабочее время поддерживать квалификацию.
Единственный вариант тимлиду не писать код, если он за время устаревания навыков разовьет менеджерские скилы настолько, что перескочит на следующий уровень - тимлид-тимлидов или как он там называется.
Чисто теоретически за качеством кода может следить техлид. Для понимания того что один человек в команде быстро решает выделенные ему таски а у другого это все очень сильно затягивается, как и оценивать уложится ли исходя из этого команда в дедлайн или нет технические подробности тимлиду знать не обязательно. Но на практике конечно способность читать код и разбираться в том как таски формируются тимлиду помогает очень сильно.
Не понимаю в чем функция тимлида, если есть еще и техлид. А если есть еще ПМ, ПО, начальник отдела и еще куча менеджеров, то тем более.
Я наверное слишком стар, но все еще живу по модели команды, описанной Бруксом - "бригада хирургов". В ней есть главный хирург (тимлид), который отвечает за успех операции в целом, несколько специалистов в своих областях и медсестры, которые подают инструменты и накладывают повязки.
При этом бригада не выбирает сама кого лечить и от чего лечить. Хотя главный хирург (тимлид) может быть также лечащим врачом (архитектором решения), а может и не быть.
Если брать PAEI модель менеджмента Азидеса, то менеджмент сводится к четырем вещам
Producer - способность добиваться результата. Руководитель понимает куда команда должна идти, какой результат должен получиться и добивается его
Administrator - организация процесса разработки. Сколько времени займет процесс разработки? Сколько человек понадобится? Сколько мы в прошлый раз сделали? Каких правил мы придерживаемся?
Entrepreneur - генерация идей. Что нужно бизнесу? Что хотят потребители?
Integrator - организация людей в команду. Как разрулить конфликт между парой девелоперов? Кто нуждается просто в похвале а кому надо дать денег? Если Вася пришел с вопросом X то кто может на этот вопрос ответить?
Любой менеджер должен в какой-то мере уметь все четыре вещи, но он в принципе не может быть сильным во всех четырех. Поэтому надо иметь несколько типов менеджеров, каждый из которых отвечает лишь за часть из вышеописанных направлений. Вместе они будут работать наиболее эффективно. И тут довольно естественным решением является вытащить P и E на уровень компании в целом. А тимлид соответственно - это тот кто возьмет на себя функции A и I.
То есть
менеджер говорит что нам для компании надо бы сделать продукт X
техлид говорит что для этого возьмем технологию Y и сделаем последовательность шагов 1,2,3...
тимлид вместе с техлидом превращает эти шаги в таски для разработчиков и исходя из прошлого опыта оценивает время потребное на каждую таску и число нужных людей / время на общую разработку
дальше тимлид пинает разработчиков чтобы они соблюдали установленные правила, ведет документацию по проекту, следит за тем чтобы статус тасок отражал реальное состояние дел, оценивает то укладывается команда в срок или нет, поднимает тревогу если возникают проблемы, объясняет к кому обратиться за помощью, выставляет оценки работе индивидуальных разработчиков и т.д.
В общем административная деятельность и поддержка.
Натягиваете сову на глобус. Тимлид это не "менеджер", "менеджер" это примерно на два уровня выше. Тимлид решает очень частную задачу - как сделать так, чтобы все члены команды "гребли" в одну сторону с максимальной эффективностью.
Ну так я не вижу тут противоречия. Тимлиду и его команде спускают список задач сверху, он просто следит за тем чтобы они выполнялись и обеспечивает поддержку сотрудникам. Техлид же и прочие менеджеры относится к тем кто эти задачи ставит, корректирует и принимает решение выполнены они или нет.
Это Ваша терминология про уровни или откуда то? У нас в компании около 15 тыс штатных сотрудников. Я тимлид, у меня уровень ГД -2. То есть, между мной и генеральным директором есть только один промежуточный слой. Есть и по другому, но примерно такую же иерархию я видел в нескольких крупных компаниях. Тимлид для 5-10 человек для меня выглядит как нонсенс.
В ЦК КПСС тоже самый главный был -Генеральный секретарь
Ситуация с терминологией сильно напоминает ту, что сложилась у инфраструктурщиков.
Раньше системный администратор был синонимом гуру глубин систем, нынче - синоним эникейщика.
Ну и выше тоже пошла фигня полная с названиями, системный инженер, руководитель группы, архитектор... И это в эксплуатации, а если ещё и разработку взять, то там вообще ад полный. Куча смежных ролей , определение которых позволило массе дилетантов влиться в процесс, под вывеской всяческих xxx-Ops-ов.
Я считаю, что тимлид просто обязан быть технарем, иначе он не сможет ни корректно задачи поставить, ни оценить трудозатраты, ни подобрать кадры, ни обучить подчиненных. По моему опыту, идеальный тимлид, это тот, которые некоторые тех задачи делает сам, но не для того, чтобы сделать что-то за подчиненных, а чтобы быть в курсе актуальных изменений, не терять квалификацию.
Если говорить про технического директора, генерального директора, то конечно они должны заниматься только руководящей деятельностью. Но самые лучшие на моей практике директора это те, кто сам начинал с азов, сам ручками все делал. Тогда он не ставит бессмысленные задачи, типа сделать за 2 часа то, на что нужна неделя.
Давайте начнем с того, что в разных компаниях разные требования к позиции тимлида:
кто-то считает, что это руководитель группы разработчиков
кто-то считает, что это руководитель группы сотрудников, среди которых есть аналитики, разработчики, QA и тд.
кто-то называет тимлидом главного разработчика
кто-то называет тимлидом руководителя IT
кто-то считает, что тимлид еще и в бизнес должен уметь
И, в зависимости от того, кто где работает, смотрит на позицию через призму своих процессов.
В моём идеальном мире тимлид - это руководитель группы разработчиков, он пишет код и управляет своей командой, в том числе декомпозируя задачи, проверяя код перед релизом и тд. И повышает скилы своей группы.
Он не занимается планированием дальше, чем на 1-2 спринта, он не нанимает разработчиков, хотя участвует в собеседовании, не умеет в бизнес и даже, практически, не ходит на совещания.
В его группе несколько профильных разработчиков, не больше 10. Он не выбирает задачи на команду, а получает их сверху
Встречаются еще т.н. "лидеры компетенции", считающие (не все), что они слишком заняты менторством, руководством, наймом, развитием и тому подобными вещами, чтобы что-то делать самостоятельно.
Карабас-Барабас никогда не стремился играть на сцене, но директором театра был крепким.
Так он не был тимлидом. Он был РП, который методом кнута собрал аджайл-команду. Без тимлидов.
Но даже в сказках оно так долго не работает. Если я правильно все помню, тимлид Буратино увел команду и основал свой театр с блек джеком и Мальвиной.
Но даже в сказках оно так долго не работает. Если я правильно все помню,
тимлидБуратино увел команду и основал свой театр с блек джеком и Мальвиной.
Не было бы у них “наследства” в виде своего театра — хрен бы он куда кого увел и что-нибудь основал
Хронологически, сначала он все-таки сколотил свою кукольную банду команду. Которая прошла шторминг-норминг по Такману. Проник во внутренний круг влияния по Берну. И не грубой силой (попрбуй на Артемона повыделываться), а личными качествами.
Наследство - оно уже потом образовалось.
И что бы он сделал с командой без театра и оборудования?
Хз. Может, выступал бы на ярмарке под звуки шарманки. Не принципиально.
Главное то, что команду-то он собрал.
1) Он команду не собрал, а увёл готовую
2) Не факт что эта команда согласилась бы выступать по ярмаркам, а не уйти в другой театр.
Папу Карло он знал очень хорошо. И, видимо, на заре карьеры был совсем другим, имел ключ и вёл интересные разговоры с Тортиллой 300 лет назад. Но со временем испортился, а с этого момента и начинается повествование.
В команде должны быть человек или люди, которые держат нервную систему других людей. Бытовые вопросы, не заставлять делать, то что не умеет или хуже получается, банальный контроль настроения и т.д.
Большинство из них перекидывают на королеву сплетен и интриг - секретаршу. Она и вовремя подскажет не наезжать на Васю, поддержит Машу, при этом не особо вмешиваясь в техпроцесс.
Собственно говоря и снимая с тимлида мелкие обязанности по поддержанию нервной системы сотрудников.
Бывают, конечно крайние случаи, когда не так, но в принципе моделька распространённая.
То, что вы хотите видеть как тимлида, скорее сеньер которому поставили задачу создавать и двигать таски в JIra. Это не Тимлид
Почему секретарша является самым дорогим ресурсом в команде?
Иначе начнется разврат!
Полностью соглашусь с
Если вы не пишете код, то утрачиваете техническую квалификацию. А если вы не обладаете технической квалификацией, то по-факту вы не являетесь тимлидом.
В реальности тут нечего обосновывать, так как это очевидно :)
А вот некоторые моменты ниже спорны:
Вы не можете нанять инженера, так как вы не в состоянии оценить его квалификацию.
Легко, поверьте. Дело в том, что проверить знания намного легче, чем их иметь. Но тут скорее надо иметь общие знания, а не детальные
Вы не можете поставить задачу инженеру, так как вы не можете её сформулировать
Вот это еще легче. БА ставит бизнес таску на ура, а технически задачу может поставить архитектор. А QA проверит выполнение с их помощью
Ну и т.д. Просто знание на общем уровне + понимание процессов + понимание что надо творит чудеса. Задача тимлида как раз в том, чтобы ревьють, коучить, организовывать на своем уровне.
Как бы так сказать. Задача тимлида в первую очередь делать свою работу и отвечать за результат команды. А попытка распыления - это хорошо, если это реально делать больше некому. Но не стоит думать, что смежные задачи может делать только тимлид
чем меньше вы понимаете в предметной области (а с годами непрограммирования этот скилл будет только расти), тем сложнее вам будет делать вами же перечисленные задачи. Коучить там и все что вы написали. Кого вы там будете коучить, чему, если ваша работа - это созвоны и карточки. Можете коучить тому, как карточка уходит из Planned в In progress.
По моему субъективному опыту, нет хуже начальников, чем "я 10-15 лет назад тоже кодил, я программист, там все просто, а еще Дельфи знаю, где кстати делся Silverlight"
чем меньше вы понимаете в предметной области (а с годами непрограммирования этот скилл будет только расти), тем сложнее вам будет делать вами же перечисленные задачи.
Я ж вроде написал, что полностью за то, что тим лид должен писать код, причем на самом верху :)
если ваша работа - это созвоны и карточки
Опять же, ваша работа - "результат команды". Это очень важно понимать. Если тимлид тонет в созвонах и карточках - он просто не очень хороший тим лид, вот и все. Либо на него повесили очень много не его работы, а он взял и несет.
Тимлид обязательно должен кодить, но вот найти баланс - это и есть часть работы. Возможно стоит брать разные задачи, чтобы не терять навык в мелочах, а также сложные задачи, чтобы смотреть вперед. Карточки вообще двигаюют исполнители, причем тут тимлид. Колы - часто это отличное время поработать :)
Всё верно написано. Но справедливости ради: где вы в России видели тим-лида, который вообще не пишет и не понимает код? Как по мне, у нас проблема ровно обратная: у нас самому пашущему программисту обычно вручают должность тим-лида, без чёткого понимания последним, какие функции предполагает эта работа. Либо с пониманием, но без ресурсов в виде времени/власти/денег
вручают должность тим-лида
Вопрос как именно "вручают" - что при этом меняется в трудовой (как там вообще по русски пишется "тим лид"?) и формальном списке должностных обязанностей? Просто всегда работал в компаниях с явно выделенными менеджерами (начиная от команд человек на 7-10) и что такое "тим-лид" не очень представляю.
Согласен в целом с позицией, и сам был лидом и пишущим код, и не пишущим.
Но при этом не со всеми аргументами согласен.
Лид, который не пишет код != лид без технической квалификации. Часть поднятых проблем касается только второго, но не первого.
Видно что статью писал разработчик со своего масштаба задачи.
Все всегда идет от задач конкретного бизнеса, ведь это бизнес платит деньги разработке, а не разработка сама себе.
Обычно на крупном, серьезном проекте/продукте есть большая бизнес-задача, которая декомпозируется на команду или команды, таким образом получается много разного типа задач, которые подвязаны к одной бизнес задаче.
И обычно, чисто технических задач, типа: написать код, провести код-ревью, не больше 20% , остальные 80% - это не чисто технические задачи, и разработчик(типа автора) не будет их выполнять т.к. если его попросить за все это отвечать он на 2ой день уволиться.
Этого не понимают многие разрабы т.к. смотрят со своей колокольни.
Плюс ко всему автор сделал явные ошибки:
1)Не можете осуществить декомпозицию крупных технических задач.
Еще как может. Обычно этого не могут разработчики т.к. не понимают всей логики решения.
Не можете адекватно расставить приоритеты задачам.
Приоритеты расставляет Бизнес, владелец продукта, разработчик о приоритетах обычно ничего не знает. ну и тд.
Так же хороший архитектор не обязан знать всех языков программирования, но не всякий разработчик является хорошим архитектором. Так что архитектуру разработчикам я бы не стал доверять полностью.
Почему секретарша является самым дорогим ресурсом в команде?