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

Новые выпуски Подлодочных подкастов На прошлой неделе выпустили два эпизода, которыми хочу с вами поделиться! 1️⃣Подлодка про тест-кейсы. Если вы лидите команду, в которой есть тестировщики – отличный выпуск, чтобы разобраться, а какие артефакты должны получаться на выходе у хорошего тестировщика, как оптимизировать постоянно растущее количество тестов и каким софтом пользоваться, чтобы держать все под контролем. 2️⃣Бреслав и Ложечкин про увольнения. Как понимать, с кем и когда надо расставаться, и как на это влияет межкультурный контекст.

Должен ли тимлид оставаться техническим специалистом Чтобы ответить на этот вопрос, важно различать два понятия: быть техническим и контрибьютить. Под "быть техническим" подразумевается поддержание уровня знания технологий, устройства системы и контекста работы команды без непосредственного вовлечения в решение задач. Под "контрибьютить" – активно писать код или другим образом работать с технологиями напрямую. Так вот, основная идея статьи в том, что менеджер в большинстве случаев контрибьютить не должен, но вот техническим быть обязан. Это помогает лучше понимать челленджи команды, говорить на одном языке с инженерами, принимать взвешенные решения, помогать своей команде расти. Ну а дальше идут разные советы про то, как оставаться техническим. Часть из них давно понятны, но несколько показались мне любопытными: 👉Жестко таймфреймить время в неделю, которое вы тратите на поддержание своего технического уровня. 👉Принимать участие в технических митингах. 👉Помогать команде писать документацию. 👉Пилить внутренние инструменты. Ну а я еще раз поделюсь советом, который даю всем начинающим менеджерам по этому вопросу. Мне кажется, что писать код или другим образом участвовать в работе команды – абсолютно нормально, но до той поры, пока эта работа не вытесняет менеджерские задачи. На практике это значит, что вы можете брать задачи из бэклога команды, но они не должны быть блокирующими. Если менеджерская работа вытеснит их выполнение, никто не должен пострадать.

Как подсидеть тимлида Я тут недавно переносил свой блог на новый движок, и вспомнил, что у меня есть много нетленок, которыми и сейчас не грех поделиться! А пятница – идеальный день для того, чтобы обсудить, как правильно подсиживать своего тимлида. Некоторые из советов: 👉Попросите тимлида добавлять вас во все его кодревью под предлогом того, что хотите учиться у лучших. Пуллреквестов скорее всего будет мало, поэтому на стендапах громко предлагайте свою помощь и намекайте, что от всех в команде ожидается одинаковый вклад. 👉Ни один тимлид не видит по-настоящему ценности в своей работе, бейте в эту точку! На стендапе попросите тимлида рассказать, чем он занимается на работе. После его историй о встречах и передвижении задачек по доске, повторите вопрос «А сделал-то что?». 👉Посоветуйте всем коллегам начать ходить по собеседованиям, чтобы оценить свою стоимость на рынке. Можете даже сами им подходящие вакансии сбрасывать. Они неминуемо вернутся с большими офферами и придут с ними к тимлиду – пусть знает, что он сидит на пороховой бочке. 👉Организуйте хакатон и сколотите команду из коллег. Когда тимлид спросит, почему его не позвали, скажите, что программисты на Excel и Exchange вам были не нужны. Расскажите в комментариях, какие новые способы подсиживания появились в последние годы!

Snow melts at the periphery Чем более сеньорный вы менеджер, тем сильнее вы рискуете оторваться от реальности. Самостоятельное общение с пользователями легко и быстро вытесняется просмотром аналитических дэшбордов и сводок, а погружение в инфраструктурные проблемы заменяется ленивым поглядыванием на первые несколько строк постмортемов. В статье предлагают хороший совет, который может помочь удержать контакт с реальностью – завести побольше прямых связей с людьми, которые находятся близко к пользователям, клиентам или непосредственному коду. Таким образом вы будете получать рассказы о проблемах из первых уст от людей, на которых они влияют больше всего. Короче говоря, дружите с саппортерами, продажниками, и линейными программистами, даже если вы большой руководитель.

Вышла книга "Made at Intel" Несколько последних лет на Хабре регулярно натыкался на серию постов менеджера-ветерана из Интела с разными историями про то, как была устроена их кухня. Причем историями довольно откровенными, после которых не возникало желания побежать туда работать. Так вот, спустя несколько лет публикаций, автор, Валерий Черепенников, завернул все эти истории в книгу. Я еще не читал, но планирую в ближайшие месяцы – потом обязательно поделюсь впечатлениями!

