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

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

Именно поэтому мне интересна серия Developer Productivity for Humans. Её редакторы Ciera Jaspan и Collin Green собирают исследования Google о людях, инструментах и условиях инженерной работы. Это последовательность небольших статей, а не единая завершённая теория. Авторы отдельных выпусков меняются, методы различаются, некоторые тексты описывают исследования, другие предлагают модель или мысленный эксперимент. Я пройду серию через три вопроса: какую работу мы хотим улучшить, как понять причины затруднений и какое изменение стоит проверить.010101Я собирал эту линию постепенно: Книжный куб · карта исследований и её продолжение. Здесь связываю эти разборы с работами 2025–2026 годов.01Я собирал эту линию постепенно: Книжный куб · карта исследований и её продолжение. Здесь связываю эти разборы с работами 2025–2026 годов.

В исходной статье A Human-Centered Approach to Developer Productivity задача сформулирована через человека, который выполняет сложную творческую работу. Техническая инфраструктура влияет на его возможности, а социальная среда — на доступ к знаниям, помощь и решения. Разделить эти факторы удобно для организации команд, но опасно для объяснения результата. Быстрый инструмент мало помогает инженеру, который не понимает, кто может согласовать изменение. Хорошая коммуникация не отменяет нестабильные тесты, ежедневно отнимающие внимание.020202В разборе исходной статьи я обращаю внимание на два условия: продуктивность зависит и от инструментов, и от социальной среды.Книжный куб · человеческий подход02В разборе исходной статьи я обращаю внимание на два условия: продуктивность зависит и от инструментов, и от социальной среды.Книжный куб · человеческий подход

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

Для практического разговора серия предлагает держать вместе скорость, удобство работы и качество. Это не требование усреднить три шкалы. Если изменение экономит время, но делает работу непонятной и хрупкой, важно увидеть обе стороны. Обратная ситуация тоже возможна: понятный код одновременно облегчает проверку, сокращает время следующего изменения и снижает вероятность ошибки. Между измерениями бывают компромиссы, но обязательного обмена одного на другое нет.

Поздняя статья Measuring Productivity: All Models Are Wrong But Some Are Useful объясняет, почему спор о единственно правильной метрике часто бесплоден. Измерение продуктивности всегда строит модель реальности: выбирает события, границы задачи, временной горизонт и результат. Неполнота неизбежна; проблема возникает, когда исключённые части работы существенны для принимаемого решения. Модель времени написания функции может быть полезной для редактора кода и одновременно недостаточной для оценки поставки продукта.030303В отдельном разборе объясняю, зачем сочетать несколько моделей, методов и показателей.Книжный куб · модели продуктивности03В отдельном разборе объясняю, зачем сочетать несколько моделей, методов и показателей.Книжный куб · модели продуктивности

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

В статье Measuring Developer Goals Ben Ferrari-Church и Carolyn Egelman предлагают более устойчивую единицу наблюдения — цель разработчика. Разница кажется словесной, пока не посмотреть на конкретный пример. «Пользоваться поиском» описывает контакт с инструментом. «Понять существующее решение, чтобы безопасно его изменить» описывает намерение человека. Во втором случае поиск может соседствовать с чтением кода, разговором с коллегой, запуском эксперимента и обращением к документации.

Если каждый инструмент оценивает только свой участок, успешные локальные отчёты вполне могут сосуществовать с неудачным пользовательским опытом. Поиск быстро вернул результаты, документация открылась, сборка завершилась. Но инженер не нашёл ответа на вопрос о допустимом поведении системы. Число успешных операций выросло именно потому, что человек снова и снова пытался разобраться. Здесь активность отражает незавершённость цели, а не продуктивный результат.

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

В моём разборе целей разработчиков особенно показателен переход от вопроса про проверку кода к вопросу о поддержке качества чужого изменения. Обычная анкета легко замыкается на удобстве интерфейса проверки. Более широкая формулировка включает понимание замысла, поиск требований, проверку тестами и обсуждение последствий. После смены вопроса оценки могут ухудшиться, хотя инструмент не менялся: исследователи просто сделали видимой прежде пропущенную работу. Эту статью мы также разбирали в Research Insights Made Simple №8 и обсуждали в Code of Leadership №67.

