46 записей с тегом "guide"

CFO обычно видит инженерию одной строкой в P&L: зарплаты. Колонка headcount, множитель loaded cost, большая цифра, растущая быстрее выручки. И всё. Отчёт Deloitte Global Technology Leadership Study 2024 подсветил разрыв жёстко: только 31% CFO могут сказать, приносит ли их инвестиция в инженерию отдачу пропорциональную расходам. Остальные 69% летят вслепую над, возможно, крупнейшей дискреционной статьёй компании.

Это не проблема инструментов. Это проблема вопросов. Цифры существуют — ваши коллеги-CFO просто ещё не научились задавать пять правильных вопросов, чтобы их вытащить.

Инженер LegalTech не просто катит фичи. Каждый коммит трогает данные, которые могут быть запрошены в рамках discovery, защищены privilege или регулироваться правилами bar association конкретного штата. Мировой рынок legal-software пересёк $29B в 2024 (Deloitte Legal Operations 2024), и вместе с ним пришла compliance-поверхность, которой нет в обычной SaaS-команде: attorney-client privilege, SOC 2 Type II как baseline, ISO 27001 для работы с документами, плюс e-discovery правила в 50+ юрисдикциях.

Измерение продуктивности здесь — не surveillance-инструмент, а аудит-артефакт. Та же IDE-телеметрия, которая в SaaS говорит EM'у «команда здорова», в LegalTech — это доказательство SDLC-зрелости на IT security review у enterprise-клиента из топ-200 юрфирм.

SOC, который ездит только на MTTR, измеряет пожар, а не пожарную команду. В отчёте IBM Cost of a Data Breach 2024 среднее время выявления и сдерживания утечки — 258 дней, и команды, которые пробили планку в 200 дней, сделали это не за счёт скорости реакции. Они детектили раньше и тратили меньше времени на toil. MTTR был побочным эффектом, а не целью.

Инженерия кибербезопасности требует своего стека метрик. Стандартные engineering KPI недооценивают асимметричную цену пропуска, а чисто InfoSec-дэшборды не замечают, выгорает ли команда или сжигает ли она бюджет.

Команда из восьми инженеров, которую я консультировал в прошлом году, держала правило: любой тикет больше 3 story points требует design doc. Получалось около четырёх документов в неделю, по полдня на написание и ещё полдня на циклы ревью. Итого 32 инженерных часа в неделю — четыре полных рабочих дня на документы, которые большинство людей пробегало глазами один раз и больше не открывало. CTO считал, что у них высокая дисциплина. Данные говорили, что у них перегруз документации и провал по velocity.

Обратная крайность ещё хуже. Stack Overflow Developer Survey 2019 года назвал «плохую документацию внутренних систем» блокером продуктивности №2 — сразу после технического долга. Полностью отказаться от design docs значит, что каждый рефакторинг через полгода превращается в археологические раскопки.

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

Среднее инженерное ретро длится 60 минут, рождает пять стикеров и ноль действий, которые доедут до следующего спринта. В опросе Scrum Alliance 2023 года жалоба №1 от senior-разработчиков звучала так: «ретро ощущается как спектакль». Это не проблема митинга — это проблема измерений. Команда обсуждает ощущения, потому что никто не вытащил цифры до звонка.

В этой статье — 30-минутное ретро, которое начинается с данных, заканчивается именами и сроками, и работает на командах от 5 до 25 инженеров.

Согласно отчёту McKinsey о продуктивности разработчиков (2023), инженеры тратят лишь 25–30% времени на написание кода. Остальное исчезает в митингах, ожидании и процессном оверхеде. DORA-метрики существуют, чтобы сделать эту невидимую трату видимой — и исправимой.

Если вы CTO, VP of Engineering или Engineering Manager, который ещё не внедрил DORA — вы управляете по интуиции в эпоху, которая требует доказательств. Это руководство охватывает всё: что измеряет каждая метрика, как сравнить свою команду с бенчмарками, как внедрить отслеживание и какие ошибки превращают данные DORA в бесполезный мусор.