4 записи с тегом "cto"

Отчёт Stripe «Developer Coefficient» оценил, что компании по всему миру теряют более $300 миллиардов ежегодно из-за неэффективности разработчиков — в значительной мере из-за недоукомплектованных команд, борющихся с техническим долгом вместо выпуска фич. Вам нужно больше инженеров. Команда перегружена, дедлайны сдвигаются, технический долг растёт. Вы это чувствуете интуитивно. Но вашему CFO плевать на вашу интуицию — его волнуют цифры, ROI и риски. Большинство запросов на штат проваливаются не потому, что они неправильные. А потому, что аргументируются на неправильном языке.

По оценкам Gartner, менее 30% инженерных лидеров имеют эффективную видимость реальной производительности своей команды. У каждого CTO есть дашборд. Большинство из них бесполезны. Они или забиты 47 графиками, которые никто не читает, или содержат один график velocity, который ничего не говорит. Хороший дашборд CTO отвечает на три вопроса: доставляем ли мы? Здоровы ли мы? Улучшаемся ли мы? Вот как построить такой, который реально работает.

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

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

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

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