Здесь более всего обескураживает следующее: этот менеджер не особенно стеснялся того, что ему не удалось предпринять какие-то шаги к улучшению рабочей среды. Такое ощущение, что программисты пожаловались на слишком сильную гравитацию, и руководство после должных размышлений пришло к выводу, что с этим ничего нельзя сделать, так как это проблема, решение которой выходит за пределы человеческих возможностей. Это политика абсолютного дефолта.
Изменение среды не выходит за пределы человеческих возможностей. Конечно, почти в каждой компании существует властная структура, мебельная полиция, управляющая всем хозяйством. Но разве нельзя донести до них здравые мысли или отобрать у них власть? В оставшейся части главы мы представим некоторые из причин, по которым следует сделать именно это, а в последующих главах приведём некоторые соображения относительно конкретных действий.
С 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 и С. Внутри каждой языковой группы распределение производительности было таким же, как в целом по выборке. Единственным исключением из этого наблюдения стал язык ассемблера: участники, писавшие на ассемблере, сильно отстали от всех остальных языковых групп. (Впрочем, люди, пишущие на ассемблере, привыкли к такому положению вещей.)
• Опыт: Люди с десятилетним опытом не превосходили по производительности тех, у кого опыта было всего два года. Опыт и производительность никак не коррелировали, разве что люди, менее шести месяцев имевшие дело с языком, работали не так эффективно, как другие участники.
• Количество недочётов: Около трети участников выполняли упражнение с нулевым количеством недочётов. В целом не было отмечено снижения производительности из-за более высокой точности работы. (Более того, в среднем эта треть участников выполняла задание быстрее, чем участники, допускавшие недочёты.)
Зарплата: Уровень зарплаты достаточно сильно варьировался для выборки. Между зарплатой и производительностью наблюдалась весьма слабая связь. Лучшая половина получала на десять процентов больше худшей, но работала почти в два раза эффективнее. Распределение производительности для любого уровня зарплаты было примерно таким же, как для выборки в целом[25].
Опять же ничего удивительного, поскольку большинство таких особенностей отмечалось ранее. Немного более удивительными были факторы, которые, как мы выяснили, на производительность влияли.
Среди обнаруженных нами факторов, положительно влияющих на производительность, оказался и весьма неожиданный: большое значение имел выбор напарника. Если вам доставался производительный напарник, все получалось и у вас. Если ваш напарник никак не мог закончить работу, не могли закончить её и вы. Если он совсем не мог завершить упражнение, вероятнее всего, то же получалось и у вас. В среднем разница в производительности для участников пары не превышала 21%.
Почему это так важно? Дело в том, что, хотя пары не работали совместно, участники каждой пары происходили из одной организации. (В большинстве случаев организацию представляли лишь два участника.) Они работали в одной физической среде и происходили из одной корпоративной культуры. Тот факт, что у них была практически одинаковая производительность, позволяет предположить, что широкое распределение способностей среди участников манёвров невозможно в организации: любые два человека из одной организации, как правило, имеют близкую производительность. Это означает, что лучшие работники накапливаются в определённых организациях, в то время как в других собираются худшие. Этот эффект Харлан Миллз (Harlan Mills) предсказал в 1981 году:
Такой разброс[27] в производительности отдельных программистов понятен, но существует точно такой же разброс в производительности организаций, разрабатывающих программное обеспечение[26].
22
Выкладки данных открытых исследований производительности с 1977 по 1981 годы представлены в работе DeMarco, 1982 {20}. Военные манёвры разработчиков описаны подробно в работе DeMarco и Lister, 1985 {22}.
23
Рисунок 8.1 с вариациями производительности и три основных правила происходят из трех источников: Boehm, 1981 {9}, стр. 435-437, 447; Sackman и др., 1968 {46}, стр. 3-11; Augustine, 1979 {6}. Последующий анализ, проведённый Майклом Лоуренсом из Университета Нового Южного Уэльса, придаёт этим трём правилам ещё больший вес (см. Lawrence, 1981 {36}).
24
Рисунок 8.2, отражающий вариации производительности в военных манёврах разработчиков 1984 года, взят из работы DeMarco и Lister, 1985 {22}.
25
Более подробно об очень слабых связях производительности и таких факторов, как зарплата и опыт, можно узнать из работы Lawrence и Jeffery, 1983 {37}.