Видеообзор исследования тимлидов

Пару недель назад я писал, что подумываю завести блог на YouTube. Так вот, оно наконец-то произошло! Я решил начать с простого, и записал короткий видеообзор интересных фактов из исследования. Заходите, смотрите (обязательно до конца, чтобы алгоритмы обучились), и подписывайтесь на канал! Очень постараюсь в ближайшие пару недель записать что-нибудь еще.

Несколько советов по онбордингу в проект

📖Начните с бэкграунда. Расскажите, как появилась ваша команда, какую проблему решает проект.
➡️Объясняйте архитектуру не по компонентам системы, а по user journey. Сторителлинг поможет выстроить в голове у человека связную картинку того, что и зачем происходит в проекте.
🎨Нарисуйте простую схему взаимодействия ваших компонентов друг с другом. Она очень упростит объяснения и ее можно будет переиспользовать и в будущем.

Зачем командам нужны тимлиды, и можно ли обойтись без них

6 апреля на YouTube Подлодки пройдет батл, в рамках которого будут разбираться, насколько различным командам нужны тимлиды, в чем состоят их главные обязанности, и возможны ли полностью автономные команды. Спикеров специально подобрали с полярными взглядами и бэкграундом: Алексей Шаграев, Барух Садогурский, Влад Козуля, Георгий Могелашвили.

Подключайтесь к трансляции, подливайте масла в огонь, разжигайте холивар и делитесь своим опытом и кейсами!

📆Дата: 6 апреля, 19:00 по Москве

Тимлид как щит для команды

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

Автор статьи предлагает ограничивать функции щита в общем виде до следующего:

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

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

Новость для системных аналитиков!
Тинькофф ищет опытных специалистов, чтобы создавать лучшие финтех-решения на рынке. Спойлер: задачи сложные, но интересные. Посмотреть и откликнуться можно тут: https://v.tinkoff.ru/prof_sa

Архитекторы – это антипаттерн

Замечательная разжигающая статья. Если вам лень читать, вот основные аргументы:

😷 У архитекторов нет шкуры в игре. Они принимают решения, а реализуют за них другие люди. Они не обучаются на последствиях решений.
😞 Если в явном виде назвать кого-то ответственным за архитектуру, остальные инженеры станут уделять ей меньше внимания, и как результат мы получим более слабых разработчиков и хуже спроектированные системы.
😡 Так как архитекторы удалены от настоящей разработки, они могут не понимать всего контекста и сравнительную важность существующих проблем. Как результат – они могут тормозить прогресс, а не двигать его.
👴 Скилы архитекторов могут быстро устаревать, потому что, опять же, они перестают писать код каждый день, считая это менее важной задачей.

А вот что автор предлагает делать, чтобы проблема горела не так ярко:

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

Научпоп конференция от Wildberries

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

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

📆Дата: 7 апреля
🗺️Место: Москва, Технопарк “Сколково”, вход свободный по регистрации

Скрытая стоимость архитектурной сложности

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

🐞Разница в плотности дефектов в проектах с высокой архитектурной сложностью и с низкой составляет целых три раза.
💪Производительность разработки падает на 50%.
👋Вероятность текучки в проектах с неоправданно сложной архитектурой повышается в 10 раз.

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

Как определить, стоит ли инженеру расти в тимлида

Про золотой стандарт нашей индустрии в виде «подойти к самому сильному разработчику в команде, похлопать по плечу и назвать новым руководителем» знают все – кто-то прошел через него сам, кто-то смотрел сбоку, а у кого-то был как раз такой руководитель. В статье разбирается более разумный способ определения, готов ли разработчик расти в тимлиды. Если не вдаваться в детали, то автор советует такой алгоритм:

1️⃣Посмотреть, умеет ли кандидат строить процессы, потому что в этом и будет заключаться большая часть его работы.
2️⃣Посмотреть, что у него с мотивацией людей – есть ли шанс, что он сможет повести людей за собой, и насколько велик риск, что команда с ним распадется.
3️⃣Оценить, насколько сам человек готов переключиться с инженерной работой на руководство.
4️⃣Делает ли он уже сам какие-то шаги в сторону менеджерской работы – берет на себя ответственность за крупные проекты, что-то читает по теме.
5️⃣Насколько он вникает в суть того, что и зачем делает. Действует ли строго в рамках выданной задачи, или ориентирован на результат.
6️⃣Насколько он открыт и конструктивно говорит о проблемах.

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

