Продуктивность разработки: человеческий взгляд Google

Александр Поломодов разбирает серию Google Developer Productivity for Humans через собственный опыт управления разработкой. Главный вопрос — как понять, что инженерам стало проще получать полезный результат. Количество задач, строк кода или время в редакторе сами по себе этого не показывают. Найденная библиотека может сэкономить неделю разработки, хотя в отчёте активность уменьшится. Поэтому сначала нужно назвать цель и решение, которое изменится по итогам измерения, а уже затем выбирать показатели.

Разговор переходит к повседневным сценариям: понять чужой код, дождаться сборки, освоиться в команде. Логи показывают действия, опросы — впечатления людей, интервью помогают объяснить расхождения. Эти наблюдения нужно сопоставлять. Например, встроенный ИИ-чат увеличивает время внутри редактора, потому что документацию теперь читают там же. Формально показатель растёт, но переключений становится меньше. Для сборок важны и скорость, и предсказуемость; при адаптации новичка — самостоятельность и затраты наставника, а не только первое изменение в рабочей системе.

Отдельная тема — цена локального ускорения. Платформенная команда может быстро выпускать библиотеки, пока другие команды тратят всё больше сил на обновления. Качество приходится рассматривать на уровнях процесса, кода, системы и продукта. Архитектурное решение полезно настолько, насколько помогает развивать продукт и поддерживать надёжность. Переиспользование готового решения тоже может быть творческой работой, даже если карьерные стимулы поощряют создание нового. Важно учитывать труд всех участников, включая потребителей результата.

В части об ИИ обсуждаются четыре противоречия: экономия времени автора и нагрузка на проверяющего, быстрый результат и накопление долга, лёгкий прототип и сложная эксплуатация, готовый код и потеря понимания. Автоматизация также меняет состав задач: после устранения простых операций среднее время оставшейся работы может вырасти. Выпуск завершается планом на месяц: выбрать одну болезненную цель, собрать исходные наблюдения, попробовать ограниченное изменение и обсудить эффект с командой. Заранее нужны признаки пользы и ухудшения, а руководителю — готовность отказаться от идеи, которая не помогает.