Это полезная предосторожность при сравнении результатов во времени. Если поменялись формулировка, границы сценария или состав участников, новый показатель нельзя без объяснения приклеить к прежнему графику. Улучшение наблюдаемости иногда выглядит как ухудшение положения дел. Прежде чем требовать исправить падающую оценку, стоит проверить, не начали ли мы задавать более содержательный вопрос. Отдельно полезно сохранять старую и новую формулировки вместе с датой изменения.

На практике я бы начинал с одной частой и болезненной цели. Например: инженер должен разобраться, почему упал тест, и вернуть изменение в проверяемое состояние. Тогда мы описываем начало и конец эпизода, основные действия, места ожидания и обращения за помощью. Различаем дефект продукта, нестабильный тест и проблему среды. Без этого одинаковое время до зелёной сборки может скрывать совершенно разные причины и требовать разных решений.

Наблюдать нужно и предусмотренный путь, и реальные отклонения. Команда платформы могла спроектировать короткую последовательность действий, а разработчики давно пользоваться обходом, потому что официальный путь требует недоступных прав. Такой обход — свидетельство о продукте, а не повод обвинить пользователей. Следующий разговор должен быть о том, какую потребность он удовлетворяет, почему возник и можно ли обеспечить эту потребность надёжнее.

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

После выбора цели возникает соблазн найти один достоверный источник данных. Логи кажутся объективными, опросы — субъективными, интервью — слишком дорогими. Серия предлагает более полезное разделение: каждый метод видит свою сторону работы и имеет собственные слепые зоны. Журнал событий хорошо хранит факт запуска сборки. Он не знает, зачем инженер запустил её именно сейчас и считает ли полученный результат достаточным для продолжения работы.

Предшествующая колонке работа Enabling the Study of Software Development Behavior With Cross-Tool Logs описывает InSession — систему объединения событий из множества инструментов разработки. Её ценность в восстановлении последовательности деятельности через границы продуктов. Между запуском теста и следующей правкой человек мог искать информацию или взаимодействовать с коллегами. Если наблюдать только редактор, эти действия исчезнут. Если смотреть только на сборочную систему, ожидание будет выглядеть пустым интервалом, хотя человек мог заниматься другой полезной задачей.040404Отдельно разбирал InSession и то, как исследователи связывают события из разных инструментов разработки.Книжный куб · события из разных инструментов04Отдельно разбирал InSession и то, как исследователи связывают события из разных инструментов разработки.Книжный куб · события из разных инструментов

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

Статья Measuring Developer Experience With a Longitudinal Survey рассказывает о программе EngSat, которую Google ведёт с 2018 года. Длительность программы позволяет видеть изменения опыта, а повторяемая организация опросов делает их частью управленческой работы. В моём разборе программы опросов отмечены сменяемая пара исследователя и инженера, документированный процесс, автоматизация обработки и отчёты участникам. Здесь измерительная инфраструктура включает не только код, но и ответственность за качество вопроса и дальнейшее решение. Этому исследованию посвящён Research Insights Made Simple №10. Для меня здесь важна обратная связь: людям показывают, какие решения приняты по их ответам.

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

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

В продолжении What Makes a Good Productivity Metric? вопрос сдвигается с модели целиком на качество отдельного показателя. Для собственной практики отсюда следует требование к определению метрики: объяснить явление, наблюдаемый признак, предполагаемую связь и решение, которое она поддерживает. Эти четыре пункта — мой рабочий способ проверки, а не дословный перечень авторов. Хорошая техническая воспроизводимость вычисления не заменяет проверки того, что показатель вообще отвечает на нужный вопрос.

Наконец, эффект вмешательства нельзя автоматически вывести из сравнения «до» и «после». Меняются задачи, состав команды, сезонная нагрузка и внешние зависимости. Контрольная группа или поэтапное внедрение помогают, когда они осуществимы; интервью объясняют неожиданные различия. В небольшой организации лучше честно показать неопределённость, чем имитировать точность большого исследования. Цель измерения — улучшить решение, а не получить красивое статистическое оформление заранее выбранного ответа.

