Содержание слайдов

1. 1. От AI-native разработки к AI-native измерению

   Зачем developer productivity становится ключом к оценке изменений процесса

2. 2. О чём будет эта статья

   Measurement stack для перехода

   Часть 1: локальное ускорение обманывает.

   Часть 2: уроки Google research.

   Часть 3: magic metric не появится.

   Части 4-6: measurement layer.

3. 3. 01. Без измерения — локальная оптимизация

   Ускорение coding loop ≠ улучшение сквозная поставка

4. 4. AI-native нельзя обсуждать без developer productivity

   Локально быстрее ≠ поставка лучше

   AI меняет platform, QA, CI/CD.

   Демо и локальные истории недостаточны.

   Нужна macro-statistics по поставке изменений.

   Productivity даёт язык системного эффекта.

5. 5. DORA 2024–2025: AI adoption ≠ delivery improvement

   Внедрение рос, пропускная способность разработки и stability падали

   Что растёт

   +25% AI-внедрение за год.

   Лучше docs, quality, review speed.

   Что падает

   –1.5% throughput; –7.2% stability.

   Слабый foundation = instability.

6. 6. Узкие метрики — удобные, но опасные

   AI-прокси не доказывают бизнес-эффект

   Generated code ≠ delivery.

   Accepted suggestions ≠ quality.

   Agent PR count ≠ value delivery.

   Local speed без downstream = шум.

7. 7. 02. Developer Productivity for Humans

   Серия Google Research — лучшая рамка для оценки изменений процесса разработки

8. 8. Продуктивность ≠ конвейер

   Разработка — complex creative work

   Измерение людей: technology + sociology.

   Тейлоризм не работает для knowledge work.

   AI убирает рутину, оставляет risk.

   Человеческая часть сложнее.

9. 9. Измерять цели разработчика, а не инструменты

   Инструменты меняются

   30 целей разработчика.

   Behavioral data + user sentiment.

   Не AI в review, а качество кода.

   Идеальная рамка для agent era.

10. 10. Один источник данных всегда врёт по-своему

    Google использует measurement stack, а не один dashboard

    Инструментальные данные

    Cross-tool logs: код, сборки, тесты, ревью.

    Десятки tools → behavioral telemetry.

    Человеческие данные

    EngSat + diary studies для flow/friction.

    Self-assessment валидирует телеметрию.

11. 11. Speed, ease, quality и доверие

    Три измерения продуктивности и фактор trust в AI-эпохе

    Speed без quality — Ускорение возвращается долгом и нестабильностью.

    Эффект изменений запаздывает — Неделя после rollout ничего не доказывает.

    Trust — ключевой фактор — Acceptance rate без доверия мало значит.

12. 12. 03. Магической метрики не будет

    All models are wrong, but some are useful

13. 13. Измерять продуктивность = строить модель

    Любая модель неполна

    Избирательная модель пропускает эффекты.

    Рецепт: несколько outcomes, metrics, methods.

    Один показатель всё не объяснит.

    Это свойство предметной области.

14. 14. 04. Measurement layer для SE 2.0

    Измерять эффект, не tool внедрение

15. 15. Единица анализа — process change

    Гипотеза про speed, ease, quality

    Агентный PR-loop.

    Ускоренный build/test-контур.

    AI в ревью кода и документации.

    Onboarding под короткие батчи.

16. 16. Пять принципов measurement layer

    Не один KPI на всю компанию, а много предметно полезных моделей

    1. Process change — Мерим эффект изменения, не tool внедрение.

    2. Speed/ease/quality — Скорость нельзя покупать friction и техдолгом.

    3. Logs + surveys — Один источник данных всегда искажает.

17. 17. Продольность и доверие

    Привычки меняются медленно

    4. Продольное измерение

    AI-native привычки перестраиваются медленно.

    Квартальный горизонт и сравнение когорт.

    5. Trust и человеческий опыт

    AI ускоряет и повышает когнитивную нагрузку.

    Нужен subjective layer.

18. 18. 05. Что измерять на практике

    Четыре петли обратной связи для большой компании

19. 19. Четыре петли измерения

    От inner loop инженера до capability loop организации

    Inner loop инженера — Iteration time, build latency, context search, focus.

    Team delivery loop — Lead time, PR cycle, CI stability, rework.

    Quality + capability — Tech debt, defects, onboarding, documentation quality.

20. 20. 06. Выводы для большой компании

    Measurement layer — механизм переноса практик из фронтира в основной контур

21. 21. Без measurement layer фронтир = case theater

    Переносить нужно эффект

    Фронтир сияет: PR, код, docs.

    Core не видит эффект поставки.

    Stability damage ≠ activity noise.

    Measurement превращает frontier в capabilities.

22. 22. AI-native без измерения — незамкнутый контур

    Productivity closes loop

    AI ускоряет локально, ломает системно.

    Хорошие модели: many outcomes, metrics, methods.

    DORA: слабый foundation → downstream disorder.

    Побеждает измерение изменения в поставке.

23. 23. Ссылки и материалы

    Productivity и результаты поставки

    DORA AI research: dora.dev/research/

    SPACE framework: queue.acm.org/detail.cfm?id=3454124

    DX Core 4: getdx.com/research

    Google Engineering Productivity + Accelerate.

24. 24. Спасибо!

    AI-native измерение

    Если хотите изучить материалы по теме, переходите в канал "Книжный куб" — там собраны все ссылки

    Александр Поломодов, Technical Director & Fellow, Т-Технологии

    @Book_Cube