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

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

Самые значимые факторы следующие:
1️⃣Удовлетворение от инфры и используемых инструментов
2️⃣Инновационность инфры и инструментов
3️⃣Качество кода в проекте
4️⃣Уровень техдолга в проекте
5️⃣Скорость кодревью

Причины инцидентов, о которых часто забывают

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

В статье приводится четыре категории, которые редко появляются в пост-мортемах, но являются истинными причинами многих проблем:

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

Про догфудинг

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

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

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

Root Cause анализ вреден

Root Cause Analysis – процесс анализа причин инцидента в поисках одной истинной, при предотвращении которой инцидента бы не случилось.

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

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

Как руководитель может обманывать команду

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

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

🌑Прямая ложь
🌒Невыполнение обещаний.
🌓Несоответствие действительности декларируемому.
🌔Несоответствие полномочий ответственности.
🌕Непрозрачность решений.

Премортемы

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

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

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

Помимо статьи по основной ссылке, я рекомендую почитать вот этот Twitter-тред про опыт проведения премортемов в Stripe.

Избавляемся от микроменеджеров

Давайте разберемся, микроменеджер ли вы. Держите чеклист:
☑️Вы не доверяете команде или конкретным участникам достижение целей
☑️Вам постоянно хочется проверять статус их работ или результатов
☑️Вам часто проще сделать что-то самому, чем доверять другим
☑️При постановке задачи вы фокусируетесь на том, как ее делать, а не на том, ради чего
☑️У вас не хватает времени на стратегические задачи
☑️При делегировании задач вы редко обсуждаете ожидания
☑️Вы не любите, когда команда достигает результатов способом отличным от того, который хотели вы
☑️Вам часто кажется, что вы теряете контроль

Помимо чеклиста и напоминания о том, почему микроменеджмент – это плохо, в статье приводится несколько прикладных советов про то, как очистить свои привычки и компанию от микроменеджмента.

Паттерны офисной политики

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

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

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

Влияние 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️⃣Роадмап никак не связан со стратегией, а содержит просто набор фичей.

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