Мы, руководители, в большинстве своём подвержены одной характерной ошибке: мы склонны управлять людьми так, словно они – модульные компоненты. Вполне очевидно, откуда берётся эта тенденция. Вспомните, как происходит подготовка к руководству: считается, что мы вполне подходим на руководящие роли, если хорошо себя зарекомендовали в качестве исполнителей, техников и разработчиков. От исполнителей часто требуется организация ресурсов в модули: фрагменты программного кода, микросхемы и другие рабочие блоки. Подобным модулям присущи свойства чёрного ящика, так что их внутреннее своеобразие можно спокойно игнорировать. Они задуманы как предметы, имеющие стандартные интерфейсы.

Мы полагаемся на модульные методы в течение многих лет, и не удивительно, что в качестве начинающих руководителей пытаемся применить их для управления человеческими ресурсами. Увы, для человеческих ресурсов эти методы не совсем пригодны.

Первая часть этой книги начинает наше исследование совершенно иного способа думать о людях и управлять ими. И этот способ требует привыкания к совершенно не модульному характеру человеческого ресурса.

С тех пор как компьютеры стали доступны широким массам пользователей, разработчики создали, должно быть, десятки тысяч бухгалтерских программ. Вероятно, ещё десяток (или больше) таких проектов кто-то ведёт прямо сейчас, когда вы читаете эти строки. И как раз в это время один из них терпит крушение.

Представьте себе! Проект, не требующий никаких технических новшеств, разваливается на глазах. Бухгалтерский учёт – это колесо, которое изобретали заново столь часто, что многие разработчики-ветераны способны участвовать в таком проекте чуть ли не с закрытыми глазами. И все же подобные предприятия время от времени оканчиваются неудачей.

Предположим, после одной из таких катастроф вас попросили сделать вскрытие. (Мечтать не вредно: существует нерушимый отраслевой стандарт, запрещающий изучать провалы.) Предположим, что вам выпал шанс выяснить причины неудачи, прежде чем участники проекта успели разбежаться кто куда. Среди причин, потопивших проект, не будет ни слова о технологии. Можно с уверенностью сказать, что в наши дни системы бухгалтерского учёта технически возможны. Должно быть иное объяснение.

Начиная с 1977 года мы ежегодно проводили исследования проектов разработки и анализ их результатов. Мы оценивали размеры, стоимость, недостатки, факторы ускорения, а также соответствие развития проекта предполагаемым срокам. К настоящему моменту мы собрали более пятисот историй различных проектов, и в каждой из них мы видим реальный труд разработчиков[1].

Около пятнадцати процентов всех проектов закончились ничем – были отменены, прерваны, отложены или их результатом стали никому не нужные продукты. В случае крупных проектов картина ещё хуже. Крах постиг двадцать пять процентов проектов, длительность которых составляла от двадцати пяти человеко-лет[2]. В ранних исследованиях мы отбрасывали провалы и изучали данные прочих проектов. Однако начиная с 1979 года мы обязательно связывались с участниками неудавшихся проектов и узнавали, что пошло не так. В подавляющем большинстве случаев не было ни одной объясняющей неудачу причины из области технологии.

Чаще всего участники наших опросов в качестве причины краха называли «политику». Следует учесть, что люди трактуют это понятие достаточно широко. В «политику» входят такие несвязанные или слабо связанные между собой вещи, как проблемы коммуникации, проблемы с персоналом, разочарование в начальнике или заказчике, недостаточная мотивация и высокая текучесть кадров. Человек часто употребляет слово политика для описания любого аспекта работы, имеющего отношение к людям, но в языке есть гораздо более точный термин для таких аспектов: они составляют социологию проекта. Трудности действительно политического толка составляют лишь крохотное, незначительное подмножество всех трудностей.

Если считать проблему политической по природе, то в отношении к ней неизбежно появляется фатализм. Вы знаете, что способны справиться с техническими сложностями, но, если честно, кто из нас чувствует себя уверенно в области политики? Если же понять, что природа проблемы социологическая, а не политическая, то решить эту проблему будет намного проще. Социология проекта и команды может выходить за рамки вашей компетенции, но не способностей.

Как ни называй проблемы, связанные с людьми, именно они, вероятнее всего, станут причиной неприятностей в вашем следующем проекте, а вовсе не вопросы проектирования, реализации и методологии. По сути, именно эта мысль и проходит красной нитью через всю книгу:

Серьёзные проблемы в нашей работе имеют не столько технологическую сколько социологическую природу.

Многие руководители готовы согласиться с тем, что сталкиваются больше с человеческим фактором, нежели с техническими сложностями.

Однако они редко учитывают это на практике. Они руководят так, будто их главной заботой является именно технология. Они проводят столько времени в размышлениях о самых запутанных и интересных головоломках, которые предстоит решать подчинённым, будто сами собираются делать эту работу, а не руководить коллективом. Они находятся в вечном поиске технологического прибамбаса, который должен автоматизировать часть работы (более подробно об этом эффекте рассказано в главе 6 «Лаетрил»), тогда как направление их деятельности, связанное с человеческим ресурсом, зачастую получает низший приоритет.

Причиной такому феномену служит отчасти процесс воспитания среднего руководителя. Его учили тому, как выполнять работу, а не как руководить работой. Редко когда новый руководитель может похвастаться чем-то, что указывало бы на его способность или склонность к руководству. У них мало опыта руководства и отсутствует осмысленная практика. Но каким же образом новым руководителям удаётся убедить себя, что они могут спокойно тратить большую часть своего времени на размышления о технологии и совсем чуть-чуть (или нисколько) на размышления о человеческой стороне проблемы?

