Сначала данные были на их стороне.

Что нам сказали

Нам сказали, что один инженер работает ниже ожидаемого уровня.

Опасения исходили от руководства продукта и разработки.

Инженера описывали как человека, который слишком долго поставляет результаты, слишком часто оспаривает решения и нарушает гармонию в команде.

Организация рассматривала возможность вывести этого инженера из команды.

Доказательства казались однозначными.

От момента назначения задачи в GitHub до открытия пул-реквеста этот инженер часто тратил больше времени, чем мы ожидали бы на саму реализацию.

По этому показателю инженер действительно был медленнее.

Что мы наблюдали

GitHub показывал затраченное время.

Но не показывал, чем инженер занимался в это время.

Поэтому мы проследили работу дальше — в Slack.

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

Это были не случайные возражения.

Это были попытки понять предпосылки требования или предложить альтернативу до начала реализации.

Продакт-оунер, как правило, считал эти вопросы и предложения излишними.

Когда предложение отклоняли, инженер сразу же приступал к реализации.

Когда вопрос или предложение оставались без ответа, инженер не ждал бесконечно.

Через три рабочих дня инженер сообщал, что ответа не поступило и реализация продолжится на основе исходного запроса.

Только после этого начиналась собственно работа по написанию кода.

Закономерность

Организация измеряла всё время между назначением задачи и поставкой как время выполнения разработки.

Но значительная часть этого времени уходила ещё до начала реализации.

Инженер пытался прояснить замысел, поставить под сомнение предположения или предложить альтернативу.

Эта деятельность не засчитывалась как полезная работа.

Её интерпретировали как задержку.

Эта интерпретация также формировала репутацию инженера.

Вопросы выглядели как сопротивление.

Альтернативные предложения выглядели как отказ следовать инструкциям.

Ожидание ответа по нерешённому продуктовому вопросу выглядело как медленная реализация.

Таким образом, одно и то же поведение служило доказательством сразу нескольких негативных суждений об этом человеке.

Затем мы нашли ещё один сигнал

Некоторые из отклонённых или проигнорированных предложений инженера никуда не исчезли.

После выпуска исходной реализации продакт-оунер иногда запрашивал ту же самую идею в одном из следующих спринтов.

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

Это имело значение.

Это показывало, что вопросы и альтернативные предложения инженера были не просто препятствием.

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

Наша гипотеза

Инженер страдал не столько от проблемы с компетенциями.

Организация создала среду, в которой один тип инженерного поведения вознаграждался больше всех остальных:

Выполнить инструкцию так, как она дана.

Вопросы к спецификации создавали задержку.

Предложение альтернативы создавало трения.

Ожидание разъяснений увеличивало измеряемое время выполнения (lead time).

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

Система измеряла не просто скорость поставки.

Она косвенно вознаграждала беспрекословное следование инструкциям.

Почему исходный диагноз выглядел убедительным

Исходное суждение опиралось не на вымышленные данные.

Затраченное время действительно было больше.

Именно это и делало кейс интересным.

Единственный источник данных подтверждал вывод организации.

Если бы мы остановились на GitHub, мы могли бы прийти к тому же выводу.

Но эта метрика отвечала лишь на один вопрос:

Сколько времени прошло между назначением задачи и поставкой?

Она не отвечала на вопросы:

• Когда реализация действительно началась?
• Что происходило до реализации?
• Кто кого ждал?
• Какие решения оставались нерешёнными?
• Какая ценность создавалась за пределами самого кода?

Что показали данные

Инженер был медленнее, если измерять только затраченное время до поставки.

Но эта цифра объединяла в одной метрике несколько разных видов деятельности.

Как только мы отделили реализацию от прояснения, предложений, принятия решений и времени ожидания, смысл этой цифры изменился.

Организация интерпретировала закономерность взаимодействия на уровне системы как проблему индивидуальной результативности.

Удаление инженера из команды не исправило бы эту закономерность.

Оно лишь убрало бы человека, чьё поведение делало эту закономерность заметной.

Данные не были ошибочными. Интерпретация была неполной.

Взгляд Pulsar

Мы не начинаем с того, чтобы решить, хорошо или плохо человек справляется со своей работой.

Мы прослеживаем саму работу.

В этом случае GitHub показал, что поставка занимала больше времени.

Slack показал, почему.

Более поздние продуктовые решения показали, что часть якобы излишнего поведения на самом деле выявляла реальную ценность.

Ни одно из этих наблюдений само по себе не рассказывало всю историю.

Вместе они изменили диагноз.

Мы не оцениваем людей по одному сигналу. Мы исследуем систему, которая этот сигнал породила.