Шрифт:
Интервал:
Закладка:
Существует вызывающий беспокойство вариант, что сверхурочные – это средство увеличить не столько количество, сколько среднее качество продукции. Подтверждения можно найти в распространённых утверждениях вроде этих:
«Лучше всего мне работается ранним утром – до того как приходят остальные.»
«Поздним вечером я могу выполнить объём работы, рассчитанный на два или три дня.»
«Целый день с утра наш офис – просто зоопарк, зато к шести вечера все стихает и можно, наконец, что-то сделать.»
Чтобы получить возможность работать продуктивно, люди приходят пораньше, или остаются на вечер, или просто пытаются избежать появления в офисе – остаются на день дома, чтобы сделать важный фрагмент работы. Одна из участниц нашего семинара рассказывала, что шеф не разрешает ей работать дома, поэтому накануне сдачи важного отчёта она взяла больничный, чтобы успеть его сделать.
Необходимость оставаться дома, задерживаться на работе, приходить раньше, чтобы спокойно поработать, – убийственное обвинительное заключение против офисной среды. Поразительно не то, что так часто нет возможности поработать на своём рабочем месте, поразительно, что все знают об этом и ничего никогда не делают, чтобы исправить положение.
Политика дефолта
Одна калифорнийская компания, которую я консультирую, заботится о потребностях сотрудников. В прошлом году руководство компании провело исследование, в ходе которого всех программистов (более тысячи человек) попросили перечислить лучшие и худшие аспекты их работы. Менеджер, руководивший исследованием, был в восторге от последовавших изменений в компании. Он рассказал мне, что второй по распространённости проблемой была слабая связь с руководителями высшего звена. Узнав об этом, компания организовала кружки качества, пятиминутки жалоб и прочие программы коммуникации. Я вежливо выслушал подробности о пресловутых программах и, когда он закончил, спросил, какая проблема оказалась самой первой. «Среда, – ответил он. – Людей раздражает шум». «Какие же шаги компания предприняла, чтобы решить эту проблему?» – поинтересовался я. «О, с этим мы ничего поделать не смогли, – сказал он. – Это уже не в наших силах».
Здесь более всего обескураживает следующее: этот менеджер не особенно стеснялся того, что ему не удалось предпринять какие-то шаги к улучшению рабочей среды. Такое ощущение, что программисты пожаловались на слишком сильную гравитацию, и руководство после должных размышлений пришло к выводу, что с этим ничего нельзя сделать, так как это проблема, решение которой выходит за пределы человеческих возможностей. Это политика абсолютного дефолта.
Изменение среды не выходит за пределы человеческих возможностей. Конечно, почти в каждой компании существует властная структура, мебельная полиция, управляющая всем хозяйством. Но разве нельзя донести до них здравые мысли или отобрать у них власть? В оставшейся части главы мы представим некоторые из причин, по которым следует сделать именно это, а в последующих главах приведём некоторые соображения относительно конкретных действий.
Военные манёвры разработчиков: наблюдаемые факторы производительности
С 1977 года мы ежегодно проводили открытое исследование производительности. К настоящему моменту в исследованиях приняли участие более трехсот организаций со всего мира. Начиная с 1984 года это ежегодное исследование проводилось в виде открытого конкурса, команды-участницы которого состояли из программистов различных организаций. Команды писали код заданного приложения и тестировали этот код на время. Мы назвали эти соревнования военными манёврами разработчиков (Coding War Games). Проходят они следующим образом:
• Боевую единицу составляют два разработчика из одной организации. Участники пары работают не совместно, но друг против друга, а также против всех других пар.
• Оба участника пары выполняют совершенно одинаковую работу: проектируют, создают и тестируют среднего размера программу по нашей спецификации.
• Выполняя упражнения, участники записывают потраченное время в специальный журнал.
• Когда все участники завершают тестирование, результаты проходят наши стандартные процедуры приёмки.
• Участники работают на своих привычных рабочих местах, используют те же языки, инструменты, терминалы и компьютеры, что и для всех своих проектов.
• Все результаты сохраняются в тайне.
За период с 1984 по 1986 годы более 600 разработчиков из 92 компаний приняли участие в манёврах[22]. Интерес отдельного участника состоит в том, чтобы оценить своё положение относительно других. Интерес компании в том, чтобы оценить свою эффективность относительно других компаний, участвующих в состязаниях. А наш интерес в том, чтобы как можно больше узнать о факторах, влияющих на производительность. Эти факты мы и обсудим ниже в данной главе.
Индивидуальные различия
Одним из первых результатов военных манёвров стало доказательство огромной разницы между участниками соревнований. Разумеется, на этот факт и раньше обращали внимание. На рис. 8.1 представлены результаты, полученные из различных источников, и он иллюстрирует масштабы различий между индивидуумами[23]:
Похоже, что при измерении вариаций производительности для выборки индивидуумов действуют три основных правила:
• Отношение производительности лучших сотрудников к производительности худших составляет примерно 10:1.
• Наиболее производительный сотрудник в 2,5 раза более производителен, чем средний.
• Наиболее производительная половина сотрудников имеет в 2 раза большую производительность, чем менее производительная половина.
Эти правила действуют практически на любые параметры производительности, которые возможно определить. Так, к примеру, лучшая половина выборки сделает заданную работу минимум в полтора раза быстрее остальных; представители другой половины, которые чаще ошибаются, сделают две трети всех ошибок и так далее.
Результаты военных манёвров разработчиков достаточно точно соответствовали такому распределению. В качестве примера рассмотрим рис. 8.2, на котором показано распределение затрат времени на достижение первого промежуточного финиша (чистая компиляция, готовность к тестированию) для манёвров 1984 года[24]: