Таблица 5.1. Производительность как функция оценки сложности (частичный результат)
Оценка сложности выполнялась
Средняя производительность
Число проектов
Программистом
8,0
19
Начальником
6,6
23
Программистом и начальником
7,8
16
Пока что результаты подтверждают популярное мнение: программисты, похоже, чуть более продуктивны, когда могут оценивать необходимое время самостоятельно, в отличие от случаев, когда оценку выполняет руководитель, не советуясь с ними. Когда же руководитель советуется с разработчиком, результат, как правило, получается промежуточный.
Для 21 проекта из числа изученных в тот год оценки выполнялись третьей стороной – как правило, системным аналитиком. Разработчики в этих проектах показали более высокую производительность, чем разработчики в проектах, где оценка времени проводилась разработчиками и/или руководителями (табл. 5.2).
Таблица 5.2. Производительность как функция оценки сложности (частичный результат)
Оценка сложности выполнялась
Средняя производительность
Число проектов
Программистом
8,0
19
Начальником
6,6
23
Программистом и начальником
7,8
16
Системным аналитиком
9,5
21
Последняя строка уже идет вразрез с популярным мнением. Почему программисту приходится работать интенсивнее, чтобы уложиться в оценку аналитика, чем в случае, когда оценку выполняет он сам? Есть соблазн объяснить такие показатели простыми погрешностями в данных. Но если вы согласитесь с нами в том, что плохие прогнозы всегда являются фактором, снижающим мотивацию, не будет никакой необходимости пытаться пренебречь полученными данными. Системные аналитики более склонны к точным оценкам, чем программисты или руководители. Системный аналитик, как правило, владеет той же информацией о поставленной задаче, но его не сдерживает природный оптимизм исполнителя или политические и финансовые взгляды шефа. Более того, системные аналитики имеют бо́льший опыт в оценке, они способны предсказывать результаты более точно, поскольку уже занимались этим в прошлом и делали соответствующие выводы.
Отрицательные прогнозы и безнадежно малые сроки поглощают энергию автора. Кейперс Джоунс (Capers Jones), известный своими количественными исследованиями проектов по разработке, сформулировал эту мысль так: «Когда расписание проекта совершенно необоснованно и нереалистично, и притом никакой объем сверхурочных не позволяет уложиться в сроки, команда, работающая над проектом, начинает испытывать злость и отчаяние... боевой дух падает до предела».3 При этом не имеет особого значения, исходит ли это «совершенно необоснованное и нереалистичное» расписание от начальства или от самих создателей продукта. Оказавшись в безвыходной ситуации, люди просто не работают эффективно.
Самая удивительная часть исследования 1985 года появилась последней, когда Лоуренс и Джеффри исследовали производительность в 24 проектах, для которых вообще не было сделано никаких предварительных оценок. Эти проекты с большим отрывом опередили все остальные (табл. 5.3).
Таблица 5.3. Производительность как функция оценки сложности (полный результат)
Оценка сложности выполнялась
Средняя производительность
Число проектов
Программистом
8,0
19
Начальником
6,6
23
Программистом и начальником
7,8
16
Системным аналитиком
9,5
21
(Без оценки)
12,0
24
Проекты, в которых шеф не оказывал временно́го давления вообще («Разбудите меня, когда все будет готово»), характеризовались самой высокой производительностью. Конечно, изложенное не позволяет сказать, что закон Паркинсона вообще никак не действует на разработчиков. Но наводит на интересные мысли, не так ли?
Решение о том, оказывать ли временно́е давление на проект, следует принимать так же, как решение о наказании ребенка. Если наказания редки, а вы безупречно выбираете время и правомерность наказаний очевидна, положительный эффект возможен. Если же вы делаете это постоянно, то это уже признак ваших собственных проблем.
Вариация на тему закона Паркинсона
Слегка перефразировав закон Паркинсона, мы получим утверждение, до боли правдивое для многих организаций:
