55 записей с тегом "developer-productivity"

HRTech-команды пишут софт, который платит людям зарплату не в тот день, если накосячить. Упавший деплой 14-го числа — это не ситуация "извинимся в Slack", а reverse wire-transfer, юридическое письмо и в ЕС — нотификация в DPA по GDPR. Deloitte Global Human Capital Trends 2024 сообщает: 73% HR-лидеров называют свою технологическую платформу одним из топ-3 операционных рисков — выше найма.

Большинство статей о продуктивности, написанных для SaaS или e-commerce, сюда не переносятся. Метрики для payroll-инженера или HRIS-платформы выглядят иначе. Этот гайд про то, что реально стоит отслеживать и почему, и как датасет PanDev Metrics по HRTech отличается от среднего B2B SaaS.

У Pluralsight Flow было три имени. Запустился как GitPrime в 2015, в 2019 куплен Pluralsight и переименован в Pluralsight Flow, в 2024 продан Appfire в рамках более широкой реструктуризации. Опыт клиентов отслеживал ребрендинги: ответы саппорта замедлились, продуктовая roadmap встала, и как минимум трое наших клиентов сообщили, что их renewal-разговоры по Flow развернулись не в ту сторону на post-Appfire переходе.

Если вы ищете «Pluralsight Flow альтернатива» или по мышечной памяти всё ещё «GitPrime альтернатива», то у вас обычно один из двух вопросов. Либо: продукт ещё реально развивается или я плачу за legacy-код? Либо: renewal на носу, хочу честно посмотреть рынок до того, как опять подпишу.

Этот текст отвечает на оба. Есть отдельный head-to-head PanDev vs Pluralsight Flow — здесь широкий обзор рынка.

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

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

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

Два разработчика на одну задачу. Удвоенная стоимость труда, вдвое меньше багов, и никто не может договориться, окупается ли это. Самое цитируемое исследование на эту тему — Cockburn & Williams, The Costs and Benefits of Pair Programming (2000) — показало +15% времени при парной работе и −15% дефектов. На бумаге это ничья. В реальности — нет. Математика "баг пойман рано" выводит ROI примерно к 2×, если учесть сэкономленный rework и предотвращённые production-инциденты.

В этой статье мы скрестили академические данные Cockburn-Williams с нашим IDE heartbeat датасетом по 100+ B2B-компаниям — включая команды, которые практикуют pair programming ежедневно, и те, что не используют его вовсе. Не "хорош ли pair programming?", а "когда он окупается, а когда это театр?".

Прямо сейчас у вашей команды несколько pull request'ов застряли в ревью. Скорее всего, три или больше. Один из них провисел пять дней. Исследование Google 2018 года (Sadowski et al., Modern Code Review: A Case Study at Google) показало: медианный review в Google закрывается за менее чем 4 часа. В большинстве команд, которые мы наблюдаем, этот показатель — 4 дня. Разница в 24 раза, и она почти полностью объясняется процессом, а не уровнем разработчиков.

Это чеклист из 11 правил, которые режут время ревью вдвое без потери качества. Каждое правило подкреплено внешним исследованием, проверено на реальных данных инженерных команд и разнесено по трём фазам: дисциплина автора, дисциплина ревьюера, дисциплина команды.

Каждый руководитель разработки задаёт один и тот же вопрос: сколько времени разработчики реально тратят на написание кода?

Microsoft Research выяснили, что разработчики тратят на код всего 30-40% рабочего времени. Исследование Haystack Analytics 2019 года показало ближе к 2 часам. Наши собственные данные IDE heartbeats по B2B-командам подтверждают медиану в 78 минут в день.

Вот что реально показывают данные и почему это важно.

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

Вот 10 метрик, которые заточат ваши решения. Без воды и совета «отслеживайте всё» — только то, что отличает управление на основе данных от гадания.

Исследование Глории Марк из UC Irvine показало, что после одного прерывания требуется в среднем 23 минуты 15 секунд, чтобы вернуться к задаче. А теперь представьте типичное утро разработчика: в 9:07 пришло сообщение в Slack, в 9:15 — напоминание о стендапе, в 9:45 — «быстрый вопрос» от PM. К 10:30 он «работал» 90 минут, но написал ровно 11 строк кода. Три прерывания съели примерно 70 минут когнитивного восстановления.

Это не проблема продуктивности. Это проблема Focus Time. И данные показывают, что она обходится вашей команде гораздо дороже, чем вы думаете.

Фред Брукс предупреждал в Мифическом человеко-месяце (1975), что измерять продуктивность программистов объёмом кода — ловушка: больше кода не значит больше ценности. Пятьдесят лет спустя некоторые организации всё ещё приравнивают написанные строки к выполненной работе. Фреймворк SPACE (Forsgren et al., 2021) прямо предостерегает от одномерных метрик активности — и всё же потребность, которую они адресуют, реальна: как понять, что ваша инженерная команда доставляет результат?

Ответ — не очередная vanity-метрика. Это составной сигнал, который мы называем Delivery Index.

«10x-разработчик» — один из самых устойчивых мифов нашей индустрии и один из самых разрушительных. Фред Брукс отмечал в Мифическом человеко-месяце (1975), что продуктивность отдельных программистов сильно варьируется, но при этом предупреждал: не стоит делать вывод, что найм решает системные проблемы. Фреймворк SPACE (Forsgren et al., 2021) идёт дальше: измерять «продуктивность» отдельного разработчика одной метрикой не просто неточно — это контрпродуктивно.

У нас есть данные B2B-инженерных команд и тысячи часов отслеженного кодирования. Вот что они на самом деле говорят о разбросе производительности разработчиков — и почему ответ значит меньше, чем вы думаете.