Можно попробовать сократить количество дефектов в продукте, для чего считать, сколько ошибок сделал каждый разработчик. Лучших работников будем награждать бонусами, а к худшим применять санкции. Все просто и прозрачно. На деле получится по-другому: разработчики будут спорить по каждой ошибке с тестировщиками, появится боязнь и желание избегать рисков. В результате мы получим отсутствие инициативы и нежелание выполнять поставленные задачи (меньше задач – меньше ошибок).
Подойдем с другой стороны и будем считать, сколько ошибок находят тестировщики. В этой ситуации также появятся косвенные эффекты, ведь каждый тестировщик будет расценивать малейшее отклонение как дефект.
Вывод из приведенных выше примеров простой: при введении метрик необходимо руководствоваться прежде всего принципом «Не навреди».
Проанализируйте, как измерения могут повлиять на поведение команды и отдельных ее членов. Причем анализ надо проводить в первую очередь по поводу неочевидных аспектов, которые могут проявиться не сразу. Подумайте, какие метрики могут послужить основой для обсуждений, например, на ретроспективах, если вы используете Scrum. Может быть, ваши измерения в действительности никому не нужны и вы меряете просто потому, что можете мерить?
Посчитайте, сколько времени у вас уходит на сбор информации по метрикам. Весьма вероятно, что этот процесс можно автоматизировать, в особенности если мы говорим о метриках кода, метриках качества и т. п.
При внедрении метрик, как и любых других инноваций, хорошо использовать цикл Деминга Plan-Do-Check-Act («планирование-действие-проверка-корректировка»), чтобы у вас была возможность получить обратную связь от команды и внести изменения в случае необходимости.
