📕📖📚Прочитал на этих выходных книгу: "Lead Developer Career Guide" от Shelley Benhoff от 2025 года. Это книга-гайд по тому, как нужно строить карьеру ведущего разработчика, или в российской терминологии тимлида. Причем не такого тимлид-менеджер, а гибрида управления и техскиллов.

И появилось стойкое ощущение, что я это уже где-то читал. Так как книга не говорит ничего нового, чего бы не было в  книгах :

• Мама я тимлид

• Как пасти котов. Наставление для программистов, руководящих другими программистами

• Карьера Software Engineering Manager

И все это приводит меня к мысли, что если разные авторы из разных стран на разных языках пишут примерно одни и те же инструкции, то позиция тимлида достаточно четко описывается и регламентируется. И уже можно говорить о некотором стандарте отрасли для тимлидов.

Поэтому, если вы раздумываете о позиции тимлида, то прочитай хотя бы одну книгу из списка выше и подумайте, нужно оно вам или нет.

p.s. Что касается самой книги, то характерно для США идет большой фокус на эмоциях и комфортной атмосфере в команде. Достаточно интересная статистика и инфографика. Плюс некоторые рекомендации, в каких отраслях есть запрос на тимлидов и юнит-лидов.

🐺🐺🐺Они бегут так, словно их подгоняет чья-то злая воля.

Примерно месяц смотрел, как трекать время на своих задачах, чтобы не попадать в прокрастинацию (ситуация, когда времени прошло много, а работы сделано преступно мало).

Какие варианты рассмотрел:

Pomodoro Tracker — идея самая очевидная, но отказался от него, потому что приходилось часто перетыкивать софт, и это меня отвлекало. Хотя журнал логов по трекеру был удобен.

Песочные часы Однако комментарии на Ozon говорили, что часы часто забиваются, и если тебе нужно переключиться на другую задачу, то их нельзя обнулить, пока они не отработают до конца. Отказался.

В итоге остановился на гравитационном таймере: https://www.ozon.ru/product/rxsm-taymer-elektronnye-1-sht-1249814540/

Кубик с шестью гранями: четыре грани отсчитывают время по 5, 10, 30 и 60 минут, пятая грань останавливает таймер, шестая — сбрасывает его в ноль. Чтобы переключить время, достаточно повернуть кубик другой стороной. Понравился.

Из инсайтов начал понимать, что некоторые задачи, которые раньше казалось, что сейчас раз-два и всё будет сделано, требуют значительно больше времени. Могу рекомендовать этот таймер.

Краткий обзор: https://vr-2.ozone.ru/vod/video-56/01JCGT9FNBPT7RSEHP8DTKGZC5/asset_1_h264.mp4

Совсем недавно была новость, что Amazon увольняет 14 тысяч менеджеров. И эта новость подавалась в апокалиптических тонах — будто конец уже близко, всё загибается, и пора бежать спасаться. Однако не стоит верить провокационным заголовкам; важно уметь правильно интерпретировать ситуацию.

Что мы знаем про Amazon:

• В Amazon работает около 1,5 миллионов сотрудников.

• Компания известна своими регулярными увольнениями неэффективных работников.

Теперь давайте посчитаем. Если каждый менеджер управляет от 5 до 10 человек, в среднем возьмём 7. Сколько же менеджеров потребуется для штата в 1,5 миллиона?

Для этого представьте себе дерево, где на нижнем уровне будет 1,5 миллиона «листьев», а все остальные уровни — менеджеры. Возводим число 7 в разные степени и смотрим результаты:

7⁰ = 1
7¹ = 7
7² = 49
7³ = 343
7⁴ = 2401
7⁵ = 16807
7⁶ = 117649
7⁷ = 823543
7⁸ = 5764801

Уже на восьмом уровне количество «листьев» превышает общее число сотрудников Amazon. Поэтому вернёмся на седьмой уровень — там примерно 800 тысяч «листьев».

Предположим, что у некоторых менеджеров подчинённых больше семи, такое бывает в функциональных подразделениях.

Теперь сложим количество менеджеров с нулевого уровня до шестого и подсчитаем итог:1+7+49+343+2401+16 807+117649 =137 257;

Таким образом, чтобы управлять всей компанией, понадобится около 137 тысяч менеджеров.

Итак, увольнение 14 тысяч менеджеров — это примерно 10% от общего числа управленцев, тех самых неэффективных сотрудников, которых Amazon ежегодно сокращает.

