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

Максим Шульга поделился в твиттере подборкой полезных ссылок про проведение хороших one-on-one встреч и своими мыслями по теме. Прикладываю сюда его материалы и добавляю несколько от себя.
🆕 О чем поговорить на самой первой встрече
💣 Развенчание мифов про большинство причин проведения 1-1
📖 Нереальные 132 вопроса для 1-1
🤭 Почему надо стремиться задавать неловкие вопросы
🚨 Признаки плохих 1-1
🔥 Подробный гайд по проведению 1-1 от Spotify

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

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

А вообще, аккуратнее с чистым скрамом, как и с любым другим карго-культом.

Давайте сегодня поговорим про платформенную разработку! Напоминаю, что это общий термин для обозначения инженерных команд, которые делают внутренние продукты для других разработчиков. Если 10 лет назад такие команды были только в самых крупных инженерных компаниях вроде Google и Netflix, то сейчас они появляются практически везде.

Я отвечал за платформенную разработку клиентсайда Авито в течение нескольких лет. Мы отвечали за создание инструментов, библиотек и окружения, которые снимали бы головную боль и уменьшали рутину у фронтендеров, бэкендеров и мобильных разработчиков. Основные особенности, которые определяют работу над платформой:
👻Каждый разработчик – сам себе продакт-менеджер, поэтому требуется обучение базовым продуктовым практикам;
🌩Платформенным командам нужно вкладываться в разработку стратегических долгостроев, выхлоп от которых виден не сразу. Поэтому конфликты с продуктовыми командами неизбежны;
🤔Частично из-за второго пункта, частично из-за технологически сложного домена, а частично из-за необходимости частых рисерчей, не каждой команде получается показывать видимые результаты. Из-за этого ее тимлиду регулярно приходится обосновывать ее ценность;

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

Я набрал себе несколько менеджерских книг для прочтения в ближайшие месяцы. Давайте такой уговор – я делюсь ими в канале, а вы:
1. Расскажете свой отзыв в комментариях, если читали что-то из них
2. Поделитесь своими планами по чтению

📚Мой список:
The Art of Action
Working Backwards
High Output Management
Шум. Несовершенство человеческих суждений
Азбука системного мышления

Всем привет.

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

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

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

Ребята из 🇺🇦, держитесь ❤️

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

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

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

В конце статьи вас ждет разбор терминов, которыми можно оперировать при разговоре с бизнесом.

Нашел небольшую заметку, которую не стал бы шарить, если бы она так сильно не попала прямо в меня. В чем суть – автор утверждает, что, вопреки частому мнению, для лида быть мягким / славным / добрым – это не так уж и плохо. Достаточно знать о возможных искажениях и бить себя по рукам, когда замечаешь за собой. Вот они:
🙊Избегание сложных разговоров
😶‍🌫️Чрезмерное смягчение речи из-за боязни обидеть чьи-то чувства
🐶Слишком сильная зависимость от одобрения
📏Низкая планка ожиданий от других людей

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

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

А кроме практики, она предлагает неплохой шаблон по донесению новостей до команды:
1️⃣Официальная позиция компании
2️⃣Конкретные факты, которые раскрывают эту позицию
3️⃣Ваша личная позиция и мнение
4️⃣Ваши следующие шаги в коммуникации

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

В сегодняшней статье роль тимлида рассматривается через призму двух таких моделей:
- Стадии развития команды (те самые storming-norming-performing)
- Шесть доменов лидерства

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

Недавно я выкладывал большой пост про платформенные команды. Судя по реакциям и обсуждениям в чате, тема вам зашла. Вот еще одна статья на тему, на этот раз из блога Мартина Фаулера. В ней дается несколько советов тем, кто строит у себя такую команду:
🧮Иметь стратегию с измеряемыми целями
💬Выяснять, что нужно вашим пользователям
🏁Онбордить пользователей максимально рано
🎤Ясно доносить техническое видение
💻Догфудить

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

Около 20% подписчиков канала еще не стали тимлидами, а только постепенно присматриваются к этой роли. Если вы еще не поняли, то к работе тимлида прилагабтся не только плюсы вроде чуть большей зарплаты, но и куча минусов. Статья неплохо проходится по части из них. Переходя из инженерной позиции в менеджерскую вы теряете:
⏱Большое количество времени на сфокусированную работу
💬Короткий цикл фидбэка о том, молодец ты или нет
⚡️Возможность уклоняться от конфликтов
💻Принятие технических решений
📚Развитие новых технических скиллов

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

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

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

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

Компания Documentat занимается именно этим: заказной разработкой документации и консалтингом в области документационных процессов.

Вот чем они могут вам помочь:

🔷 Возьмут написание документации на аутсорс (пользовательская документация, документация API/SDK, ГОСТ...) или дадут вам технического писателя в аутстаффинг.

🔷 Наведут порядок во внутренних и внешних базах знаний.

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

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

Услугами Documentat пользуются Сбер, 2ГИС, Miro, JetBrains, Yandex.Cloud, Avito, Timepad, Росплатформа и еще десятки российских IT-компаний.

Приходите за документацией!

documentat.io

[email protected]

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

Серия статей про то, как различные виды организационных зависимостей могут тормозить команды. Мне особенно понравилась последняя, про роль главного архитектора, где на понятном кейсе объясняется, почему такая роль – это зло.
1️⃣Зависимости внутри команды
2️⃣Зависимости вне команды
3️⃣Часть команд разбиты по фичам, часть по компонентам
4️⃣В сложном продукте все команды разбиты по компонентам
5️⃣Зависимость от одного человека снаружи команды

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