Бегство от совершенства
Руководители ставят под угрозу качество продукта, устанавливая невозможные сроки его сдачи. Но они вовсе не задумываются об этом; они полагают, что такие действия ставят перед сотрудниками интересную задачу, которая поможет им стремиться к совершенству.
Опытные (вернее, заезженные) сотрудники знают, что все не так. Они понимают, что под дулом автомата их старания будут чрезмерно стеснены. У них не будет возможности распорядиться ресурсами так, чтобы своевременно сдать продукт. Не говоря уже о привлечении дополнительных участников или перераспределении функций. Единственное, чем можно будет пожертвовать, – это качество. Крайняя степень давления сроков заставит их принести качество в жертву. Они станут заметать проблемы под ковёр, чтобы разобраться с ними в последний момент или вовсе оставить в продукте на «радость» конечному пользователю. Они будут сдавать продукты нестабильные и незавершённые. Они возненавидят свою работу, но какой у них выбор?
Практичный боевой руководитель внутри вас ответит на это: «Кое-кто из моих ребят может до бесконечности возиться с задачей во имя „качества“. Но рынку абсолютно плевать на такой уровень качества – он в истерике требует продукта, причём уже со вчерашнего дня, и примет его в том виде, какой у нас есть сейчас». Во многих ситуациях вы будете правы насчёт рынка, но решение заставить людей выдать продукт, не соответствующий их собственным стандартам качества, практически всегда будет ошибкой.
Мы, руководители, склонны считать качество лишь одним из свойств продукта, чем-то, что можно регулировать в зависимости от потребностей рынка. Качество – вроде шоколадного соуса на пломбире домашнего приготовления – каждый добавляет по вкусу.
Взгляд создателя на качество совсем иной. Поскольку самооценка сильно связана с качеством продукта, он, создатель, устанавливает собственные стандарты. Удовлетворительный для него минимум более-менее соответствует высшему уровню качества, достигнутому им в прошлом. И это неизбежно более высокий стандарт, чем тот, что необходим рынку и за который рынок готов платить.
«Рынку абсолютно плевать на такой уровень качества». Прочтите эти слова и прослезитесь, потому что они почти всегда правдивы. Люди могут с пеной у рта говорить о качестве и горько жаловаться на его отсутствие, но когда приходит время платить за качество, их действительные ценности выходят на поверхность. В проекте по разработке программного обеспечения вы можете представить пользователям следующее объяснение: «На основе эмпирических данных мы можем прогнозировать, что Среднее Время Между Сбоями для этого продукта в настоящий момент составляет примерно один час и двенадцать минут. Если мы сдадим продукт вовремя, то есть сегодня, он будет иметь низкую стабильность. Если мы затратим ещё три недели, то можем прогнозировать увеличение СВМС до двух тысяч часов, что есть вполне достойный результат». После этого можете ожидать потока недовольного бормотания со всех сторон. Пользователи объяснят, что качество ценят точно так же, как все, но три недели стоят серьёзных денег.
Что касается индустрии программного обеспечения, то она приучила клиентов принимать как должное внутрикорпоративные прикладные программы со средней плотностью изъянов от одного до трех на сотню строк кода! И – какова ирония – этот катастрофический результат зачастую относят на низкую сознательность разработчиков в том, что касается качества. То есть тех же, кого обвиняют в желании «до бесконечности возиться с программой во имя качества», ещё и осуждают за низкое качество. Давайте-ка найдём тех, кто действительно виноват. Тот, кто платит пианисту, почему-то предлагает играть плохую музыку. Сообщество пользователей программного обеспечения продемонстрировало свои стандарты качества, регулярно подвергая процесс разработки неимоверному временному давлению, а затем принимая продукты низкого качества[8].
Такие слова могут показаться обличительной речью, направленной против пользователей программного обеспечения и стандартов рынка в целом, но не стоит воспринимать их подобным образом. Мы должны исходить из того, что люди, финансирующие наш труд, находятся в здравом уме и способны принять разумный компромисс между качеством и стоимостью. Основная идея здесь в том, что осознаваемая клиентом потребность в качестве зачастую не столь велика, как аналогичная потребность разработчика. Существует естественное противоречие. Снижение качества продукта, вероятно, приведёт к тому, что некоторые люди откажутся от покупки, но сокращение рыночной доли – прямое следствие любого подобного снижения качества – зачастую компенсируется увеличением прибылей на каждую проданную единицу продукта.
Бегство от совершенства – так мы называем ситуацию, когда стандарты качества устанавливает покупатель, а не создатель. Стандарты, основанные на существующем рыночном качестве, имеют смысл лишь до тех пор, пока вы не обращаете внимания на настроение и эффективность труда разработчиков.
В долгосрочной перспективе рыночные стандарты качества обходятся дороже. Какой урок отсюда следует?
Качество, серьёзно превосходящее запросы конечного пользователя, есть средство достижения более высокой производительности.
Если вы сомневаетесь в этом, вообразите следующий глубокомысленный эксперимент: спросите сто человек с улицы, какая культура или нация прославилась благодаря высокому качеству. Предсказываем, что более половины людей сегодня ответят «японская». Теперь спросите у другой сотни людей, какая культура или нация известна высокой производительностью. И опять можно ожидать, что большинство ответят «японская». Нация, признанная лидером в области качества, столь же известна своей высокой продуктивностью.
Постойте. Как же возможно, что более высокое качество сосуществует с более высокой производительностью? Ведь это противоречит прописной истине, что повышение качества продукта означает увеличение его себестоимости. Вот подсказка Тадзимы (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. Производительность как функция оценки сложности (частичный результат)
|
Оценка сложности выполнялась |
Средняя производительность |
Число проектов |
|
Программистом |
8.0 |
19 |
|
Начальником |
6.6 |
23 |
|
Программистом и начальником |
7.8 |
16 |
Пока что результаты подтверждают популярное мнение: программисты, похоже, чуть более продуктивны, когда могут оценивать необходимое время самостоятельно, в отличие от случаев, когда оценку выполняет руководитель, не советуясь с ними. Когда же руководитель советуется с разработчиком, результат получается промежуточный.
Для 21 проекта из числа изученных в тот год оценки выполнялись третьей стороной, как правило, системным аналитиком. И эти проекты показали более высокую производительность (табл. 5.2.):
|
Оценка сложности выполнялась |
Средняя производительность |
Число проектов |
|
Программистом |
8,0 |
19 |
|
Начальником |
6,6 |
23 |
|
Программистом и начальником |
7,8 |
16 |
|
Системным аналитиком |
9,5 |
21 |
Последняя строка уже идёт вразрез с популярным мнением. Почему программисту приходится работать интенсивнее, чтобы уложиться в оценку аналитика, чем в случае, когда оценку выполняет он сам? Есть соблазн объяснить такие показатели простыми погрешностями в данных. Но если вы согласитесь с нами в том, что плохие прогнозы всегда являются фактором, снижающим мотивацию, не будет никакой необходимости пытаться пренебречь полученными данными. Системные аналитики более склонны к точным оценкам, чем программисты или руководители. Системный аналитик, как правило, владеет той же информацией о поставленной задаче, но его не сдерживает природный оптимизм исполнителя или политические и финансовые взгляды шефа. Более того, системные аналитики имеют больший опыт в оценке, они способны предсказывать результаты более точно, поскольку уже занимались этим в прошлом и делали соответствующие выводы.
Отрицательные прогнозы и безнадёжно малые сроки поглощают энергию автора. Кейперс Джоунс (Capers Jones), известный своими количественными исследованиями проектов по разработке, сформулировал эту мысль так: «Когда расписание проекта совершенно необоснованно и нереалистично, и притом никакой объём сверхурочных не позволяет уложиться в сроки, команда, работающая над проектом, начинает испытывать злость и отчаяние… боевой дух падает до предела»[16]. При этом не имеет особого значения, исходит ли это «совершенно необоснованное и нереалистичное» расписание от начальства или от самих создателей продукта. Оказавшись в безвыходной ситуации, люди просто не работают эффективно.
Самая удивительная часть исследования 1985 года появилась последней, когда Лоуренс и Джеффри исследовали производительность в 24 проектах, для которых вообще не было сделано никаких предварительных оценок. Эти проекты с большим отрывом опередили все остальные (табл. 5.2)[17]:
Таблица 5.3. Производительность как функция оценки сложности (полный результат)
|
Оценка сложности выполнялась |
Средняя производительность |
Число проектов |
|
Программистом |
8,0 |
19 |
|
Начальником |
6,6 |
23 |
|
Программистом и начальником |
7,8 |
16 |
|
Системным аналитиком |
9,5 |
21 |
|
(Без оценки) |
12,5 |
24 |
Проекты, в которых шеф не оказывал временного давления вообще («Разбудите меня, когда все будет готово»), характеризовались самой высокой производительностью[18]. Конечно, изложенное не позволяет сказать, что закон Паркинсона вообще никак не действует на разработчиков. Но наводит на интересные мысли, не так ли?
Решение о том, оказывать ли временное давление на проект, следует принимать так же, как решение о наказании ребёнка. Если вы безупречно выбираете время и правомерность очевидна, положительный эффект вероятен. Если же вы делаете это постоянно, то это уже признак ваших собственных проблем.
