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

Методологии разработки, о которых вы не слышали Сразу несколько дисклеймеров: - Ничто не ново под луной, все эти методологии – просто докрученные варианты базовых практик. - Никогда не нужно тащить чужую методологию к себе в команду as-is, вместо этого – решайте реальные проблемы и стройте свой процесс. 1️⃣ShapeUp от BaseCamp Весь цикл разработки делится на три фазы: Shaping, Betting, Building. На первой фазе команда исследует разные проблемы и экспериментирует с разными подходами к ее решению. На второй – стейкхолдеры выбирают, какие ставки сделать на основе предложенных решений. На третьей – в течение шести недель команда реализует MVP и доводит его до пользователей. Выглядит похоже на стандартный Double Diamond, с небольшими локальными подкрутками. 2️⃣Plan > Build > Ship Облегченная версия привычного всем водопада с декомпозицией его по отдельным фичам. За каждую фичу отвечает один или несколько инженеров, задача которых – максимально быстро провести ее через все фазы процесса. Фазы стандартные: собрать требования, задизайнить решение, имплементировать дизайн, собрать фидбэк и внести требуемые изменения. 3️⃣Get Shit Done Внутренний процесс Shopify, который в основном крутится вокруг их внутреннего же инструмента трекинга. Вся работа бьется на отдельные проекты, задача которых – решить какую-то проблему пользователя. Работа бьется на три фазы, близкие к тому же ShapeUp: Think (исследуем проблему), Explore (исследуем область решений), Build (коммитимся на одном решении, разрабатываем и выпускаем его). 🌟Бонус для тех, кто дочитал: govno.works

Как организовать succession planning Succession planning – это процесс, который помогает вам заранее продумать, кто займет ключевые роли в команде, если текущие сотрудники уйдут. Помимо очевидного менеджмента рисков, succession planning полезен тем, что помогает вести более осмысленные карьерные разговоры. Вот как организовать процесс у себя: 👉Выделите ключевые роли в команде – формальные и неформальные лидеры, ответственные за важные компоненты, главные эксперты по каким-то темам. 👉Подумайте над вариантами развития будущего – какие новые роли могут появиться в команде в ближайший год с учетом того, куда движется вся компания. 👉Соберите список ожиданий от каждой из позиций, поговорив с людьми, которые их сейчас занимают, или с теми, кто выполняет похожие роли в других командах. Тут есть один тонкий момент – нужно очень хорошо объяснить, что вы не планируете никого увольнять, а наоборот, хотите предусмотреть план на будущее, чтобы сотрудник мог расти дальше. 👉Решите, что делать с каждой ролью. Вариантов море – нанять нового человека с потенциалом роста, вырастить преемника внутри, распределить обязанности между другими людьми, или вообще закрыть позицию. Этот план, конечно, будет меняться со временем, поэтому на него стоит периодически посматривать и обновлять.

Не важно, сколько денег есть на счетах компании – нанимать нового сотрудника осмысленно только тогда, когда именно его появление может решить основную проблему, тормозяющую рост компании. Начнем понедельник с хоттейка трехлетней давности от Пола Грэма. Что скажете? С одной стороны, совет мне очень нравится – вместо бестолковых попыток улучшать локальные максимумы, давая каждой команде бюджет на найм, мы фокусируемся на одном конкретном бутылочном горлышке и расширяем его. Расширили – определяем следующее. При этом, как и любая другая чрезмерно упрощенная модель звучит прекрасно, но разбивается о реальность: 👉Определение одного бутыдочного горлышка – не тривиальная задача, и иногда все-таки разумнее сосредоточиться сразу на нескольких проблемных местах. 👉Если решать только проблемы сегодняшнего дня, не смотря вперед, можно упустить много возможностей.

