Как создавать дисфункции, пытаясь их устранить

Ох, какая же вредная статья! Начинается все клево – автор рассказывает про то, что на все проблемы обязательно надо смотреть системно, не бросаться тушить пожары сломя голову, а искать взаимосвязи в системах. А решение – составлять специальные Dysfunction Maps.

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

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

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

Признаки хорошей стратегии

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

А вообще, лучше всего прочитайте "Good strategy, bad strategy" Румельта. Не расскажет, как именно надо составлять стратегию, но хорошо натренирует нейроночку на то, чтобы распознавать плохую.

Как организовать one day offer event

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

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

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

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

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

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

Как продавать техдолг

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

Помимо этого, в статье есть еще несколько советов по продаже техдолга:

👉Обосновывая инвестиции во внутренний тулинг, сразу продумайте ответы на вопросы про ожидаемый возврат инвестиций и то, как вы будете оценивать адопшн. Можно посмотреть на фреймворк продаж MEDDIC.
👉Инвестиции в отказоустойчивость проще всего обосновать через SLO.
👉Инвестиции в переписывание кода обосновывайте через оценку того, когда вы сможете доставить результаты рефакторинга до прода, улучшение читаемости и поддерживаемости кодовой базы, экономию времени или решение проблем ближайшего будущего.

Ошибки в переговорах о зарплате

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

1️⃣Раскрывать рекрутеру заранее подробную информацию о ваших ожиданиях и текущем состоянии дел: компенсации на работе и других собеседованиях.
2️⃣Вступать в переговоры за оффер, не будучи к ним полностью готовым. Например, не имея на руках сразу несколько офферов от разных компаний, и не понимая своей итоговой цены на рынке.

Проблемы лишних абстракций во фреймворках

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

Ключевая цитата: "Frustration happens when the developer is unable to use their existing skills or feels disproportionally punished for doing it their way instead of your way".

Product Map – карта всего, что надо знать продактам

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

Из хороших альтернатив могу еще посоветовать вот эту карту от автора Product Architecture Framework.

Что отличает хорошие решения от плохих

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

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

Помимо этих тезисов большая часть статьи как раз про советы по повышению качества процесса и анализа.

SRE принципы для CI/CD пайплайна

Хороший подход к определению ожиданий к стабильности CI/CD пайплайна с использованием хорошо известных SRE практик:

⭐️Service Level Objectives (SLOs): какой уровень стабильности гарантирован.
📊Service Level Indicators (SLIs): как именно трекается уровень стабильности.
🧳Error Budgets: как долго пайплайн может не отвечать требованиям SLO.

Пример:

⭐️SLO: Каждый коммит должен быть протестирован в течение 5 минут после пуша.
📊SLI: Общее время прогона билда.
🧳Error budget: 40 билдов, время прогона которых заняло больше 5 минут, на протяжении 4 недель.

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

Пол и потолок в перфомансе

У баскетбольных аналитиков есть модель описания перфоманса игроков, основанная на их граничных показателях:

👉High floor, high ceiling: Самые лучшие игроки, которые показывают отличный результат и в хорошие дни, и в плохие.
👉High floor, low ceiling: надежные игроки с предсказуемо средним перфомансом.
👉Low floor, high ceiling: ненадежные игроки с проблесками гениальности. Могут сыграть как отвратительно плохо, так и слишком хорошо.

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

Что уменьшает продуктивность разработчиков

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

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

Бреслав и Ложечкин про делегирование

Новый выпуск моего любимого (хоть я и немного аффилированное лицо) подкаста про тимлидство! Андрей Бреслав, Александр Ложечкин и приглашенный гость Мария Аникина обсуждают все про делегирование: зачем оно нужно, кому и что можно делегировать, и что делать, если делегировать не получается.

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

Как менеджеры могут влиять на мотивацию

Никак. Мотивация – это внутренняя сила человека, которая формируется в течение всей его жизни. Поменять то, что драйвит человека, практически невозможная задача. "Замотивировать" его – тоже. Вместо этого менеджер может:

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

Холивары о собеседованиях

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

Так вот, расскажите в комментариях, а как все-таки правильно нанимать людей!

Подход к онбордингу джунов

Когда New Relic выросли до 60 команд, они решили активнее нанимать джунов. Вот как у них выглядел онбординг:

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

Фишинговые письма для проверки поведения людей

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

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

Фидбэком не решить проблему недостатка скиллов

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

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

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