Согласно отчету McKinsey, автоматизация HR-процессов в найме, сокращает время на подбор сотрудников на 40%, а автоматизация обучения и развития, повышает эффективность обучения на 50%.

Но так ли все просто, ведь для успешной автоматизации HR-процессов необходимо учитывать множество факторов?

Обсудят 13 апреля в 18:00 на онлайн-встрече с OTUS, где разберутся в преимуществах для бизнеса от автоматизации HR-процессов и насколько они существенны для его развития.

В рамках встречи вы узнаете, как:
– Оценивать уровень автоматизации HR процессов в компании
– Формировать требования при внедрении новых HR решений
– Подбирать метрики и процессные KPI для каждого этапа жизненного цикла сотрудника
– Идентифицировать, какие риски стоит учитывать при автоматизации HR и разработке HR аналитики

👉Регистрируйтесь https://otus.pw/yuhw/ и приглашайте коллег!

Реклама. Информация о рекламодателе на сайте otus.ru

Подборка рекомендованных книг из недавнего исследования тимлидов

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

Так вот, это оказалось идеальным кейсом применения ChatGPT:

✍️Сначала я попросил выделить названия существующих книг и их авторов из сырых ответов.
🇬🇧Затем – использовать оригинальные англоязычные названия.
🔗А в финале – обогатить список ссылками на Amazon на все книги (для скептиков – в промпте просил не вставлять ссылку, если LLM не уверена в ней).

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

А сам список книг классный, разбирайте!

Polyglot – автоматическая локализация приложений

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

1️⃣Добавляете один шаг в конфигурацию проекта
2️⃣Запускаете сборку, и мгновенно получаете машинный перевод (не абы какой, а сделанный с помощью ChatGPT с использованием контекста, где собственно текст будет использоваться). На данном шаге вы потратили 10 минут и уже можно смело отправлять в App Store.
3️⃣При последующих сборках переводы будут корректироваться и улучшаться по мере того, как переводчики сервиса их проверяют.

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

Диаграмма Исикавы для Root-Cause анализа

Представьте – вы обсуждаете какую-то проблему с группой людей, у каждого из которых есть сильное мнение про ее причины. Один из способов организовать обсуждение и получить на выходе понятный артефакт – использовать диаграмму Исикавы, она же – «рыбьи кости».

Флоу работы с ней максимально простой:

✍️Выписываете проблему и рисуете линию. Это – «позвоночник» диаграммы.
✍️По диагонали выписываете основные факторы, повлиявшие на проблему. Это «кости» скелета.
✍️Для каждого из факторов определяете основные причины, которые повлияли на его появление. Их снова записываете по горизонтали, получая «кости» поменьше.

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

Новые крутые вакансии в Авито. Ребята ищут тимлидов разработки в четыре команды:

➡️ Incident & Problem Management
➡️ Support Systems
➡️ Авито Работы
➡️ Новостроек в Авито Недвижимости

Вот что предлагают:

• Работа удалённо или в московском офисе на Белорусской;
• Прозрачная система бонусов и премий;
• Страховка со стоматологией, в офисе ведут приём терапевт, психолог и массажист;
• Мощное железо, дополнительные мониторы и всё, что нужно для продуктивной работы;
• Личный бюджет на обучение, который можно тратить на книги, курсы и конференции.

За подробностями переходим по ссылкам, и если мэтч — не откладываем и откликаемся!

Стажировки как способ найма

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

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

Как LLM повлияют на работу с кодом

Большую часть прошлой недели я провел на KotlinConf. Так вот, в половине случаев все разговоры спустя пять минут после начала сводились к обсуждению нейронок и того, как они влияют на нашу ежедневную работу. Кажется, что сейчас самое большое ограничение – это приватность данных. Все крупные компании строго запрещают использовать облачные сервисы, ожидая появления on-premise версий.

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

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

Руководители из Яндекса с опытом от 5 лет сделали тест для коллег-управленцев: 20 вопросов, чтобы проверить свои навыки и наметить пути развития. Тест займет около 10 минут. В конце — характеристика сильных сторон и персональные рекомендации по точкам роста: ссылки на статьи, видео, литературу.

Обновленный карьерный фреймворк от Dropbox

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

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

Почитайте, и расскажите в комментариях, что понравилось и не понравилось в нем.