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

Команда, которая делает батарейный сельхоз-сенсор, гоняет CI-пайплайн 38 минут: собрать firmware, прошить HIL-стенд, прогнать 12-минутный on-device smoke, опубликовать артефакты. Их коллеги из веб-команды пушат в main и видят зелёные галки за 7 минут. Когда обе команды меряют по deployment frequency, firmware-команда выглядит отстающей в 5 раз. Они не отстают. Они делают более сложную работу с более длинным циклом обратной связи, а метрика этого не видит.

Большинство инженерных метрик построены под веб: быстрые билды, обратимые деплои, observability с первого дня. IoT- и embedded-команды наследуют эти метрики и выглядят на их фоне плохо. Фреймворк DORA это явно признаёт — отчёт Accelerate State of DevOps 2023 отмечал, что "команды, шипящие embedded или регулируемый софт, имеют другое распределение и не должны сравниваться с веб-командами по deployment frequency". Эта статья — о том, что трекать вместо этого.

В инженерной культуре Google есть правило: до первой строчки кода для любой нетривиальной задачи пишется design doc. Не 40-страничный монумент, а обычно 5-12 страниц, с двумя ревьюерами и комментариями на полях. Команда Engineering Practices из Google публично называла это одним из самых дешёвых рычагов качества в компании.

Большинство команд вне Google либо пропускают этот шаг, либо прикручивают шаблон в Confluence к существующему процессу и смотрят, как он атрофируется. Шаблон ниже — тот, который реально выживает при встрече с уставшим ревьюером в 16:45 в четверг. Это тот момент, когда спека живёт или умирает.

Команда из 40 инженеров за 8 месяцев приняла одно и то же архитектурное решение дважды — в июне и в феврале, оба раза откатила. После второго отката наконец внедрили RFC-процесс. Разбирая историю коммитов, они обнаружили: оригинальный контекст остался в Slack-треде, который автоматически архивировался через 90 дней, а инженер, который владел решением, уже уволился. RFC-документ стоил бы 4 часа на написание и сэкономил бы примерно 3 инженеро-недели переделок.

RFC-процессы существуют потому, что технические решения переживают людей, которые их приняли. Stripe, Cloudflare, Oxide Computer и проект Rust публично описывают свои RFC-форматы — и общая структура уже, чем кажется большинству команд. Эта статья — тот самый шаблон, к которому они сходятся, плюс реалистичный ревью-цикл для команд 10-80 человек, плюс честные цифры о том, когда RFC просто тратят время.

Команда из 60 инженеров, с которой я работал в прошлом году, имела 1400+ страниц Confluence, Notion-воркспейс на 380 страниц, GitHub wiki в каждом из 22 репозиториев и Google Drive с «командными знаниями». Задачей новой сотрудницы на второй неделе было найти runbook стейджинга. Ушло четыре часа. Он существовал во всех четырёх системах, с тремя разными URL, двумя противоречивыми версиями и одной корректной, но устаревшей на три года инструкцией в wiki.

Это сравнение четырёх подходов к knowledge management — Confluence, Notion, GitHub Wiki, Git-native docs (Obsidian/MkDocs/Docusaurus поверх репозитория) — и фреймворк выбора. Microsoft Research в отчёте по productivity 2024 назвал «не могу найти документацию» фактором трения №3 после медленных билдов и сломанных тестов, выше задержек code review. Выбор инструмента не нейтрален: он определяет, будет ли документация написана, найдена и доверяема.

Fintech-команда в Варшаве сократила средний рабочий день на 45 минут — и стала катить больше фич. SaaS из 40 человек в Сингапуре запретил митинги до 11 утра — медиана lead time на PR упала на 22%. Ни одна команда ничего не изобрела — они внедрили защищённые блоки deep work. UC Irvine, Gloria Mark, почти два десятилетия публикует (The Cost of Interrupted Work: More Speed and Stress, 2008, и follow-ups): одно прерывание стоит ~23 минут на рефокус. Cal Newport Deep Work (2016) популяризировал термин у инженерных лидеров. Данные устоялись; имплементация — там, где команды расходятся.

Эта статья проходит по 5 реальным расписаниям команд. Что сработало, что сломалось, и что мы увидели в IDE-телеметрии, когда паттерн стабилизировался.

Команда из 6 инженеров с 15-минутным daily standup стоит вам 7,5 человеко-часов в неделю только в запланированном времени. Добавьте цену переключения контекста — Gloria Mark (UC Irvine) измерила ~23 минуты на возврат к задаче после прерывания — и реальная стоимость ближе к 15 часам в неделю. Для команды, тянущей фичу 10 недель, это 150 инженер-часов. Это не встреча. Это part-time инженер, которого вы наняли и сразу поставили говорить.

Standup'ы не плохи сами по себе. Они решают реальную задачу: выносят блокеры на поверхность, пока те не сгнили. Вопрос в том, единственный ли синхронный ежедневный формат её решает — и лучший ли. Отчёт State of Agile 2024 показывает, что 32% команд активно экспериментируют с async-first альтернативами, и наиболее чистые данные из IDE-телеметрии говорят, что эти альтернативы возвращают 1-2 часа focus time на разработчика в неделю без ущерба доставке.

Это сравнение 5 альтернатив standup, когда какая подходит, и как выбрать свою.

Ваша команда из 40 инженеров держит 34 репозитория. Звучит разумно? Мы видим эту форму часто. Типичный разработчик в такой конфигурации триггерит 11,4 переключения контекста в день между репо — почти все невидимы EM, каждое стоит ~23 минут рефокуса (UC Irvine, Gloria Mark, The Cost of Interrupted Work, 2008, и последующие репликации). Та же команда после миграции в monorepo: 3,2 переключения в день. Продуктивностная математика очевидна; стоимостная — интереснее.

Обе архитектуры работают. Google держит крупнейший известный monorepo (2B+ строк, ~85,000 инженеров). Netflix — тысячи polyrepo. Вопрос не в том, что лучше в вакууме — а что подходит вашему размеру команды, вашему CI-бюджету и вашей терпимости к координационному оверхеду.

Copilot написал 420 тестов для модуля платежей за два дня. Coverage прыгнул с 58% до 84%. Уверенность в релизе? Без изменений, а то и хуже. Исследование 2024 IEEE (An Empirical Study on the Usage of Transformer Models for Code Completion, Ciniselli et al.) показало: LLM-сгенерированные тесты компилируются в 92% случаев, но ловят лишь 58-62% инъектированных мутаций — стандартный исследовательский тест на «этот тест вообще что-то проверяет». Человеческие тесты в том же исследовании — 78%. Разрыв ~20 процентных пунктов в mutation score — реальная история качества AI-тестов, а не цифра coverage, которую все репортят.

Эта статья измеряет, в чём AI-тесты хороши, что они пропускают, и как выстроить pipeline, чтобы AI давал throughput, не разъедая уверенность в релизе.

Рынок AI-инструментов для кода к началу 2026 года разделился на четырёх серьёзных игроков: GitHub Copilot, Cursor, Claude Code (CLI от Anthropic) и ChatGPT с Code Interpreter. Маркетинг у всех четырёх обещает "+40% продуктивности" — цифра одинаковая и бессмысленная без измерения. Мы подняли данные IDE heartbeat и session у 112 инженеров в 14 B2B-командах за Q1 2026, чтобы посмотреть, что реально экономит время.

Суть: пользователи Claude Code экономят 54 минуты в день; пользователи Copilot — 28. Но распределение не то, на что намекает маркетинг — лучший инструмент зависит от вида работы, а не от "AI-зрелости" команды.

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.