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

В начале Александр вспоминает работу в крупном финтехе: подсчёт задач и попытка сделать показатели зелёными легко превращаются в отдельную деятельность, далёкую от улучшения разработки. Инженер, который нашёл готовую библиотеку вместо недели самостоятельного программирования, решил задачу, но написал мало кода. Если вознаграждать объём кода, система начнёт наказывать полезное решение. Поэтому наблюдение, его интерпретацию и управленческое действие нужно разделять. Между ними всегда есть предположения: отправка изменения не равна созданной ценности, а увеличение активности не доказывает роста продуктивности. В обсуждаемом подходе Google рядом рассматриваются скорость, простота выполнения работы и качество результата. Они отвечают на разные вопросы и не сводятся к одному среднему баллу. До исследования стоит договориться, какое решение изменят его результаты. Если руководитель всё равно собирается поступить заранее выбранным способом, дополнительный сбор данных лишь откладывает действие. Хороший вопрос связывает неопределённость с выбором: например, поможет ли вложение в инфраструктуру сборок инженерной работе настолько, чтобы оправдать затраты.

Следующий шаг — описать цель инженера через весь рабочий сценарий. Вместо оценки удобства поиска можно спросить, удалось ли человеку понять существующее решение и безопасно его изменить. Для этого могут потребоваться несколько инструментов и помощь коллег; каждый инструмент способен выглядеть успешным отдельно, пока переходы между ними разрушают сценарий. Логи показывают действия, опросы — восприятие работы, интервью помогают объяснить расхождение, а эксперимент проверяет эффект изменения. Ни один источник не заменяет остальные. Александр приводит пример обсуждавшейся в выпуске метрики времени подготовки изменения: встроенный в редактор ИИ-чат позволяет изучать документацию, не уходя в браузер. Время внутри редактора растёт, хотя число переключений сокращается. Если трактовать рост времени как ухудшение работы, можно отключить полезную возможность. Аналогично стабильные вопросы регулярного опроса позволяют сравнивать опыт инженеров во времени, но сами ответы ещё требуют объяснения. Противоречие между хорошими логами и жалобами людей — повод исследовать конкретные эпизоды, а не объявить одну сторону ошибочной.

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

Качество в выпуске разбирается на четырёх уровнях: процесс, код, система и продукт. Александр связывает эту схему с опытом архитектурной функции: просьба дать одну метрику хорошей архитектуры скрывает разные последствия решений. Архитектурное изменение нужно обосновывать через возможность развивать продукт, надёжность или поведение системы, а не через абстрактную красоту. Пример неудачного разбиения на микросервисы показывает, как новая система может сразу стать техническим долгом: границы по сущностям вынуждают собирать каждый бизнес-сценарий из цепочки зависимых запросов. Другой пример — платформенная команда, быстро выпускающая библиотеки, пока потребители тратят огромные усилия на согласование обновлений. Локальная скорость выпуска не учитывает труд интеграции. Реальные связи между людьми и командами поэтому важнее одной организационной схемы. Творчество также не обязательно означает создание нового: найти, доработать и переиспользовать решение может быть полезнее очередного собственного инструмента. Александр замечает, что система карьерного признания способна поощрять обратное. Это его практическая интерпретация стимулов, а не универсальный результат для любой компании.

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

Мысленный эксперимент об исчезновении части технического долга показывает ещё одну ловушку. Если повторяемые миграции забирает автоматизация, у людей остаются более сложные задачи. Среднее время задачи может вырасти именно потому, что простая работа исчезла из выборки. Такое изменение состава работы нельзя интерпретировать как падение продуктивности без дополнительного разбора. Практический ответ выпуска — небольшая программа улучшений на месяц. Сначала выбрать одну болезненную инженерную цель и поговорить с исполнителями и потребителями результата. Затем собрать исходную картину из реальных эпизодов, доступных событий и короткого опроса. После этого попробовать ограниченное изменение, заранее определив признаки пользы и ухудшения. В конце обсудить результаты с командой и решить, продолжать, менять подход или останавливаться. Для команды из десятков инженеров личные разговоры могут дать больше, чем копирование измерительной инфраструктуры Google. Доверие возникает, когда руководитель объясняет решения, возвращается с обратной связью и готов отменить собственную идею, если она не помогает.