Ответ, возможно, кроется в явлении, которое мы окрестили миражами высоких технологий. Это распространённая убеждённость людей, имеющих дело с любым аспектом новой технологии (а кто из нас не имеет?), что они работают в сфере действительно высоких технологий. Они потворствуют развитию этой иллюзии, объясняя на какой-нибудь вечеринке, что работают «в области компьютеров» или же «в области телекоммуникаций» или занимаются «электронным переводом денежных средств», намекая тем самым, что принадлежат к миру высоких технологий. Между нами говоря, обычно это не так. Исследователи, совершающие фундаментальные прорывы в перечисленных областях, действительно из мира высоких технологий. А мы лишь используем результаты их труда. Компьютеры и прочие элементы новых технологий служат нам для организации собственных предприятий. Наши рабочие единицы – команды, проекты и взаимосвязанные рабочие группы, а потому наша область деятельности – преимущественно человеческое взаимодействие. Наш успех напрямую зависит от качественного человеческого взаимодействия всех участников предприятия, а наши неудачи являются прямым следствием недостатка человеческого взаимодействия.

Главная причина, по которой мы склонны сосредоточивать усилия на технической, а не на человеческой стороне работы, – вовсе не приоритет первой перед второй. Технические вопросы проще решать. Гораздо проще организовать установку нового оптического привода, чем выяснить, почему Хорас в замешательстве или почему Сьюзен выражает недовольство компанией уже после нескольких месяцев работы. Человеческие взаимодействия сложны, их проявления не бывают очевидными и прозрачными, но они имеют большее значение, чем любой другой аспект работы.

И если вы концентрируетесь больше на технологии, чем на социологии, то уподобляетесь персонажу водевиля, который потерял ключи на тёмной улице, а ищет их на соседней, потому что, как объясняет он сам: «Там не так темно».

Разработка по природе своей отличается от производства. Однако руководителям предприятий по разработке и смежных с ними свойственен образ мышления, уходящий корнями исключительно в производственную среду.

Представьте на секунду, что вы – менеджер местного предприятия быстрого питания. Перечисленные ниже меры повышения эффективности производства, причём в любой комбинации, будут полностью оправданны:

• Исключить ошибки. Заставить машину (коллектив) работать гладко, насколько возможно.

• Занять жёсткую позицию в отношении сотрудников, склонных филонить на рабочем месте.

• Считать служащих взаимозаменяемыми винтиками.

• Оптимизировать стабильное состояние. (Даже не задумываясь о том, как производство вышло на полную мощность или каким образом его возможно остановить.)

• Стандартизировать процедуру. Делать все по инструкции.

• Исключить эксперименты – за это получают деньги те, кто сидит в штаб-квартире.

Подобные меры были бы разумными для бизнеса быстрого питания (или любой производственной среды), но вы работаете в другой сфере. Подход «сделал чизбургер – продай его» может стать фатальным для вашей разработки. Он способен лишь подавить дух сотрудников и отвлечь их внимание от проблем, подлежащих решению. Такой стиль управления противоречит сути работы.

Чтобы эффективно управлять людьми в области интеллектуального труда[3], необходимо принимать меры, противоположные перечисленным выше. Эти противоположные меры описаны в последующих разделах.

Для большинства работников, занятых в сфере интеллектуального труда, допускаемые время от времени ошибки – вполне естественная и безопасная составляющая деятельности. Но иногда между ошибкой в работе и грехом проводятся почти библейские ассоциации. Для того чтобы изменить подобное отношение, необходимо принять действительно серьёзные меры.

В разговоре с группой руководителей проектов по разработке программного обеспечения мы представили стратегию, которую считаем случаем итеративного проектирования. Идея заключается в том, что некоторые проектные решения изначально содержат недостатки, и такие решения следует выбрасывать, а не пытаться исправить. При проектировании следует ожидать появления подобных тупиков. Усилия, потраченные на тупиковую разработку, – небольшая цена за возможность начать с чистого листа. К нашему удивлению, многие руководители считают, что такой подход станет неразрешимой политической проблемой для их собственного начальства: «Как мы можем выбросить продукт, в производство которого наша компания вложила деньги?» Похоже, они считают, что лучше все же спасать дефектный вариант, пусть это в перспективе и обойдётся дороже.

Поощрение атмосферы, не позволяющей допускать ошибки, просто заставляет людей занимать оборонительные позиции. Они не пробуют подходы, способные закончиться отрицательным результатом. Вы же поощряете такое поведение, пытаясь упорядочить процесс и использовать жёсткие методологии, ради исключения ошибок запрещающие сотрудникам принимать ключевые стратегические решения. Любые меры, препятствующие совершению ошибок, могут лишь ненамного поднять уровень технологии, а вот социология команды может пострадать весьма серьёзно.

Противоположный подход – поощрение нечастых ошибок. Время от времени спрашивайте у своих подчинённых, с какими тупиковыми ситуациями они столкнулись, и постарайтесь объяснить, что ответ «такого не было» – не самый лучший. Когда люди совершают ошибки, их следует поздравлять, потому что они получают деньги в том числе и за ошибки.

