Teamlead Good Reads – тимлиды, архитектура, менеджмент людей и разработки

2022-04-23 10:14:06 Какие-то компании очень внимательно подходят к вопросу инфраструктурных костов, а какие-то вообще не следят за затрачиваемыми деньгами. В статье разбирается, как к инфраструктурным расходам стоит относиться на разных стадиях развития компании:
На ранней – можно вообще не заморачиваться. Ваша задача – придумать продукт, нужный пользователям, и экономия на костах сильно картину не поменяет.
Период роста. Здесь важно смотреть на то, какой процент от переменных расходов занимает инфра. Если отношение затрат на инфру к доходам не растет со временем, то все нормально.
Когда рост прекратился. Вот тут уже пора резать косты, смотря на два показателя: расходы на каждого инженера, расходы на количество продуктовых операций (поиски, покупки).

Помимо этой классификации, в статье приводятся полезные инструменты по оценке расходов и советы, как их сократить. Открыть/Комментировать

2022-04-22 10:25:15 У команды inDriver была проблема – кода много, проверок качества много, а автотестов и тех, кто их умеет писать – мало. Чтобы решить проблему, они начали обучать автоматизации ручных тестировщиков. За несколько этапов реализации этой идеи они собрали кучу очень интересных граблей. Если вас посещают идеи сделать свой внутренний курс по чему угодно, обязательно почитайте – вы точно натолкнетесь на что-то подобное!

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

2022-04-21 10:15:13 One-on-one встречи – не панацея. Хороший менеджер должен работать не только над выстраиванием связей между собой и каждым отдельным сотрудником, но и между всеми членами команды. Кто-то может лучше вас обучать техническим деталям, кто-то – поддерживать в сложных ситуациях. Держите небольшую заметку про то, как достичь таких отношений в команде. Открыть/Комментировать

2022-04-20 10:05:10 Приоритизация – это не просто аналитический процесс. Очень часто к любым попыткам разложить задачи по RICE, Kano или другим фреймворкам, начинает примешиваться политика. В статье собрали подходы, которые помогают и не работают в таких случаях:
Просить стейкхолдеров коллективно приоритизировать длинный список задач
Обучать всех алгоритмам приоритизации и процессам разработки
Настраивать модельку в спредшите и ожидать, что она все объяснит
В явном виде распределить ресурсы по нескольким верхнеуровневым категориям
Собирать у каждого стейкхолдера короткий список их ключевых потребностей
Использовать разбитие задач по категориям «сейчас»/«следующая»/«никогда»
Заранее продумывать возможности аутсорса части работы Открыть/Комментировать

2022-04-19 09:50:09 Пять лет назад мы с Виталиком Леоновым работали вместе в Авито. Я руководил мобильной разработкой, а он – бэкендом. Виталик – крутой инженер и технический руководитель, у которого очень многому можно научиться. Сейчас он – СТО в Skyеng, а параллельно ведет Telegram-канал "Тимлид Леонид", в котором делится разными тимлидовыми практиками и результатами их внедрения. Вот мои любимые посты:
Time to productivity новичков: замеряем по десятому пулл реквесту
Затраты на инфраструктуру в разных типах российских компаний
Как СТО вкатиться в новую компанию
Эволюция тимлида

Подписывайтесь, Виталик фигни не посоветует! Открыть/Комментировать

2022-04-18 09:40:11 Смысл существования тимлида в том, чтобы обеспечивать непрерывность производства результатов своей командой. С непрерывностью с точки зрения конкретных процессов написания, поставки и обслуживания кода мы за последние десятилетия более-менее разобрались. А вот с непрерывностью с точки зрения наличия и сохранения людей в команде все намного хуже.

Виталий Шароватов, админ нашего чата, поделился практиками того, как тимлиду можно влиять на эту непрерывность через найм, культуру и рабочие отношения. Открыть/Комментировать

2022-04-17 10:11:01 Каждый день я стараюсь публиковать хотя бы один классный и полезный материал про тимлидство. За месяц их набегает несколько десятков, и ориентироваться в них не всегда легко. Чтобы облегчить вам задачу, раз в месяц я публикую дайджест самых популярных постов, разбитых на категории.

Если у вас есть предложения по тому, как развивать канал и какие новые форматы попробовать – пишите в комментариях!

Развитие тимлида
Как развивать свое продуктовое чутье
Как принципы помогают тимлиду отстраивать процессы в команде
Антипаттерны поведения тимлида

Работа над качеством
12 принципов обеспечения качества в GitLab
Чем технический долг отличается от технического хлама

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

Работа с людьми
Как оптимизировать время, которое нужно новичку в команде, чтобы вкатиться
Лоу-перформеры не всегда мало работают, а иногда просто делают не то
Что такое микроконтекст, и как его избежать, чтобы команда была продуктивной
Причины, по которым сеньоры не могут раскрыться в вашей команде

Рекомендации по книгам
Цель, Элияху Голдратт
Цель 2, Элияху Голдратт
Теория ограничений Голдратта, Уильям Детмер
Принципы, Рэй Далио

Если дайджест вам понравился – ставьте , и . Благодаря этому я пойму, что собирал его не зря!

#digest Открыть/Комментировать

2022-04-16 10:30:42 Все знания, которые нужно получить новичку во время онбординга, можно разделить на две категории:
Known unknowns
Unknown unknows

Первая категория – это вещи, о которых вам известно, что вы их не знаете. Например, новая команда использует Vue.js, а вы до этого работали только с React. Вам понятно, что надо изучить.

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

Задача хорошего процесса онбординга – выводить вещи из второй категории в первую, а оттуда – в разряд known knowns. В статье предлагается неплохой подход к его организации, разделяющий все погружение на 4 стадии: первые 30, 60, 90 и 150 дней, и дающий критерии оценки успуха каждой. Открыть/Комментировать

2022-04-15 18:17:53 Открыть/Комментировать

2022-04-15 18:16:38 Тестовые задания могут быть не так плохи, когда они хорошо организованы с процессной и технической стороны, не требуют от кандидата больших временных вложений и приближены к реальным задачам. Прочитайте, как этот этап интервью организован у GitHub – там все очень круто! Открыть/Комментировать