Новые выпуски подкастов про менеджмент 👉"Подлодка" про смену роли в IT. В этот раз мы не стали звать никаких гостей, и делились своим собственным опытом. Я, например, рассказывал и про переход из линейного разработчика в тимлиды, и из пипл-менеджмента в продакты. Если вас периодически посещают мысли, не попробовать ли что-то новое в сравнительно безопасных условиях – обязательно слушайте! 👉"Три тимлида заходят в бар" про managing up – как проактивно выстраивать отношения со своим руководителем и управлять его ожиданиями. 👉"Бреслав и Ложечкин" про то то, как выживать в мире позивной дискриминации, и то, насколько действительно имеет место гендерное неравенство.

Откуда берется бюрократия 👉Когда сотрудников становится больше, чем человек может удержать в голове, становится сложно понять, к кому конкретно надо прийти, чтобы обсудить свою проблему. Это ведет к усложнению структуры организации и коммуникаций, и вот она – бюрократия. 👉Люди боятся рисковать, даже если выгода перевешивает потери. В компании это усиливается. Представьте себе проект с одинаковым шансом потерять $1М и заработать $10М. Большинство линейных сотрудников не возьмут на себя такой риск, так как потеря статуса в случае неудачи несравнима с пользой, которую они получат от выигрыша. Бюрократия может появляться, чтобы компенсировать этот эффект. 👉Если вам нужно принять какое-то решение, чаще всего для этого достаточно 1-2 конкретных людей. Но при этом всегда есть кто-то, кто обидится, если его не позовут. Быть плохим и наживать себе врагов никто не хочет, поэтому размер групп раздувается до огромных комитетов и тяжеловесных процессов. 👉Вместо честного разговора о проблемах проще внедрить процесс, который распределяет ответственность на систему, а не на конкретного человека. 👉Культура компании притягивает тех, кто ей соответствует, и продвигает тех, кто хорошо в нее вписывается. Это особенно хорошо работает для бюрократии.

Что означают девятки в надежности сервисов Погнали разбираться, что скрывается за всеми этими девятками в расчете аптайма сервиса. 1️⃣ С каждой следующей девяткой сложность инфраструктуры растет экспоненциально. Например, если для 99.9% надежности достаточно сервера в одном регионе, то 99.99% влечет за собой деплой сразу во много регионов, автоматический хелсчек и более сложные алгоритмы восстановления. 2️⃣ Такая оценка дает лишь очень приближенное представление о реальной надежности, так как скрывает много нюансов. Например, игнорирует частичный отказ сервисов, и предполагает равномерное распределение отказов по времени. Для пользователя картинка выглядит по-другому, и одно падение на час может быть существенно хуже, чем 200 минутных падений в течение года. 3️⃣ Не стоит стремиться к наибольшему количеству девяток, так как более высокая надежность влечет за собой кучу трейдоффов. Например, будут страдать скорость разработки и существенно расти косты на поддержку. Иногда придется даже жертвовать пользовательским опытом – упрощать фичи, чтобы архитектура системы была проще, или заменять синхронное действие сложными асинхронными распределенными транзакциями. Хорошие вопросы, которые помогут понять, а что именно вам нужно в плане надежности: 👉Как влияют на бизнес разные типы инцидентов? 👉Где во всей системе мы можем иметь разные уровни стабильности? 👉Как надо обрабатывать случаи частичного отказа каких-то частей сервиса? 👉Как повышение надежности влияет на скорость разработки и возможность делать что-то новое?

Как уважать свое время Все советы в статье будут довольно очевидны любому менеджеру, который смог выжить первые два года после своего назначения – почаще говорите "нет", назначайте короткие митинги, не поощряйте опоздания, отклоняйте встречи без повестки. Но одна идея мне запала в душу: Смотрите на свой календарь как на кошелек. Если вы не готовы просто так дать кому-то 100€, не стоит просто так выделять и свое время. Свои часы стоит рассматривать как инвестицию, и распределять их не на первые попавшиеся возможности, а согласно продуманной заранее стратегии. Мне в этом очень сильно помогает сервис Reclaim. В чем суть – вы можете заранее забронировать нужное количество часов в вашем календаре под какие-то дела, и сервис будет умным образом их перераспределять по рабочей неделе с учетом приориетов. Вот в каких сценариях я его использую: 👉Каждую неделю у меня гарантированно есть четыре непрерывных слота на три часа чтобы поработать над задачами, требующими большой концентрации внимания. При этом эвристика настроена так, чтобы они предпочтительно находились в первой половине дня, когда я соображаю получше. 👉Дополнительно по пятницам есть гибкий слот на 1-2 часа, выделенный чисто под догфудинг наших продуктов. Его продолжительность зависит от того, есть ли в этот день другие важные встречи и та самая фокусная работа. 👉Каждый день между 13 и 16 часами бронируется слот на обед. 👉1-1 с командой тоже переназначаются автоматически, если появляются более приоритетные встречи – причем учитываются календари обоих участников. Я очень кайфую – на менеджмент календаря уходит сильно меньше времени и даже в самые загруженные недели у меня остается время двигаться по важным проектам. Если еще не пробовали, очень рекомендую!

Месяц с AI-джуном в команде Весь прошлый год практически каждый день анонсировали какой-то новый прорывной продукт, использующий AI, а программирование хоронили еще чаще. Но даже на фоне всего этого информационного шума анонс Devin довольно сильно выделялся. В чем суть – это полноценный AI-агент, которому доступны все нужные разработчику инструменты: браузер, IDE, консоль. Все общение проходит через Slack, где вы просто просите решить какую-то задачу, а Devin асинхронно решает ее, приходит за уточнениями и рассказывает о статусе. Короче говоря, именно тот AI, которого мы все ждали! На деле все оказалось, конечно, совсем не так весело. Команда, попробовавшая поработать с ним в течение месяца на реальных задачах, скорее разочарована: 👉Из 20 делегированных ему проектов он справился с 3, завалил 14, и в еще 3 случаях задачу хоть и решил, но лучше бы это сделал человек. Вот тут, кстати, есть поисание всех задач. 👉Лучше всего ему даются задачи с небольшим скоупом и очень хорошо сформулированные. При этом пользы от делегирования их AI не очень много, потому что времени они не отнимут и у обычного инженера, осоьенно вооруженного нормальным AI ассистентом. 👉Он подвержен той самой проблеме 70%, о которой сейчас модно рассуждать: первые видимые результаты можно получить очень быстро, но докрутить до продакшн-состояния занимает столько времени, что проще все было сделать самому. Но я вообще AI-оптимист, и верю, что вот такие заметные провалы – необходимый шаг для того, чтобы получить реальный рабочий инструмент. Способности моделей продолжают быстро расти, UX вокруг взаимодействия с человеком, валидирующим результаты их работы, улучшается, они учатся использовать все больше и больше инструментов и опираться на все более сложный контекст. Еще год-два, и спокойно сможем делегировать агенту заполнение таймшитов в Jira и хождение на дейлики!

Что посмотреть на выходных Когда-то я очень сильно угорал по организации конференций. Началось все с небольших камерных митапов про iOS разработку, которые мы с командой собирали на мансарде Рамблера, продолжилось совместными с Онтико полноценными конфами AppsConf и ProductFest, а закончилось уже собственными онлайн-конференциями Podlodka Crew, когда мы в пике делали что-то около 40 мероприятий в год. Главная вещь, которую я за это время понял – конференции вообще непредсказуемы. Насколько успешно получится привлечь посетителей, с какими организационными проблемами предстоит столкнуться, какие спикеры исчезнут в самый последний момент – все эти вопросы будут не выходить из твоей головы до самого последнего момента. Поэтому к Андрею Смирнову, который решил за рекордно короткое время организовать оффлайновую конференцию про софт-скиллы, и дотащил проект до конца, я испытываю прямо огромное уважение. А вам очень рекомендую на выходных посмотреть доклады оттуда, большинство из них для менеджеров очень актуальны: 👉Алексей Пименов про управление изменениями с помощью карт гипотез. Хороший системный подход к тому, как расставлять приоритеты в изменениях, и выстраивать стратегию, опирающуюся на логику, а не интуицию. 👉Сережа Попов про доверие. Как оно проникает в коммуникации и помогает строить отношения в команде. 👉Глеб Михеев про то, как перестать со всеми сраться, и начать договариваться. Это вообще моя любимая тема, с которой мы начали новый год в этом канале! 👉Андрей Смирнов про то, как извлечь пользу из хаоса в компании. Согласен с основным посылом про то, что работа в компании, проходящей через такой этап – отличная возможность прокачать свои навыки и найти неочевидные пути для карьерного роста.