Таким образом, новость перестаёт казаться сенсационной и становится обычной практикой. Так что всегда сохраняйте ясность ума и не поддавайтесь панике.

В недавней книге про построение успешной карьеры в IT в качестве менеджера, отдельным пунктом идет пункт про ИИ, в котором автор призывает тимлида разрабатывать политику использования ИИ в своей команда и согласовать её с политикой использования ИИ в компании. В вольном пересказе это звучит примерно так:

"Как ведущий разработчик, одна из ваших ключевых обязанностей — оценивать и интегрировать новые технологии, включая инструменты искусственного интеллекта (ИИ), в процессы разработки. Рассматривая возможность принятия или отказа от внедрения инструментов ИИ, важно сохранять сбалансированный подход, который ставит во главу угла потребности команды, конкретные преимущества технологий и потенциальные риски.

Перед предложением использования любого инструмента ИИ начните с оценки того, насколько он соответствует текущим и будущим проектам вашей команды. Оцените, сможет ли инструмент ИИ повысить производительность и оптимизировать рабочие процессы путем автоматизации рутинных задач, освобождая разработчиков для решения более сложных проблем. Важно также оценить качество выходного продукта, создаваемого инструментом ИИ, частоту возникновения ошибок и степень интеграции с существующими инструментами и рабочими процессами. Инструменты ИИ должны легко встраиваться без значительных изменений текущих процессов.

Внедрение инструментов ИИ связано с рисками, которые требуют тщательного управления. Команды могут стать чрезмерно зависимыми от ИИ, что потенциально снижает способность решать проблемы и ограничивает инновации. Важную роль играют безопасность и конфиденциальность, особенно в отношении обработки данных инструментами ИИ и соблюдения соответствующих норм защиты данных. Помимо начальных затрат, учитывайте долгосрочные расходы на обучение, интеграцию и обслуживание"

И дальше проводится обзор того, какие инструменты есть, для чего их можно использовать, какие есть бест-практисы в области ИИ и так далее.

Собственно есть парочка вопросов:

1. Используете ли вы лично какие-то ИИ-инструменты для работы?

2. Требует ли компания от вас, чтобы вы согласовывали использование ИИ?

3. Считаете ли важным регламентировать использование ИИ-инструментов?

4. Есть ли у вас в компании формальные правила использования ИИ в виде регламента?

Дополнительное образование для менеджера в IT

Недавно задался вопросом, какое сейчас есть дополнительное образование для линейных и средних менеджеров в IT. И начал проводить ресерч по доступному образованию.

Сейчас на рынке есть три дополнительных типа образования для менеджера:

Различные программы MBA для топ-менеджеров и руководителей. Все это стоит от 1,1 миллиона рублей и выше, занимает примерно год и проводится ведущими вузами столицы, включая Сколково. https://www.skolkovo.ru/programmes/skolkovo-mba

Изучив программы, пришло понимание, что это для ребят, кто метит в CEO и CTO позиции, для тимлидов и юнит-лидов выглядит избыточно.

Программы профессиональной переподготовки от ведущих вузов столицы. Тут в целом программа ложится на рабочие обязанности классического "проект-менеджера" и выдается официальный диплом вуза о переподготовке.

Однако, изучив программы, пришло понимание, что во многих местах все делается через образовательный портал в заочном формате с тестами для галочки. И не выглядит, что там ты реально сможешь получить что-то большее, чем прочитав книгу "Настольная книга проект-менеджера". Исключением является программа от БАУМКИ, где все выглядит серьезно, но и цена — 130 тысяч рублей. https://do.bmstu.ru/napravleniya-obucheniya/upravlenie-proektami/upravlenie-it-proektami-v-it/

Курсы менеджеров в IT от частных контор. Это Стратоплан, Отус, Скиллбокс, Нетология, Яндекс Практикум и другие курсы. Естественно, это все — неофициальные сертификаты, которые котируются исключительно субъективно. Где-то отзывы хорошие от людей, прошедших курсы, а где-то говорят, что курсы были бесполезными, с информацией не большей, чем в рядовой книге. https://stratoplan-school.com/team/

Что по итогу:

На рынке очень много различных программ, каждая из которых выглядит красиво, но реальная полезность остается под вопросом. Скорее всего, каждому руководителю в IT придется пройти тот или иной MBA, чтобы получить экспертизу и репутацию при работе с государственными компаниями. Но все остальные программы вызывают сомнения в целесообразности получения. Исключением видится программа от Баумки, по которой хорошие отзывы и настоящий сертификат о переподготовке.