Исследование Build Latency, Predictability, and Developer Productivity начинается с вопроса, который легко услышать от руководителя инфраструктуры: насколько быстрыми должны быть сборки, чтобы разработчик оставался продуктивным? В вопросе уже спрятана удобная модель. Будто существует порог: ниже него человек продолжает работать, выше — теряет сосредоточенность. Если найти этот порог, можно прекратить инвестиции, как только сборочная система станет достаточно быстрой.

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

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

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

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

Работа Measuring Flow, Focus, and Friction for Developers продолжает эту линию, сопоставляя логи с опросами и дневниками инженеров. Состояние потока, сосредоточенная работа и препятствия — близкие, но разные понятия. Из длинного интервала без переключений нельзя автоматически заключить, что человек продуктивно решает задачу. Он мог застрять. Из нескольких переходов между инструментами нельзя автоматически заключить обратное: они могли быть естественной частью поиска решения.050505Мой разбор этой работы вышел в двух частях: о переживаемом опыте инженера и его сопоставлении с поведением.Книжный куб · поток, фокус и препятствияКнижный куб · продолжение разбора05Мой разбор этой работы вышел в двух частях: о переживаемом опыте инженера и его сопоставлении с поведением.Книжный куб · поток, фокус и препятствияКнижный куб · продолжение разбора

Для руководителя это меняет постановку задачи. Полезно защищать возможность сосредоточиться, но счётчик непрерывных минут не должен становиться новой нормой выработки. Сначала выясняем, какие прерывания разрушительны, какие помогают получить ответ, а какие неизбежны из-за характера работы. У дежурного инженера и автора сложного алгоритма разные обязанности. Одинаковая цель по длительности непрерывной работы может улучшить отчёт и ухудшить обслуживание системы.

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

Статью Hybrid Productivity легко использовать как аргумент в споре об офисе. Но прежде нужно восстановить исследовательский контекст: пандемия изменила не только место работы. Одновременно изменились домашние условия, доступность коллег, расписания и способы адаптации новых сотрудников. Выделить чистый эффект физического присутствия из такой ситуации трудно. История Google полезна прежде всего способом постановки вопросов, а не готовым правилом количества офисных дней.060606В разборе я сохраняю пандемийный контекст: без него выводы легко превратить в универсальный совет об офисе.Книжный куб · гибридная работа06В разборе я сохраняю пандемийный контекст: без него выводы легко превратить в универсальный совет об офисе.Книжный куб · гибридная работа

Сравнение среднего сотрудника тоже скрывает различия. Опытный инженер, который знает систему и нужных людей, приходит в удалённую работу с накопленной сетью связей. Новичку приходится строить её одновременно с освоением инструментов и предметной области. Даже одинаково хорошие технические условия не делают эти ситуации равными. Вопрос «может ли человек выполнить задачу дома?» недостаточен без вопроса «откуда он получит контекст, которого пока не знает?».

Продолжение Onboarding and Ramp-Up рассматривает адаптацию и выход на самостоятельную работу. Первая отправка кода — удобный наблюдаемый рубеж, но он захватывает только часть процесса. Можно быстро исправить опечатку и всё ещё не понимать устройство системы. Можно дольше готовить первое содержательное изменение, зато разобраться в тестировании и ответственности. Выбор стартовой задачи влияет на показатель, поэтому сравнение людей по этому числу особенно легко вводит в заблуждение.070707Подробнее разбирал, почему первая отправка кода и освоение работы — разные рубежи адаптации.Книжный куб · адаптация инженеров07Подробнее разбирал, почему первая отправка кода и освоение работы — разные рубежи адаптации.Книжный куб · адаптация инженеров

Вместо одного рубежа полезно описать, что человек постепенно начинает делать сам. Найти владельца компонента, запустить нужные проверки, объяснить последствия изменения, получить содержательную обратную связь. Эти признаки зависят от роли. Для инженера платформы и разработчика пользовательского интерфейса набор рабочих ситуаций отличается. Общими могут быть принципы оценки, а конкретные задания и ожидания должны соответствовать будущей ответственности, иначе программа будет обучать прохождению учебного маршрута.

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

