Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Как избегать накопления техдолга У причин появления в проекте большого количества техдолга всегда есть два наивных объяснения: неосознанные разработчики или глупый и жадный менеджмент. Но в подавляющем большинстве случаев настоящие причины не настолько полярны. Типичная история – менеджер просит команду побыстрее сделать фичу, на что тимлид соглашается, не озвучивая при этом риски, либо считая их очевидными, либо просто не желая быть негативным. В этой ситуации, конечно, виноваты оба участника: и менеджер не проговорил, какая вообще ценность от задачи, и в чем причины спешки, и тимлид не задал вопросов. Чтобы избежать такого паттерна накопления техдолга, попробуйте следующие шаги: 👉Вместо прямых указаний или просьб сделать фичу задавать вопросы вида "Можем ли мы сделать Х за время У?". Это дает команде возможность сделать выбор вместо того, чтоьы пойти по простому пути и следовать указанию. 👉Еще лучше использовать открытый вопрос. Например, "Что нам придется убрать из скоупа, чтобы сделать Х?" или "Как вы оцениваете риски фичи Х по 10-балльной шкале?" 👉Еще лучше – делать команду достаточно автономной и передавать ей ответственность за результат, чтобы продакту достаточно было рассказать о фактах и дать команде самой решить, что самое ценное для пользователя они могут сделать. 👉Поощряйте привычки команды, которые заставляют ее регулярно задумываться о стоимости и смысле изменений, или уделять внимание инженерной культуре. Например, учитывать в приоритизации cost of delay. 👉Поощряйте не только релизы фичей, но и невидимую работу по решению техдолга и улучшению процессов.

Spotify Wrapped для менеджера У кого-то год был музыкальный, а у кого-то...

Опрос про Роадмап Тимлида Я тут недавно посчитал, сколько лет прошло с момента первого запуска Роадмапа Тимлида. Оказывается, целых пять! Изначально я вписался в этот проект с очень корыстной целью – собрать базу знаний, с помощью которой смогу помогать развитию тимлидов, которыми руковожу сам. Так и получилось, за прошедшую пятилетку Роадмап помог мне бесчетное количество раз. Если вы тоже пользовались Роадмапом для решения каких-то своих задач, то, пожалуйста, пройдите наш небольшой опрос. Нам со Стасом будет очень приятно узнать, каким компаниям мы смогли помочь, а заодно набрать идей по дальнейшему улучшению проекта. 👉Ссылка на опрос

Как строить доверие Никаких секретных способов быстро заслужить доверие команды нет. Нужно быть хорошим менеджером, на которого можно положиться, и со временем доверие придет. При этом есть некоторые гигиенические вещи, без которых доверия точно не заслужить: 👉Действуйте одинаково в похожих ситуациях. Менеджер, реакцию которого невозможно заранее предсказать, точно не создаст фундамента для доверительного общения. 👉Ясно и открыто рассказывайте про происходящее в компании и любые изменения, которые могут затронуть людей. Если что-то рассказывать нельзя, то не уклоняйтесь от ответов, а ясно объясняйте, почему информацией сейчас делиться нельзя. 👉Будьте надежными, и отвечайте за свои слова. 👉Как можно реже прибегайте к режиму авторитарного управления. 👉Давайте как можно больше фидбэка, причем с уклоном в позитивный. 👉Открыто признавайте заслуги других, а провалы берите на себя. 👉Делегируйте людям в команде не только скучную для вас работу, но и те задачи, которые вам самому кажутся интересными.

Прямо сейчас три команды Авито находятся в поиске опытных тимлидов разработки: ➡️Тимлид разработки в команду инфраструктуры поиска ➡️Тимлид разработки в команду внутренних проектов (Legal Tech) ➡️Тимлид разработки в команду Support Systems Здесь вы сможете реализовать свои идеи в проекте с многомиллионной аудиторией и талантливой командой. Зарплата достойная (обсуждается на собеседовании), а ещё: – мощное железо, дополнительные мониторы и всё, что нужно для продуктивной работы; – личный бюджет на обучение, который можно тратить на книги, курсы и конференции; – ДМС со стоматологией с первого дня; – прозрачная система премий; – удалёнка и крутой офис в 2-х минутах от метро «Белорусская»; – терапевт и массажист, которые принимают в офисе. Откликайтесь на вакансии и присоединяйтесь к одной из команд!

State of Developer Ecosystem Подъехали результаты большого ежегодного исследования разработчиков от JetBrains. 👉77% разработчиков используют ChatGPT, а 46% – CoPilot. Самый частый сценарий – задавать вопросы общего характера про программирование. 👉Выгорание за свою карьеру переживали 73% разработчиков. 👉Для 58% первым шагом к обучению программированию было формальное образование. На втором месте – книги, но уже только 10%. 👉Только у 63% разработчиков в проекте есть юнит тесты. 👉Среди языков программирования единственным растущим остался Rust. 👉Три самых высокооплачиваемых языка: Scala, Go, Kotlin. 👉Новые языки чаще всего учат просто ради интереса, для работы над личными проектами и чтобы следить за трендами.

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

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

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

Приемы по внедрению изменений в процессы 👉Если все в команде понимают решаемую проблему, и нужно выровняться по конкретным улучшениям, подойдет Improvement Kata. Это простой подход к проведению процессных экспериментов и оценке их влияния на результат. Основной плюс – удобная визуализация происходящего. 👉Если общего понимания проблемы нет, и ее сначала нужно продать, лучше всего начать с разговоров с отдельными людьми, и, только получив согласие от всех вовлеченных, делать презентацию на группу. Такой подход называется японским термином Nemawashi. 👉Если количество людей, которых надо убедить в изменении, слишком большое – лучше всего описывать его в виде документа. Как варианты: A3 problem solving или RFC.

Уточняйте свои просьбы Не все сотрудники готовы переспрашивать менеджера о деталях, когда он просит с чем-то помочь. Как результат, чтобы ответить на какой-то вопрос своего менеджера или кого-то из топов, человек может потратить в несколько раз больше времени и сил, чем на самом деле необходимо. Например, на просьбу сообщить какие-то данные вместо быстрого ответа можно начать готовить красивую презентацию, которая будет вообще излишней. Поэтому, если вы просите кого-то о помощи, будьте конкретными: 👉Уточните время, которое стоит потратить на вопрос. Например: "Если займет больше 15 минут, то забей". 👉Уточните приоритет относительно других задач. Например: "Не стоит откладывать другие важные задачи из-за этой. Но если за две недели не успеешь заняться, скажи мне, пожалуйста". 👉Уточните, просите ли вы рассказать о существующем знании или узнать что-то новое. 👉Уточните, как конкретно вы планируете использовать полученную информацию, чтобы было легче сопоставить результат и затрачиваемые усилия.

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