Почему нам нужна смелость и безрассудство

После того как человек сталкивается с какой-то критической ситуацией, где его технические или организационные решения привели к проблеме, которая стоила команде много времени и сил на устранение, он может словить антипаттерн: «Замороженный троглодит».

Этот антипаттерн заключается в том, что человек начинает действовать слишком осторожно и закладывает в свои решения слишком много негативных кейсов и нештатных ситуаций.

Например, мы не можем выкатить этот MVP, потому что у нас нет роллбеков для клиентов, которые случайно пройдут регистрацию из страны, для которой у нас не настроен шардинг. Даже если вероятность этого крайне мала, а компенсационные действия в ручном режиме занимают четверть часа, человек всё равно будет препятствовать релизу и запрашивать доработки на то, что не требуется на уровне MVP.

Или когда отдел продукта просит выкатить какой-то новый функционал, который в целом ОК, но без тщательного регресса, который может сорвать запланированные активности, человек боится давать добро, хотя все бизнес-кейсы проверены, остаётся лишь место неожиданности.

То есть получается, обжегшись однажды, человек пытается не допустить появления этого риска там, где его появление граничит с фантастикой, либо не представляет собой большой проблемы.

Чтобы преодолеть появление этого антипаттерна, необходимо:

1. Снизить значимость ошибки. То есть если все регламенты выполнены, задача прошла тестирование, но при выкатке случилась какая-то проблема, то окей — это допустимый риск, с которым мы готовы работать. Это не повод вызывать команду и отчитывать её за ошибку.

2. Проговаривать значимые риски. Если вы соглашаетесь делать работу, которая может вызывать проблему, то проговорите три-четыре самых крупных риска и регламент компенсационных работ. Если после разговора не возникает ощущение, что это слишком опасно, — вперёд!

3. Поощрять смелость. В большинстве случаев гораздо быстрее и эффективнее выкатить какую-то правку, собрать логи и откатить её обратно, чем тормозить разработку и решать проблемы, которых никогда не будет.

4. Решение нетипичных ситуаций — тоже опыт. Когда человек поймёт две-три ситуации, когда нужно было разбираться с кодом, который как-то неправильно работает на продакшене, то в четвёртый раз он уже без стресса сможет оперативно решить проблему, ведь он будет к этому готов.

Но к чему геройство…

После прочтения этих рекомендаций вы можете спросить: зачем столько рисков, когда можно сделать всё правильно? Современная разработка подразумевает непрерывное тестирование гипотез, когда победителем чаще всего оказывается не тот, кто сделал правильно, а тот, кто сделал быстро и так, как это нужно клиенту. И нет лучшего способа доставлять инкременты максимально быстро, как действовать смело и иногда даже безрассудно.

Должен же тимлид смотреть Merge Request (Pull Request)? 

Если задать такой вопрос, то большинство людей ответят утвердительно, поскольку это кажется максимально очевидной обязанностью любого тимлида, чтобы:

• контролировать качество кода программистов команды;

• следить за соблюдением принятых стандартов;

• управлять рисками кодовой базы команды;

• обучать участников команды через ревью их кода;

• держать руку на пульсе того, чем занимаются участники команды. 

Однако что делать, если у вас кросс-функциональная команда, состоящая из двух бэкендеров, пары фронтендов, QA и аналитика? Нужно ли вам просматривать все их MR? Сможете ли вы адекватно оценить код на PHP, код на React + TypeScript и автотесты на Python? Очевидно, что нет. 

Для разрешения данной ситуации вы можете:

Забить на код-ревью систем, которые не считаете критическими для успеха проекта. Возможно, никто не расстроится, если автотестер будет писать код так, как посчитает нужным.

Попросить разработчиков проводить код-ревью друг у друга. Однако всё довольно быстро превратится в формальные проверки, когда одобрения ставятся просто ради галочки.

Попросить самого опытного разработчика функциональной команды (например, техлида всех фронтендов) просматривать ревью вашего фронта, чтобы всё было хорошо. Но это быстро превращается в узкое место, когда ваши MR ждут ревью неделями, замедляя все релизы.

 Как поступить?

Предварительное согласование решений. Мало кому нравится читать чужой код, но многие любят обсуждать правильные подходы. Если члену команды предстоит сложная задача, попросите его описать своё решение и предложите остальным её обсудить. Это станет одновременно и публичной документацией, и предварительным ревью выбранного подхода.

