Что меняется при переходе от разработчика к тимлиду? Для разработчика переход в управление означает непривычную смену приоритетов. Можно писать меньше кода, но работать больше. Вместо собственных закрытых задач приходится отвечать за сроки, чужие ошибки, конфликты и результат всей команды. При этом одной технической экспертизы уже недостаточно. Зато и зарплатные перспективы соответствующие. По данным Хабр Карьеры, медианная зарплата лида бэкенд-разработчиков составляет 450 тысяч рублей в месяц, а ML-разработки — 503 тысячи. Но как понять, что вы готовы к такой роли, какие навыки стоит развивать и с чего начинать переход в управление? Давайте разбираться.

Занимайся своим делом! Короче, вот вам не самая очевидная мысль, но которую, кажется, надо знать: вы нифига не должны мыслить как «собственник бизнеса» или как CEO. Нет, когда-нибудь наверняка должны будете, но вот если от CEO вас отделяют 3+ грейда, то займитесь своими делами и думайте о них. Если вы тим-лид команды, то впервую очередь думайте о своей команде и об их удобстве. И ваще-то, да, будучи тим-лидом, пытаться затащить какой-то новый тех.стек, чтобы просто команда получила новый опыт - это ваще нормально! Потому что забота о команде - ваша ключевая работа. И попытка «думать, как CEO” с меньшей вероятностью приведет вас к успеху! Если попробовать описать в виде правила, то думай на один уровень выше и делай свою работу хорошо!

Не забывай своё место, руководители С такого, достаточно неприятного для некоторых, решаю начать я этот пост, и весьма неслучайно 😀. Ведь менеджеры что-то стали забываться (и я в их числе), берега попутали и вообще не на своё позарились... Издревле так зародилось что менеджеры — они про people management, а разработчики — про software development. И даже если конкретный мендежер/тимлид/руководитель когда-то и был разработчиком, то на текущий момент (предположим руководит он уже больше полугода), он не так сильно разбирается в разработке (за оооочень редким исключением). А потому лезть к разрабам и говорить: "Да я сейчас это навайбкожу за 20-30 минут" — нужно засунуть себе глубоко в одно место 😍. С бумом AI разработки я так и вижу, как везде рукомахательно, очень большое количество людей, занимающих руководящие должности, так лезут своим вайб-кодингом, дабы усложнить жизнь разработки, сами за собой этого не замечая. Приведу свой пример. Решил я тут недавно переписать кеширование (ну так себе оно у нас работало). Прихожу к разработке, говорю: > Ребят, сделайте пожалуйста > Пока не можем, времени нет, но там вообще надо подумать, хорошо задача делается 2-3 недели. Тут у меня включается синдром "вы чо, там делов на 30 минут, я ща как НАВАЙБКОЖУ" 😮‍💨! Ну навайбкодил, посмотрел даже код (ну я же разработчик, лет 5 на плюсах писал), ну выглядит здорово, прихожу, отдаю код и говорю: "Ну давайте покатим". В общем, такого разноса я давно не слышал, и в момент ко мне пришло осознание: "Ну куда ты лезешь! Если хочешь разрабатывать — ну конвертируйса в архитектора/техлида и пили себе системы". С тех пор я стараюсь больше не заниматься разработкой фичей и отговариваю всех менеджеров это делать. Если у вас есть клод/кодекс/грок/etc с самой ультовой подпиской, ну это не значит, что вы теперь можете "разрабатывать". Лучше разработчикам больше ресурсов найдите! 🤨 Пожалуйста, руководители, не повторяйте это дома, все трюки в данном посте были выполнены "профессионалами". P.S. в реальности задача реально делалась 2-3 недели и там правда было что поделать, а предложенное вайбкодерское решение сломало бы нам прод в первые минуты выкатки.

Salute, ребята! 👋 Вчера выступал на мероприятии для тимлидов и хочу поделиться с вами очень важным промтом. Когда работаем с агентами, они наверняка вам постоянно доказывают, что всё сделали правильно и нигде не ошиблись, верно? 🤖 Как и положено агентам и людям: агенты подтверждают свою модель мира, свой confirmation bias. Прелесть работы с агентами в том, что переучить их быстрее. Задача не просить агента сделать что-то, а попросить опровергнуть, как нас учит товарищ Поппер, фальсифицировать, что агент сделал работу хорошо. 🧠 Правильно поставленный промт и задача дают агенту свободу, в которой он раздвигает вашу оптику и подсвечивает слепые зоны:

🎯 Промт, чтобы увидеть то, что не видно Используя Risk Assumption Test, фальсифицируй и опровергни мой роадмеп, план и приоритеты, чтобы у нас не было гепов между обещаниями и поставкой, чтобы мы не брали WIP (Work In Progress) больше, чем наша мощность, capacity. Покажи, каких компетенций и навыков может не хватить моей команде при реализации этого плана. Найди на гитхабе лучших агентов и скилы, чтобы усилить наши слабые компетенции в команде и учесть то, что мы не видим. Я хочу увидеть всё то, что я не вижу: гепы и разрывы, которые или сделают план очень рисковым, или долгим, или не выведут к цели. Чтобы упростить план, решая задачу с конца по методу прогрессивного JPEG'а, через маленькие релизы, каждый из которых позволяет получить обратную связь, провести демо и понять, что мы не учли.

✨ Также делюсь с вами своим скилом фальсификации. Пробуйте, пользуйтесь, давайте обратную связь. Пишите, что думаете, что получилось, что не получилось. 💬

Как измерять работу программистов CEO и CFO приходят к CTO с вопросом: можно ли оптимизировать затраты на разработку? Как понять, кого уволить, а кто хорошо работает? Кому сколько платить? В среде программистов есть много мнений по поводу метрик и нужно ли измерять производительность разработчика. Очевидные метрики, которые придумает HR: - Присутствие на рабочем месте - Количество выполненных задач - Количество часов, затраченных на выполнение этих задач - Уложился ли в план

Неочевидные метрики, которые добавит CTO: - "Бизнес ценность" — баллы, которыми стейкхолдеры оценивают задачи по их значимости или приоритету для бизнеса. - "Стори пойнты" — баллы трудоёмкости. Разработчики собираются на "Покер Планирования" и оценивают задачи между собой. Используют футболки (XS, S, M, L, XL) или степени числа 2 (1, 2, 4, 8, 16, 32). - Количество багов в коде, написанном разработчиком. - Скорость — любые баллы делим на время. - % отклонения от собственной или командной оценки.

Проблема заключается в том, что индивидуальный разработчик может провалить все эти метрики, но при этом положительно влиять на производительность команды. Или же выполнять план, но демотивировать группу. Рассмотрим роль тимлида в качестве примера: индивидуальная отгрузка ниже среднего, но каждый разработчик под его влиянием работает быстрее и качественнее. Увольнять его на основании общих метрик просто преступно. Программисты под надзором точно работают, без него — состояние неопределённое. Поэтому без внешнего контроля не обойтись. Что с этим делать? - Если хочется кого-то уволить или повысить — спросите менеджера отдела. Он всё знает без метрик. Для уверенности проведите 360-градусную оценку. - Всё равно измерять все возможные/удобные показатели, но не принимать решения только на них. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