Developer Productivity for Humans
Карта серии IEEE Software из девяти материалов о human-centered productivity: от базовой модели до техдолга, build latency, onboarding, flow, качества и креативности.
Открыть оригиналЧто объединяет серию
Одна метрика не описывает developer productivity: серия рассматривает её как социотехническую систему. Опросы и телеметрия полезнее в связке, а данные должны улучшать среду работы, а не ранжировать отдельных инженеров. Девять статей охватывают human-centered фрейм, hybrid work, technical debt, build latency, onboarding, flow/focus/friction, software quality, creativity и границы моделей измерения.
Маршруты чтения
Для базового фрейма: части 1 → 3 → 9. Для DevEx и процессов: 5 → 6 → 8. Для инженерной эффективности платформы: 4 → 7 → 9. После каждой ветки сформулируйте, какие сигналы вы соедините и какое решение они должны поддержать.
Полный разбор из прежнего каталога
Текст перенесён целиком: короткие секции выше — это его конспект, а ниже идёт исходный разбор с ссылками и материалами.
Основа главы
Пост в tg-канале про всю колонку
Список из 9 статей Developer Productivity for Humans (публикация от 3 октября 2024).
Основа главы
Пост в tg-канале про всю колонку
Список из 9 статей Developer Productivity for Humans (публикация от 3 октября 2024).
Оригиналы
Поиск статей на IEEE
Официальные публикации колонки Developer Productivity for Humans.
Оригиналы
Поиск статей на IEEE
Официальные публикации колонки Developer Productivity for Humans.
Это разводящая глава по всей серии: в одном месте собраны все материалы, их фокус и ссылки на уже опубликованные главы в библиотеке.
Колонка
IEEE Software
Статей
9
Период
2023-2025
Фокус
Human-centered productivity
Что это за серия
Колонка последовательно развивает human-centered подход: от базовых принципов измерения productivity до прикладных тем вроде technical debt, build latency, onboarding, flow/focus/friction и креативности в разработке.
Карта всех 9 статей
Статья 1 · 2023
A Human-Centered Approach to Developer Productivity
Базовый фрейм: продуктивность как социотехническая система, а не одна метрика output.
Статья 2 · 2023
Developer Productivity for Humans, Part 2: Hybrid Productivity
Как переход в hybrid/remote влияет на ритм работы, коммуникацию и onboarding.
Статья 3 · 2023
Defining, Measuring, and Managing Technical Debt
Техдолг как управляемый фактор инженерной скорости и качества решений.
Статья 4 · 2023
Build Latency, Predictability, and Developer Productivity
Влияние latency и предсказуемости build/test циклов на темп инженерной работы.
Статья 5 · 2023
Onboarding and Ramp-Up
Измерение выхода новых инженеров на рабочий темп без токсичных сравнений.
Статья 6 · 2023
Measuring Flow, Focus, and Friction for Developers
Связка self-reports и логов для поиска реальных инженерных фрикций.
Статья 7 · 2024
Developer Productivity for Humans, Part 7: Software Quality
Почему качество кода и устойчивость изменений важны для долгосрочной продуктивности.
Статья 8 · 2024
Creativity in Software Engineering
Креативность как практичная рекомбинация знаний и collaboration в командах.
Статья 9 · 2025
Measuring Productivity: All Models are Wrong But Some are Useful
Как использовать модели продуктивности прагматично и не сводить управление к одному KPI.
Сквозные идеи серии
- Одна метрика не описывает productivity: нужны многомерные модели и контекст задач.
- Опросы и логи работают сильнее в связке, чем по отдельности.
- Фрикции в tooling и процессах нужно измерять и устранять системно, а не точечно.
- Качество кода, onboarding и collaboration дают долгосрочный эффект на delivery.
- Данные стоит использовать для улучшения системы, а не для рейтинга отдельных инженеров.
С чего начать чтение
- Если нужен базовый фрейм, начните со статей 1 -> 3 -> 9.
- Если приоритет DevEx и процессы команды, идите по пути 5 -> 6 -> 8.
- Если фокус на инженерной эффективности платформы, начните с 4 -> 7 -> 9.
Дополнительно по теме
RIMS #8 - Measuring developer goals
Goal-centric измерение инженерной продуктивности через critical journeys и outcome-подход.
DevOps Metrics. Your biggest mistake might be collecting the wrong data
Почему выбор исходных сигналов определяет качество управленческих решений.
RIMS #10 - Measuring Developer Experience With a Longitudinal Survey
Практика регулярных DevEx-опросов и проверка динамики метрик во времени.
Практический смысл серии: улучшать не «абстрактную производительность», а условия, в которых инженерные команды стабильно принимают хорошие решения.
Для этой главы использован пост-оглавление серии из tg-канала и ссылки на оригинальные публикации IEEE.