[8].
Такие слова могут показаться обличительной речью, направленной против пользователей программного обеспечения и стандартов рынка в целом, но не стоит воспринимать их подобным образом. Мы должны исходить из того, что люди, финансирующие наш труд, находятся в здравом уме и способны принять разумный компромисс между качеством и стоимостью. Основная идея здесь в том, что осознаваемая клиентом потребность в качестве зачастую не столь велика, как аналогичная потребность разработчика. Существует естественное противоречие. Снижение качества продукта, вероятно, приведёт к тому, что некоторые люди откажутся от покупки, но сокращение рыночной доли – прямое следствие любого подобного снижения качества – зачастую компенсируется увеличением прибылей на каждую проданную единицу продукта.
Бегство от совершенства– так мы называем ситуацию, когда стандарты качества устанавливает покупатель, а не создатель. Стандарты, основанные на существующем рыночном качестве, имеют смысл лишь до тех пор, пока вы не обращаете внимания на настроение и эффективность труда разработчиков.
В долгосрочной перспективе рыночные стандарты качества обходятся дороже. Какой урок отсюда следует?
Качество, серьёзно превосходящее запросы конечного пользователя, есть средство достижения более высокой производительности.
Если вы сомневаетесь в этом, вообразите следующий глубокомысленный эксперимент: спросите сто человек с улицы, какая культура или нация прославилась благодаря высокому качеству. Предсказываем, что более половины людей сегодня ответят «японская». Теперь спросите у другой сотни людей, какая культура или нация известна высокой производительностью. И опять можно ожидать, что большинство ответят «японская». Нация, признанная лидером в области качества, столь же известна своей высокой продуктивностью.
Постойте. Как же возможно, что более высокое качество сосуществует с более высокой производительностью? Ведь это противоречит прописной истине, что повышение качества продукта означает увеличение его себестоимости. Вот подсказка Тадзимы (Tajima) и Мацубары (Matsubara), двух авторитетных комментаторов японского феномена:
В Японии компромисс между качеством и стоимостью не существует. Здесь почто все считают, что высокое качество приводит к сокращению стоимости [9].
Нас терзает ужасное подозрение, что книга Кросби принесла скорее вред, чем пользу. Беда в том, что подавляющее большинство руководителей не затруднилось эту книгу прочитать, хотя название слышали все. Название и стало восприниматься как основная идея книги. Руководители по всему миру проявляют энтузиазм в отношении качества: «Нет пределов для качества, и у нас будет столько бесплатного качества, сколько мы захотим!». Навряд ли это можно назвать беспокойством о качестве. Такое отношение совершенно противоположно тому, за которое ратует Кросби.
На самом деле идею связи качества и производительности следует представить немного иными словами:
Качество не стоит ничего, но только для тех, кто готов дорого за него заплатить.
Организация, готовая заплатить за качество ноль долларов и ноль центов, получит то, за что заплатила. Правило «Качество? Если успеем!» гарантирует отсутствие всякого качества в продукте.
Примером организации, пожинающей обильный урожай производительности за счёт высоких авторских стандартов качества, является Hewlett-Packard. Качество в этой компании возведено в ранг культа. В такой среде обычно не услышишь аргумент, что для создания более качественного продукта потребуется больше времени или денег. В результате разработчики осознают, что качество создаваемых ими продуктов превосходит потребности рынка. Возможность руководствоваться собственными критериями даёт им большее удовлетворение от работы, а компании – одни из самых низких показателей текучести кадров в отрасли.
Сможете ли вы наделить своих людей правом вето? Да, нервы потребуются стальные, по крайней мере, поначалу. Главной вашей заботой станет Закон Паркинсона, способный заработать против вас. Эта тема настолько важна, что мы посвятили ей целую главу.
5. Ещё раз о законе Паркинсона
6. Лаетрил
II. ОФИСНАЯ СРЕДА
Такие слова могут показаться обличительной речью, направленной против пользователей программного обеспечения и стандартов рынка в целом, но не стоит воспринимать их подобным образом. Мы должны исходить из того, что люди, финансирующие наш труд, находятся в здравом уме и способны принять разумный компромисс между качеством и стоимостью. Основная идея здесь в том, что осознаваемая клиентом потребность в качестве зачастую не столь велика, как аналогичная потребность разработчика. Существует естественное противоречие. Снижение качества продукта, вероятно, приведёт к тому, что некоторые люди откажутся от покупки, но сокращение рыночной доли – прямое следствие любого подобного снижения качества – зачастую компенсируется увеличением прибылей на каждую проданную единицу продукта.
Бегство от совершенства– так мы называем ситуацию, когда стандарты качества устанавливает покупатель, а не создатель. Стандарты, основанные на существующем рыночном качестве, имеют смысл лишь до тех пор, пока вы не обращаете внимания на настроение и эффективность труда разработчиков.
В долгосрочной перспективе рыночные стандарты качества обходятся дороже. Какой урок отсюда следует?
Качество, серьёзно превосходящее запросы конечного пользователя, есть средство достижения более высокой производительности.
Если вы сомневаетесь в этом, вообразите следующий глубокомысленный эксперимент: спросите сто человек с улицы, какая культура или нация прославилась благодаря высокому качеству. Предсказываем, что более половины людей сегодня ответят «японская». Теперь спросите у другой сотни людей, какая культура или нация известна высокой производительностью. И опять можно ожидать, что большинство ответят «японская». Нация, признанная лидером в области качества, столь же известна своей высокой продуктивностью.
Постойте. Как же возможно, что более высокое качество сосуществует с более высокой производительностью? Ведь это противоречит прописной истине, что повышение качества продукта означает увеличение его себестоимости. Вот подсказка Тадзимы (Tajima) и Мацубары (Matsubara), двух авторитетных комментаторов японского феномена:
В Японии компромисс между качеством и стоимостью не существует. Здесь почто все считают, что высокое качество приводит к сокращению стоимости [9].
Качество ничего не стоит, но…
Именно об этом Филип Кросби (Philip СговЬу) написал книгу «Quality Is Free» (Качество бесплатно), опубликованную в 1979 году. В этой работе Кросби привёл многочисленные примеры и чётко доказал, что если исполнитель работы устанавливает удовлетворяющий его самого стандарт качества, то увеличение производительности компенсирует удорожание более высокого качества [10].Нас терзает ужасное подозрение, что книга Кросби принесла скорее вред, чем пользу. Беда в том, что подавляющее большинство руководителей не затруднилось эту книгу прочитать, хотя название слышали все. Название и стало восприниматься как основная идея книги. Руководители по всему миру проявляют энтузиазм в отношении качества: «Нет пределов для качества, и у нас будет столько бесплатного качества, сколько мы захотим!». Навряд ли это можно назвать беспокойством о качестве. Такое отношение совершенно противоположно тому, за которое ратует Кросби.
На самом деле идею связи качества и производительности следует представить немного иными словами:
Качество не стоит ничего, но только для тех, кто готов дорого за него заплатить.
Организация, готовая заплатить за качество ноль долларов и ноль центов, получит то, за что заплатила. Правило «Качество? Если успеем!» гарантирует отсутствие всякого качества в продукте.
Примером организации, пожинающей обильный урожай производительности за счёт высоких авторских стандартов качества, является Hewlett-Packard. Качество в этой компании возведено в ранг культа. В такой среде обычно не услышишь аргумент, что для создания более качественного продукта потребуется больше времени или денег. В результате разработчики осознают, что качество создаваемых ими продуктов превосходит потребности рынка. Возможность руководствоваться собственными критериями даёт им большее удовлетворение от работы, а компании – одни из самых низких показателей текучести кадров в отрасли.
Право вето
В отдельных японских компаниях, в частности Hitachi Software и некоторых подразделениях Fujitsu, команда проекта имеет право налагать вето на сдачу продукта, если по мнению команды этот продукт не готов. Не имеет значения, готов ли клиент принять низкокачественный продукт, команда может настоять на том, чтобы сдача продукта была отложена до тех пор, пока он не будет удовлетворять собственным стандартам разработчиков. Разумеется, руководители проектов там находятся под тем же давлением, что и у нас: от них требуют результатов немедленно – покажите нам хоть что-нибудь прямо сейчас. Однако культура качества в достаточной степени распространена, так что эти японские руководители понимают, насколько неправильно склонять сотрудников к компромиссам в области качества.Сможете ли вы наделить своих людей правом вето? Да, нервы потребуются стальные, по крайней мере, поначалу. Главной вашей заботой станет Закон Паркинсона, способный заработать против вас. Эта тема настолько важна, что мы посвятили ей целую главу.
5. Ещё раз о законе Паркинсона
В 1954 году англичанин Сирил Паркинсон выразил мнение, что работа растёт, заполняя любое отведённое под неё время. Сейчас это мнение известно как закон Паркинсона
[11].
Если не знать, что весьма немногие руководители проходят обучение менеджменту, можно подумать, что существует спецшкола, в которой они посещают интенсивный курс по закону Паркинсона и его вариациям. Даже руководители, не знающие вообще ничего о менеджменте, цепляются за эту аксиоматическую истину – закон Паркинсона, руководящую людьми и их отношением к работе. Он даёт им крайнюю убеждённость в том, что единственный способ добиться выполнения работы – это установить невозможно оптимистические сроки её сдачи.
Паркинсон учёным не был. Он не собирал данные и, вероятно, даже не понимал правил статистических заключений. Паркинсон был юмористом. Его «закон» получил такое распространение не потому, что он соответствовал действительности. Просто шутка была забавная.
Разумеется, закон Паркинсона кажется нам забавным, поскольку в нем есть частичка истины. Паркинсон приводит примеры действия своего закона в рамках вымышленной правительственной бюрократической машины, прообразом которой, по мнению некоторых, является Британская почтовая служба. Бюрократия подвержена таким проблемам, потому что её сотрудники почти не получают удовлетворения непосредственно от рабочих задач. Но вы-то, вероятно, не состоите в бюрократии. А если и состоите, то изо всех сил стараетесь устроить так, чтобы ваших людей её воздействие не затрагивало, потому что в противном случае они никогда ничего не сделают. В результате ваши люди имеют возможность получать от работы удовлетворение. Из этого следует простая истина, которую имеет смысл озвучить:
Закон Паркинсона наверняка не применим к вашим людям.
Их жизнь слишком коротка, чтобы они стали отлынивать от работы. Раз им нравится работа, они не склонны растягивать её до бесконечности, поскольку это лишь отсрочит удовлетворение, ради которого все они стараются. Они не меньше вашего желают выполнить работу, но только с тем условием, что им не придётся нарушать собственные стандарты качества.
В здоровой рабочей обстановке причинами стагнации для некоторых людей становятся недостаток компетенции, нехватка уверенности, а также неопределённость цели проекта и отсутствие интеграции с командой. Ни в одном из этих случаев временное давление помочь не способно. Скажем, когда сотрудник вяло работает и кажется, что он не задумывается о качестве своих результатов, это верный признак того, что бедняга подавлен сложностью работы. Ему не нужно более сильное давление. Ему нужна смена деятельности, возможно, просто перевод в другую компанию.
Даже в тех редких случаях, когда давление на человека остаётся единственным вариантом, руководитель должен это давление оказывать последним. Эффект гораздо сильнее, когда давление исходит от команды. Нам встречались случаи однородных команд, где руководителям пришлось бы занимать очередь, чтобы покричать на единственного человека, который не старается вмести со всеми.
В последующих главах мы ещё не раз вернёмся к командам и разумному их формированию. А пока речь не о том, что действует. Речь о том, что не действует: не действует отношение к сотрудникам, основанное на законе Паркинсона. Оно способно лишь унизить и лишить мотивации.
Два уважаемых исследователя Университета Нового Южного Уэльса [12], Майкл Лоуренс (Michael Lawrence) и Росс Джеффри (Ross Jeffery), ежегодно выполняют обзор проектов. Они оценивают действующие проекты в отрасли, следуя общему стандарту сбора данных. Каждый год они сосредоточивают внимание на новом аспекте проектной работы. В обзоре 1985 года содержались данные, отражающие неприменимость закона Паркинсона. Они не могут служить свидетельством, полностью опровергающим закон, но их достаточно, чтобы возникли некоторые сомнения [13].
Лоуренс и Джеффри поставили задачу определить влияние на производительность различных методов оценки. Они хотели доказать (или опровергнуть) популярное верование, что разработчики (в данном случае программисты) работают интенсивнее, если пытаются следовать собственным критериям. Для каждого из 103 изученных проектов Лоуренс и Джеффри определили параметры производительности, сходные с параметрами конструктивной модели стоимости (Constructive Cost Model – СоСоМо), которые пропагандирует Барри Бём (Barry Boehm) [14]. Затем они разделили выборку на подгруппы на основе того, каким образом были получены исходные оценки. Некоторые результаты представлены в табл. 5.1.4 [15].
Таблица 5.1. Производительность как функция оценки сложности (частичный результат)
Пока что результаты подтверждают популярное мнение: программисты, похоже, чуть более продуктивны, когда могут оценивать необходимое время самостоятельно, в отличие от случаев, когда оценку выполняет руководитель, не советуясь с ними. Когда же руководитель советуется с разработчиком, результат получается промежуточный.
Для 21 проекта из числа изученных в тот год оценки выполнялись третьей стороной, как правило, системным аналитиком. И эти проекты показали более высокую производительность (табл. 5.2.):
Последняя строка уже идёт вразрез с популярным мнением. Почему программисту приходится работать интенсивнее, чтобы уложиться в оценку аналитика, чем в случае, когда оценку выполняет он сам? Есть соблазн объяснить такие показатели простыми погрешностями в данных. Но если вы согласитесь с нами в том, что плохие прогнозы всегда являются фактором, снижающим мотивацию, не будет никакой необходимости пытаться пренебречь полученными данными. Системные аналитики более склонны к точным оценкам, чем программисты или руководители. Системный аналитик, как правило, владеет той же информацией о поставленной задаче, но его не сдерживает природный оптимизм исполнителя или политические и финансовые взгляды шефа. Более того, системные аналитики имеют больший опыт в оценке, они способны предсказывать результаты более точно, поскольку уже занимались этим в прошлом и делали соответствующие выводы.
Отрицательные прогнозы и безнадёжно малые сроки поглощают энергию автора. Кейперс Джоунс (Capers Jones), известный своими количественными исследованиями проектов по разработке, сформулировал эту мысль так: «Когда расписание проекта совершенно необоснованно и нереалистично, и притом никакой объём сверхурочных не позволяет уложиться в сроки, команда, работающая над проектом, начинает испытывать злость и отчаяние… боевой дух падает до предела» [16]. При этом не имеет особого значения, исходит ли это «совершенно необоснованное и нереалистичное» расписание от начальства или от самих создателей продукта. Оказавшись в безвыходной ситуации, люди просто не работают эффективно.
Самая удивительная часть исследования 1985 года появилась последней, когда Лоуренс и Джеффри исследовали производительность в 24 проектах, для которых вообще не было сделано никаких предварительных оценок. Эти проекты с большим отрывом опередили все остальные (табл. 5.2) [17]:
Таблица 5.3. Производительность как функция оценки сложности (полный результат)
Проекты, в которых шеф не оказывал временного давления вообще («Разбудите меня, когда все будет готово»), характеризовались самой высокой производительностью [18]. Конечно, изложенное не позволяет сказать, что закон Паркинсона вообще никак не действует на разработчиков. Но наводит на интересные мысли, не так ли?
Решение о том, оказывать ли временное давление на проект, следует принимать так же, как решение о наказании ребёнка. Если вы безупречно выбираете время и правомерность очевидна, положительный эффект вероятен. Если же вы делаете это постоянно, то это уже признак ваших собственных проблем.
Организационная работа увеличивается в масштабах, занимая весь рабочий день.
Этот эффект может впервые проявиться при основании компании, и из года в год положение ухудшается. Это одна из причин, по которой в давно сформировавшхся компаниях не так интересно работать. Немногие оставшиеся сотрудники Dutch East India Company (основанная в 1651 году, она была когда-то самой крупной компанией в мире) сегодня проводят по сорок часов в неделю, заполняя формуляры. Обратите внимание, как в данном случае компания, а не её сотрудники, демонстрирует поведение, подчиняющееся закону Паркинсона. Мы вернёмся к этой теме во второй части.
Если не знать, что весьма немногие руководители проходят обучение менеджменту, можно подумать, что существует спецшкола, в которой они посещают интенсивный курс по закону Паркинсона и его вариациям. Даже руководители, не знающие вообще ничего о менеджменте, цепляются за эту аксиоматическую истину – закон Паркинсона, руководящую людьми и их отношением к работе. Он даёт им крайнюю убеждённость в том, что единственный способ добиться выполнения работы – это установить невозможно оптимистические сроки её сдачи.
Закон Паркинсона и закон Ньютона
В законе Паркинсона вовсе нет ничего аксиоматичного. Это даже не закон в том смысле, в каком является им закон Ньютона. Ньютон был учёным, он исследовал гравитационный эффект, следуя строжайшему научному методу. Его теория была принята лишь после тщательных проверок и экспериментов. Закон Ньютона выдержал испытание временем – около двухсот лет исследований.Паркинсон учёным не был. Он не собирал данные и, вероятно, даже не понимал правил статистических заключений. Паркинсон был юмористом. Его «закон» получил такое распространение не потому, что он соответствовал действительности. Просто шутка была забавная.
Разумеется, закон Паркинсона кажется нам забавным, поскольку в нем есть частичка истины. Паркинсон приводит примеры действия своего закона в рамках вымышленной правительственной бюрократической машины, прообразом которой, по мнению некоторых, является Британская почтовая служба. Бюрократия подвержена таким проблемам, потому что её сотрудники почти не получают удовлетворения непосредственно от рабочих задач. Но вы-то, вероятно, не состоите в бюрократии. А если и состоите, то изо всех сил стараетесь устроить так, чтобы ваших людей её воздействие не затрагивало, потому что в противном случае они никогда ничего не сделают. В результате ваши люди имеют возможность получать от работы удовлетворение. Из этого следует простая истина, которую имеет смысл озвучить:
Закон Паркинсона наверняка не применим к вашим людям.
Их жизнь слишком коротка, чтобы они стали отлынивать от работы. Раз им нравится работа, они не склонны растягивать её до бесконечности, поскольку это лишь отсрочит удовлетворение, ради которого все они стараются. Они не меньше вашего желают выполнить работу, но только с тем условием, что им не придётся нарушать собственные стандарты качества.
А нашего Ивана вы видели?!
Каждый руководитель хотя бы раз в жизни вынужден иметь дело с сотрудником, который избегает работы, или же не имеет стандарта качества, или просто не может сделать работу. Разве это не подтверждает закон Паркинсона?В здоровой рабочей обстановке причинами стагнации для некоторых людей становятся недостаток компетенции, нехватка уверенности, а также неопределённость цели проекта и отсутствие интеграции с командой. Ни в одном из этих случаев временное давление помочь не способно. Скажем, когда сотрудник вяло работает и кажется, что он не задумывается о качестве своих результатов, это верный признак того, что бедняга подавлен сложностью работы. Ему не нужно более сильное давление. Ему нужна смена деятельности, возможно, просто перевод в другую компанию.
Даже в тех редких случаях, когда давление на человека остаётся единственным вариантом, руководитель должен это давление оказывать последним. Эффект гораздо сильнее, когда давление исходит от команды. Нам встречались случаи однородных команд, где руководителям пришлось бы занимать очередь, чтобы покричать на единственного человека, который не старается вмести со всеми.
В последующих главах мы ещё не раз вернёмся к командам и разумному их формированию. А пока речь не о том, что действует. Речь о том, что не действует: не действует отношение к сотрудникам, основанное на законе Паркинсона. Оно способно лишь унизить и лишить мотивации.
Университет Нового Южного Уэльса: некоторые данные
Конечно же, влияние закона Паркинсона на умы не исчезнет лишь потому, что мы к этому призываем. А вот достоверные данные, доказывающие, что закон Паркинсона не применим к большинству работников, помогли бы переубедить руководителей. (Забудем на секунду, что Паркин-сон не привёл вообще никаких данных в подтверждение своего закона, а лишь пережёвывал его на протяжении нескольких сотен страниц.)Два уважаемых исследователя Университета Нового Южного Уэльса [12], Майкл Лоуренс (Michael Lawrence) и Росс Джеффри (Ross Jeffery), ежегодно выполняют обзор проектов. Они оценивают действующие проекты в отрасли, следуя общему стандарту сбора данных. Каждый год они сосредоточивают внимание на новом аспекте проектной работы. В обзоре 1985 года содержались данные, отражающие неприменимость закона Паркинсона. Они не могут служить свидетельством, полностью опровергающим закон, но их достаточно, чтобы возникли некоторые сомнения [13].
Лоуренс и Джеффри поставили задачу определить влияние на производительность различных методов оценки. Они хотели доказать (или опровергнуть) популярное верование, что разработчики (в данном случае программисты) работают интенсивнее, если пытаются следовать собственным критериям. Для каждого из 103 изученных проектов Лоуренс и Джеффри определили параметры производительности, сходные с параметрами конструктивной модели стоимости (Constructive Cost Model – СоСоМо), которые пропагандирует Барри Бём (Barry Boehm) [14]. Затем они разделили выборку на подгруппы на основе того, каким образом были получены исходные оценки. Некоторые результаты представлены в табл. 5.1.4 [15].
Таблица 5.1. Производительность как функция оценки сложности (частичный результат)
Пока что результаты подтверждают популярное мнение: программисты, похоже, чуть более продуктивны, когда могут оценивать необходимое время самостоятельно, в отличие от случаев, когда оценку выполняет руководитель, не советуясь с ними. Когда же руководитель советуется с разработчиком, результат получается промежуточный.
Для 21 проекта из числа изученных в тот год оценки выполнялись третьей стороной, как правило, системным аналитиком. И эти проекты показали более высокую производительность (табл. 5.2.):
Последняя строка уже идёт вразрез с популярным мнением. Почему программисту приходится работать интенсивнее, чтобы уложиться в оценку аналитика, чем в случае, когда оценку выполняет он сам? Есть соблазн объяснить такие показатели простыми погрешностями в данных. Но если вы согласитесь с нами в том, что плохие прогнозы всегда являются фактором, снижающим мотивацию, не будет никакой необходимости пытаться пренебречь полученными данными. Системные аналитики более склонны к точным оценкам, чем программисты или руководители. Системный аналитик, как правило, владеет той же информацией о поставленной задаче, но его не сдерживает природный оптимизм исполнителя или политические и финансовые взгляды шефа. Более того, системные аналитики имеют больший опыт в оценке, они способны предсказывать результаты более точно, поскольку уже занимались этим в прошлом и делали соответствующие выводы.
Отрицательные прогнозы и безнадёжно малые сроки поглощают энергию автора. Кейперс Джоунс (Capers Jones), известный своими количественными исследованиями проектов по разработке, сформулировал эту мысль так: «Когда расписание проекта совершенно необоснованно и нереалистично, и притом никакой объём сверхурочных не позволяет уложиться в сроки, команда, работающая над проектом, начинает испытывать злость и отчаяние… боевой дух падает до предела» [16]. При этом не имеет особого значения, исходит ли это «совершенно необоснованное и нереалистичное» расписание от начальства или от самих создателей продукта. Оказавшись в безвыходной ситуации, люди просто не работают эффективно.
Самая удивительная часть исследования 1985 года появилась последней, когда Лоуренс и Джеффри исследовали производительность в 24 проектах, для которых вообще не было сделано никаких предварительных оценок. Эти проекты с большим отрывом опередили все остальные (табл. 5.2) [17]:
Таблица 5.3. Производительность как функция оценки сложности (полный результат)
Проекты, в которых шеф не оказывал временного давления вообще («Разбудите меня, когда все будет готово»), характеризовались самой высокой производительностью [18]. Конечно, изложенное не позволяет сказать, что закон Паркинсона вообще никак не действует на разработчиков. Но наводит на интересные мысли, не так ли?
Решение о том, оказывать ли временное давление на проект, следует принимать так же, как решение о наказании ребёнка. Если вы безупречно выбираете время и правомерность очевидна, положительный эффект вероятен. Если же вы делаете это постоянно, то это уже признак ваших собственных проблем.
Вариация на тему закона Паркинсона
Слегка перефразировав закон Паркинсона, мы получим утверждение, до боли правдивое для многих организаций:Организационная работа увеличивается в масштабах, занимая весь рабочий день.
Этот эффект может впервые проявиться при основании компании, и из года в год положение ухудшается. Это одна из причин, по которой в давно сформировавшхся компаниях не так интересно работать. Немногие оставшиеся сотрудники Dutch East India Company (основанная в 1651 году, она была когда-то самой крупной компанией в мире) сегодня проводят по сорок часов в неделю, заполняя формуляры. Обратите внимание, как в данном случае компания, а не её сотрудники, демонстрирует поведение, подчиняющееся закону Паркинсона. Мы вернёмся к этой теме во второй части.
6. Лаетрил
Лаетрил – это бесцветный экстракт из мягкого содержимого абрикосовых косточек. В Швеции его можно купить в бакалее по цене, сравнимой с ценой миндальной эссенции. Как и любая другая эссенция, он применяется для выпечки. В Мексике его продают по пятьдесят долларов за каплю как «лекарство» от смертельного рака. Разумеется, он ничего не лечит. Все свидетельства подтверждают лишь то, что это грубое мошенничество. Но смертельно больные принимают заверения толкачей лаетрила – и неважно, насколько вопиющие, поскольку других вариантов все равно нет. Находясь в достаточно сильном отчаянии, люди не слишком склонны искать реальные подтверждения.
Точно так же «находятся в достаточно отчаянном положении» руководители, и это отчаяние делает их легковерными жертвами тех видов лаетрила технологического, которые по слухам способны повышать производительность. Редко когда находятся свидетельства, подтверждающие действенность «лекарственных» средств. И руководители также обходятся без свидетельств – им просто некогда их искать.
Терзающие вас сирены – свойство отрасли, в которой вы работаете. Мы обнаружили семь сирен в области, которую лучше всего знаем. Вот сирены разработки программного обеспечения:
Семь ложных надежд руководителя проекта по разработке программного обеспечения
1. Существует ещё не изученный новый трюк, который поднимет производительность до небес.
Ответ: вы недостаточно глупы, чтобы пропустить нечто столь фундаментальное. Вы постоянно исследуете новые подходы и пробуете те, что кажутся наиболее осмысленными. Ни одна из мер уже принятых и ни одна из тех, что вы ещё можете принять, не позволит поднять производительность до небес. Что они, однако, могут, – так это держать всех в форме: людям нравится думать, учиться и расти. Мысль же о том, что существует волшебное новшество, которое вы пропустили, – это мысль пораженческая, и ею умело пользуются те, кто волшебные новшества продают.
2. Другие руководители умудряются получить прирост производительности в сто, двести и даже более процентов!
Ответ: Забудьте об этом. Как правило, волшебный инструмент, который вам предлагают, работает на этапах программирования и тестирования. Но как только программирование и тестирование заканчиваются, уже невозможно получить прирост в сто процентов. Остаются ещё анализ, контракты, спецификации, подготовка, приёмка, реконструкция и переключение с одной системы на другую.
3. Технологии развиваются с такой скоростью, что невозможно за всем
4. успевать.
Ответ: Да, технологии развиваются быстро, но (вот опять иллюзия высоких технологий) ваши труды по большей части к высоким технологиям не относятся. Машины изменились очень сильно, но бизнес, связанный с разработкой программного обеспечения, всегда был довольно статичен. Мы все так же тратим большую часть времени на требования и спецификации, на низкотехнологичные аспекты нашей работы. Производительность индустрии программного обеспечения растёт на 3-5% в год, что лишь немногим больше, чем показатели в автомобильной или сталелитейной индустрии [19].
5. Смена языка даст гигантские преимущества.
Ответ: Выбор языка имеет значение, потому что он влияет на способ решения проблемы, но опять же, язык оказывает влияние лишь на этапе реализации. Благодаря преувеличениям, некоторые из новых языков попадают в разряд лаетрила. Не исключено, что новое приложение лучше написать, например на PowerBuilder™, а не на COBOL, но даже до появления PowerBuilder существовали способы лучшие, чем COBOL: специализированные инструменты, упрощаюшие запросы и обновления. Если последние несколько десятилетий вы не проспали у голубого телеэкрана, то смена языка не сильно вам поможет. Она может повысить производительность процентов на пять (вряд ли с этим стоит считаться), но не более того.
6. Из-за отставания следует немедленно удвоить производительность.
Ответ: Отставание разработки, о котором так много говорят, – это миф. Все мы знаем, что в конечном итоге любой проект обходится дороже, чем было запланировано в начале. Поэтому стоимость системы, не созданной в прошлом году (потому что не было ресурсов), принято оптимистично считать равной половине стоимости этой же системы, будь она создана, или даже менее того. Проект, попавший в капкан мифического отставания, находится там потому, что выгода от него явно недостаточна, чтобы служить причиной вообще этот проект затевать, даже если оценки стоимости крайне оптимистичны. Если бы вы знали реальную стоимость проекта, то верно понимали бы его смысл: экономическая неудача. Этот проект из отстающих следует перевести в категорию предназначенных для мусорной корзины.
6. Все уже автоматизировано; не пора ли напрочь автоматизировать персонал, разрабатывающий программное обеспечение?
Ответ: Это ещё одна вариация на тему иллюзии высоких технологий – вера в то, что разработчики программ выполняют работу, легко поддающуюся автоматизации. Их основная работа – человеческое взаимодействие, позволяющее преобразовать изложенные пользователями потребности в формальное представление. Кто-то должен делать эту работу независимо от того, какие формы принимает цикл жизни продукта. И вряд ли возможно данную задачу автоматизировать.
7. Люди будут лучше работать, если как следует на них надавить.
Ответ: Нет, не будут. Но будут меньше любить свою работу.
Как видим, один сплошной негатив. Если давление на людей способствует снижению производительности, а установка самых последних техно-фенечек тоже не сильно спасает, чем же должен заниматься руководитель?
Точно так же «находятся в достаточно отчаянном положении» руководители, и это отчаяние делает их легковерными жертвами тех видов лаетрила технологического, которые по слухам способны повышать производительность. Редко когда находятся свидетельства, подтверждающие действенность «лекарственных» средств. И руководители также обходятся без свидетельств – им просто некогда их искать.
Худейте во сне
В один прекрасный день в порыве глупости я начал вырезать из газет рекламные объявления, обещавшие увеличить производительность на сто или более процентов. Довольно быстро я набрал их целый ворох. Многообразие рекламируемых средств фантастического повышения производительности не могло не поразить. Семинары, комплексные программы, методологии, книги, способы календарного планирования, аппаратные средства наблюдения, вычислительные языки и бюллетени. Возвращаясь вечером того дня на метро домой, на обложке «Нью-Йорк Пост» я вдруг увидел ещё одно объявление, которое гласило: «Худейте во сне». И оно вполне подходило ко всем остальным.Все мы очень обеспокоены вопросом повышения производительности. От этой проблемы уже не избавиться посредством простых решений, все такие решения были найдены и задействованы уже очень давно. Однако некоторые организации чувствуют себя намного лучше других. Мы убеждены, что их лидеры не используют какие-либо исключительно продвинутые технологии. Их более высокую производительность можно полностью объяснить более эффективными способами работы с людьми, иным подходом к планированию рабочего пространства и иной корпоративной культурой, а также реализацией мер, которые мы обсудим в частях II, III и IV. Относительная малозначимость технологии может несколько обескураживать, по меньшей мере, в первое время, поскольку принимать предлагаемые нами меры по изменению корпоративной культуры нелегко, а эффекты этих мер проявляются далеко не скоро. Гораздо интереснее было бы вырезать из журнала купон, приложить к нему несколько тысяч зелёных, послать по почте, а в ответ получить какой-нибудь чудесный трюк повышения производительности. Конечно, этот трюк может вам и не помочь, но простые способы не решать проблему более привлекательны, чем сложные способы решать её, не так ли?
Т. Д.
Семь сирен
Ложные надежды, порождаемые простыми технологическими способами нерешения проблемы, подобны Сиренам, соблазнявшим несчастного Одиссея. Каждая тянется к вам со своим собственным чарующим посланием, предлагая привлекательный, но никуда не ведущий ложный путь. Пока вы верите этим сиренам, вы будете сопротивляться нелёгкому труду, необходимому для построения здоровой корпоративной культуры.Терзающие вас сирены – свойство отрасли, в которой вы работаете. Мы обнаружили семь сирен в области, которую лучше всего знаем. Вот сирены разработки программного обеспечения:
Семь ложных надежд руководителя проекта по разработке программного обеспечения
1. Существует ещё не изученный новый трюк, который поднимет производительность до небес.
Ответ: вы недостаточно глупы, чтобы пропустить нечто столь фундаментальное. Вы постоянно исследуете новые подходы и пробуете те, что кажутся наиболее осмысленными. Ни одна из мер уже принятых и ни одна из тех, что вы ещё можете принять, не позволит поднять производительность до небес. Что они, однако, могут, – так это держать всех в форме: людям нравится думать, учиться и расти. Мысль же о том, что существует волшебное новшество, которое вы пропустили, – это мысль пораженческая, и ею умело пользуются те, кто волшебные новшества продают.
2. Другие руководители умудряются получить прирост производительности в сто, двести и даже более процентов!
Ответ: Забудьте об этом. Как правило, волшебный инструмент, который вам предлагают, работает на этапах программирования и тестирования. Но как только программирование и тестирование заканчиваются, уже невозможно получить прирост в сто процентов. Остаются ещё анализ, контракты, спецификации, подготовка, приёмка, реконструкция и переключение с одной системы на другую.
3. Технологии развиваются с такой скоростью, что невозможно за всем
4. успевать.
Ответ: Да, технологии развиваются быстро, но (вот опять иллюзия высоких технологий) ваши труды по большей части к высоким технологиям не относятся. Машины изменились очень сильно, но бизнес, связанный с разработкой программного обеспечения, всегда был довольно статичен. Мы все так же тратим большую часть времени на требования и спецификации, на низкотехнологичные аспекты нашей работы. Производительность индустрии программного обеспечения растёт на 3-5% в год, что лишь немногим больше, чем показатели в автомобильной или сталелитейной индустрии [19].
5. Смена языка даст гигантские преимущества.
Ответ: Выбор языка имеет значение, потому что он влияет на способ решения проблемы, но опять же, язык оказывает влияние лишь на этапе реализации. Благодаря преувеличениям, некоторые из новых языков попадают в разряд лаетрила. Не исключено, что новое приложение лучше написать, например на PowerBuilder™, а не на COBOL, но даже до появления PowerBuilder существовали способы лучшие, чем COBOL: специализированные инструменты, упрощаюшие запросы и обновления. Если последние несколько десятилетий вы не проспали у голубого телеэкрана, то смена языка не сильно вам поможет. Она может повысить производительность процентов на пять (вряд ли с этим стоит считаться), но не более того.
6. Из-за отставания следует немедленно удвоить производительность.
Ответ: Отставание разработки, о котором так много говорят, – это миф. Все мы знаем, что в конечном итоге любой проект обходится дороже, чем было запланировано в начале. Поэтому стоимость системы, не созданной в прошлом году (потому что не было ресурсов), принято оптимистично считать равной половине стоимости этой же системы, будь она создана, или даже менее того. Проект, попавший в капкан мифического отставания, находится там потому, что выгода от него явно недостаточна, чтобы служить причиной вообще этот проект затевать, даже если оценки стоимости крайне оптимистичны. Если бы вы знали реальную стоимость проекта, то верно понимали бы его смысл: экономическая неудача. Этот проект из отстающих следует перевести в категорию предназначенных для мусорной корзины.
6. Все уже автоматизировано; не пора ли напрочь автоматизировать персонал, разрабатывающий программное обеспечение?
Ответ: Это ещё одна вариация на тему иллюзии высоких технологий – вера в то, что разработчики программ выполняют работу, легко поддающуюся автоматизации. Их основная работа – человеческое взаимодействие, позволяющее преобразовать изложенные пользователями потребности в формальное представление. Кто-то должен делать эту работу независимо от того, какие формы принимает цикл жизни продукта. И вряд ли возможно данную задачу автоматизировать.
7. Люди будут лучше работать, если как следует на них надавить.
Ответ: Нет, не будут. Но будут меньше любить свою работу.
Как видим, один сплошной негатив. Если давление на людей способствует снижению производительности, а установка самых последних техно-фенечек тоже не сильно спасает, чем же должен заниматься руководитель?
Это и есть руководство
На заре моей карьеры разработчика мне выпала честь работать в проекте под руководством Шерон Ввйнберг (Sharon Weinberg). Сейчас она является президентом компании Codd and Date Consulting Group. Эта женщина – яркий пример того, что я теперь привык называть просвещённым руководством. Как-то раз шёл снег, и я, переборов своё болезненное состояние, притащился на работу, чтобы собрать нашу шаткую систему воедино – в демонстрационную версию для пользователей. Шерон зашла и обнаружила меня за консолью. Она исчезла и вернулась через несколько минут с миской супа. Когда она влила в меня этот суп, я почувствовал прилив бодрости и спросил, как она умудряется находить время на такие вещи, ведь ей ещё нужно решать столько вопросов, связанных с руководством проектом. Она улыбнулась своей неповторимой улыбкой и сказала: «Том, это и есть руководство».Шерон знала то, что знают инстинктивно все хорошие руководители: назначение руководителя не в том, чтобы заставить людей работать, а в том, чтобы создать им условия для работы.
Т. Д.
II. ОФИСНАЯ СРЕДА
Для того чтобы дать людям возможность работать, необходимо справиться со всеми теми факторами, которые иногда делают работу невозможной. Причины потерь часов и дней многочисленны, но они не очень отличаются одна от другой. Чаще всего это в той или иной форме недостатки среды, в которой приходится работать. Телефон звонит не переставая, мастер по ремонту принтеров остановился поболтать, копировальная машина сломалась, какой-то гражданин звонит, чтобы уточнить время сдачи крови. Отдел кадров продолжает вопить, что нужны обновлённые отчёты о квалификации сотрудников, расписание сдавать в три часа дня, снова телефонные звонки в безумных количествах… и день пропал. В некоторые дни невозможно потратить хотя бы минуту на что-либо, имеющее отношение к непосредственной задаче.