Как измерять цели разработчиков

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

Статью участники называют типично гугловской: очень структурированной, на вид про простые вещи, но детали в ней действительно важны. Александр, прочитавший почти всю серию, поясняет формат: это колонка, в которой у исследователей Google накопилось уже десять, если не пятнадцать статей, — они пересказывают выводы человеческим языком, без панельного анализа, регрессий и обсуждения статистической значимости, а на полноценные работы дают ссылки. Частей в статье семь: первая и последняя стандартные — введение с аннотацией и список источников, внутри пять содержательных кусков. Главный сюжет — подход critical user journey, который в Google применяют давно и который ведущему напоминает customer journey map, но на собственных разработчиков как на пользователей внутренних инструментов его навели только недавно. Сапожник без сапог: компания сделала кучу продуктов по этой методике, а взгляд внутрь себя оказался инновацией. Если очевидная идея до сих пор не применена, обычно в ней закопана сложность.

Эта сложность видна в критериях, которыми авторы ограничили список целей. Цель должна быть общей, а не специфичной для одного проекта и не временной: в Google десятки тысяч разработчиков, тысячи проектов и сотни технологий, и полное пространство сценариев как минимум очень велико. Цель должна иметь смысл именно для разработчиков — это ещё немного сужает вовлечённую популяцию. Цель должна быть связана с наблюдаемым поведением: не можешь пощупать — значит, этого нет, иначе в списке остались бы психологические сюжеты, происходящие только в голове. Цели должны быть сопоставимой гранулярности и опираться на стадии жизненного цикла разработки, с которыми плюс-минус все согласны, — иначе не сравнить вклад сценариев и не понять, куда прикладывать усилия. В разговоре всплывает аналогия с декомпозицией работ в проектном управлении: на выровненных кусочках начинает работать статистика, точность оценки растёт как корень из N, на этом же держатся story points.

Пятый критерий — цели должны покрывать весь жизненный цикл, иначе сложность останется закопанной в той части, про которую забыли или умолчали. Гость приводит аналогию из своего оптимизаторского прошлого: первое, чему учат при оптимизации, — сначала померяйте всё вместе, от начала до конца, потому что оптимизировать всегда хочется отдельный компонент, а ценность создаётся сквозным путём. Сам список собирали четырёхтактным процессом, и в разговоре разобрали два первых такта: сначала эксперты дали первоначальные гипотезы о целях, потом гипотезы сверили с данными. Фундамент был готов: с 2018 года в Google идёт Engineering Satisfaction Survey — опрос проводят каждый квартал, но групп инженеров четыре, и одна и та же группа попадает в него не чаще раза в три квартала. По оценке гостя, на практике группу спрашивают раз в девять месяцев или раз в год, так что между опросами успевает материально что-то поменяться. Плюс логи внутренних инструментов: по частотности видно, какой сценарий массовый, а какой специфичен для узкого скоупа.

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

А у цели «найти информацию» или «найти эксперта» одного инструмента нет вовсе — в «Кортехе» на это ответили поиском сразу по разным источникам. Авторы научились ловить в логах старт сценария и смотреть путь целиком, а путь бывает цикличным: тесты упали, ты пошёл в документацию, нашёл эксперта, вернулся и починил. В разрезе инструмента это выглядит как «запустил, через два часа запустил снова, всё хорошо», и два часа хождения по кругу никого не интересуют. Второй сюжет — два графика, где опросная оценка лежит рядом с измеренной: недовольным починка инструмента не поможет, если причина не в нём, а в перегрузке и нехватке времени. Опросы масштабируются легко, телеметрия со всех инструментов — нет, поэтому SPACE как продукт внешней платформы не взлетел: даже жизненный цикл задачи в Jira у всех свой, и надежду на единообразие гость оставляет разве что за git. Ведущий вспоминает интервью Кента Бека, скептика метрик: метрики — скальпель, которым можно натворить дел, а ответом на это становится методология использования и обучение людей, то есть скальпель стоит поставлять вместе с обученным хирургом. Сходятся на том, что подход авторов ближе к научному исследованию с анализом угроз валидности, чем к инфоцыганству.