Менеджмент – понятие достаточно сложное, чтобы ему можно было дать простое определение, однако этот нюанс ускользнул от одного менеджера высшего звена, с которым мы общались на профессиональном конвенте в Лондоне. Своё понимание предмета он суммировал так: «Менеджмент – это умение пинать сотрудников». Это равнозначно мнению, что руководители в основном думают, а подчинённые лишь выполняют их волю. Опять же, для производства чизбургеров это, быть может, вполне продуктивный подход, но и только; он не действует для предприятия, в котором люди работают головой, а не руками. В подобной сфере мозг каждого участника должен участвовать в процессе. Посредством пинков вы сможете в лучшем случае активизировать сотрудников, но не добиться от них творческого подхода, вдумчивости и изобретательности.

Даже если бы воздействие на пятую точку давало кратковременный прирост производительности, в перспективе оно могло бы оказаться не столь полезным: нет ничего более обескураживающего для любого работника, чем чувство, что его собственной мотивации не хватает и потому требуются «добавки» со стороны начальства.

Самое печальное в таком подходе к руководству – это то, что он практически никогда не оправдан. Большинство сотрудников любят свою работу, и чаще всего не требуются жёсткие меры, чтобы они продолжали работать. Напротив, может возникнуть необходимость сделать так, чтобы они работали меньше, но более осмысленно (эту идею мы развиваем в главе 3).

В производственной сфере людей удобно считать частями рабочего механизма. Когда часть механизма износилась, её заменяют на другую. Замена совместима с оригиналом, поэтому новую можно, грубо говоря, заказать по каталогу.

Многие руководители проектов по разработке придерживаются такого же подхода. Они идут на все, убеждая себя, что нет незаменимых людей. Из страха, что ключевой человек уйдёт, они заставляют себя считать, что ключевых людей попросту не существует. Разве не в этом, в конце концов, сущность менеджмента – делать так, чтобы работа не останавливалась в случае ухода отдельных людей? Эти руководители ведут себя так, словно существует волшебный магазин человеческих запчастей, куда можно позвонить с примерно такой просьбой: «Пришлите мне нового Джорджа Гарденайера, только пусть он будет не такой дерзкий».

Один мой клиент поднял вопрос о повышении зарплаты одному из превосходных сотрудников и, к своему удивлению, узнал, что этому человеку нужно нечто другое, не деньги. Сотрудник сообщил, что дома у него часто появляются хорошие идеи, но работа через медленный коммутируемый терминал слишком неудобна. Не может ли компания провести ему домой выделенную линию и купить высокопроизводительный терминал? Компания так и сделала. В последующие годы она даже создала и обставила для этого сотрудника маленький домашний офис. Но этот мой клиент – нетипичный случай. Интересно, что сделал бы менее восприимчивый руководитель? Слишком уж многие руководители остро реагируют на любые попытки сотрудников подчеркнуть собственную индивидуальность.

(Т. Д.)

Вот один пример такого менее восприимчивого руководителя, взятый из жизни. Этот начальник крайне остро реагировал на индивидуальность своих подчинённых. Один весьма талантливый сотрудник большую часть года проводил на площадках клиентов и, как следствие, жил на командировочные. Анализ расходов этого сотрудника показал, что расходы на питание сильно отличаются от расходов других «путешественников» по этой статье. На еду он тратил в полтора раза больше других. В негодующем открытом письме начальник заклеймил «гастрономического преступника». Между прочим, общие расходы этого сотрудника не выбивались из ряда: излишние расходы на еду он компенсировал экономией в других областях. Он не обходился компании дороже, он просто был не таким, как все.

Уникальность каждого человека – постоянный раздражитель для руководителя, слепо уверовавшего в стиль управления, взятый из производственной сферы. Руководитель, умеющий работать с людьми, напротив, осознает, что именно уникальность участников является залогом активности и эффективности внутрипроектных отношений.

Образ мышления, характерный для производства, находящегося в стабильном состоянии, особенно плохо сочетается с ведением проектов. Мы склонны забывать, что самоцель существования проекта состоит в том, чтобы выйти из бизнеса. Единственное стабильное состояние в жизни проекта – трупное окоченение. Управление проектом должно сосредоточиваться на динамике его развития, разумеется, за исключением случаев, когда вы управляете проектом уже прерванным или находящимся на грани отмены. Но почему-то ценность людей для нового проекта мы вычисляем, исходя из их стабильных показателей: сколько кода они могут написать или сколько могут задокументировать. И слишком мало внимания уделяем тому, какой именно качественный вклад каждый из них может внести в развитие предприятия.

Несколько лет назад я вёл курс проектирования в одной фирме, и один из менеджеров высшего звена буквально преследовал меня просьбой оценить некоторых слушателей (сотрудников его проекта). Особенно его интересовала одна женщина. Его сомнения выражались так: «Не совсем понимаю, какая польза от неё проекту – она не гениальный разработчик, не очень разбирается в тестировании, да и вообще в чем-либо ещё». Небольшое расследование выявило любопытный факт: за двенадцать лет работы в компании эта женщина участвовала исключительно в проектах, закончившихся гигантским успехом. Её вклад был неочевиден, но проект с её участием неизменно был удачным. Понаблюдав за ней на занятиях с неделю и переговорив с её коллегами, я пришёл к выводу, что эта женщина – великолепный катализатор. В её присутствии команда начинала работать легко. Она помогала людям общаться и ладить. Проекты с её участием не были скучными. Попытавшись донести эту мысль до руководителя, я потерпел неудачу. Он попросту не считал катализатор жизненно необходимым для проекта.

(Т. Д.)

Катализатор важен, потому что проект постоянно находится в движении. Человек, способный заставить проект шевелиться, стоит двух, просто выполняющих работу.

