Комментарии 17
Вождь разрабчьей стаи
Это специально?
Я бы ещё добавил, что хороший "вождь-техлид" должен уметь быть посредником между командой "волчар" и бизнесом. С одной стороны отстаивать интересы разработчиков перед бизнесом (время на техдолг, исследование новых подходов, качество, которое сэкономит время на длинной дистанции). С другой – правильно расставлять приоритеты в разработке. Бизнесу не нужен красивый, качественный код сам по себе. Ему нужно регулярное, планируемое решение проблем пользователей, которые ему приносят прибыль.
В идеальном мире - пожалуй, соглашусь. Однако, это уже со всего человечества единицы соискателей на такую позицию будет - способных совместить поддержку технического единства разрабов-альфачей и находить при этом время чтобы держать контакт с бизнесом.
Моё мнение - чтобы техлид работал эффективно, он, всё-таки, должен быть в основном сосредоточен на построении технической работы команды, на формировании и поддержке магистрального направления разработки.
В статье поэтому упоминаются именно топовые фирмы - у них вероятнее могут найтись ресурсы на введение подобной, с позиции краткосрочного планирования, "непродуктивной" должности.
Кроме шуток, кажется, такая команда это рай для разработки. Дай любую задачу - сделают топовое, уникальное решение и спросят что ещё доработать.
Топовое и особенно уникальное решение — признак неопытного разработчика. Так делают крепкие джуны только с университетской скамьи. Опытный волчара сделает неуникальное тупое решение которое а) работает, б) легко сопровождать и в) не жалко выкинуть. И не заняло слишком много времени.
Про то что решение должно быть простым - полностью согласен. С позиции опыта так же считаю что архитектурные замки ради архитектурных замков - чистое зло.
Однако, выскажу возражение по одному моменту. Почему уникальность и топовость решения должны идти в конфликте с его работоспособностью и лёгкостью сопровождения? По опыту часто как раз максимально простое решение может оказаться топовым и уникальным - потому что программисты без опыта накрутили бы трёхэтажных абстракций. У опытного человека рука набита на "гениальную простоту".
В дополнение также можно заметить - если говорить о так богатых в средствах выражения мысли языках как С++, часто красивые решения завязаны на знание языковых фич. Чуть менее известные языковые конструкции помогают сделать API (и его реализацию) более компактной и, при этом, дескриптивной - за счёт использования каких-то языковых конструкций. Углубленное знание языка приходит с опытом.
Не могу на себя примерить ни альфу, ни волчару, ни стремление к уникальным топовым решениям. Слышать в команде только себя из-за того, что у меня есть устойчивая система своих убеждений считаю деструктивным моветоном. Очевидно, ярлык сильного разработчика не для меня, не смотря на более 10 лет опыта.
А нормально, если лид совмещает функции разраба? Например, у меня была такая ситуация, когда лид совмещал бекэнд. Получается, у него не было не то что 80%, а даже 30% на обучение и менторство
На мой идеалистический взгляд (описанный в статье) - если техлиду приходится тащить ещё и разработку, есть вероятность что он не будет успевать заниматься непосредственно "техлидовой" работой. Потому что в сильной команде на организацию, поддержание технического порядка и единства будет уходить много сил и времени.
Например, в том идеальном варианте который описан в статье, техлид должен проводить сопровождение изменений - от проектирования до финального код-ревью. Уметь анализировать результат не на уровне "может назови переменную по-другому", а на уровне логики и дизайна - и по результату дать точные советы где чего доработать. Это само по себе будет отнимать прилично времени.
Адекватным тру разрабам поводыри не нужны. Статья скорее про то, как по фен-шую организовать галеру с грейдами.
Если брать со стороны - вовлекайте команду в выбор
Вот это не советую, тем более отбирать вопросы самым скилловым из этой команды. У него с большой вероятностью мотивация показать, что техлидом должно быть ему по скиллам.
Вовлеките соседние команды например.
плохая статья, смешали в одну кучу все обязанности: и техлида, и тимлида, и наставника. То, о чем Вы пишите в самом начале (разные подходы к написанию кода) обычно решается написанием регламента разработок, которого заставляют всех придерживаться.
Пару раз встречал на проектах техлидов, но их обязанности в основном заключались, чтобы выбрать корректный стек, на котором все работают.
Вникать в каждую проблему, одновременно всех убеждать и при этом как-то, чтобы 80 % времени оставалось на обучение - с трудом укладывается в 40-часовую рабочую неделю) Ну и это скорее относится к обязанностям тимлида
Вождь разрабчьей стаи