Привет! Меня зовут Егор Толстой. Я веду подкаст Подлодка, руковожу командой разработки языка программирования Kotlin, а до этого много лет был продакт-менеджером и руководил разными инженерными командами.

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

Если какой-то пост был вам полезен – ставьте 👍, ❤️ и 🔥, мне это важно! А еще лучше – подписывайтесь на мой Твиттер и другие Telegram-каналы: iOS Good Reads, Android Good Reads, QA Channel.

Навигация по постам:
#digest – регулярные подборки лучших материалов
#книги – рекомендации книг
#найм – все, связанное с подбором людей и собеседованиями
#развитие_себя – улучшение своих тимлидовских навыков
#люди – про все навыки, связанные с работой с людьми
#процессы – процессы разработки, управление сроками и скоупом
#техлидство – инженерная культура, архитектура, практики
#управление_компанией – про company-wide процессы, оргструктуру
#инструменты – прикладные материалы, пополняющие ваш toolbox
#качество – управление и улучшение качества системы, за которую вы отвечаете
#карьера – поиск работы тимлидом, прохождение собеседований, рост в компании

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

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

В итоге команда выработала свой подход с двумя типами итераций: build iteration со скользящей продолжительностью для работы над конкретной пользовательской проблемой и refine iteration фиксированной продолжительности для багфиксов и закрытия техдолга.

#процессы

Очень разумная статья про то, как постепенно растить в команде Agile практики. В противовес частому подходу «прочитал про практику – прибежал внедрять», автор рассказывает про планомерный поиск и расширение бутылочных горлышек в процессах команды.

Несколько наблюдений и советов из статьи, с которыми я обеими руками согласен:
🐞За качество отвечает вся команда, а не отдельный человек в ней
👨‍👩‍👧‍👧У разных людей – разный контекст, и нужно его учитывать при продаже своих идей
✊Культуру почти никогда нельзя насадить административно

#процессы #качество

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

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

Для тех, кто страдает от этих моделей, а в особенности от консенсуса, есть еще один подход. Вместо того, чтобы добиваться активного согласия от каждого участника обсуждения, можно довольствоваться отсутствием активно несогласных. Этот принцип часто встречается под именем disagree and commit. В статье – чуть больше деталей и много дополнительных ссылок для заинтересовавшихся.

#процессы

Статья с советами для инженеров и менеджеров, которые работают в early stage стартапах:
⚖️При выборе технического решения всегда явно показывайте альтернативы и принятые трейдоффы, это помогает всем выравниваться вокруг единых приоритетов
⏳В первую очередь разрабатывайте те части системы, которые скорее всего не будут меняться. За это время команда получит возможность разобраться с задачами с большей неопределенностью.
📆Не спешите вкладываться в какие-то долгоиграющие инфраструктурные решения – в стартапе все может поменяться в любой день, и это сразу превратится в техдолг.
⌚️Для крупных задач проводите мысленный эксперимент – как бы вы подошли к ее решению, если бы сроки были на порядок меньше – месяц вместо года, неделя вместо месяца. Это может помочь найти какие-то неожиданные решения.
🥱Выбирайте скучные технологии. Слишком экзотический стек не даст вам быстро растить команду при необходимости.

#процессы

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

Вот несколько инсайтов:
⏱Разные часовые пояса могут стать плюсом, если правильно распределить нагрузку. Например, наличие географически-распределенных QA часто позволяет быстрее проходить через этап тестирования.
📆Распределенная работа заставляет внимательнее подходить к тайм-менеджменту и подготовке общих встреч.
📖Отсутствие возможности в любой момент дернуть любого коллегу и уточнить договоренности приводит к тому, что они четче описываются заранее.

#процессы

Одна из ключевых идей теории ограничений – нужно управлять не загрузкой отдельных элементов, а общей пропускной способностью системы. Это очень хорошо ложится и на инженерные команды. Если каждый из ее участников нагружен на 100% – скорее всего, общая эффективность команды значительно ниже оптимальной.

Быстро с этой идеей можно ознакомиться в этой статье, а если захотите закопаться поглубже – в очередной раз посоветую вам “Цель” и “Проект Феникс”.

#процессы

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

#процессы

Если вы еще не послушали новый выпуск Подлодки про то, что оценки сроков и дедлайны вредны, срочно бегите это делать. Вот вам три причины, почему:
🎸Гость – Виталий Шароватов, админ нашего чата и очень рациональный менеджер
📚Разбираются все самые частые кейсы, в которых вас заставляют оценивать сроки – и каждый из них уничтожается
🏃🏻‍♂️Даются прикладные советы по тому, как убедить свою команду и руководителя отказаться от оценое

#процессы

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

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

#процессы #техлидство

Большой гайд от GitLab про то, как управлять командой в условиях удаленной работы. Как и все остальные материалы из их плейбука – хорошо проработан и основывается на куче примеров из их же опыта. Несколько мыслей, которые мне понравились:
📌Многие руководители неосознанно начинают микроменеджерить, когда не могут видеть свою команду глазами. То, что вам может казаться здоровой синхронизацией, для вашего сотрудника может быть жестким микроменеджментом.
📌Нужно стараться как можно большее число процессов переводить в асинхронный режим. Это помогает получить максимум пользы от ремоута, когда каждый может работать в своем удобном режиме и часовом поясе.
📌Сохраненная в письменном виде информация становится еще более ценной. Документируйте больше своих решений, ожиданий от сотрудника и фидбэка. Это даст людям возможность потреблять информацию в своем темпе.

#процессы

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

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

#процессы

Где бы я ни работал, мне приходилось решать конфликты между дизайнерами и разработчиками. Дизайнеры, которые не хотят думать о граничных состояних приложения. Разработчики, которые задают отступы или межстрочные расстояния на глаз, и отказываются проводить попиксельную сверку с макетом. Больше всего запомнился случай, когда разработчик и дизайнер из одной команды не разговаривали друг с другом около полугода, а все сообщения передавали через кого-то третьего.

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

#люди #процессы

Разгружаем команду разработки от любых внешних коммуникаций с помощью дежурных

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

В результате такого подхода команды получили:
- Крутое обучение новичков
- Шаринг знаний внутри команды
- Повышение эффективности работы всей команды, несмотря на потерю одного человека
- Появилось чувство коллективного владения кодом

#процессы