Если на вас лежит ответственность за выполнение задания, какую долю времени следует потратить непосредственно на выполнение? Не сто процентов. Необходимо предусмотреть время на мозговые штурмы, на изучение новых подходов, на поиск экономичных решений, на чтение, подготовку, да и просто безделье.

Вспоминая годы, когда мы сами руководили проектами, мы пришли к заключению, что подходили к этому вопросу неправильно. Слишком много времени тратили на попытки получить результат и недостаточно на ключевой вопрос: а нужны ли вообще эти результаты? Принцип стабилизированных чизбургеров даже рядом не валялся с идеей о размышлениях на работе. Единственная его цель – по максимуму свести все усилия к действию. Если надо как-то объяснить недостаток времени на размышления, то этим объяснением всегда становятся сжатые сроки. Можно подумать, существует работа, не подверженная давлению сроков.

Потребность в более взвешенном подходе возрастает по мере того, как растут ставки. Лишь когда требуются поистине титанические усилия, мы начинаем постигать другой режим, в котором больше времени уделяется размышлениям о работе и меньше собственно выполнению работы. Чем больше требуется героических усилий, тем важнее, чтобы люди в команде учились взаимодействовать эффективно и получать от этого удовольствие. Именно проект, сдача которого запланирована на нереальную фиксированную дату, более всего нуждается в частых мозговых штурмах и даже в неформальной проектной тусовке или любом подобном мероприятии – во всем, что помогает объединить отдельных участников в эффективное целое.

Но ведь все эти нежности совершенно неуместны. Каждый знает и действует с пониманием, ведь так? Не так. Мы столь слепо стремимся к Достижению Чего-Либо, Чего Угодно, что тратим лишь скудные пять процентов своего времени на деятельность, посвящённую планированию, исследованию новых методов, обучению, чтению книг, прогнозированию, бюджетному планированию, а также распределению кадров. (Показатель в пять процентов получен путём анализа проектов по системной разработке, но применим, похоже, более широко к целой категории работников, сидящих на окладе[4].)

Статистика по чтению литературы обескураживает особенно сильно: средний разработчик программного обеспечения, к примеру, не имеет ни единой книги по предмету собственной работы и не может похвастать тем, что читал такую книгу[5]. Это ужасающий факт для тех, кто обеспокоен качеством работы в отрасли, а уж для тех, кто пишет книги, как мы, совершенно катастрофический.

Несколько лет назад мы с руководителем крупного проекта из Южной Калифорнии делились боевым опытом. Он стал перечислять последствия, которые проект и безумное количество потраченных на него рабочих часов имели для его сотрудников. Два развода можно было отнести непосредственно на счёт сверхурочных, а сын одного из сотрудников попал в какую-то нехорошую историю, связанную с наркотиками, вероятно, потому, что его папа был слишком занят в тот год и не мог уделять время своим родительским обязанностям. И наконец, нервный срыв руководителя группы тестирования.

Пока он перечислял все эти ужасы, я постепенно осознал, что он просто хвастает – на свой странный манер. Надо думать, если добавить ещё один-два развода и самоубийство, проект стал бы абсолютно успешным, по крайней мере, в его глазах.

(Т. Д.)

Несмотря на все разговоры в ключе «надо работать с умом», существует распространённое мнение, что менеджмент на самом деле существует исключительно для того, чтобы заставить людей работать интенсивнее и больше, в основном за счёт их личной жизни. Не смолкают горны руководителей, оповещающие о сверхурочных часах и о том, как увеличить продолжительность этих часов.

Историки уже давно вывели абстракции различных систем ценностей. Так, испанская теория утверждает, что ценности на Земле имеют некую конечную фиксированную стоимость и путь к накоплению богатства – узнать, как эффективнее всего эту стоимость извлекать из природных ресурсов или рабского человеческого труда. Английская же теория постулирует, что ценности можно создавать и нужны для этого изобретательность и технология. Короче говоря, англичане провернули промышленную революцию, пока испанцы крутили свои колёса и пытались эксплуатировать землю и индейцев в Новом Свете. Испанцы перевезли неимоверные объёмы золота через океан и получили в результате лишь грандиозную инфляцию (огромные суммы золотом против слишком малого количества полезных товаров).

Испанская теория ценностей жива и здорова в сознании многих руководителей. Это становится ясно, как только они заговаривают о производительности. Увеличение производительности по идее означает увеличение объёма полезной работы, выполняемой за определённый период времени, но слишком часто на практике выходит, что это стремление получить больше за оплаченный час работы. Разница велика. Руководители, следующие испанской теории, мечтают о достижении новых уровней производительности посредством простого механизма неоплаченных сверхурочных. Они делят выполненную в течение недели работу на сорок часов, а не на те восемьдесят или девяносто, которые в действительности затратил работник.

Это не совсем производительность (скорее мошенничество), но такова повседневная деятельность многих американских менеджеров. Кнутом и пряником они заставляют своих людей работать дольше. Они внушают, насколько важна дата выдачи продукта (хотя дата эта может быть совершенно произвольной, конец света не наступит только из-за того, что проект на месяц опоздал). Они заставляют людей принимать безнадёжно жёсткие графики, заставляют принести в жертву все, чтобы уложиться в сроки, и делают все возможное, чтобы заставить людей работать дольше и усерднее.

