Ваш сениор-разработчик назначен на три проекта. Вы полагаете, что он отдаёт каждому проекту треть времени. Джеральд Вайнберг посчитал реальную математику в Quality Software Management (1992): при трёх параллельных проектах каждый получает около 20% времени разработчика — а оставшиеся 40% испаряются в виде накладных расходов на переключение контекста.

Это не предположение. Это хорошо задокументированный когнитивный феномен, подтверждённый данными нашей платформы по B2B-инженерным командам и согласующийся с исследованиями Глории Марк из UC Irvine, показавшими 23 минуты восстановления после каждого прерывания. Переключение контекста — одна из самых дорогих невидимых затрат в разработке ПО.

Согласно исследованиям McKinsey о продуктивности разработчиков, инженеры тратят лишь 25–30% времени на написание кода. Поэтому то, где работают разработчики, должно значить куда меньше, чем как структурировано их время. Тем не менее спор «удалёнка или офис» длится уже шесть лет: CEO ссылаются на «коллаборацию», разработчики — на «фокус», и обе стороны аргументируют убеждениями, а не доказательствами.

У нас есть тысячи часов отслеженной IDE-активности по 100+ B2B-компаниям. Данные рисуют более нюансированную картину, чем хотелось бы любой из сторон.

Исследования Gallup неизменно показывают, что качество менеджера — главный фактор вовлечённости сотрудников, и всё же большинство инженерных менеджеров проводят 1:1 одинаково: «Как дела?», за чем следует неловкая тишина, а потом разговор сползает в обновление статуса по проекту. Это не 1:1 — это стендап с лишними шагами. Настоящие 1:1 должны быть самыми ценными 30 минутами в неделе вашего разработчика, и данные делают их кратно лучше.

Анализ Harvard Business Review показал, что более 90% менеджеров признают: процесс performance review в их компании не даёт точных результатов. В инженерии проблема ещё хуже: менеджеры пишут размытые абзацы на основе того, что помнят за последние две недели. Тихие высокоэффективные сотрудники остаются незамеченными. Громкие слабые — получают оценки выше заслуженного. И все уходят с ощущением, что процесс был произвольным. Данные это исправляют — но только если использовать их правильно.

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

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

Опросы 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 связывают техническую работу с бизнес-результатами, а правильные метрики делают их реально измеримыми.

Глобальный опрос Deloitte по аутсорсингу неизменно называет «недостаток видимости» одной из главных причин провала аутсорсинговых отношений. Ваш клиент платит за 160 часов в месяц на разработчика. Но в глубине души он задаётся вопросом: были ли эти 160 часов действительно продуктивной работой? Это единственное сомнение убило больше аутсорсинговых контрактов, чем сорванные дедлайны.

Проблема не в доверии — а в отсутствии доказательств.