Предисловие
То, что принято теперь называть проектом «Человеческий фактор», началось для нас одним долгим ночным перелетом через Тихий океан более тридцати лет назад. Мы летели вместе из Лос-Анджелеса в Сидней, чтобы читать свои лекции по конструированию программного обеспечения. Не в силах уснуть, мы всю ночь трепались о серьезнейших сложностях, с которыми сталкивались в собственных проектах разработки систем и о которых узнавали из рассказов наших клиентов. Один из нас – и мы не можем уже вспомнить, кто именно, – резюмируя разговор, сказал вот что: «Быть может... главные проблемы системной разработки не столько технологические, сколько социологические».
Эта мысль укоренилась далеко не сразу, поскольку противоречила тому образу мышления, который мы использовали в те годы. Как и практически каждый, кто в то время участвовал в предприятиях, основанных на высоких технологиях, мы были убеждены, что технология – это ответ на все вопросы, и что какими бы ни были ваши проблемы, для них найдутся более качественные технологические решения. Но если вам предстояло решать задачи гуманитарные по самой своей природе, более качественная технология навряд ли могла помочь. Например, если люди, вынужденные работать в одной группе, не доверяли друг другу, никакой чудный пакет программ и никакая технологическая штучка не способны были это исправить.
Как только на эту идею пролился свет, мы начали придумывать примеры к ней, и нам обоим вскоре стало очевидно, что социальные сложности в большинстве известных нам проектов стократно превосходили любые технологические вызовы, возникавшие в этих проектах. Далее мы неизбежно столкнулись с еще более печальным фактом: хоть каждый из нас и чувствовал нутром, причем довольно давно, что социология важнее технологии,
Как изменился бы стиль нашего управления, осознай мы ранее, что человеческая составляющая вопроса имеет гораздо большее значение, чем технологическая? Мы принялись писать списки. У нас были под рукой чистые слайды для проектора и маркеры, так что мы нанесли некоторые списки на слайды и, испытывая легкое головокружение, обдумывали идею взять и показать некоторые из этих идей нашим слушателям в Сиднее. Какого черта! Сидней находится на другом конце света относительно Штатов и Европы; если мы провалимся в Австралии, дома даже никто не узнает, решили мы.
На следующей неделе наши слушатели в Сиднее сразу же включились в материал о человеческом факторе, а кроме того – были несколько раздосадованы (очевидно, не только мы управляли так, как будто значение имела лишь технология). Самое приятное, что люди стали включаться в процесс и рассказывать нам свои примеры по этой теме, за что мы были невероятно благодарны.
Между тем ранним экспериментом на окраине и первым изданием книги, вышедшим в 1987 году, мы проделали огромную работу: проводили опросы и эмпирические исследования, чтобы подтвердить свои подозрения о воздействии среды (часть II третьего издания) и проверить некоторые из своих более радикальных предположений относительно командной динамики и общения (большая часть оставшейся части книги).
Первые два издания «Человеческого фактора» сделали нас своего рода счетной палатой идей относительно гуманитарной стороны технологических проектов, так что нам пришлось расширять свой подход, чтобы поспеть за происходящим. Новые разделы этого третьего издания посвящены некоторым патологиям лидерства, которые ранее таковыми не считались, эволюционирующей культуре собраний, гибридным командам, состоящим из людей разных и, казалось бы, несовместимых поколений, а еще растущему пониманию того, что некоторые наши самые распространенные инструменты служат скорее якорями, а не двигателями.
За это третье издание мы выражаем благодарность Венди Икин (Wendy Eakin) из Dorset House и Питеру Гордону (Peter Gordon) из Addison-Wesley за редактирование нашей рукописи и придание ей формы. Также хотим сказать спасибо нашим давнишним коллегам по The Atlantic Systems Guild – Петеру Хрушке (Peter Hruschka), Стиву Мак-Менамину (Steve McMenamin), Джеймсу и Сюзанне Робертсон (James Robertson, Suzanne Robertson) – за тридцать лет идей, мозговых штурмов, дискуссий, трапез и дружбы.
Том Демарко и Тим Листер
Февраль 2013
Об авторах
Том Демарко и Тимоти Листер – руководители компании The Atlantic Systems Guild (
Том Демарко (фотограф Ганс-Рудольф Шульц)
Том Демарко – соавтор девяти книг на самые разные темы, от методов разработки до функций и дисфункций организаций. Кроме того, он написал два романа и сборник коротких рассказов. В своей практике консультанта выполняет чаще всего функцию специалиста-наблюдателя, хотя время от времени консультирует проекты и команды. Сейчас Том уже третий год преподает этику в Университете штата Мэн, а проживает неподалеку, в городке Кэмден.
Тимоти Листер (фотограф Джеймс Робертсон)
Тимоти Листер свое время посвящает консультированию, преподаванию и написанию книг. Тим живет на Манхэттене. Вместе с Томом написал книгу «Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения», а в соавторстве с четырьмя другими руководителями The Atlantic Systems Guild – книгу «Балдеющие от адреналина и зомбированные шаблонами: паттерны поведения проектных команд». Является членом организаций IEEE, ACM и Cutter IT Trends Council.
I
Управление человеческим ресурсом
Мы, руководители, в большинстве своем подвержены одной характерной ошибке: мы склонны управлять людьми так, словно они – модульные компоненты. Вполне очевидно, откуда берется эта тенденция. Вспомните, как происходит подготовка к руководству: считается, что мы вполне подходим на руководящие роли, если мы хорошо себя зарекомендовали в качестве исполнителей, техников и разработчиков. От исполнителей часто требуется организация ресурсов в модули: фрагменты программного кода, микросхемы и другие рабочие блоки. Подобным модулям присущи свойства черного ящика, так что их внутреннее своеобразие можно спокойно игнорировать. Они задуманы как предметы, имеющие стандартные интерфейсы.
Мы полагаемся на модульные методы в течение многих лет, и неудивительно, что в качестве начинающих руководителей пытаемся применить их для управления человеческими ресурсами. Увы, для человеческих ресурсов эти методы не совсем пригодны.
Первая часть этой книги начинает наше исследование совершенно иного способа думать о людях и управлять ими. И этот способ требует привыкания к совершенно
1.
А в это время где-то гибнет проект
С тех пор как компьютеры стали доступны широким массам пользователей, разработчики создали, должно быть, десятки тысяч бухгалтерских программ. Вероятно, еще десяток (или больше) таких проектов кто-то ведет прямо сейчас, когда вы читаете эти строки. И как раз в это время один из них терпит крушение.
Представьте себе! Проект, не требующий никаких технических новшеств, разваливается на глазах. Бухгалтерский учет – это колесо, которое изобретали заново столь часто, что многие разработчики-ветераны способны участвовать в таком проекте чуть ли не с закрытыми глазами. И все же подобные предприятия время от времени оканчиваются неудачей.
Предположим, после одной из таких катастроф вас попросили сделать вскрытие. (Мечтать не вредно, разумеется: существует нерушимый отраслевой стандарт, запрещающий нам изучать провалы.) Предположим, что вам выпал шанс выяснить причины неудачи, прежде чем участники проекта успели разбежаться кто куда. Среди причин, потопивших проект, не будет
В первое десятилетие нашего проекта «Человеческий фактор» мы ежегодно проводили исследования проектов разработки и анализ результатов этих проектов. Мы оценивали размеры, стоимость, недостатки, факторы ускорения, а также соответствие развития проекта предполагаемым срокам. В конечном итоге мы собрали более пятисот историй различных проектов, и в каждой из них мы видим реальный труд разработчиков.
Около пятнадцати процентов всех проектов закончились ничем: они были отменены, или прерваны, или отложены, или же результатом их стали никому не нужные продукты. В случае крупных проектов картина еще хуже. Крах постиг двадцать пять процентов проектов, длительность которых составляла от двадцати пяти человеко-лет. В ранних исследованиях мы отбрасывали провалы и изучали данные прочих проектов. Однако начиная с 1979 года мы обязательно связывались с участниками неудавшихся проектов и узнавали, что пошло не так. В подавляющем большинстве случаев не было
Суть вопроса
Чаще всего участники наших опросов в качестве причины краха называли «политику». Следует учесть, что люди трактуют это понятие достаточно широко. В «политику» входят такие несвязанные или слабо связанные между собой вещи, как проблемы коммуникации, проблемы с персоналом, разочарование в начальнике или заказчике, недостаточная мотивация и высокая текучесть кадров. Человек часто употребляет слово
Если считать проблему политической по природе, то в отношении к ней неизбежно появляется фатализм. Вы знаете, что способны справиться с техническими сложностями, но, если честно, кто из нас чувствует себя уверенно в области политики? Если же понять, что природа проблемы – социологическая, а не политическая, то решить эту проблему будет намного проще. Социология проекта и команды может выходить за рамки вашей компетенции, но не способностей.
Как ни называй проблемы, связанные с людьми, именно они, вероятнее всего, станут причиной неприятностей в вашем следующем проекте, а вовсе не вопросы проектирования, реализации и методологии. По сути, именно эта мысль и проходит красной нитью через всю книгу:
Многие руководители готовы согласиться с тем, что сталкиваются больше с человеческим фактором, нежели с техническими сложностями.
Причиной такому феномену служит отчасти процесс воспитания среднего руководителя. Его учили тому, как выполнять работу, а не как руководить работой. Редко когда новый руководитель может похвастаться чем-то, что указывало бы на его способность или склонность к руководству. У них мало опыта руководства и отсутствует осмысленная практика. Но каким же образом новым руководителям удается убедить себя, что они могут спокойно тратить бо́льшую часть своего времени на размышления о технологии и совсем чуть-чуть (или нисколько) на размышления о человеческой стороне проблемы?
Миражи высоких технологий
Ответ, возможно, кроется в явлении, которое мы окрестили миражами высоких технологий. Это распространенная убежденность людей, имеющих дело с любым аспектом новой технологии (а кто из нас не имеет?), что они работают в сфере действительно высоких технологий. Они потворствуют развитию этой иллюзии, объясняя на какой-нибудь вечеринке, что работают «в области компьютеров» или же «в области телекоммуникаций» или занимаются «электронным переводом денежных средств». Намекая тем самым, что они принадлежат к миру высоких технологий. Между нами говоря, обычно это не так. Исследователи, совершающие фундаментальные прорывы в перечисленных областях, – действительно из мира высоких технологий. А мы лишь используем результаты их труда. Компьютеры и прочие элементы новых технологий служат нам для организации собственных предприятий. Наши рабочие единицы – это команды, проекты и взаимосвязанные рабочие группы, а потому наша область деятельности – преимущественно человеческое взаимодействие. Наш успех напрямую зависит от качественного человеческого взаимодействия всех участников предприятия, а наши неудачи являются прямым следствием недостатка человеческого взаимодействия.
Главная причина, по которой мы склонны сосредотачивать усилия на технической, а не на человеческой стороне работы, – вовсе не приоритет первой перед второй. Технические вопросы проще решать. Гораздо проще организовать установку нового оптического привода, чем выяснить, почему Хорас в замешательстве или почему Сьюзен выражает недовольство компанией уже после нескольких месяцев работы. Человеческие взаимодействия сложны, их проявления не бывают очевидными и прозрачными, но они имеют бо́льшее значение, чем любой другой аспект работы.
И если вы концентрируетесь больше на технологии, чем на социологии, то уподобляетесь персонажу водевиля, который потерял ключи на темной улице, а ищет их на соседней, потому что, как объясняет он сам: «Там не так темно».
2.
Сделал чизбургер – продай его
Разработка по природе отличается от производства. Однако руководителям предприятий по разработке и смежных с ними свойственен образ мышления, уходящий корнями исключительно в производственную среду.
Представьте на секунду, что вы – менеджер местного предприятия быстрого питания. Перечисленные ниже меры повышения эффективности производства, причем в любой комбинации, будут полностью оправданны:
Исключить ошибки. Заставить машину (коллектив) работать гладко, насколько возможно.
Занять жесткую позицию в отношении сотрудников, склонных филонить на рабочем месте.
Считать служащих взаимозаменяемыми винтиками.
Оптимизировать стабильное состояние. (Даже не задумываясь о том, как производство вышло на полную мощность или каким образом его возможно остановить.)
Стандартизировать процедуру. Делать все по инструкции.
Исключить эксперименты – за это получают деньги те, кто сидит в штаб-квартире.
Подобные меры были бы разумными для бизнеса быстрого питания (или любой производственной среды), но вы работаете в другой сфере. Подход «сделал чизбургер – продай его» может стать фатальным для вашей разработки. Он способен лишь подавить дух сотрудников и отвлечь их внимание от проблем, подлежащих решению. Такой стиль управления противоречит сути работы.
Чтобы эффективно управлять людьми в области интеллектуального труда, необходимо принимать меры, противоположные перечисленным выше. Эти противоположные меры описаны в последующих разделах.
Допустимость ошибок
Для большинства работников, занятых в сфере интеллектуального труда, допускаемые время от времени ошибки – вполне естественная и безопасная составляющая деятельности. Но иногда между ошибкой в работе и грехом проводятся почти библейские ассоциации. Для того чтобы изменить подобное отношение, необходимо принять действительно серьезные меры.
В разговоре с группой руководителей проектов по разработке программного обеспечения мы представили стратегию, которую считаем случаем
Поощрение атмосферы, не позволяющей допускать ошибки, просто заставляет людей занимать оборонительные позиции. Они не пробуют подходы, способные закончиться отрицательным результатом. Вы же поощряете такое поведение, пытаясь упорядочить процесс и использовать жесткие методологии, ради исключения ошибок запрещающие сотрудникам принимать ключевые стратегические решения. Любые меры, препятствующие совершению ошибок, могут лишь ненамного поднять уровень технологии, а вот социология команды может пострадать весьма серьезно.
Противоположный подход –
Менеджмент: простецкое определение
Менеджмент – понятие достаточно сложное, чтобы ему можно было дать простое определение, однако этот нюанс ускользнул от одного менеджера высшего звена, с которым мы общались на профессиональном конвенте в Лондоне. Свое понимание предмета он суммировал так: «Менеджмент – это умение пинать сотрудников». Это равнозначно мнению, что руководители в основном думают, а подчиненные лишь выполняют их волю. Опять же для производства чизбургеров это, быть может, вполне продуктивный подход, но и только; он не действует для предприятия, в котором люди работают головой, а не руками. В подобной среде мозг каждого участника должен участвовать в процессе. Посредством пинков вы сможете в лучшем случае активизировать сотрудников, но не добиться от них творческого подхода, вдумчивости и изобретательности.
Даже если бы воздействие на пятую точку давало кратковременный прирост производительности, в перспективе оно могло бы оказаться не столь полезным: нет ничего более обескураживающего для любого работника, чем чувство, что его собственной мотивации не хватает и потому требуются «добавки» со стороны начальства.
Самое печальное в таком подходе к руководству – это то, что он практически никогда не оправдан. Большинство сотрудников любят свою работу, и чаще всего не требуются жесткие меры, чтобы они продолжали работать. Напротив, может возникнуть необходимость сделать так, чтобы они работали
Человеческие запчасти
В производственной сфере людей удобно считать частями рабочего механизма. Когда часть механизма износилась, ее заменяют на другую. Замена совместима с оригиналом, поэтому новую можно, грубо говоря, заказать по каталогу.
Многие руководители проектов по разработке придерживаются такого же подхода. Они идут на все, убеждая себя, что нет незаменимых людей. Из страха, что ключевой человек уйдет, они заставляют себя считать, что ключевых людей попросту не существует. Разве не в этом, в конце концов, сущность менеджмента – делать так, чтобы работа не останавливалась в случае ухода отдельных людей? Эти руководители ведут себя так, словно существует волшебный магазин человеческих запчастей, куда можно позвонить с такой примерно просьбой: «Пришлите мне нового Джорджа Гарденайера, только пусть он будет не такой дерзкий».
Один мой клиент поднял вопрос о повышении зарплаты одному из превосходных сотрудников и, к своему удивлению, узнал, что этому человеку нужно нечто другое, не деньги. Сотрудник сообщил, что дома у него часто появляются хорошие идеи, но работа через медленное подключение к Интернету слишком неудобна. Не может ли компания провести ему домой выделенную линию и купить высокопроизводительную рабочую станцию? Компания так и сделала. В последующие годы она даже создала и обставила для этого сотрудника маленький домашний офис. Но этот мой клиент – нетипичный случай. Интересно, что сделал бы менее восприимчивый руководитель? Слишком уж многие руководители остро реагируют на любые попытки сотрудников подчеркнуть собственную индивидуальность.
Т.Л.
Вот один пример такого менее восприимчивого руководителя, взятый из жизни. Этот начальник крайне остро реагировал на индивидуальность своих подчиненных. Один весьма талантливый сотрудник большую часть года проводил на площадках клиентов и, как следствие, жил на командировочные. Анализ расходов этого сотрудника показал, что расходы на питание сильно отличаются от расходов других «путешественников» по этой статье. На еду он тратил в полтора раза больше других. В негодующем открытом письме начальник заклеймил «гастрономического преступника». Между прочим,
Уникальность каждого человека – постоянный раздражитель для руководителя, слепо уверовавшего в стиль управления, взятый из производственной сферы. Руководитель, умеющий работать с людьми, напротив, осознает, что именно уникальность участников является залогом активности и эффективности внутрипроектных отношений.
Стабилизация проекта означает его смерть
Образ мышления, характерный для производства, находящегося в стабильном состоянии, особенно плохо сочетается с ведением проектов. Мы склонны забывать, что самоцель существования проекта состоит в том, чтобы выйти из бизнеса. Единственное стабильное состояние в жизни проекта – трупное окоченение. Управление проектом должно сосредоточиваться на
Несколько лет назад я вел курс проектирования в одной фирме, и один из менеджеров высшего звена буквально преследовал меня просьбой оценить некоторых слушателей (сотрудников его проекта). Особенно его интересовала одна женщина. Его сомнения выражались так: «Не совсем понимаю, какая польза от нее проекту – она не гениальный разработчик, не очень разбирается в тестировании, да и вообще в чем-либо еще». Небольшое расследование выявило любопытный факт: за двенадцать лет работы в компании эта женщина участвовала исключительно в проектах, закончившихся гигантским успехом. Ее вклад был неочевиден, но проект с ее участием неизменно был удачным. Понаблюдав за ней на занятиях с неделю и переговорив с ее коллегами, я пришел к выводу, что эта женщина – великолепный катализатор. В ее присутствии команда начинала работать легко. Она помогала людям общаться и ладить. Проекты с ее участием не были скучными. Попытавшись донести эту мысль до руководителя, я потерпел неудачу. Он попросту не считал катализатор жизненно необходимым для проекта.
Т. Д.
Катализатор важен, потому что проект постоянно находится в движении. Человек, способный заставить проект шевелиться, стоит двух, просто выполняющих работу.
У нас есть время только выполнить работу, но не думать о ней
Если на вас лежит ответственность за выполнение задания, какую долю времени следует потратить непосредственно на выполнение? Не сто процентов. Необходимо предусмотреть время на мозговые штурмы, на изучение новых подходов, на поиск экономичных решений, на чтение, подготовку, да и просто безделье.
Вспоминая годы, когда мы сами руководили проектами, мы пришли к заключению, что подходили к этому вопросу неправильно. Слишком много времени тратили на попытки получить результат и недостаточно на ключевой вопрос: а нужны ли вообще эти результаты? Принцип стабилизированных чизбургеров даже рядом не валялся с идеей о размышлениях на работе. Единственная его цель – по максимуму свести все усилия к действию. Если надо как-то объяснить недостаток времени на размышления, то этим объяснением всегда становятся сжатые сроки. Можно подумать, существует работа, не подверженная давлению сроков.
Потребность в более взвешенном подходе возрастает по мере того, как растут ставки. Лишь когда требуются поистине титанические усилия, мы начинаем постигать другой режим, в котором больше времени уделяется размышлениям о работе и меньше собственно выполнению работы. Чем больше требуется героических усилий, тем важнее, чтобы люди в команде учились взаимодействовать эффективно и получать от этого удовольствие. Именно проект, сдача которого запланирована на нереальную фиксированную дату,
Но ведь все эти нежности совершенно неуместны. Каждый знает и действует с пониманием, ведь так? Не так. Мы столь слепо стремимся к Достижению Чего-Либо, Чего Угодно, что тратим лишь скудные пять процентов своего времени на деятельность, посвященную планированию, исследованию новых методов, обучению, чтению книг, прогнозированию, бюджетному планированию, а также распределению кадров. (Показатель в пять процентов получен путем анализа проектов по системной разработке, но применим, похоже, более широко, возможно, к целой категории работников, сидящих на окладе.)
Статистика по чтению литературы обескураживает особенно сильно: средний разработчик программного обеспечения, к примеру, не имеет ни единой книги по предмету собственной работы и не может похвастать тем, что читал такую книгу. Ужасающий факт для тех, кто обеспокоен качеством работы в отрасли, а уж для тех, кто пишет книги, как мы, совершенно катастрофический.