Возможно, ваш персонал на работе находится под воздействием принципа «работай больше и усерднее», однако дома человек находится во власти совсем иных мыслей. Например, таких: «Жизнь проходит. Нестираное бельё переполняет шкаф, детей некому обнять, супруг(а) начинает смотреть налево. Карусель жизни совершает лишь один оборот, и есть только один шанс добиться успеха. А ты тратишь свою жизнь на COBOL…»

But you know when the truth is told,
That you can get what you want or you can just get old.
You're going to kick off before you even get halfway through.
When will you realize... Vienna waits for you?

(«The Stranger», Billy Joeli[6])

(Но если совсем уж по правде сказать,
Можешь выиграть приз или старым ты стать,
И концы ты отдашь, полпути не пройдя,
Когда ты поймёшь, что… Вена ждёт тебя?)

Вена, которая, по словам Билли Джоэла, ждёт тебя, – это последняя остановка на твоём жизненном пути. Когда ты окажешься там, все будет кончено. Если вам кажется, что участников проекта никогда не интересуют такие серьёзные вещи, подумайте получше. Ваши люди очень остро понимают, что человеку дана лишь одна короткая жизнь, и они слишком хорошо знают, что в этой жизни должно быть что-то поважнее, чем их глупая работа.

Сверхурочные сотрудников, сидящих на окладах, – это плод воображения наивного руководителя. Да, в паре лишних субботних часов, позволяющих уложиться в сроки и сдать проект в понедельник, может быть очевидная польза, но за ними всегда следует равносильный период компенсации, сокращения рабочего времени, позволяющий сотрудникам вернуться в ритм привычной жизни. В конечном итоге каждый час сверхурочных компенсируется часом недоработки. В краткосрочной перспективе такой компромисс может принести пользу проекту, но в долгосрочной польза нивелируется.

Slow down you crazy child,
And take the phone off the hook and disappear for a while.
It's all right. You can afford to lose a day or two.
When will you realize... Vienna waits for you?

(Замедли свой бег, безумный ребёнок,
Отключи телефон и передохни,
Все в порядке, позволь себе день или два,
Когда ты поймёшь, что… Вена ждёт тебя?)

Для руководителя, следующего испанской теории, недоработанное время невидимо точно так же, как и сверхурочные, поскольку он всегда считает, что в рабочей неделе сорок часов независимо от того, сколько на самом деле потратили сотрудники. Это время невозможно увидеть в чьём-либо расписании. Это время разговоров по телефону, бесед в курилке или просто отдыха. Нет такого человека, который мог бы постоянно работать намного больше сорока часов в неделю, сохраняя уровень интенсивности, необходимый для творчества.

Сверхурочные похожи на спринт: он имеет смысл на последней стометровке марафонской дистанции для тех людей, у которых ещё остались силы, но если начать спринт на первом километре, вы только зря потеряете время. Если заставлять людей постоянно бежать в темпе спринта, они лишь потеряют уважение к руководителю. Лучшие из сотрудников уже все это проходили – они будут молчать и закатывать глаза, пока руководитель бредит, что эту работу просто необходимо закончить к апрелю. После этого они воспользуются компенсирующими недоработками и в конечном итоге каждую неделю будут работать не более сорока часов. Так реагируют лучшие; все остальные – просто трудоголики.

Трудоголики не компенсируют свои сверхурочные. Они согласны работать лишние часы, пусть и с понижающейся эффективностью. При достаточном давлении трудоголик способен далеко зайти по пути разрушения собственной личной жизни. Но это все лишь на время. Рано или поздно даже самых отъявленных трудоголиков осенит:

Slow down, you're doing fine,
You can't be everything you want to be before your time.
Although it's so romantic on the borderline tonight.
But when will you realize... Vienna waits for you?

(Замедли свой бег, все в порядке,
Ты достигнешь всего, когда время придёт,
И пусть на границе сегодня романтика,
Когда ты поймёшь, что… Вена все ещё ждёт?)

Переварив эту идею, сотрудник навсегда перестаёт быть полезным для проекта. Осознание того, что большие ценности (семья, любовь, дом, молодость) принесены в жертву меньшим (работа), разрушительно. Оно заставляет человека, совершившего столь глупую жертву, искать отмщения. Он не пойдёт к шефу, чтобы спокойно и вдумчиво объяснить, что положение вещей должно измениться; он просто уйдёт – ещё один человек, который сгорел на работе. Так или иначе, его больше не будет.

Трудоголизм – это заболевание, но оно не похоже на алкоголизм, затрагивающий лишь некоторых из нас. Трудоголизм больше похож на насморк – с каждым случается время от времени. И мы вспомнили об этой болезни не затем, чтобы обсудить причины и лечение, а чтобы поднять вопрос об отношении руководителя к трудоголикам. Если вы станете эксплуатировать таких людей до изнеможения, в стиле испанской теории, то рано или поздно потеряете их. Неважно, насколько отчаянно проект нуждается в их сверхурочных часах, вы не должны допускать, чтобы эти часы вычитались из личной жизни сотрудников. Потеря хорошего сотрудника того не стоит. Эта мысль выходит за узкие рамки вопросов трудоголизма и продолжается в более сложной области осмысленной производительности.

В следующий раз, слушая чьи-либо соображения по поводу производительности, обратите внимание, употребляет ли говорящий слово текучка. Скорее всего – нет. За многие годы мы стали свидетелями многочисленных споров о производительности и прочли сотни статей по этой теме, но ни один специалист не мог ничего внятного сказать о текучести кадров. Но какой смысл обсуждать одно, не вспоминая о другом? Рассмотрим некоторые типичные меры, предпринимаемые для повышения производительности:

• Давление на людей, цель которого – получить больше человеко-часов

• Автоматизация процесса разработки продукта

• Пренебрежение качеством продукта (более подробно в главе 4)

• Стандартизация процедур

Каждая из этих мер может сделать работу менее интересной и захватывающей. Следовательно, процесс повышения производительности связан с риском увеличения текучести рабочей силы. Разумеется, производительность невозможно увеличивать без этого. Просто всегда следует учитывать текучесть кадров, принимая решение стремиться к увеличению производительности. В противном случае можно получить «повышение», которое будет компенсировано потерей ключевых сотрудников.

В большинстве организаций даже нет статистики текучести кадров. Практически никто не может вычислить, сколько стоит замена опытного сотрудника. А когда речь идёт о производительности, все делают вид, что текучка не существует или бесплатна. Подходящий пример – проект Eagle в Data General[7]. С точки зрения испанской теории проект триумфальный: трудоголики, занятые в проекте, вкладывали бесконечные часы неоплачиваемых сверхурочных, чтобы поднять производительность на недосягаемые высоты. По окончании проекта практически все разработчики уволились. Какова была стоимость этой потери? Никто не позаботился включить её в уравнение.

Производительность следует определять как отношение выгоды к затратам, где выгода – экономия, выраженная в долларах, плюс прибыль от выполненной работы, а затраты – полная стоимость проекта, включая стоимость замены сотрудников, сгоревших на работе.

В прошлом году я консультировал проект, продвигавшийся столь гладко, что его руководитель была уверена – продукт будет сдан в срок. Её вызвали на совещание руководства и попросили сделать доклад о ходе работ. Она гарантировала, что продукт будет готов к установленному сроку – к первому марта, в полном соответствии с изначальными планами. Начальство почесало в затылках, получив столь неожиданные хорошие новости, и снова вызвало её на следующий день. Поскольку она успевает закончить проект к первому марта, сказали они, то решено перенести сроки сдачи на пятнадцатое января.

(Т. Д.)

Сроки, в которые проект мог реально уложиться, совершенно не интересовали этих «испанских теоретиков», поскольку с таким расписанием люди не находились бы под давлением. Пусть лучше будет безнадёжное расписание, которое позволит извлекать максимум труда из работников.

Весьма вероятно, что вы встречали одного или нескольких таких теоретиков на своём трудовом пути. Можно, конечно, посмеиваться над их близорукостью, но не думайте, что вы сами уже слезли с этой иглы. Каждый из нас хотя бы изредка поддаётся соблазну на короткий срок увеличить давление, чтобы заставить людей работать более интенсивно. При этом приходится закрывать глаза на снижение эффективности и конечную текучесть кадров, но игнорировать отрицательные побочные эффекты очень просто. Гораздо сложнее помнить вот такую неприятную истину:

Под давлением люди работают не лучше, а всего лишь быстрее.

Чтобы работать быстрее, им приходится жертвовать качеством продукта и собственным удовлетворением от работы.

Психологическая теория двадцатого века гласит, что характер человека находится под влиянием немногочисленных основных инстинктов, таких как выживание, самооценка, продолжение рода, территориальный инстинкт и так далее. Эти инстинкты записаны в аппаратной прошивке мозга. Их можно анализировать на интеллектуальном уровне, не поддаваясь эмоциям (что мы сейчас и делаем), но когда инстинкты проявляются на чувственном уровне, от страстей избавиться невозможно. Малейшее воздействие на любую из этих встроенных ценностей может вывести человека из равновесия.

Сильные эмоции являются показателем того, что одна из инстинктивных ценностей находится под угрозой. Начинающий руководитель может полагать, что работу можно сделать, не затрагивая человеческих эмоций, но если у вас есть хотя бы небольшой опыт руководства, вы полностью уверены в обратном. Наша работа даёт много возможностей для проявления эмоций.

Скорее всего, вы легко вспомните по меньшей мере один случай, когда эмоциональный всплеск был вызван чем-то, связанным исключительно с работой. Подумайте об этом случае и задайтесь вопросом (вероятно, в который уже раз) – откуда взялись все эти эмоции? Не имея никакой информации о данном конкретном случае, мы готовы спорить, что причиной была угроза самооценке. В личной жизни причины эмоциональных реакций многочисленны и разнообразны, но на рабочем месте главным источником душевных потрясений является самооценка, находящаяся под угрозой.

Мы склонны считать, что существует сильная связь между самооценкой и качеством создаваемого продукта – не количеством, а именно качеством. (Почему-то сдача большого количества продукции среднего уровня не приносит удовлетворения, хотя именно таковы могут быть требования момента.) Любой шаг, который может угрожать качеству продукта, весьма вероятно станет для сотрудников источником эмоций, направленных против вас.

Руководители ставят под угрозу качество продукта, устанавливая невозможные сроки его сдачи. Но они вовсе не задумываются об этом; они полагают, что такие действия ставят перед сотрудниками интересную задачу, которая поможет им стремиться к совершенству.

Опытные (вернее, заезженные) сотрудники знают, что все не так. Они понимают, что под дулом автомата их старания будут чрезмерно стеснены. У них не будет возможности распорядиться ресурсами так, чтобы своевременно сдать продукт. Не говоря уже о привлечении дополнительных участников или перераспределении функций. Единственное, чем можно будет пожертвовать, – это качество. Крайняя степень давления сроков заставит их принести качество в жертву. Они станут заметать проблемы под ковёр, чтобы разобраться с ними в последний момент или вовсе оставить в продукте на «радость» конечному пользователю. Они будут сдавать продукты нестабильные и незавершённые. Они возненавидят свою работу, но какой у них выбор?

Практичный боевой руководитель внутри вас ответит на это: «Кое-кто из моих ребят может до бесконечности возиться с задачей во имя „качества“. Но рынку абсолютно плевать на такой уровень качества – он в истерике требует продукта, причём уже со вчерашнего дня, и примет его в том виде, какой у нас есть сейчас». Во многих ситуациях вы будете правы насчёт рынка, но решение заставить людей выдать продукт, не соответствующий их собственным стандартам качества, практически всегда будет ошибкой.

Мы, руководители, склонны считать качество лишь одним из свойств продукта, чем-то, что можно регулировать в зависимости от потребностей рынка. Качество – вроде шоколадного соуса на пломбире домашнего приготовления – каждый добавляет по вкусу.

Взгляд создателя на качество совсем иной. Поскольку самооценка сильно связана с качеством продукта, он, создатель, устанавливает собственные стандарты. Удовлетворительный для него минимум более-менее соответствует высшему уровню качества, достигнутому им в прошлом. И это неизбежно более высокий стандарт, чем тот, что необходим рынку и за который рынок готов платить.

«Рынку абсолютно плевать на такой уровень качества». Прочтите эти слова и прослезитесь, потому что они почти всегда правдивы. Люди могут с пеной у рта говорить о качестве и горько жаловаться на его отсутствие, но когда приходит время платить за качество, их действительные ценности выходят на поверхность. В проекте по разработке программного обеспечения вы можете представить пользователям следующее объяснение: «На основе эмпирических данных мы можем прогнозировать, что Среднее Время Между Сбоями для этого продукта в настоящий момент составляет примерно один час и двенадцать минут. Если мы сдадим продукт вовремя, то есть сегодня, он будет иметь низкую стабильность. Если мы затратим ещё три недели, то можем прогнозировать увеличение СВМС до двух тысяч часов, что есть вполне достойный результат». После этого можете ожидать потока недовольного бормотания со всех сторон. Пользователи объяснят, что качество ценят точно так же, как все, но три недели стоят серьёзных денег.

Что касается индустрии программного обеспечения, то она приучила клиентов принимать как должное внутрикорпоративные прикладные программы со средней плотностью изъянов от одного до трех на сотню строк кода! И – какова ирония – этот катастрофический результат зачастую относят на низкую сознательность разработчиков в том, что касается качества. То есть тех же, кого обвиняют в желании «до бесконечности возиться с программой во имя качества», ещё и осуждают за низкое качество. Давайте-ка найдём тех, кто действительно виноват. Тот, кто платит пианисту, почему-то предлагает играть плохую музыку. Сообщество пользователей программного обеспечения продемонстрировало свои стандарты качества, регулярно подвергая процесс разработки неимоверному временному давлению, а затем принимая продукты низкого качества[8].

Такие слова могут показаться обличительной речью, направленной против пользователей программного обеспечения и стандартов рынка в целом, но не стоит воспринимать их подобным образом. Мы должны исходить из того, что люди, финансирующие наш труд, находятся в здравом уме и способны принять разумный компромисс между качеством и стоимостью. Основная идея здесь в том, что осознаваемая клиентом потребность в качестве зачастую не столь велика, как аналогичная потребность разработчика. Существует естественное противоречие. Снижение качества продукта, вероятно, приведёт к тому, что некоторые люди откажутся от покупки, но сокращение рыночной доли – прямое следствие любого подобного снижения качества – зачастую компенсируется увеличением прибылей на каждую проданную единицу продукта.

Бегство от совершенства – так мы называем ситуацию, когда стандарты качества устанавливает покупатель, а не создатель. Стандарты, основанные на существующем рыночном качестве, имеют смысл лишь до тех пор, пока вы не обращаете внимания на настроение и эффективность труда разработчиков.

В долгосрочной перспективе рыночные стандарты качества обходятся дороже. Какой урок отсюда следует?

Качество, серьёзно превосходящее запросы конечного пользователя, есть средство достижения более высокой производительности.

Если вы сомневаетесь в этом, вообразите следующий глубокомысленный эксперимент: спросите сто человек с улицы, какая культура или нация прославилась благодаря высокому качеству. Предсказываем, что более половины людей сегодня ответят «японская». Теперь спросите у другой сотни людей, какая культура или нация известна высокой производительностью. И опять можно ожидать, что большинство ответят «японская». Нация, признанная лидером в области качества, столь же известна своей высокой продуктивностью.

Постойте. Как же возможно, что более высокое качество сосуществует с более высокой производительностью? Ведь это противоречит прописной истине, что повышение качества продукта означает увеличение его себестоимости. Вот подсказка Тадзимы (Tajima) и Мацубары (Matsubara), двух авторитетных комментаторов японского феномена:

В Японии компромисс между качеством и стоимостью не существует. Здесь почто все считают, что высокое качество приводит к сокращению стоимости[9].

Именно об этом Филип Кросби (Philip СговЬу) написал книгу «Quality Is Free» (Качество бесплатно), опубликованную в 1979 году. В этой работе Кросби привёл многочисленные примеры и чётко доказал, что если исполнитель работы устанавливает удовлетворяющий его самого стандарт качества, то увеличение производительности компенсирует удорожание более высокого качества[10].

