36 записей с тегом "leadership"

Опросы Stack Overflow Developer Survey неизменно показывают, что автономия и доверие разработчиков — одни из сильнейших предикторов удовлетворённости работой, и всё же большинство внедрений метрик полностью это игнорируют. С одной стороны — руководители, которые хотят понимать и улучшать работу команд. С другой — разработчики, которые слышат «мы внедряем метрики» и сразу думают «Большой Брат». У обеих сторон есть обоснованные опасения. Вопрос не в том, измерять или нет, а в том, как измерять, не разрушая культуру, которую вы пытаетесь улучшить.

Как документируют Matthew Skelton и Manuel Pais в Team Topologies, коммуникационный overhead между инженерами растёт квадратично: при 10 людях — 45 потенциальных каналов связи; при 100 — почти 5 000. При 10 инженерах вы знаете каждого. Слышите каждый разговор. Ревьюите большинство PR. Всё работает — потому что вы сами клей, скрепляющий систему. При 100 это невозможно. CTO, который пытается управлять 100 инженерами так же, как управлял 10, выгорит, создаст узкие места и будет наблюдать, как падает качество. Переход от 10 к 100 — самый сложный организационный вызов для CTO стартапа, и данные — единственный способ пройти его, не потеряв рассудок.

Исследования McKinsey по инженерной эффективности показали, что у самых высокопроизводительных организаций есть одна общая черта: их инженерные цели явно связаны с бизнес-результатами. И всё же большинство инженерных команд пишут OKR вроде «Улучшить качество кода» с key result «Увеличить покрытие тестами до 80%». Это не OKR. Это задача с числом рядом. Хорошие инженерные OKR связывают техническую работу с бизнес-результатами, а правильные метрики делают их реально измеримыми.

У каждого CTO был такой разговор. Вы заходите в кабинет CEO и говорите: «Нам нужно потратить следующий квартал на рефакторинг». CEO спрашивает: «Какая бизнес-ценность?» Вы пытаетесь ответить в терминах, не включающих слова «архитектура», «связанность» или «внедрение зависимостей». DORA State of DevOps Reports последовательно показывают, что команды с большим техническим долгом деплоят ~50% реже и имеют ~2-3x более высокий change failure rate.

CEO не ошибается, задавая этот вопрос. Он не против инженерии. Он просто хочет понять инвестицию в бизнес-терминах. И именно здесь большинство CTO терпят неудачу — не потому что плохо коммуницируют, а потому что у них нет нужных данных.

Вот как это исправить.

Самый распространённый страх инженеров по поводу трекинга активности прост: «Мой руководитель использует эти данные против меня.»

И они имеют основания беспокоиться. Многие организации внедряли «метрики продуктивности» как кнут — выявляя, кто пишет меньше всего кода, кто коммитит меньше всего строк, кто логирует меньше всего часов. Результат предсказуем: разработчики накручивают метрики, нарастает обида, лучшие уходят, а оставшаяся команда оптимизирует видимость занятости вместо реальной эффективности.

Есть лучший путь. Данные могут быть инструментом позитивного подкрепления — и это гораздо эффективнее.

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

В реальности рейтинги — самая поляризующая функция геймификации в инженерии. Self-Determination Theory (Деси и Райан) предупреждает, что внешние системы ранжирования могут подрывать внутреннюю мотивацию, но исследования также показывают, что грамотно спроектированные системы признания повышают вовлечённость. Если сделать правильно, рейтинги создают здоровую вовлечённость и видимость. Если неправильно — тревогу, накрутку и обиду.

Вот как сделать правильно.