Команда делала именно то, о чём её просили.

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

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

Работа занимала больше времени, чем ожидалось. Функциональность доходила до ревью, но не принималась. Релизы срывались.

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

Если это объяснение было верным, очевидным местом для расследования была продуктивность разработки.

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

Команда работала итеративно.

Перед реализацией обсуждалась история (story), и определялось ожидаемое поведение. Затем команда разработки реализовывала это поведение в течение спринта.

Инженеры не игнорировали эти требования.

Они их реализовывали.

Проблема проявлялась позже.

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

Например, история могла определять один рабочий процесс для конкретной операции.

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

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

На ревью ожидание могло измениться: система сама должна восстанавливаться после сбоя, не требуя действий от пользователя.

В ещё одном случае функция предпросмотра могла удовлетворять согласованным критериям — но во время ревью дополнительно требовалась функция редактирования.

Каждое отдельное требование могло быть обоснованным.

Проблема была не в этом.

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

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

Их расценивали как доказательство того, что команда разработки не смогла корректно реализовать исходную спецификацию.

Это различие меняло всё.

С точки зрения продакт-оунера, запрошенная функциональность не была завершена.

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

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

Но наблюдаемая последовательность работы была иной:

1. Критерии приёмки согласовывались.
2. Команда разработки их реализовывала.
3. Во время ревью появлялись новые ожидания.
4. Новые ожидания не классифицировались как изменения.
5. Из-за этого исходная реализация считалась незавершённой.
6. Дополнительная работа увеличивала срок поставки.
7. Задержку относили на счёт продуктивности разработки.

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

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

Система, определявшая, завершена ли работа, была нестабильной.

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

Это создаёт особенно трудноразрешимую проблему продуктивности.

Ускорение написания кода её не решает.

Улучшение инструментов её не решает.

Требование к разработчикам оценивать точнее её не решает.

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

Почему проблему было трудно увидеть

Никому не нужно было быть нечестным, чтобы эта система возникла.

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

Разработчики вполне могли искренне считать, что реализовали именно то, что было согласовано.

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

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

Поэтому нам не нужно было решать, чья интерпретация верна.

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

Разница была наблюдаемой.

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

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

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

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

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

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

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

Взгляд Pulsar

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

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

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

Заявленной проблемой была продуктивность разработки. Наблюдаемая проблема находилась в другом месте.