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

Шесть признаков перфекциониста:
- Страх провала
- Подход «все или ничего»
- Не умеет делегировать
- Часто прокрастинирует
- Слишком сильно сфокусирован на результате
- Тяжело принимает конструктивную критику

Подробный рассказ про эти шесть признаков и подходы к управлению такими людьми

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

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

Сейчас онбординг у меня состоит из следующих больших кусков:
📹 Видеокурс, где простым языком объясняется устройство различных компонентов: компилятора, IDE, билд тудтнга и других штук
🎛 Trello-доска с задачами на погружение в компанию, разными материалами для изучения и ключевыми людьми, с которыми нужно познакомиться
🎯 Цели на период онбординга, которые составляются вместе с новичком спустя пару недель работы
🤝 Наличие ментора, который сопровождает новичка в процессе онбординга

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

Интересный взгляд на то, почему в большинстве организаций 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]