Руководителю полезно видеть и другую сторону: кто оплачивает адаптацию своим временем. Наставник может временно отправлять меньше собственного кода, потому что объясняет систему. Если личные показатели учитывают только прямой выпуск изменений, организация наказывает нужное ей поведение. Сравнение скорости новичка без нагрузки наставника даёт столь же неполную картину, как измерение генерации кода без времени его проверки. Коллективный результат шире суммы индивидуальных счётчиков.

Для своей команды можно собрать короткий журнал затруднений: чего не хватило, где искали ответ, кто помог, что теперь можно сделать самостоятельно. Не превращать его в обязательную подробную отчётность о каждом действии. Несколько содержательных эпизодов за неделю могут показать, что проблема не в качестве вводной лекции, а в недоступном окружении или неясных границах ответственности. Тогда и вмешательство получится конкретным.

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

В статье Software Quality предлагается различать качество процесса, кода, системы и продукта. Для меня это один из самых полезных результатов серии, потому что он объясняет частый организационный конфликт. Руководитель просит улучшить качество, имея в виду пользовательские проблемы. Команда отвечает рефакторингом. Эксплуатация предлагает повысить надёжность, а продуктовая команда — пересмотреть сценарий. Все действия могут быть разумными, но отвечают на разные вопросы.080808В разборе качества я связывал эту модель с архитектурными характеристиками: сначала стоит договориться, какое именно свойство мы улучшаем.08В разборе качества я связывал эту модель с архитектурными характеристиками: сначала стоит договориться, какое именно свойство мы улучшаем.

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

Здесь важно не превратить концептуальную модель в доказанный закон. Хорошо устроенный процесс может поддерживать качество кода, но конкретный набор правил ещё нужно проверить. Читаемый код не гарантирует отсутствия внешнего сбоя. Надёжная система может решать ненужную пользователю задачу. Поэтому объяснение инвестиции должно пройти всю цепочку: какое свойство меняем, какое поведение ожидаем, где увидим промежуточный эффект и какой конечный результат для нас важен.

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

Работа Defining, Measuring, and Managing Technical Debt добавляет ещё одну сложность: технический долг зависит не только от текущего состояния кода, но и от представления о желаемом будущем. В моём разборе технического долга приведён пример перехода с Python 2 на Python 3. После принятия решения о миграции старый код начинает восприниматься как долг, хотя его байты не изменились. Оценка возникла из нового контекста, требований и возможностей. Статический анализ без этого знания видит только часть ситуации. Отдельный разговор об этой работе — Research Insights Made Simple №2.

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

Руководитель может обсуждать долг через три вопроса. Какую работу он затрудняет? Почему эта работа важна в обозримом будущем? Какой вариант уменьшения помехи выгоднее остальных? Такой разговор не требует немедленно переводить каждую проблему в денежную сумму. Для части решений достаточно установить частоту, затрагиваемые команды и тяжесть последствия. Но список «плохого кода» без связи с планируемыми изменениями быстро превращается в бесконечный каталог технических предпочтений.

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

Особенно полезен мысленный эксперимент What Happens When Technical Debt Vanishes?. Допустим, один класс долга исчез навсегда. Разработчики освободили время и взялись за другую работу. Состав задач изменился, появились новые сложные участки, а привычные метрики не обязаны дружно улучшиться. Отсюда нельзя вычислить реальный эффект автоматического исправления кода. Зато можно проверить логическую слабость требования: «если инвестиция полезна, любой показатель продуктивности должен вырасти».090909В этом разборе мне интересна смена состава задач после устранения долга: привычные показатели могут перестать объяснять результат.Книжный куб · исчезновение техдолга09В этом разборе мне интересна смена состава задач после устранения долга: привычные показатели могут перестать объяснять результат.Книжный куб · исчезновение техдолга

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

До этого момента легко представлять разработчика центральной фигурой модели: он ставит цель, использует инструменты, получает результат. Но результат продукта обычно создаётся совместно. В работе Software Development Is a Team Sport исследователи рассматривают наблюдаемые связи сотрудничества и отдельно — качество командной работы через опросную шкалу. Это два разных вопроса: кто взаимодействует с кем и насколько хорошо это взаимодействие помогает достигать общей цели.

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

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

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

