Comments 76
Если команда более-менее ровная по уровню квалификации и квалификация достаточно высокая, то ваш Серега поступал правильно. Он доверял разработчикам и защищал их от внешних воздействий. Результат очевидный. Андрей, судя по всему, перфекционист без меры. С командой из слабых разработчиков это в общем-то и неплохо. Без дубины тут порой не обойтись. Но с сильными разработчиками это метод работает плохо. Они, как говорится, и сами с усами. Да, можно и нужно поправить, обсудить, убедить в конце-концов, но ломать через коленку и принуждать делать исключительно так, а не иначе - рано или поздно приводит к выгоранию, раздражению и уходу
Плот твист: заметку написал Серёга
Плот-твист: заметку написал Андрей, а Серёга - его раздвоение личности, возникшее из-за дикого истощения. И первое правило клуба: рост PR - это показатель эффективности, а вовсе не признак снижения качества первоначальной реализации задач.
Если бы статью писал Серёга, он бы делегировал написание мне )
в голове запустилась заставка к Мистеру Роботу
Еще было бы интересно увидеть метрики количества багов пролезших при старом и новом лидах, и количество переделок / рефакторингов / фиксов в кода, написанного опять же при старом и новом лидах. Еще один неучтенный фактор - новому лиду вы достались в состоянии "мы такие жертвы лида" - но подтянутые в профессиональном плане.
Есть такое замечательное высказывание - "Ребёнок – гость в твоём доме. Накорми, выучи и отпусти". Менее опытный коллега, которого ты взялся обучать, такой же гость в твоём доме. Нужно вовремя его "отпустить". Иначе вреда от твоего менторства будет больше, чем пользы. Гиперопека так же вредна, как и полное невнимание.
И есть ещё одно замечательное высказывание - "На ошибках учатся". Дай возможность своему ученику ошибаться. Иначе он ничему не научится.
По моим данным — команда без кодящего тимлида выдаёт на 41% больше
Больше не значит лучше
Он сел и за полтора часа переписал 70% моего кода. Объективно стало лучше. И абсолютно чужим
Зато вы научились новому, верно? Ведь научились, да? Теперь вы тоже сможете делать такого класса задачи не за три дня, а за один (ну, для начала) - то есть ваша эффективность выросла в три раза.
Эффективность, то, может, и выросла. Только мотивация упала. А она важнее.
Нужно каждый день тянуть лямку, можно и плохо, и медленно, и неэффективно. А не пару раз в год - зато супер эффективно!
Только мотивация упала.
Если у вас упала мотивация от того, что вам на практике принесли новое знание, то наверное вы не в той профессии. Тем более, насколько понимаю, первый тимлид не оскорблял, не обзывал дураком и вообще всячески берег самоощущение автора
Именно. Работать без мотивации это как ехать идеально правильно, но с полупустым баком.
Судя по описанию автора, команда там была из необучаемых "инженеров". Т.е. им показывают как надо/правильно/лучше. Объясняют принципы, методики, бестпрактисы, приводят ссылки на материалы и исследования, буквально вкладывают разжеванный опыт индустрии в мозг ... но у них не откладывается ни-че-го. Годами. Ну ок.
Я тоже не пишу. И не собираюсь. В редких случаях, когда вообще нет ресурса, помогаю в проектировании бд, в аналитике, написание контрактов. Могу подсказать по архитектуре. Но все - именно как исключение из обычного рабочего процесса. Есть другие активности, которые не позволяют серьезно и вдумчиво погружаться в код.
Мало что погружаться, так ещё и нет предсказуемости в сроках
"Тимлид должен кодить" - это не про то, что он должен всё ревьювить круче всех, обучать и быть параллельно техлидом, а про то, что он должен иметь адекватное представление о рабочих процессах, проблемах и подходах к их решению. Если не кодить, то года за 3 можно сильно оторваться от реальности. Просто вспомните, как все писали код 3 года назад (без LLM), как пишут сейчас, и как это повлияло на рабочие процессы - и представьте, что тимлид всё это пропустил, потому что вместо того, чтобы лично пощупать LLM он ходил на созвоны и отбивал фичереквесты…
Жёсткие ревью PR с десятками замечаний и переделкой по 4 раза могут быть крайне полезны для развития и обучения команды, и давать кратный рост производительности команды. А могут душить инициативу команды и вести к её выгоранию и увольнению. Это вопрос софт-скиллов того, кто такие ревью делает - он должен учитывать много факторов: есть ли бизнес-возможность отложить мерж этого PR ради обучения, есть ли время у самого ревьювера заниматься обучением во время этого ревью, готов ли автор PR обучаться прямо в рамках работы над этим PR… ну и сдерживать собственную вкусовщину, потому что требовать чтобы другие писали ровно как ты - бессмысленно и вредно.
Доверие команде "не глядя" может идеально работать в сильной команде и полностью провалиться в слабой (равно как и в команде увлёкшейся вайб-кодингом и пользующейся отсутствием жёстких ревью чтобы быстро мержить мусор выдаваемый LLM).
Иными словами, как лучше - жёсткие ревью или доверие команде не глядя в код - сильно зависит от конкретной команды. Но, в любом случае, тимлид должен кодить. ;-)
А я понимаю Андрея и его цели. Думаю, что он хотел понятную и управляемую систему без накопленного технического долга. По крайней мере, вот эта фраза об этом говорит:
Объективно стало лучше
Да, он тормозил разработку, но у этого была причина - недопущение экспоненциального роста сложности системы. Да и 31% отклонённых PR я бы не назвал гейткипом.
Вы можете и не заметить дальнейшего ухудшения процессов, ориентируясь на PR. PR, как и строки кода, ни о чём не говорят. Сказать может лишь сложность выполнения новой неожиданной задачи. Только метрику такую ещё не придумали, чтобы измерять эффективность выполнения новых неожиданных задач. Потому что они новые и неожиданные.
Всё верно, только одновременно с этим ещё крайне важно не убивать мотивацию команды. Иначе можно прийти к понятной и управляемой системе с единственным разработчиком в команде, что само по себе сильно замедлит разработку.
Тут все сложнее. Я - такой Андрей (только в собственном бизнесе и меня не уволить).
Команда и правда демотивирована. Но я экспериментировал и на несколько месяцев отпускал поводья. Команда встаёт колом просто. Какое-то время по инерции двигаются, потом замирают.
А когда сам - оно растет и развивается. А так, как технический долг не копится, даже спустя несколько лет мне не сложно одному все писать за всех.
Команда сегодня почти уже не нужна. Всегда код пишут 1-2 самых сильных, а остальные - обуза.
Это порождает другую проблему, bus factor, но пусканием под автобус Андрея она не решается.
А как решается - сам не знаю...
Но я экспериментировал и на несколько месяцев отпускал поводья. Команда встаёт колом просто.
Тут одно из двух: либо команда в принципе не способна самостоятельно работать, либо им это отбил текущий стиль управления. Первое встречается редко, это должно было либо "повезти" при найме, либо команда прошла многолетний "отрицательный отбор", когда способные на самостоятельную работу просто не выдерживали и увольнялись, а оставались те, кому норм. В первом случае придётся менять всю команду, во втором помимо самоустранения необходимо нанять нового сильного тимлида практикующего другой стиль управления - если, конечно, нужно чтобы команда начала работать самостоятельно.
Команда сегодня почти уже не нужна. Всегда код пишут 1-2 самых сильных, а остальные - обуза.
Пока продукт небольшой - так было всегда. А вот когда продукт начинает активно развиваться, то 1-2 сильных разработчиков резко перестаёт хватать. Да, сегодня, если эти разработчики успешно освоят LLM, то они смогут выдавать больше результата (того же качества) в месяц. Но больше - всё-таки не в разы, по разным оценкам это 20%+. Потому что всё-равно нужно тщательно продумывать архитектуру, постановку задач и внимательно ревьювить код выдаваемый LLM. Объективно можно рассчитывать максимум на то, что команда из 2-х сильных разработчиков будет выдавать результат как будто их там таких 3, а не 2.
Помимо роста продукта нужда в команде обычно возникала ещё и потому, что во-первых не всем удавалось нанять тех самых 1-2 реально сильных, и во-вторых для защиты от bus factor. И вот это пока никуда не делось. Без контроля сильного разработчика LLM будет выдавать мусор очень среднего уровня, и bus factor тоже никуда не делся.
Если, как в Вашем случае, сильный разработчик одновременно владелец компании, и продукт достаточно небольшой чтобы он лично успевал его развивать, то да, команда особо не нужна (особенно если перекинуть всю рутину на LLM). Только вот есть проблема: шансы что бизнес будет развиваться при таком подходе стремятся к нулю. Потому что владелец либо будет тратит свои силы на бизнес, либо на код. Если он будет заниматься бизнесом, то код придётся писать кому-то другому, плюс резко увеличивается шанс, что с развитием бизнеса понадобится больше (сильных) разработчиков чтобы успевать развивать продукт. А если он будет заниматься кодом, то вполне реально поддерживать текущий уровень бизнеса, но не более того.
Тут одно из двух: либо команда в принципе не способна самостоятельно работать, либо им это отбил текущий стиль управления.
Что-то как-то вывод похож на ложную дихотомию. Неужели не допускаете промежуточных вариантов?
Я допускаю. Допускаю, что у наёмных сотрудников есть семья, ипотека, свои проблемы и радости. И работа у них далеко не в первых строках приоритетов. Они могут быть замечательными и честными людьми. Но ответьте на вопрос: а у них будет выше зарплата, если они начнут работать больше?
А если будут работать меньше, будет ли у них снижаться уровень стресса? А что им даёт устойчивость и поддержание низкой сложности проекта? Они будут меньше получать, если проект станет сложнее?
Собственники замотивированы в решениях, влияющих на долгосрок. Есть отдельная категория наёмных сотрудников, которые действительно думают о долгосрочных последствиях и очень ответственно относятся к работе. Но это скорее исключение.
31% отклонённых PR - это феноменальный уровень гейткиперства. Мы же тут не про опенсорс, а про работу в коммерческой компании.
Фактически, этот Андрей прожирал ресурс компании, заставляя её оплачивать пустой труд. В коммерческой компании если 5-10% PR отклоняются - это уже аларм, надо срочно менять подходы к разработке, передаче знаний, найму или приёмке. 31% - это "вон из профессии!", если мы говорим именно о тимлиде, коим Андрей и был
Я зашёл в ваш профиль, и увидел, что вы работаете тимлидом. Значит вы хорошо знаете на собственном опыте, где находится засада этой должности.
Для остальных: у тимлида нет никаких рычагов давления на "подчинённых". Да у него и нет фактически подчинённых. У него есть только ответственность за проект. Есть то же самое начальство, что и у всей команды. Есть спрос с него. Есть ответственность за проект, а полномочий нет. Только красивая лычка и возможность не принимать PR. Больше ничего. То есть проект пишет вся команда, а спрашивают с него.
Андрей прожирал ресурс компании, заставляя её оплачивать пустой труд
Ну всмысле прожирал ресурс? Он сам писал код, при этом находил время для ревью кода, объяснял что не так. Объяснял почему. Показывал как надо.
Я не буду исключать, что он мог где-то ошибаться или слишком ревностно относиться к кодовой базе. Но "прожирал ресурс" - это ну просто слишком.
Спасибо за подсказку насчёт профиля. Поменял, из тимлидов уже перешёл в РП.
Насчёт рычагов. Это сильно зависит от компании. В каких-то так, как вы описываете. Я работал тимлидом с правом набирать и увольнять людей. Зарплатой (бюджетом департамента) управлял не я, но в остальном - полноценная руководящая должность. И своими правами я пользовался, когда надо было.
Ну всмысле прожирал ресурс?
Тут конечно надо поговорить о том, что такое "отклонял PR". В моём понимании - это когда код настолько негодный, что комментарии и исправления после них не помогут, надо целиком переписать.
Да, я настаиваю на "прожирал". Он из руководящей позиции, коей является тимлид, так построил работу в команде (точнее, не смог построить), что люди треть времени работают на мусорку. Это как если бы не нанимать треть людей и сократить тем самым треть (ну, с поправкой на уровень зарплаты четверть) бюджет команды. Или наоборот, с этой командой и с этим бюджетом выполнять на треть больше работы. Такая работы руководителя недопустима в коммерческой компании.
В том то и дело, что Андрей не работал тимлидом. Он работал самым лучшим программистом
Во-первых тимлид - это не руководящая должность. По определению. Если у вас были полномочия набирать и увольнять людей, значит вы были начальником отдела. Само определение "team lead" говорит о том, что он находится внутри команды.
Во вторых существует две крайности: не давать никому править свой код и придерживаться позиции "ну они же потратили время".
Ну потратили, дальше что? Да, компания заплатила за их время. И что теперь, тимлид обязан принять их PR? Просто за то, что были сожжены IRL токены?
Тимлид должен принимать решение исходя из того, насколько PR соответствует решению задачи в рамках архитектуры проекта. И всё. Ни потраченное время, ни личные предпочтения тут не должны играть роли. Это, конечно, утопия, но надо к этому стремиться.
Примерно лет 10 назад я работал в команде с одной девочкой. Очень продуктивная была. Так за примерно полгода работы она наворотила столько, что потом два года пришлось переписывать. Не потому, что я такой принципиальный. Просто по мере доработки различных частей системы я сталкивался с тем, что придётся сначала её код поправить, чтобы новая часть заработала. Я матерился, потому что у меня не было никакого желания переписывать этот код, но ничего поделать не мог.
Вот это - прожирание денег компании. Девочка сделала абы как, чтобы казаться полезной, а по итогу сожгла своё время и в два раза больше моего.
И я пожалел, что не был тем "Андреем", который вовремя заворачивает реквест и отправляет на доработку. Это сэкономило бы кучу времени и денег компании.
Называйте как хотите. Рынок ИТ в этом смысле очень подвижный, все по-разному нанимают. В одних компаниях тимлид - просто старший программист. В других - нач.отдела. В одних ещё и РП, в других чисто технарь.
По сути и PR.
И что теперь, тимлид обязан принять их PR? Просто за то, что были сожжены IRL токены?
Тимлид, он же лидер команды обязан построить работу так, чтобы люди работали эффективно. Он не наблюдатель со стороны, который просто беспристрастно оценивает качество кода. В его обязанностях - непосредственно влиять своих подчинённых, как то: нанимать нужных, увольнять ненужных, обучать недообученных, вводить правила, которые помогут создавать правильный код, а неправильный не создавать. В этом суть работы руководителя.
Если он просто как сторонний экзаменатор, то его следовало бы по-другому назвать. Например, на заводах есть ОТК. Тётя из ОТК не лидирует цех, она просто заворачивает брак.
Я могу только повторить мысль, высказанную ваше: Андрей не работал тимлидом, он работал лучшим программистом
Андрей не работал тимлидом
Как это не работал? Он проводил код-ревью, обучал, объяснял, показывал. Это всё обязанности тимлида.
Ну вот так он обучал и объяснял, что треть работы после этого в помойку
Уверены, что было бы лучше, если бы вместо помойки эта треть пошла в прод?
Объективно - мы не знаем, что предлагал Андрей и что написал автор статьи. Аналогично можно рассуждать, что найдется всегда Андрей версии PRO v2 и предложит ещё более лучшие решения.)
Таким образом давать оценку без фактического ревью нами, комментаторами - не объективно. Покажи нам кусок кода и комментарии, началась бы дискуссия в части и Андрей не прав и автор и ещё 100500 мнений))).
Отсюда вывод - выводы делать рано и бесполезно.
На каждого сеньора помидора найдется другой сеньор.:)
А у лида все таки задачи иные, не ревьюить, не кодить. Если он все может сам, зачем тогда участники в команде?
Разные команды могут быть эффективны в разных конфигурациях. Одни раскрываются, когда все синьеры и плоская структура. Другие – сильный лид + много рабочих рук. Довелось как-то поработать в диджитале, там команда человек на 30–40 разрабы с менеджерами примерно 1:1 количественно, зато QA не существовало даже как понятия. Эта роль была размазана по всем участникам.
К чему это я? В статье, мне кажется, описан кейс, когда команде поменяли лида на ПМ и команда поехала быстрее. А вся интрига в том, что шильдик на позиции поменять забыли. И изменения, следовательно, потребовали больше времени на осознание сути произошедшего.
Хороший тимлид — не обязательно лучший инженер. Иногда это тот, кто даёт инженерам спокойно работать. Банально звучит, на практике — редкость.
Это называется не тимлид а менеджер. А если он менеджер, то все-равно должен быть старший от разработки, можно называть как угодно, хоть ведущий разраб хоть техлид, иначе однажды команда просто разосрется из за природы разных мнений и опыта.
По моим данным — команда без кодящего тимлида выдаёт на 41% больше. Может, мой случай — исключение, и мне просто повезло с Серёгой. Но мне кажется, мы неправильно понимаем, что такое лидерство в разработке.
Два сеньора с противоположными точками зрения и тимлид который 3 года не кодит...
Поздравляем! Партия вами довольна! Вы получаете повышение: держите своя кошка-жена и миска риса!
Всем бы найти такого Серёгу) Рад, что есть такой мощный сотрудник😁
У нас тоже есть такой, только имя его — Claud Code :)
Как вам удалось получать отчеты от тимлида?
Ваш тимлид пишет код? Помогает это команде или мешает?
А можно пофантазировать с точки зрения программиста, который никогда не работал в команде? По советскому принципу: «Если бы я был директором!»?
Разрабатывая и внедряя учетные программы на производственных предприятиях, которые кормили меня двадцать лет, я иногда задумывался над тем, а как бы я делал их в команде?
Особенно ярко эти мысли стали возникать на фоне моей обучающей (иностранным языкам) программы «L'école», о которой я писал в своих статьях, здесь. Там я себе чуть мозги не сломал, пока не довел её до, более-менее, рабочего состояния. Теперь вот решил разобраться, а как ее можно сделать коллективно?
В итоге, пришел к мнению, что прототип программы должен разрабатывать архитектор программы. Это должен быть работающий минимальный код, в котором весь потенциальный функционал реализован в виде формальных классов – модулей. В данном случае я имею в виду оконные приложения на С++.
Все формальные классы представлены своими публичными функциями, которые ничего не возвращают (обмен данными происходит через их параметры), за исключением обработчиков сообщений. Те возвращают стандартные значения LRESULT (TRUE либо FALSE), но, как и все остальные публичные функции имеют пустые тела.
Приватные части автономных классов (на уровне файлов это *.h и *.cpp модули) находятся в компетенции членов команды.
Далее, архитектор программы фиксирует вызовы формальных публичных функций в «модуле управления» (для оконных интерфейсов это, как правило, обработчики класса типа CMainFrame либо CMainWindow). Но, поскольку, эти функции – пустые, то их использование никак не проявляется.
На примере моей обучающей программы, основными, независимыми друг от друга модулями, являются: класс для работы с чтением / записью текущего состояния приложения, класс логирования, классы для работы с графикой, текстом (отображение и редактирование), звуком и данными, классы вспомогательных окон («О программе», «Помощь», «Настройка» и прочее) и т.д. и т.п.
Для всех этих классов архитектор дает их формальную реализацию. Затем раздает копии своего проекта всем членам команды и говорит, кому, какой модуль реализовывать. Такой подход позволяет достаточно просто организовать коллективную работу без использования внешних систем контроля версий, вроде, гита.
Члены команды доводят до ума свои модули и передают их архитектору. Он замещает формальные модули – их полными версиями и тестирует общую реализацию. При необходимости вносит коррективы в работу команды.
При таком подходе члены команды могут работать удаленно и иметь минимальный конфликт интересов, о которых шла речь в статье.
Я даже не знаю, нужен ли, в таком случае, тимлид либо техлид. Наверное, да, для больших проектов. Но, для группы из нескольких программистов, думаю, без последних можно обойтись. В таком случае, архитектор «пишет» код прототипа либо ваяет его по принципу конструктора модулей.
Таким образом, используя модульное программирование либо итерационно-модульное (где предыдущие итерации, собственные для «своего» модуля каждого программиста, фактически являются просто бэкапами), можно, как мне кажется, упростить работу команды. Зато, основная нагрузка ложится на архитектора. А члены команды могут даже работать независимо друг от друга.
Однако, возможность «легко подключить модуль к проекту» (путем простой замены формальной реализации – полной) и «легко отключить модуль от проекта» (соответственно, наоборот, заменяя полную реализацию – формальной), позволяет, со временем, накаливать потенциальные модули для будущих проектов. Что дает возможность быстро создавать новые прототипы для новых проектов, аналогичного типа.
По сути, в идеале, мы получаем этакий конструктор для будущих программ.
Например, у меня есть неопубликованная программа «МедиаТекст» ( http://scholium.webservis.ru/Pics/MediaText.png ).
Вместе, эти две программы, явно, могут иметь общие модули. При этом, в последней используются потоки и опенсорсный видеоплейер, для которых можно создать свою формальную реализацию.
Вот, приведение уже только этих двух программ к общему модульному типу (к ним можно добавить и мою третью программу – загрузчик «MiniDL» для любимых видосиков, которая опубликована здесь), позволит создать хорошую базу прототипов для будущих проектов данного типа задач. После чего можно будет уже спокойно предлагать себя в роли архитектора на похожую работу :) .
Но, даже если программировать только для себя на уровне пет-проектов, то данный подход кажется перспективным, по крайней мере, я перестану забывать программную логику своих давно написанных программ и смогу спокойно модернизировать их до новых версий. Чем и собираюсь заняться, в ближайшее время.
Как-то так.
В компаниях, где я работал, тимлид всегда лидировал продукт\проект, а то, что делал описываемый Андрей - у нас делал техлид. Именно к техлиду обращались тимлид и остальные участники команды по вопросам разработки, планирования загрузки разработчиков, каким-то техническим деталям.
С чего бы тимлиду быть сильным разрабом? - не понимаю... А почему не системным\бизнес аналитиком, или тестировщиком? Эти роли не менее важны, чем собственно кодирование.
Мне кажется, тимлиду не нужно программировать, это менеджерская роль, которая очень часто выполняется Владельцем продукта.
Половина стилистика
а нечего вместо табуляции пробелы использовать
Скрипт писал ночью, продакшн-качество не обещаю. Для разовой аналитики хватило.
А разве LLM-кам имеет значение, в какое время суток по UTC генерировать код?
На Хабре любят хейтить менеджеров, которые «забыли, как кодить».
Не совсем так. Хейтят менеджеров, которые изначально не умели кодить, так как они не понимают сроков, не чувствуют боль разработчика и полностью оторваны от реальности.
К тем, кто умеет кодить, хейта как раз таки нет.
Хороший тимлид — не обязательно лучший инженер.
Лучший инженер называется техлидом или архитектором, а не тимлидом. Тимлид - это работа с людьми и бизнесом, т.е. менеджерская работа.
В некоторых компаниях часто жалеют денег на отдельного менеджера, поэтому заставляют ведущего разработчика сочетать в себе роль техлида и тимлида. Получается дёшево и сердито, но крайне не эффективно.
Если команда маленькая (до 6 человек), то в ней менеджерской работы может быть не так много, поэтому остаток времени человек может посвящать кодингу, т.е. выполнению технических задач.
P.S. Тимлид всегда должен помнить, что работу по кодингу могут выполнить другие люди в группе, а вот менеджерскую работу может выполнить только он, т.к. наделён для этого полномочиями. Так что пока тимлид занимается кодом, менеджерская работа в этот момент не делается, а это очень плохо, т.к. возникает узкое место в работе.
Два часа: как у вас локально фронт запустить? Ещё час: почему npm install ругается на peer dependency? Полчаса: поменял CSS, изменения не появляются.
Кстати, это его факап. Должна быть инструкция для новичка для входа в проект - что где лежит, как запускать локально, как запускать unit-тесты, как пушить, как собирать и разворачивать на сервере.
И раз уж он столкнулся с этой проблемой, то надо ее решить так, чтобы больше с ней не сталкиваться.
Вторую статью подряд "поднял метрики из GitLab... Написал скрипт...". Попробуйте готовые отчеты по репе:// NodeJS
npx assayo
// Python
pipx install assayo
assayo
У нас CTO был, который обожал ходить, особенно какие-то новые фичи, которые он обсуждал напрямую с заказчиком. Качество кода было такое себе, куда лучше было бы, если бы он объяснял задачу и отдавал ее команде. По итогу его теперь нет, и в большей части этого кода никто не разбирается, потому что чем тратить время на понимание хренового кода, проще это переписать с нуля, но переписать тоже сложно, потому что никто в этих решениях не участвовал, и что там из-за чего и почему именно так, никому не понятно. Так что уж лучше бы он не кодил вообще.
У нас тимлид вообще не разработчик. Хорошо живётся, формирует план работ и практически от него не отступаем, все работы сбоку отсекаются если ни что то рискованное. Это нормальная практика - разделение труда называется
Я не пишу код в 95% случаев, но я знаю как это все работает и если команде нужна помощь - они уверены в том, что могут обратиться ко мне за советом.
Некоторые уже отметили в комментариях, очень странная структура команды в вашем примере.
Тимлид и Техлид - это две большие разницы. Если на очень небольших продукте и команде эти роли ещё как-то можно совмещать, то при масштабировании они должны разделяться, иначе либо ревью либо коммуникации и развитие команды будут страдать. Либо ваш всея лид быстро закончится и пострадают оба направления.
Судя по истории:
Андрей всегда был и остался Техлидом. Техлид само собой должен писать код и быть очень близко к продукту, стеку, архитектуре и тех долгу. Автор сам упоминает, что к нему ходят за советом, значит функции Техлида он продолжил выполнять.
Серёга - адекватный Тимлид, который знает продукт настолько, чтобы адекватно общаться со всеми внешними заказчиками. Писать код для этого не требуется, гораздо важнее понимать кто и зачем просит какие фичи, кому что лишний раз стоит объяснить и напомнить и подобное. Все что может составлять техническую проблему (трудоемко, может вызвать клинч, сложно тестировать и т. д. ) - можно взять у команды или того же Техлида.
В общем кажется, что в описанной истории проблема не в практике писать код, а в адекватности разделения обязанностей.
Метрики очень косвенные, в них нет ничего про то, что компании нужно от команды.
Хотелось бы увидеть что-то связанное с доставкой ценности - насколько то что команда делает нужно компании, какого это качества и так далее.
С точки зрения people management ясно что у первого тимлида были недостатки. Люди чувствовали неудовлетворённость и, похоже, он не давал им ошибаться в тех случаях когда можно было бы и давать.
По идее это должно было быть ясно на 1:1 и ретроспективах также это должны были заметить hr при опросах удовлетворенности или каких-то ещё механизмах обратной связи которые должны быть.
С этим вообще непонятно как было. Беседовал ли старый лид с вами просто по ощущениям от работы? А новый беседует?
Про доставку ценности, тут бизнес голосует деньгами. Та же история с демо для инвесторов или отбитая атака безопасников сэкономили компании кучу ресурсов, чего при Андрее могло и не случиться из-за перфекционизма (хотя кто его знает).
Насчёт почему не заметили раньше имхо это ловушка авторитета. Ну банально сложнее жаловаться на технического гуру, который «тратит время на твоё обучение», проще поверить, что это ты сам не тянешь.
Андрей на встречах обсуждал только код и сроки, а Серёга на 1:1 спрашивает про «как тебе работается» и «что мешает».
У меня как-то не сходится - в компании где есть архитектор, новый тимлид говорит что архитектурные решения на разработчиках. Дак может первый тимлид как настоящий инженер защищал чистоту архитектуры, а второй работает на бизнес и kpi? И кайфовую атмосферу в команде) Что косвенно подтверждает ваш график.
Может ли так получиться что с новым тимлидом ваш продукт через пару лет будет с красивым kpi, но по сути представлять огромную кучу грязи?)
Ждём сиквелл через год когда посчитаем среднее время выполнения задач и увидим, что бывают более важные метрики помимо душевного равновесия во время ревью. Система всегда усложняется, бизнес требования каждый раз пытаются проверить текущую кодовую базу на прочность. В какой то момент станет понятно, что кодить просто ужасно больно, а уже будет поздно и на рефакторинг время не выделят. Но в памяти останется крутой Серёга, а не душный Андрей.
А какой ожидаемый срок жизни кода в современном мире? Только не говорите что проектируете ядрену электростанцию или полет на Марс. В 95% это очередная гениальная маркетинговая фича чтобы выкинуть через пол года когда не взлетело. Перфекционизм здесь вреден
Код к одному из серийных изделий был написан в 2017м году. Доработки - до 2020го были выполнены.
Сейчас - производство и косметические правки для стыков с другими системами.
Но перфекционизм даже там был вреден, потому что устройство нужно было выпустить в срок.
Другой программный комплекс писался в середине 00х. Он до сих пор в активной, хоть и не масштабной, разработке.
В моём опыте, срок жизни кода примерно от 5+ до 30 лет... Модули даже сотрудников "переживают" (в одном проекте, наверно, только один остался через 30 лет, остальные ушли...) Но перфекционизм действительно вреден, т.к. код модуля разрабытывается обычно год-два, а потом не слишком активно правится. Если код не очень хорошо написан, но надёжно работает, его улучшение можно отложить до момента перед пакетом крупных правок - возможно, оно не понадобится, или к тому времени будут новые вводные.
Команда или нытиков и/или слабых специалистов. Если автор пишет так, что за него надо большую часть переписывать, то даже не знаю, что тут сказать.
Здесь ещё нужно установить именно необходимость переписывания. "Объективно стало лучше" не указывает на то, что как было до переписывания было неприемлемо.
ТимЛид всё же в первую очередь менеджер младшего звена, он должен управлять тем, что ему доверили. Есть знаменитое высказывание: "Делай, что можешь, с тем, что имеешь, там, где ты есть".
Программисты - производственноее оборудование, этим оборудованием надо пользоваться правильно, в том числе беречь и обслуживать, а не тащить своё из дома и делать им всё самому.
Учитывая что скрипт явно нагенерен нейронкой, а автор пишет что "писал скрипт ночью" - сразу возникло сомнение по поводу правдивости всего текста. Хотя может просто неудачный оборот)
У нас есть свой "Андрей", который в конце концов просто устал делать строгие ревью. Давление было и снизу ("придирается по мелочам") и сверху ("тормозится прогресс разработки"). Я теперь скучаю по тем временам, когда он смотрел мои PR - да, много комментов, да, что-то переписывал. Но и многое впитал, - коменты-то все по делу.
И с ним - я рос, как инженер. То что прогресс выкатывания продукта медленнее, чем могло бы быть, - меня волновало куда меньше.
Разным по уровню квалификации командам нужен разный уровень менторства. Слабым командам нужен Андрей, сильным - Серега. За год-два Андрей может поднатаскать слабую команду до уровня, где будет справляться и Серега. Что, как я понимаю, и произошло. Если Серегу окружить джунами, будет эпик фейл. Ровно как если Андрея окружить синьорами-лидами, команда просто разбежится.
Помню, когда перешёл из сеньора в тимлиды, работы оказалось примерно в 10 раз больше. Если не по объёму (в конце концов в сутках 24 часа), то по числу отвлечений, переключений контекста и т.д. и т.п.
Поэтому да, бесконечно удивляют две вещи: как программисты не понимают, чем реально занимаются менеджеры и как компании экономят на менеджерах, сильно проигрывая в итоге в труде программистов.
У вас был блокер в полтора дня на одном разрабе и тьма треков на переписывание. Понятно что если это убрать то станет проще. Неясно что за защита от посторонних. Может там есть реальные принты что помогут
Роль тимлида включает в себя и организацию разработки внутри команды. Везде по-разному - где-то тимлид сам много кодит, где-то распределяет задачи, где-то общается с заказчиком. Но, чтобы команда предсказуемо выдавала результат, важен баланс - нельзя погружаться в код, забывая о команде, нельзя блокировать команду, и также нельзя полностью забывать, как пишется код (иначе произойдёт отрыв от реальности). Что должен делать тимлид - вопрос расстановки приоритетов, а не отказа от какой-то работы.
Мой тимлид не пишет код,
Он ленивый словно кот.
Он задачи не решает,
Важно, медленно шагает.
Пьёт какау поутру,
Говорит, что не помру
Если буду код писать
И забуду про кровать.
Очень любит обещать,
Обещая - забывать.
Как-то сьел моё печенье,
Объяснил - из уваженья.
Сам хочу таким же стать,
Чтоб была и власть и стать.
Чтобы видеть перспективы
Обходя других могилы.
Размечтался поутру,
Ещё релиз и отдохну...
Мой тимлид не пишет код 3 года. Почему он — лучший тимлид, с которым я работал