Человеческий фактор: успешные проекты и команды

Здесь более всего обескураживает следующее: этот менеджер не особенно стеснялся того, что ему не удалось предпринять какие-то шаги к улучшению рабочей среды. Такое ощущение, что программисты пожаловались на слишком сильную гравитацию, и руководство после должных размышлений пришло к выводу, что с этим ничего нельзя сделать, так как это проблема, решение которой выходит за пределы человеческих возможностей. Это политика абсолютного дефолта.

Изменение среды не выходит за пределы человеческих возможностей. Конечно, почти в каждой компании существует властная структура, мебельная полиция, управляющая всем хозяйством. Но разве нельзя донести до них здравые мысли или отобрать у них власть? В оставшейся части главы мы представим некоторые из причин, по которым следует сделать именно это, а в последующих главах приведём некоторые соображения относительно конкретных действий.

Военные манёвры разработчиков: наблюдаемые факторы производительности

С 1977 года мы ежегодно проводили открытое исследование производительности. К настоящему моменту в исследованиях приняли участие более трехсот организаций со всего мира. Начиная с 1984 года это ежегодное исследование проводилось в виде открытого конкурса, команды-участницы которого состояли из программистов различных организаций. Команды писали код заданного приложения и тестировали этот код на время. Мы назвали эти соревнования военными манёврами разработчиков (Coding War Games). Проходят они следующим образом:

• Боевую единицу составляют два разработчика из одной организации. Участники пары работают не совместно, но друг против друга, а также против всех других пар.

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

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

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

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

• Все результаты сохраняются в тайне.

За период с 1984 по 1986 годы более 600 разработчиков из 92 компаний приняли участие в манёврах[22]. Интерес отдельного участника состоит в том, чтобы оценить своё положение относительно других. Интерес компании в том, чтобы оценить свою эффективность относительно других компаний, участвующих в состязаниях. А наш интерес в том, чтобы как можно больше узнать о факторах, влияющих на производительность. Эти факты мы и обсудим ниже в данной главе.

Индивидуальные различия

Одним из первых результатов военных манёвров стало доказательство огромной разницы между участниками соревнований. Разумеется, на этот факт и раньше обращали внимание. На рис. 8.1 представлены результаты, полученные из различных источников, и он иллюстрирует масштабы различий между индивидуумами[23]:

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

• Отношение производительности лучших сотрудников к производительности худших составляет примерно 10:1.

• Наиболее производительный сотрудник в 2,5 раза более производителен, чем средний.

• Наиболее производительная половина сотрудников имеет в 2 раза большую производительность, чем менее производительная половина.

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

Результаты военных манёвров разработчиков достаточно точно соответствовали такому распределению. В качестве примера рассмотрим рис. 8.2, на котором показано распределение затрат времени на достижение первого промежуточного финиша (чистая компиляция, готовность к тестированию) для манёвров 1984 года[24]:

Лучшая производительность в 2,1 раза превышает среднюю. Лучшая половина опережает худшую в соотношении 1,9:1. Результаты последующих манёвров были практически идентичны этим.

Что не влияет на производительность

Исследуя результаты состязаний, мы обнаружили, что следующие факторы слабо влияли на производительность или не влияли вовсе:

• Язык: Разработчики, использовавшие старые языки, такие как COBOL или Fortran, выполняли задание не хуже тех, кто писал на Pascal и С. Внутри каждой языковой группы распределение производительности было таким же, как в целом по выборке. Единственным исключением из этого наблюдения стал язык ассемблера: участники, писавшие на ассемблере, сильно отстали от всех остальных языковых групп. (Впрочем, люди, пишущие на ассемблере, привыкли к такому положению вещей.)