Вторая линия этого раздела — Creativity in Software Engineering. Качественное исследование показывает, как участвовавшие разработчики связывают творчество с полезностью и умным переиспользованием. Новизна сама по себе не гарантирует хорошего инженерного решения. Найти знакомую идею в соседней области, понять ограничения и аккуратно перенести её в свой контекст может быть более творческой работой, чем написать ещё одну уникальную библиотеку для уже решённой задачи.101010В разборе я связываю творчество с полезностью решения и умным переиспользованием, а не только с новизной кода.Книжный куб · творчество в разработке10В разборе я связываю творчество с полезностью решения и умным переиспользованием, а не только с новизной кода.Книжный куб · творчество в разработке

Этот результат помогает объяснить, почему некоторые важные вклады плохо видны в отчётах активности. Инженер может остановить ненужную реализацию, помочь двум командам договориться об общей модели или заметить, что существующий механизм уже решает задачу. Следов нового кода станет меньше. Для организации это может быть выигрышем, однако подтвердить его нужно через конкретный результат: устранённое дублирование, уменьшенную сложность или возможность быстрее вносить следующие изменения.

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

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

Совместная работа и творчество соединяются в передаче контекста. Идея полезна организации, когда другие люди понимают, где её можно применить и где нельзя. Поэтому документация о причинах решения, обсуждение альтернатив и наставничество помогают коллегам понять, проверить и изменить решение. Если оценивать их только как отвлечение от кодирования, можно получить краткосрочное ускорение вместе с долгосрочной зависимостью от нескольких незаменимых людей.

ИИ не отменяет вопросов предыдущих разделов, а делает их заметнее. Статья What Do Developers Want From AI? предлагает начинать с потребностей разработчиков, а не с доступной технологической возможности. Если инструмент умеет продолжать код, это ещё не означает, что именно продолжение кода является главным затруднением человека. Возможно, ему нужно понять незнакомую систему, согласовать требования или убедиться, что предлагаемое изменение не нарушает важное ограничение.111111Эту статью я разбирал в «Книжном кубе» и с Николаем Бушковым в подкасте.Книжный куб · чего разработчики ждут от ИИResearch Insights Made Simple №911Эту статью я разбирал в «Книжном кубе» и с Николаем Бушковым в подкасте.Книжный куб · чего разработчики ждут от ИИResearch Insights Made Simple №9

В работе Understanding and Designing for Trust in AI Powered Developer Tooling внимание направлено на доверие и возможность настроить взаимодействие с ИИ. Пользователи по-разному относятся к ошибочным подсказкам и вмешательствам инструмента. Поэтому единая частота предложений или навязанный способ использования могут плохо подходить части инженеров. Практический вопрос — как дать человеку достаточный контроль и понятную обратную связь, сохранив возможность получить помощь в нужный момент.

Продолжение Seamful AI for Creative Software Engineering добавляет тему творческой работы. Авторы обсуждают проектирование ИИ, которое оставляет место для осмысления и участия разработчика. Это не призыв специально замедлять любой инструмент. Полезное различие проходит между бессмысленной помехой и моментом, когда человек должен заметить предположение, рассмотреть альтернативу или проверить понимание. Удаляя все остановки без разбора, можно убрать и возможность учиться на собственных решениях.

Сентябрьская статья Navigating the Tensions of AI in the Software Development Lifecycle собирает четыре противоречия использования ИИ. В моём разборе от 16 сентября описана её основа: 1110 открытых ответов разработчиков Google о влиянии ИИ на работу за предшествующие три месяца. Это качественный анализ опыта в одной компании. Из него нельзя получить универсальный процент ускорения, распространённость каждого риска во всей индустрии или доказательство долгосрочной потери навыков. К разбору приложена моя аннотированная версия статьи.

Экономия работы и её перенос

Первое противоречие возникает между сэкономленным трудом и трудом, который переместился. Генерация может сократить набор текста, но добавить уточнение задания, проверку результата и исправление ошибок. Часть нагрузки может перейти к коллеге, который проверяет изменение. Поэтому время автора до отправки кода недостаточно для оценки результата. Нужно понять, что случилось с общей стоимостью доведения изменения до состояния, которому команда готова доверять.

