blv May 5 2011 at 11:50

Эффект наблюдателя

3 min

24K

Чтобы узнать, посолен ли борщ, достаточно опустить в него два электрода, а затем пустить по ним ток. Если появится запах хлора — значит, борщ уже посолен :)

В физике есть такое понятие как «эффект наблюдателя»: если над системой ведется наблюдение, то оно вносит изменение в ее поведение. Очень интересно этот эффект проявляется в организации работы команд разработчиков (да и в любых производственных процессах). Как только мы начинаем считать любые метрики, мы вносим изменения в поведения команды и отдельных ее членов.

«Не навреди»

С точки зрения управления, мерить в численном виде (вводить метрику), идея, на первый взгляд, очень здравая. Мы получаем точные данные и на их основе производим необходимые действия. Но, к сожалению, не все так просто: как только мы вводим метрику, поведение команды начинает меняться. Команда и каждый ее член начинает подстраиваться под введенную нами метрику.

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

А между тем, это как ни парадоксально, это очень точная метрика. Два программиста в команде правят примерно одинаковое количество строчек за один и тот же промежуток времени. Конечно, необходимо много условностей (схожие задачи, наличие стандартов кодирования, например, максимальная длина метода, отсутствие дублирования, рефакторинг и так далее), но все же метрика достаточно точная… если не использовать ее как оценку производительности.

Можно попробовать сократить количество дефектов в нашем продукте, для чего считать, сколько багов сделал каждый разработчик. Лучших разработчиков будем награждать бонусами, а к худшим разработчикам — применять санкции. Все просто и прозрачно. Но на деле получиться по другому: разработчики будут спорить по каждому багу с тестировщиками, появится боязнь и желание избегать рисков, как результат отсутствие инициативы и нежелание делать поставленные задачи («Меньше задач, меньше багов»). Очень неплохой топик есть на хабре на эту тему «Живут, как тестировщик с программистом» за авторством Юлии Нечаевой.

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

Что же делать?

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

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

При внедрение метрик, как и любых других инноваций, очень неплохо использовать цикл Деминга: Plan-Do-Check-Act, чтобы у вас была возможность получить фидбек от команды и внести изменения в случае необходимости.

Вкусненькие ссылки

Tags:

Hubs:

Project management