Комментарии 15
НЛО прилетело и опубликовало эту надпись здесь
Мы последних пять лет даже без «старшого» обходимся. Все кодеры равны, сложные решения принимаются сообща. От этого много профита в сравнении с выделением тимлидов, техлидов, архитекторов…
Я так понимаю, тех. лид и может быть тем самым «старшим». Ведь без формального бейджика он может чувствовать себя не в праве уделять багам меньше времени чем другие члены команды. Может не иметь формального права «ставить точку» в споре, который длится уже долго, а какое-то (пусть и плохое) решение — будет лучше чем ещё один день в митинге. И ещё разные моменты есть.
Прочитал в RSS заголовок статьи, и сначала долго силился понять, почему на хабре обсуждают соединения технеция…
Автор путается в терминологии. Если речь идёт о тимлиде, то это одно. Если о ведущем программисте, устоявшемся переводе термина tech lead — другое. Но автор очевидно пишет о тимлиде!
А если через пятнадцать лет опыта у автора даже элементарная терминология не устоялась, то заслуживает ли он доверия?
А если через пятнадцать лет опыта у автора даже элементарная терминология не устоялась, то заслуживает ли он доверия?
> Интуиция может подсказывать двигаться в менеджмент или даже в открытие своего дела.
Вообще-то есть еще нормальные люди, которым нравится писать код и совсем не нравится «двигаться в менеджмент или даже в открытие своего дела». С чего вы взяли что нужно хотеть двигаться туда, где некомфортно?
Вообще-то есть еще нормальные люди, которым нравится писать код и совсем не нравится «двигаться в менеджмент или даже в открытие своего дела». С чего вы взяли что нужно хотеть двигаться туда, где некомфортно?
Есть люди, которых бесит, когда их упорный труд руководители, своими ошибками, раз за разом превращают в мусор.
1) В такие моменты хочется взять и сделать «правильно».
2) Найти нормального руководителя, который не станет косячить.
И то и другое, требует понимания важности работы командования.
Даже если ты никогда не будешь сам руководить, важно уметь отличать годного руководителя от «мобильного и эффективного», который все испортит.
1) В такие моменты хочется взять и сделать «правильно».
2) Найти нормального руководителя, который не станет косячить.
И то и другое, требует понимания важности работы командования.
Даже если ты никогда не будешь сам руководить, важно уметь отличать годного руководителя от «мобильного и эффективного», который все испортит.
Я уже довольно давно нахожусь в позиции «я выбираю руководителя, а не руководитель выбирает меня». Поэтому мне не нужно «брать и делать правильно», я просто не работаю с такими людьми.
Вообще, в нормальных компаниях давно поняли, что слесарь гораздо важнее директора завода.
Вообще, в нормальных компаниях давно поняли, что слесарь гораздо важнее директора завода.
Статья не ставит целью сподвигнуть двигаться в конкретную сторону, буть то менеджмент или архитектура. Мысль абзаца была в том, что нужно пробовать то, что кажется интересным. Каждый ищет баланс для себя. Одновременно с тем, часто можно услышать мнение, что менеджер или свое дело — это интереснее/перспективнее/круче, чем разработка. Какой смысл спорить, возможно, для кого-то это и правда так. Но сложно понять, не попробовав.
Даже студент, который ищет практику, может оценить командование (со своей колокольни) и отказаться работать в организации.
Позвольте с вами не согласится. Директор завода — важнее.
С него спрашивают больше и платят ему тоже больше.
Если ты имел глупость связать свою судьбу с «мобильным» — терпи или ищи другую работу.
Собственник не будет увольнять директора из-за претензий слесаря.
Учитесь уважать работу управленцев — это всегда полезно.
Позвольте с вами не согласится. Директор завода — важнее.
С него спрашивают больше и платят ему тоже больше.
Если ты имел глупость связать свою судьбу с «мобильным» — терпи или ищи другую работу.
Собственник не будет увольнять директора из-за претензий слесаря.
Учитесь уважать работу управленцев — это всегда полезно.
> С него спрашивают больше и платят ему тоже больше.
> Собственник не будет увольнять директора из-за претензий слесаря.
Да ну?
В нашей индустрии программисты получают гораздо больше менеджеров. И будет, конечно. Директоров вокруг вагон, а хорошего слесаря днем с огнем не сыщешь.
И на управленцев мне и дальше будет насрать, в просьбе отказано :)
> Собственник не будет увольнять директора из-за претензий слесаря.
Да ну?
В нашей индустрии программисты получают гораздо больше менеджеров. И будет, конечно. Директоров вокруг вагон, а хорошего слесаря днем с огнем не сыщешь.
И на управленцев мне и дальше будет насрать, в просьбе отказано :)
Годная статья.
Автор скучными словами пишет правильные вещи.
Спасибо!
Автор скучными словами пишет правильные вещи.
Спасибо!
Чем отличается лидер от других работников? Лидер внушает уважение и доверие компетентностью. Почему уважение и доверие обязательно? Потому, что без него нет команды.
Лидер уверен в том, что он делает и может принимать решения, не очень приятные для большинства, но правильные с точки зрения проекта. Лидер — это тот, кто не может не быть лидером по своему природному складу. Совершенно бесполезно учить этому или рассуждать об этом, на мой взгляд… Техническим лидером будет тот, кто видит чужие косяки, а со своей стороны допускает минимум оных ввиду компетентности. Тот, кто знает, кому, почему и как поручить ту или иную задачу. И не надо быть семи пядей во лбу, чтобы понимать то, что я написал. Это всё набор очевидностей.
Если два разработчика «берутся за одну задачу, а узнают об этом только через 2 недели», то о компании, в которой происходит, можно смело говорить, что команды там нет. Просто нет. Потому, что «умение быть командой» это — само собой — слаженность действий. И если кто-то, кто взял на себя ответственность за это, такое допускает, то это не лидер вообще, а просто какой-то самонадеянный глупец. Лидер — это тот, с кем у команды есть гарантиялучшей цены, то есть наименьшего количества косяков в проекте. Можно, конечно, бесконечно «определять понятия» и рассусоливать, попросту говоря, бесконечно об этом. Но всё на самом деле очень просто: лидер — это тот, кому без ответственности не комфортно. И не важно, за что: за софт, за новый самолёт или за новые вагоны по госзаказу.
Вот была команда техобслуживания у самолёта упавшего. Кто-то там е стал делать штатную, положенную процедуру, махнул рукой: «а, так сойдёт», работу никто не проверил — и самолёт упал. А почему? а потому, что у команды техобслуживания был какой-то «формальный» лидер, который не внушил уважения и ответственности за работу. А если работу любишь, сами приходят и системность, и модульность, и желание развиваться, и всё прочее; потому что «делать как попало» руки не поворачиваются.
Лидер уверен в том, что он делает и может принимать решения, не очень приятные для большинства, но правильные с точки зрения проекта. Лидер — это тот, кто не может не быть лидером по своему природному складу. Совершенно бесполезно учить этому или рассуждать об этом, на мой взгляд… Техническим лидером будет тот, кто видит чужие косяки, а со своей стороны допускает минимум оных ввиду компетентности. Тот, кто знает, кому, почему и как поручить ту или иную задачу. И не надо быть семи пядей во лбу, чтобы понимать то, что я написал. Это всё набор очевидностей.
Если два разработчика «берутся за одну задачу, а узнают об этом только через 2 недели», то о компании, в которой происходит, можно смело говорить, что команды там нет. Просто нет. Потому, что «умение быть командой» это — само собой — слаженность действий. И если кто-то, кто взял на себя ответственность за это, такое допускает, то это не лидер вообще, а просто какой-то самонадеянный глупец. Лидер — это тот, с кем у команды есть гарантия
Вот была команда техобслуживания у самолёта упавшего. Кто-то там е стал делать штатную, положенную процедуру, махнул рукой: «а, так сойдёт», работу никто не проверил — и самолёт упал. А почему? а потому, что у команды техобслуживания был какой-то «формальный» лидер, который не внушил уважения и ответственности за работу. А если работу любишь, сами приходят и системность, и модульность, и желание развиваться, и всё прочее; потому что «делать как попало» руки не поворачиваются.
Да, всё верно. Надо отличать «эффективных менеджеров» и лидеров. По определению лидер, сколь угодно технически подкованный и сколь угодно много участвующий в непосредственном создании продукта, не будет просто писать код и говорить «насрать мне на ваше управление проектом, не моя деревня». Лидер – это тот, кто «making things happen». Попробуйте собрать программистов и без лидерства создать продукт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про роль техлида