Рекомендации, выделенные в разборе, касаются проверки по ходу работы: небольшие задачи, тесты внутри цикла агента, меньше переключений между разрозненными инструментами. Руководителю полезно проверить, где обнаруживаются ошибки. Если они стали появляться позднее, на более дорогом этапе, раннее ускорение может оказаться переносом затрат. Это исследовательская гипотеза для своей команды, а не заранее отрицательная оценка использования ИИ.

Быстрый результат и накопление долга

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

Позиционная статья Technical Debt in the AI Era помогает команде решить, какой долг исправлять с помощью AI и как проверить улучшение. ИИ способен помогать уменьшать долг, поэтому утверждение «генерация всегда увеличивает долг» столь же слабое, как обещание его автоматического исчезновения. Значение имеют выбранная задача, критерий приёмки и ответственность за последствия. Доверять инструменту исправление нужно вместе с возможностью проверить, что именно стало лучше.

Лёгкий старт и трудная последняя миля

Третье противоречие проявляется между быстрым прототипом и готовностью к реальной эксплуатации. Пограничные случаи, интеграция, права доступа и проверка поведения остаются частью работы. В моём разборе отмечены даже ответы о сообщениях инструмента, что тесты пройдены, хотя они не выполнялись. Это описанный участниками опыт, а не оценка частоты такого поведения всех инструментов. Но он показывает, почему утверждение агента об успехе нельзя считать самим свидетельством успеха.

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

Возможность сделать и способность проверить

Четвёртое противоречие касается обучения. ИИ помогает взяться за незнакомый язык или компонент, но проверка предложенного решения требует знаний. Ускоренное получение результата может пропустить самостоятельное исследование, через которое эти знания формируются. Авторы обсуждают риск; опрос не устанавливает неизбежную деградацию навыков. Для руководителя полезнее поставить проверяемый вопрос: какие задачи инженеры теперь могут решать и объяснять без постоянной внешней подсказки?

Сохранить обучение можно через объясняющее использование ИИ, наставничество и самостоятельную работу на тех участках, где нужна глубокая экспертиза. Важна и когнитивная нагрузка проверяющего: непрерывный аудит большого объёма чужого текста отличается от собственного последовательного решения. Возможность сказать «я не понимаю это изменение» или «мне не хватает времени на проверку» должна оставаться частью нормальной инженерной работы.

Так серия возвращает нас к исходной рамке. После внедрения ИИ меняются последовательности действий, распределение труда, способы обучения и содержание качества. Следовательно, нужно заново проверить, что видят старые метрики. Рост принятых подсказок, отправок кода или числа задач может быть полезным наблюдением. Решением о продуктивности он станет лишь после рассмотрения целей, проверенного результата и последствий для остальных участников.

Из исследований Google не следует необходимость воспроизводить всю их инфраструктуру. Компания другого размера может не иметь исследовательской команды, единого набора инструментов или достаточно большой выборки для обнаружения слабого эффекта. Переносить стоит дисциплину постановки вопроса. Сначала выбираем решение, которое хотим улучшить. Затем описываем цель инженера, границы работы, наблюдаемые затруднения и людей, на которых повлияет вмешательство.

Ниже — мой практический план первого месяца. Это управленческая эвристика по мотивам серии, а не проверенная авторами универсальная программа. Месяц нужен, чтобы запустить полезный цикл исследования и действия. Он не гарантирует, что за это время проявится полный эффект. История со сборками уже показывает, почему адаптация поведения может потребовать более длительного наблюдения.

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

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

Условия эксперимента и обратная связь

Перед запуском решите, какие данные изменят ваш выбор. Улучшенное сообщение может помочь лишь одной группе или только после обучения; поддержка может оказаться слишком дорогой, а метрика — нечувствительной. Такой результат тоже полезен, если меняет действие. Если любое движение графика оправдывает продолжение, гипотеза непроверяема.

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

Верните результат участникам: какую проблему выбрали, что попробовали, чего не выяснили и когда повторите проверку. Можно отказаться от изменения, объяснив причину. Но если после опроса следует только презентация руководству, полезная обратная связь постепенно исчезает.

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

Для меня главный вывод серии — улучшать работу инженеров, инструментов и организации вместе. Скорость создания артефактов важна, но способность команды понимать, проверять и развивать систему тоже нужно видеть и оценивать.