Нас терзает ужасное подозрение, что книга Кросби принесла скорее вред, чем пользу. Беда в том, что подавляющее большинство руководителей не затруднилось эту книгу прочитать, хотя название слышали все. Название и стало восприниматься как основная идея книги. Руководители по всему миру проявляют энтузиазм в отношении качества: «Нет пределов для качества, и у нас будет столько бесплатного качества, сколько мы захотим!». Навряд ли это можно назвать беспокойством о качестве. Такое отношение совершенно противоположно тому, за которое ратует Кросби.

На самом деле идею связи качества и производительности следует представить немного иными словами:

Качество не стоит ничего, но только для тех, кто готов дорого за него заплатить.

Организация, готовая заплатить за качество ноль долларов и ноль центов, получит то, за что заплатила. Правило «Качество? Если успеем!» гарантирует отсутствие всякого качества в продукте.

Примером организации, пожинающей обильный урожай производительности за счёт высоких авторских стандартов качества, является Hewlett-Packard. Качество в этой компании возведено в ранг культа. В такой среде обычно не услышишь аргумент, что для создания более качественного продукта потребуется больше времени или денег. В результате разработчики осознают, что качество создаваемых ими продуктов превосходит потребности рынка. Возможность руководствоваться собственными критериями даёт им большее удовлетворение от работы, а компании – одни из самых низких показателей текучести кадров в отрасли.

В отдельных японских компаниях, в частности Hitachi Software и некоторых подразделениях Fujitsu, команда проекта имеет право налагать вето на сдачу продукта, если по мнению команды этот продукт не готов. Не имеет значения, готов ли клиент принять низкокачественный продукт, команда может настоять на том, чтобы сдача продукта была отложена до тех пор, пока он не будет удовлетворять собственным стандартам разработчиков. Разумеется, руководители проектов там находятся под тем же давлением, что и у нас: от них требуют результатов немедленно – покажите нам хоть что-нибудь прямо сейчас. Однако культура качества в достаточной степени распространена, так что эти японские руководители понимают, насколько неправильно склонять сотрудников к компромиссам в области качества.

Сможете ли вы наделить своих людей правом вето? Да, нервы потребуются стальные, по крайней мере, поначалу. Главной вашей заботой станет Закон Паркинсона, способный заработать против вас. Эта тема настолько важна, что мы посвятили ей целую главу.

В 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 году, она была когда-то самой крупной компанией в мире) сегодня проводят по сорок часов в неделю, заполняя формуляры. Обратите внимание, как в данном случае компания, а не её сотрудники, демонстрирует поведение, подчиняющееся закону Паркинсона. Мы вернёмся к этой теме во второй части.

Лаетрил – это бесцветный экстракт из мягкого содержимого абрикосовых косточек. В Швеции его можно купить в бакалее по цене, сравнимой с ценой миндальной эссенции. Как и любая другая эссенция, он применяется для выпечки. В Мексике его продают по пятьдесят долларов за каплю как «лекарство» от смертельного рака. Разумеется, он ничего не лечит. Все свидетельства подтверждают лишь то, что это грубое мошенничество. Но смертельно больные принимают заверения толкачей лаетрила – и неважно, насколько вопиющие, поскольку других вариантов все равно нет. Находясь в достаточно сильном отчаянии, люди не слишком склонны искать реальные подтверждения.

Точно так же «находятся в достаточно отчаянном положении» руководители, и это отчаяние делает их легковерными жертвами тех видов лаетрила технологического, которые по слухам способны повышать производительность. Редко когда находятся свидетельства, подтверждающие действенность «лекарственных» средств. И руководители также обходятся без свидетельств – им просто некогда их искать.

В один прекрасный день в порыве глупости я начал вырезать из газет рекламные объявления, обещавшие увеличить производительность на сто или более процентов. Довольно быстро я набрал их целый ворох. Многообразие рекламируемых средств фантастического повышения производительности не могло не поразить. Семинары, комплексные программы, методологии, книги, способы календарного планирования, аппаратные средства наблюдения, вычислительные языки и бюллетени. Возвращаясь вечером того дня на метро домой, на обложке «Нью-Йорк Пост» я вдруг увидел ещё одно объявление, которое гласило: «Худейте во сне». И оно вполне подходило ко всем остальным.

(Т. Д.)

Все мы очень обеспокоены вопросом повышения производительности. От этой проблемы уже не избавиться посредством простых решений, все такие решения были найдены и задействованы уже очень давно. Однако некоторые организации чувствуют себя намного лучше других. Мы убеждены, что их лидеры не используют какие-либо исключительно продвинутые технологии. Их более высокую производительность можно полностью объяснить более эффективными способами работы с людьми, иным подходом к планированию рабочего пространства и иной корпоративной культурой, а также реализацией мер, которые мы обсудим в частях 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. Эта женщина – яркий пример того, что я теперь привык называть просвещённым руководством. Как-то раз шёл снег, и я, переборов своё болезненное состояние, притащился на работу, чтобы собрать нашу шаткую систему воедино – в демонстрационную версию для пользователей. Шерон зашла и обнаружила меня за консолью. Она исчезла и вернулась через несколько минут с миской супа. Когда она влила в меня этот суп, я почувствовал прилив бодрости и спросил, как она умудряется находить время на такие вещи, ведь ей ещё нужно решать столько вопросов, связанных с руководством проектом. Она улыбнулась своей неповторимой улыбкой и сказала: «Том, это и есть руководство».

(Т. Д.)

Шерон знала то, что знают инстинктивно все хорошие руководители: назначение руководителя не в том, чтобы заставить людей работать, а в том, чтобы создать им условия для работы.