Ознакомительная версия.
Изменение среды не выходит за пределы человеческих возможностей. Конечно, почти в каждой компании существует властная структура, мебельная полиция, управляющая всем хозяйством. Но разве нельзя донести до них здравые мысли или отобрать у них власть? В оставшейся части главы мы представим некоторые из причин, по которым следует сделать именно это, а в последующих главах приведём некоторые соображения относительно конкретных действий.
Военные манёвры разработчиков: наблюдаемые факторы производительности
С 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].
Software Productivity
Наше исследование показало огромные различия между 92 организациями, принявшими в нем участие. В целом по выборке лучшая организация (показавшая лучшую среднюю производительность своих сотрудников) работает в 11,1 раза быстрее, чем худшая. Код, созданный участниками из быстрейшей организации, оказался не только самым быстрым, он также прошёл основные приёмочные испытания.
Это вызывает серьёзную тревогу. В течение многих лет руководители проявляли определённый фатализм в отношении индивидуальных различий. Они утверждали, что различия присущи людям, так что с ними ничего нельзя поделать. Гораздо труднее проявлять фатализм по поводу эффекта накопления. В некоторых компаниях дела обстоят гораздо хуже, чем в других. Что-то в среде и корпоративной культуре этих компаний противодействует привлечению и сохранению хороших сотрудников или не позволяет им эффективно работать.
Влияние рабочего места
Суровая правда жизни такова, что многие компании предоставляют разработчикам места столь тесные, шумные и подверженные внешним воздействиям, что невозможно работать, не испытывая раздражения. Один этот факт может объяснить пониженную эффективность, а также тенденцию перехода хороших сотрудников в другие компании.
Гипотеза о том, что свойства рабочего места могут сильно влиять на эффективность труда разработчика, легко поддаётся проверке. Достаточно разработать набор фиксированных тестовых задач, сходных с теми, которые разработчики обычно выполняют во время работы, и понаблюдать, насколько хорошо люди справляются с этими задачами в различной обстановке. Военные манёвры разработчиков проектировались именно с этой целью.
Ознакомительная версия.