Максимально возможное покрытие фитнес-функциями (автоматические форматтеры, автотестеры, анализаторы кода). Согласуйте с техлидами внедрение в проект автоматических анализаторов и добавьте их в пайплайны репозитория. Ни один MR не пойдёт на ревью до тех пор, пока не будет соответствовать установленным стандартам. Так вы сэкономите массу времени.

Автоматическое распределение код-ревью среди всех участников функции (все фронтенды, все бэкенды), вне зависимости от проекта, с фиксацией лица, поставившего одобрение. Автоматически напомните человеку, что он превысил установленные компанией сроки на проведение ревью.

То есть программисты из других команд могут не разбираться в вашем домене, но они способны проверить, что код не делает ничего лишнего и корректно функционирует в рамках проекта (при нагрузке, сущностях, подходах). А факт рандомности ревьювера и фиксации апрува, не позволит им проводить ревью формально.

Приемочные тесты и регрессионное тестирование при релизах. QA-специалисты проверяют задачи на готовность и удостоверяются, что решение соответствует требованиям, а при выпуске на продакшн проводится автоматизированное тестирование, чтобы убедиться, что система нормально справляется с последним добавлением функционала.

В итоге, если тимлид вместе с техническими лидерами выстроит жёсткую систему доставки инкремента на продакшн, ему самому не обязательно просматривать каждый MR своей команды. Исключение составляют лишь те случаи, когда «душа просит».

P.s. Рекомендую: Эволюционная архитектура - автоматизированное управление программным обеспечением - Нил Форд`

Как тимлиду работать со своим руководителем (engineering manager)

Проактивное донесение информации

Если у вас есть какие-то вопросы по команде, текущему проекту, процессам в команде и её эффективности, вам следует самостоятельно назначить встречу со своим руководителем, чтобы он подсказал вам, что следует делать - напрямую, через рекомендации и указания, либо через направление вас на самостоятельный поиск ответа (статьи, книги, курсы и тренинги).

Не нужно доводить ситуацию до того, чтобы каждый заход к вам был следствием ситуации, которая вышла из под контроля и стала проблемой.

Обсуждайте свой перфоманс

1. Обсуждайте, что такое хорошая работа тимлида в глазах руководителя. В разных компаниях от тимлида требуется решать разные задачи, поэтому нужно понимать, что от вас ожидают.

2. От чего зависит ваша продуктивность (какие показатели от вас ожидают). Тут мы уже переходим к числовым оценкам, а не каким-то субъективным впечатлениям. Чтобы вы могли улучшать свою работу, вам нужны эталонные значения и ваши текущие цифры.

Составляйте отчеты

Хорошая практика - выделять каждую неделю по 30 минут, чтобы написать небольшой отчет по тому, что вы делали, что вы думаете на этот счет, что делали ваша команда, что стало блокером, а что стало возможностью. Сохраняйте отчет себе и отправляйте его вашему руководителю.

Показывайте, что вы можете брать на себя ответственность

Проявляйте интерес к новым обязанностям, будьте тем тимлидом, которому руководитель отдаст новый проект или какую-либо деятельность.

После того, как вы становитесь лидом, у вас резко возрастает объем информации, который нужно обрабатывать. В этом помогут следующие инструменты:

Календарь. Используйте его, чтобы планировать встречи со своей командой, проводить встречи один на один, общаться с другими отделами в ходе согласований, бронировать время для себя (обед или сессия какой-либо работы). Обязательно используйте автоматические напоминания. Главное помните, что календарь - это не список дел.

To-Do-List. Создавайте приортизированные списки дел, которые необходимо выполнить в течение дня или недели. Заносите туда даже самые банальные вещи, которые кажутся глупыми: "Проверить борду спринта". Чем меньше вы будете держать в голове, тем проще вам будет сосредоточиться на деле.

Почтовый ящик. При работе с внешними сторонами и внутренними заказчиками обязательно нужно использовать почту, чтобы фиксировать договоренности. Так, вы не только получаете артефакт, но понимаете, что все договоренности могут быть найдены в одном месте. Не нужно будет ходить по сотням чатиков и искать нужное сообщение.

Хранилище информации. Когда вы каждый день пропускаете через себя много информации, вы очень быстро теряете какие-либо идеи, хорошие мысли, замечания и советы. Поэтому закидывайте их в хранилище, а потом при удобном случае структурируйте их.

Сделайте работу с этими инструментами ежедневным ритуалом, и вам станет гораздо легче работать.