Баги – не проблема, а ее симптомы Когда мы в команде Kotlin решились серьезно взяться за улучшение качества проекта, одним из самых важных решений было следующее – для того, чтобы судить об успехе изменений, мы будем смотреть не только на тренды в изменении количества дефектов, но и на то, чтобы все серьезные баги проходили через root cause анализ, и выявленные корневые проблемы со временем бы закрывались. Это правда помогло, хоть было и сложно. Сегодняшняя статья как раз про это. Наличие багов в системе в первую очередь говорит о том, что что-то сломано в процессах или в коммуникации. Например: 👉До разработчика не дошли полные функциональные требования. Он просто не знал всех деталей того, как должна работать фича, поэтому произошло расхождение между ожиданиями и реальностью. 👉Не хватает понимания нефункциональных требований: какую нагрузку должен держать сервис, сколько времени может открываться какой-то экран, какой уровень безопасности требуется для хранения определенного типа данных. 👉Проблемы архитектуры и логики связки компонентов друг с другом. Чтобы явно видеть такие паттерны, нужно внедрять культуру анализа багов. Она может работать как в том формате, про который я рассказал – анализировать самые критичные проблемы, так и в другом – разбивать все баги за какое-то время на категории, и дальше относиться к расследованию причин появления каждой из категорий как к исследовательскому проекту.

Что происходит в индустрии – Developer Ecosystem Report 2024 На прошлой неделе вышел ежегодный отчет JetBrains по состоянию дел в индустрии разработки. Вот несколько интересных наблюдений: 👉Языки программирования, которые скорее всего покажут самый большой рост в будущем: TypeScript, Rust, Python и Go. Отдельно советую посмотреть на матрицу по тому, какие языки для каких задач используются, там интересно. 👉Десктопная разработка ого-го как жива. Разработчиков, которые разрабатывают что-то под десктоп, на 6% больше, чем мобильщиков. Я где-то год назад исследовал, чем же они занимаются – оказалось, что подавляющее большинство пилит внутренние приложения в огромных энтерпрайзах: бесчисленные ERP и CRM. 👉18% респондентов разрабатывают что-то, что попадает в категорию "AI фичей". 👉Большая тройка облаков теперь четверка. Alibaba Cloud сравнялся по доле рынка с Google Cloud, но до AWS, занимающего половину рынка, им всем еще очень далеко. 👉60% компаний пытаются измерять developer experience и productivity, причем в большинстве случаев за это отвечают тимлиды. Жаль, нет проверки корреляции реального счастья программистов с попыткой его измерить. 👉Самые популярные AI ассистенты: ChatGPT, GitHub Copilot, Google Gemini и JetBrains AI Assistant. Из интересного – в 11% компаниях вообще запрещены любые AI тулы. 👉В среднем на активности вокруг написания кода уходит 70-80% времени, а на митинги и чаты – 10-20%. Лучше, чем я ожидал! 👉Больше половины опрошенных говорят, что лэйоффы на них никак не сказались, треть затронуло по касательной, а реально потеряло работу 16%. 👉Написать код – наименее сложная из задач. Тяжелее всего понять, что конкретно хочет пользователь, и общаться с другими людьми.

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