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

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

Как в Google работает code review Интересный разбор особенностей code review в Google – от гайдлайнов и до разбора Critique, внутреннего инструмента для ревью. Среди заметных фич: 👉Использование AI для того, чтобы в одну кнопку применить предложения из комментария. 👉Автоматическая генерация комментов-саджестов для ревьюеров кода на основе работы статических анализаторов. 👉Есть специальные дэшборды, которые показывают, какие ревью на ком зависли. 👉Если PR содержит и стилистический рефакторинг, и изменения бизнес-логики, Critique отфильтровывает только значимый код.

Почему вы увольнялись с менеджерской работы Я увольнялся с менеджерских позиций два раза. Первый раз был в 2016 году в Rambler&Co. У нас одним днем сменился весь менеджмент технического подразделения на каких-то очень эффективных ребят из Инновы. Первое, что они сделали – собрали всю нашу команду и начали рассказывать про Scrum и другие великие изменения, которые планируют внедрить. На любые разумные вопросы про эти изменения отвечали чем-то типа "Да я уже пять успешных бизнесов построил, когда сделаешь столько же, вопросы и задавай". После этой встречи мы завели встречи для всего iOS отдела, на которых совместно стали готовиться к интервью. Спустя пару месяцев уволился и я, и процентов 70 всей команды. Мораль, которую я для себя вынес – даже если вас нанимают ради внедрения изменений, не стоит врываться с ними с порога без внятной стратегии их исполнения. Второй раз был уже из Авито. В какой-то момент количество скучных менеджерских задач на монй позиции стало перевешивать интересные. В частности, смешно получилось с перфоманс ревью. Еще в 2017 году я начал его внедрять в компании. Со временем он эволюционировал, превращаясь во все более сложную машину. Два года спустя, сидя поздно вечером на калибровке, на которой мы несколько часов до хрипоты спорили о том, кто из двух незнакомых мне инженеров заслуживает +0.05 к оценке, я понял, что это совсем не то, на что я хочу тратить свою жизнь. А теперь ваша очередь! Расскажите в комментариях, почему вы увольнялись с менеджерской работы.

Как деливерить быстрее Набор принципов, некоторые из которых показались мне интересными: 👉Protect momentum. Чем чаще вы что-то релизите, тем выше получается держать уровень мотивации и энергии в команде. Длинные циклы разработки приводят к выгоранию и потере контакта с пользователем. 👉Beware of prioritization. Бессмысленно тратить много времени на приоритизацию, когда все, что действительно важно – это какую задачу делать прямо сейчас, а какую – следующей. 👉Only doers can plan what you work on. Как только за планирование начинают отвечать оторванные от разработки люди, появляется искуственное раздувание сроков разработчиками, которые не хотят промахиваться в оценках. А работа занимает все выделенное на нее время. 👉There is no quality vs speed tradeoff. Плохое качество кода замедлит вам работу в будущем. Любой компромисс такого рода – в долгую вреден. При достаточном уровне культуры разработки и скиллов инженеров можно достичь обеих целей.

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

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

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

Производительность определяется не личностью разработчика, а случайными факторами Интересное исследование за 1995 год. 500 разработчиков выполняли на протяжении времени набор одинаковых задач, оценивая свои трудозатраты на разные этапы работы над ними. На выходе получились интересные данные: 👉В рамках отдельных заданий есть огромная разница между некоторыми программистами – лучший может быть производительнее худшего аж в 55 раз. 👉Если отбросить эти выбросы, то разница между 25 и 75 перцентилем очень небольшая. 👉Все интереснее, когда анализируется производительность каждого разработчика в рамках всех задач. У 90% разработчиков очень большой разброс времени выполнения разных заданий. Фактически 482 из 494 программистов закончили хотя бы одно задание быстрее среднего, а 415 — медленнее. Короче, еще одно подтверждение того, что бессмысленно сравнивать перфоманс разработчиков друг с другом, когда они работают над разными задачами, и что вместо фиксации на скорости разработки лучше уменьшать ее неопределенность.

Как запрашивать фидбэк на свою работу Типичная история – вы работаете над какой-то идеей, запрашиваете у коллег фидбэк, и вместо чего-то полезного получаете поток обратной связи про несущественные аспекты и косметику. Чтобы этого избежать, надо заранее проговаривать, фидбэк какого типа вы ожидаете. Вот одна из моделей: 👉Работа завершена на 5%: "Согласны ли вы с проблемой, которую я решаю?" 👉Работа завершена на 30%: "На правильном ли пути я нахожусь с моим решением проблемы?" 👉Работа завершена на 60%: "Является ли решение разумным, достигнем ли мы с ним наших целей?" 👉Работа завершена на 90%: "Пропустил ли я что-нибудь?" 👉Работа завершена на 100%: "Что в следующий раз надо сделать по-другому?"

Бреслав и Ложечкин про обратную связь Вышел новый эпизод дочернего проекта Подлодки – подкаста для менеджеров "Бреслав и Ложечкин". В этот раз разговор идет про обратную связь: когда и кому она нужна, сколько времени на нее тратить и с какими подводными камнями можно столкнуться.

Пост для всех, кто любит новогодние подарки с пользой Грейд клуб от Яндекс Практикума запустил адвент-календарь для руководителей цифровых команд. Грейд Клуб — сообщество для нетворкинга цифровых лидеров и площадка для поиска решений о том, как драйвить рост IT-команд. На протяжении трех недель пользователи будут получать классные подарки от клуба и его партнеров. А их собралось внушительное количество: Эйч, МИФ, Ясно, Кинжал и топовые эксперты индустрии. Внутри вас ждут: 🎁Полезные фичи для мессенджеров 🎁Билеты на отраслевые конференции 🎁Гайды по эффективному лидерству и другие полезные подарки. Переходите в бот адвент-календаря, чтобы не пропустить подарки! ООО Яндекс. ИНН 7736207543

Как построить найм студентов Один из способов расширить воронку найма – посмотреть в сторону найма студентов, которые пока нигде поработать не успели. С одной стороны, нужно построить непростой процесс обучения и отфильтровывания тех из студентов, кто не готов вкладываться, а с другой вы можете получить отлично обучаемых людей, которые готовы будут быстро вникнуть именно в ваш технический стек. Ребята из МойОфис рассказывают, как запускали два потока студенческих стажировок и с какими сложностями столкнулись. По цифрам результат такой: 👉50 собеседований на входе воронки, 5 наймов спустя 3 месяца. 👉4 из 5 нанятых остались в компании после испытательного срока.