Исправление неудачных команд

Получая в наследство уже существующую команду, вы становитесь чем-то вроде дантиста, принимающего пациента, который не встречался с дантистом около 20 лет, и его зубы начали портиться. Вы собираетесь делать три вещи.
1. Подробное исследование и рентген. После чего вы узнаете, где что не так: какие зубы целы, каким требуется "ремонт", а какие просто нужно удалить и заменить.
2. Много-много сверления, чтобы расчистить "дупла".
3. Заполнение пломбами и фарфоровыми протезами больших проемов, оставшихся после сверления.
Скорее всего будет довольно больно и вам придется засовывать пальцы в рот пациенту, но после нескольких недель болезненной работы у него снова появится прекрасная улыбка. И если вы исполните священный долг дантиста, то напугаете пациента до такой степени, что он будет избегать всех дантистов следующие 20 лет.
Да знаю я, вы всегда говорите пациенту, что ему надо всерьез начинать чистить зубы вощеной ниткой. Тогда скажите, как это получается у вас.
Как это не надо делать: измерения и стимулы
Крайне популярным и якобы научным считается исправление команды с помощью измерений и стимулов.
Например, вы решили начать считать строки кода, ежедневно создаваемого каждым разработчиком. Разработчики с максимальным числом строк получают премию. У кого среднее количество строк, те сохраняют свое место. Попадите в низшие 20%, и вы уволены.
Это довольно распространенный прием управления, а он имеет разрушительный эффект.
Дело в том, что вы как программист можете тривиально увеличить количество строк, создаваемых вами каждый день. Просто иногда вставляйте в код пустые строки.
- Хорошо, - скажете вы. - Будем считать непустые строки кода.
- Ладно, - скажут программисты. - Будем писать много комментариев. Длинные пояснительные абзацы по три слова в каждой строке.
- Ну, комментарии я ценю, но эти - сплошной обман. Буду считать только строки настоящего кода.
- Ладно, не будете платить за комментарии, я их совсем писать не буду. А вызов каждой функции я раздвину так, что каждый ее аргумент будет на отдельной строке. Это будет разумно!
- Да-а! - думаете вы. - Может быть, есть то, что можно посчитать и с чем труднее делать махинации. Буду считать выражения; счет не изменится, даже если раздвигать их на несколько строк.
- Ладно. Вот у меня большой блок устаревшего кода, который больше не используется. Вообще-то его надо удалить, чтобы он не запутал другого программиста, читающего мой код. Но, удалив 500 строк кода, я на ближайшие два месяца стану наихудшим программистом в команде. Поэтому я этот блок просто "окружу" загадочным if-выражением, чтобы он никогда не выполнялся. Может быть, тогда не попаду под ваши санкции.
Этот диалог может продолжаться еще долго. Начальники явно верят, что есть некая единица измерения, с помощью которой можно мерить производительность, и надо просто выработать определенные правила, чтобы не было махинаций с этой единицей.
Программисты знают, в каких бы единицах вы ни измеряли, результаты измерений можно оптимизировать. Причем тривиально. 
Как бы вы ни измеряли.
Поэтому измерять, откровенно говоря, бесполезно. Измерять - это плохо?
Да, оказывается, что плохо. Профессор Роберт Д. Остин из Гарвардской школы бизнеса провел на эту тему большие исследования и написал классический труд Измерение производительности и управление ею в организациях1. Суть книги в том, что люди - не химические опыты, они сами себя осознают, и когда вы пытаетесь измерить что-то к ним относящееся, то они это ощущают. Кроме того, с помощью имеющихся у людей мозгов полученные значения измерений будут выглядеть так, как этим людям нужно.
Как показано в книге, какую бы новую единицу измерения вы ни устанавливали в "знающей" организации, т.е. в такой, работникам которой надо делать нечто более сложное, чем просто закручивать колпачки на тюбиках с зубной пастой, вначале будет заметно общее улучшение того, что вы хотите измерять. Программисты действительно будут стараться писать больше кода каждый день. Но очень скоро вы заметите, что работники придумывают ухищрения, позволяющие ре­зультатам измерений расти до небес, хотя реальная производительность будет на самом деле падать, ведь программисты начнут тратить больше времени на оптимизацию результатов измерений, которая будет делаться за счет качества выполняемой ими работы.
Более важно следующее: это происходит не просто из-за того, что вы не нашли совершенную единицу измерения, а из-за самой природы "знающей"работы.