Teamlead Good Reads – тимлиды, архитектура, менеджмент людей и разработки
21.9K subscribers
295 photos
2 videos
1.47K links
Самые интересные статьи, видео и новости, связанные с управлением людьми, командами, разработкой и продуктами.

Размещение рекламы: @tanyasanovna

Папка лучших продуктовых каналов: https://t.me/addlist/YvmnHCHUp700Nzky
Download Telegram
Влияние ChatGPT на индустрию

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

Поделитесь в комментариях, как, по вашему мнению, развитие LLM (Large Language Models) повлияет на индустрию!
Подборка лучших постов за 2022 год

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

❤️Моя любимая статья года
Борьба с пожарами – признак плохого менеджера

💬Жизненный цикл сотрудника: найм, развитие, увольнение
Что мешает разработчикам проходить собеседования
Как нанимают VP of Engineering
Как проводить собеседования, не заставляя кандидатов писать код
Как организовать инженерную карьерную линейку
Фреймворк управления ростом в команде разработки
Обязан ли разработчик развиваться
Вред ежегодных performance review
Что делает разработчиков менее счастливыми
Неочевидные аспекты стоимости ухода сотрудника
Как отток людей из команды влияет на качество продукта

🤝Работа с людьми и стили менеджмента
Советы по менеджменту команды во времена нестабильности и кризиса
Что такое менеджерский долг
Почему многие руководители пытаются быть хорошими, и чем это опасно
Частые ошибки начинающих менеджеров
20 софт-скиллов, важных любому лидеру
Как правильно просить помощи
Как научиться лучше давать обратную связь
Советы по тому, как рассказывать команде плохие новости
Радикальная искренность
Быть тимлидом, а не казаться: обзор человечных практик и инструментов

💻Инженерные практики
Подборка материалов про то, как в разных компаниях подходят к тестированию
Культура документации в Google, Twitter, Spotify
Принципы Quality Engineering в GitLab
Вред от метрик разработки
Подробнейший гайд по инцидент-менеджменту
Закон Конвея

🔗Процессы разработки
Разбор RACI матриц как менеджерского инструмента
Три техники работы со стейкхолдерами
Осознанное затаскивание Agile практик в команду
Большой плейбук от GitLab по управлению распределенной командой
Фиксация соглашений в команде
Процессы в команде, которые позволяют оставить разработчиков в покое

📚Прочее
Фреймворки 3H и 5P для организации эффективных встреч
People>Business>Money как пирамида ценностей организации
Вопросы, которые помогут вам провести личную ретроспективу
Влияние рабочих конфликтов на выгорание
Как вернуться из СТО в инженеры
Ежемесячный email от CЕО как управленческий инструмент
Зачем нужны офисы в мире, склоняющемся к удаленке

Если у вас есть обратная связь по подбираемым в канал статьям, формату постов или чему угодно еще – пишите в комментарии!
Cascade of Attention-Deficit Teenagers

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

Править баги – нудно и скучно. Переписывать все с нуля – челлендж и интересно. Я такое видел регулярно, но не знал, что у такого поведения уже есть название – CADT, Cascade of Attention-Deficit Teenagers. Теперь и вы можете его использовать!
Если ИТ – это ваш конек, то Тинькофф ждет вас 23 января на катке в Москве!

Ледовый ИТ-квест, нетворкинг, дискуссии со спикерами в теплом шатре и многое другое. Вечер точно будет насыщенным и приятным. За коньки не беспокойтесь — их выдадут бесплатно.

Не медлите, регистрируйтесь сами и зовите коллег — будет весело!
Откладывайте технические решения

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

Конечно, ключевой вопрос здесь – как определить ту точку, в которой оттягивание принятия решения приносит вред, а не пользу. Универсального ответа нет, есть только несколько рекомендаций:

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

Все знают, как первые пробы автоматизации могут «уронить» мотивацию команды. Статья Юлы поможет перестать «кликать мышкой» и пересылать коллекции, и при этом безболезненно перейти на автоматизацию тестирования API. Здесь расскажут по шагам, как внедрить фреймворк, навести порядок в Jira, автоматизировать тестирование с учётом мультиплатформенности. Материал статьи призван помочь сгенерировать фреймворк и обучить команду, которая может автоматизировать без знания кода и уничтожить рутину бесконечного «кликанья» мышкой.

Читать статью
О чем стоит рассказывать вашему менеджеру

Когда-то ваш менеджер решил открыть вакансию, на которую вас и наняли. Он сделал это потому, что у него самого не хватало рук и фокуса, и он готов был делегировать часть ответственности отдельному человеку. Чем больше у менеджера зона ответственности, тем больше кусков из нее приходится делегировать.

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

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

В статье разбирается несколько областей, о которых ваш менеджер скорее всего не знает, и о которых стоит его проактивно держать в курсе:

*️⃣Что замедляет вас, и решеник каких проблем могло бы помочь команде двигаться быстрее
*️⃣Ваш прогресс по ключевым проектам
*️⃣Основные технические риски
*️⃣Ваши текущие цели
*️⃣Проблемы, которые требуется эскалировать
*️⃣Чем вы занимаетесь помимо основных задач
Четыре признака плохих роадмапов

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

1️⃣Топ-менеджмент в изоляции формирует роадмап и после этого отдает его на выполнение продуктовым командам.
2️⃣Роадмап содержит в себе список фичей, которые надо разработать, но ничего не говорит о целевых результатах, ради которых эти фичи делаются.
3️⃣Роадмап не учитывает зависимости между командами и необходимость совместной работы для реализации определенной фичи.
4️⃣Роадмап никак не связан со стратегией, а содержит просто набор фичей.

Автор еще предлагает несколько очевидных советов, как улучшить ситуацию («задавайте вопросы», «предлагайте сфокусироваться на результатах»). Но в большинстве случаев лучще рассматривать наличие таких проблем как сигнал к тому, что стоит поискать другое место работы – лечить топ-менеджмент сложное и очень неблагодарное занятие.
Как получить работу технического топ-менеджера

- Работу СТО проще получить не благодаря внутреннему повышению, а поменяв компанию. Обычно эта роль уже занята, освобождается она довольно редко, и расчитывать на этот шанс довольно бесполезно.
- Вакансии СТО довольно редко попадают на доски вакансий. Кандидатов обычно ищут с помощью нетворкинга, или привлекая рекрутеров, специализирующихся на executive должностях.
- Процесс интервью будет хаотичным и в каждой компании своим. Иногда вас будут собеседовать люди с техническим бэкграундом, иногда без него. Успех зависит больше от восприятия того, насколько вы подходите компании и своим новым коллегам, а не от объективных критериев.
- Чтобы понять, за какую компенсацию торговаться, лучше всего пообщаться с людьми, занимающими схожие позиции в аналогичных компаниях.
- До принятия оффера обязательно побольше пообщайтесь с СЕО, чтобы оценить, насколько вы хотите с ним работать, попросите финансистов рассказать про текущее финансовое положение компании, и узнайте, почему увольняли прошлых топ менеджеров.
Слёрм приглашает на бесплатную стрим-конференцию «Школа мониторинга» с 17 по 19 января

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

Что в программе?

Стрим разбит на три секции:

1️⃣Философия мониторинга — будем говорить про observability и процессы в компании.

2️⃣Техническая секция — про инструменты, подходы и кейсы.

3️⃣Бизнес-секция — про извлечение ценности из мониторинга: метрики, показатели, решения на основе данных.

Эргономичный мониторинг, удобная работа с алертами, мультитенанси мониторинг, кастомизация шаблонов для Zabbix, оценка ущерба инцидентов в деньгах — это только малая часть тем школы.

Онлайн-трансляции пройдут 17–19 января с 14:00 до 19:00.

Регистрация
Книга «Software Engineering at Google» стала бесплатной

SWE at Google – довольно популярная книга про хорошие инженерные практики, применяемые на проектах большого масштаба. Я сам до сих пор ее так и не прочитал, но от друзей слышал много хороших рекомендаций. Вон, даже Брагилевский советует!

Так в чем новость – авторы книги решили сделать ее бесплатной, так что можете посмотреть расписание и прочитать любую главу.
Выпуск Подлодки про онбординг

Записали выпуск с Женей Антоновым про то, какие частые косяки встречаются в процессе онбординга новых сотрудников и как можно дешево построить достаточно хороший процесс. Ближе к концу выпуска я рассказал про несколько интересных приемов, которые сам использую в онбординге в свою текущую команду:

- Notion доска с кучей задач на испыталку, которые помогают погрузиться в компанию, процессы и продукт.
- Внутренний видеокурс про то, как в техническом плане устроены разные подсистемы Kotlin, и значения слов из внутреннего словаря команды.
Воркшоп по выстраиванию процесса развития в команде

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

Илья расскажет:
🔸Почему важно заниматься развитием сотрудников и в чем здесь сложности;
🔸Как сделать процесс развития сотрудников системным и надежным;
🔸Какие бывают подходы к развитию сотрудников, их плюсы и минусы;
🔸Примеры инструментов, помогающих трекать эффективность сотрудников и их следование PDP

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

🗓26 января, 19:00 по Москве
👉
Регистрация
Эволюция биллинга в Додо

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

Любая задача руководителя в какой-то момент утыкается в навыки коммуникации – выяснение потребностей и намерений коллег, согласования со стейкхолдерами, разбор обратной связи со своей командой, отказ делать чьи-то задачи, не разрушая с ними отношения. Если среди ваших планов по развитию есть галочка “прокачать коммуникации”, то приходите на открытый вебинар «Как вырасти в IT с помощью навыков коммуникации», в котором на рабочих кейсах будет разбираться:

*️⃣Как выяснять потребности и намерения коллег
*️⃣Как доносить свою позицию и обозначать личные границы
*️⃣Как давать экологичную обратную связь
*️⃣Как отвечать на манипуляции, не вызывая лишнюю агрессию
*️⃣Как эффективно коммуницировать со стейкхолдерами и учитывать разные интересы

📆Дата: 24 января в 18:30
👉Регистрация
Story Points Revisited

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

👀Сторипойнты выглядят очень удобной метрикой для того, чтобы сравнивать производительность разных команд друг с другом. Это в корне неверная идея, которая не ведет к полезному исходу.
📆Наличие оценки задачи приводит к тому, что эту оценку сравнивают с итоговым потраченным временем, и на основе этого делают выводы о предсказательной способности команды. Вместо того, чтобы фокусироваться на выборе самых важных задач для разработки и декомпозиции их на небольшие кусочки, менеджеры требуют от команды повышения качества оценки ей сроков. В большинстве случаев это мусорная работа, которая не несет пользы.
👊Сторипойнты ведут к давлению на команду, от которой будут регулярно требовать наращивать их количество в каждой итерации. Сроки будут давить на команду, она будет ускоряться за счет понижения качества, а итоговый продукт будет получаться плохим. Зато сторипойнтов больше съели!
🤔Сторипойнты, как и любая другая оценка сроков, дают только иллюзию контроля и предсказуемости. На самом деле в сложных инженерных проектах никто не может предсказать, сколько займет та или иная задача.
✈️ Программы миграции работают даже в сложные времена

Relocode - это консалтинговое агентство, которое помогает получить ВНЖ стартапам и удалёнщикам digital nomad, а также занимается IT-визами.

У компании более 7 лет опыта в сфере релокации. Если вы мечтаете переехать в Великобританию один/с семьёй, то Global Talent Visa создана именно для вас.

❗️Её можно получить за 4 месяца, а ВНЖ дают сразу на 3-5 лет

Relocode берёт на себя все работы по ВНЖ: от оценки шансов до сопровождения после релокации.

Виза Global Talent:

📍подходит IT и бизнес специалистам в IT компаниях (product/project-менеджер и др.);
📍не требует знания английского и готового бизнес-проекта;
📍ведёт к ПМЖ и гражданству;
📍имеет высокий процент одобрений.

Не нужно быть талантом, чтобы получить Global Talent Visa. Достаточно быть хорошим специалистом, а с правильной презентацией поможет Relocode.

Подписывайтесь на Telegram-канал Relocode, где регулярно публикуют полезную информацию о релокации: https://t.me/relocode
Ошибки в работе с Architecture Decision Records

Architecture Decision Records – практика записи всех ключевых технических решений, принимаемых командой, с объяснением их контекста. Про какие ошибки идет речь в треде:

📚Держать ADR отдельно от кода, к которому они относятся, описывая их в виде документов и презентаций. Из-за этого их реже будут открывать, появятся дополнительные барьеры для их заведения, и все превратится в бюрократию.
🔀Выстраивать отдельный процесс по написанию и оформлению ADR. Проще не относиться к этому как к отдельному этапу разработки, а вести ADR по ходу обсуждений, сразу же записывая ключевые идеи принятого решения. ADR должны быть интегрированы в процесс разработки, а не отделены от него.
📝Вместо описания принятого решения слишком много времени тратить на перечисление возможных альтернатив. Из-за этого объем ADR раздувается, их сложнее читать, и меньше фокуса уделяется самому важному – принятому командой решению.

В треде еще много интересных обсуждений про другие ошибки в ведении ADR и подходящую организацию для их хранения, тоже советую почитать!
Частые примеры менеджерского долга

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

*️⃣Слишком мелкое дробление команд, при котором появляются тимлиды с 1-2 сотрудниками
*️⃣Команды, состоящие из джуниоров
*️⃣Инфляция тайтлов сеньоров/стаффов
*️⃣Инфляция компенсаций
Хотите продать идею – напишите документ

1️⃣Изложение своих идей в письменной форме позволяет увидеть пробелы в логике, которые вы можете не замечать, прокручивая их в голове, или обсуждая с кем-то вслух. У вас есть больше времени и возможностей подобрать самые убедительные аргументы, вместо тех, которые первыми приходят в голову.
2️⃣Сложно заставить людей сфокусированно слушать тебя, особенно в течение продолжительного времени. С документом работать гораздо проще – каждый человек может прочитать его в режиме и темпе, удобном для него.
3️⃣В отличие от живого обсуждения, даже с записанным видео, документы обычно живут намного больше. Их гораздо проще проиндексировать и найти спустя несколько лет.
4️⃣Часто бывает так, что люди серьезнее относятся к идеям, изложенным в письменном виде.
5️⃣Человеческая память очень ненадежная. Спустя несколько лет вы скорее всего забудете, почему приняли то или иное решение. А бумага все помнит.