Исследование продактов Каждый год я с командой провожу исследования разных сегментов IT рынка. Первое исследование в 2024 – про продакт-меннджеров! В этот раз, помимо стандартных вопросов про скиллы, компании и сообщество, мы спрашиваем про: 👉медианные зарплаты по грейдам 👉сложность устройства на работу 👉время, которое уходит на различные рабочие процессы Нам очень важен каждый голос, поэтому проходите опрос сами, и, самое главное, поделитесь им со своими коллегами продакт-менеджерами! 🔗Пройти опрос

Онлайн-конференция про AI от Epic Growth Мои друзья из Epic Growth делают крутую штуку – большую онлайн-конференцию про то, как внедрять AI в свои продукты и команды. Будет три трека про продукт, маркетинг и личную эффективность. В каждом выступит с десяток спикеров, которые поделятся своим практическим опытом. В программе уже подтверждены ребята из Tinkoff AI, Zalando, Artefacto и Evolwe AI. 📆Дата: 12, 13, 14 марта 👉Регистрация

Советы по управлению долгими проектами 👉В первую очередь приоритизируйте самые непонятные и сложные проблемы, откладывая остальные части на потом. Именно у них есть потенциал растянуть проект на бесконечность времени. 👉Как можно быстрее выводите проект в продакшн. Это поможет выявить различную невидимую работу, о которой вы не догадывались. Как вариант, оптимизировать проект сначала под какой-то один узкий сценарий. 👉Подумайте об оттоке людей заранее. На всех критичных позициях должны быть замены. Все решения должны быть задокументированы, чтобы знания не пропали с увольнениями. Если кто-то увольняется, скоуп или сроки должны быть пересмотрены, чтобы оставшаяся часть команды не кранчила. 👉Старайтесь выбирать для проекта такие майлстоуны, которые позволяют получить какую-то внятную ценность. Это поможет поддерживать интерес бизнеса и команды. 👉Управляйте отношением к проекту внутри компании, причем проактивно. Делайте частые публичные апдейты статуса, празднуйте достижение майлстоунов, проводите Q&A и техтолки. По опыту работы в Котлине, в котором большая часть сколько-то значимых проектов занимает больше года, советы очень релевантные.

Как писать больше Andrew Chen, автор одной из лучших книг про продакт-менеджмент за последние годы, написал эссе про то, что помогает ему писать часто и много контента. Вот идеи, которые я сам хочу попробовать: 👉Нужно построить максимально простой пайплайн записи интересных идей, которые могут приходить откуда угодно. А потом регулярно эти идеи разбирать, связывать друг с другом, и попадающие под настроение разворачивать в посты. 👉Не нужно фиксироваться на каком-то конкретном формате. Идея может превратиться как в длинное эссе, так и в небольшой пост в Телеге, или вообще в твит. 👉Лучше выделять фиксированные слоты в календаре под то, чтобы писать. 👉Используйте ChatGPT как партнера для брейншторма структуры и тезисов, а штуки вроде Oasis AI для записи и расшифровки голосовых заметок. 👉Как можно меньше заморачивайтесь про качество результата, иначе перфекционизм убьет весь результат. Вместо этого подходите к процессу итеративно. Напишите твит. Если он зашел, разверните в тред. Если и он зашел, то можно и статью писать, и аудитории она тоже понравится.

How do Committees Invent В нашей индустрии все хотя бы краем уха, но слышали про закон Конвея: организации обречены создавать дизайн систем таким же, как выглядит их структура коммуникаций. Но мало кто читал оригинальную статью Конвея, где он эту идею раскрывал и доказывал. Прочитайте, она крутая!

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

Как AI ассистенты влияют на качество кода На днях GitClean опубликовали исследование, согласно которому за последний год качество кода существенно упало. Сначала про методологию: 👉Анализировали 150+ миллионов строк кода, как из опенсорса, так и своих коммерческих клиентов. 👉В качестве основной метрики выбрали code churn – процент строк кода, которые были удалены в течение двух недель после написания. 👉Помимо чёрна, смотрели на количество рефакторингов – перемещений существующего кода в новое место. Результаты такие: 👉Доля churn code растет с 2022 года, когда появился Copilot. В 2020 эта доля была равна 3.3%, сейчас уже 5.5%. 👉Доля рефакторингов, наоборот, заметно упала. По версии авторов исследования это может означать, что людям проще сгенерировать новый код, чем думать о переиспользовании старого. Я бы не делал далеко идущих выводов на основе этого исследования. Выводы в отчете немного притянуты за уши, сами метрики выбраны тоже довольно странно.