Новая часть VI «Наследие Peopleware» включает главы о командах и их травле, о программах по улучшению процессов, о внутреннем соперничестве, об изменениях и управлении изменениями, о человеческом капитале, о трате времени, о корпоративном обучении и о том, что мы называем аристотелевой политикой.
Август 1998
Том Демарко
Камден, Мэн
Тим Листер
Нью-Йорк
Предисловие к первому изданию
Если вам приходилось участвовать в серьёзных проектах по разработке, вы практически наверняка знакомы с мудростью поговорки «Первый блин комом». Только закончив работу, вы обладаете полноценным знанием о том, как её следовало делать. Очень редко удаётся сделать шаг назад и выполнить работу заново, но приятно было бы иметь такую возможность.
Эта же мысль справедлива и для карьеры в целом. Мы вдвоём потратили около тридцати лет на управление проектами и консультирование в этой области. В основном мы приобретали знания в результате того, что первый блин выходил комом. И ни разу нам не была доступна роскошь вести любой из этих проектов заново, чтобы сделать все абсолютно безошибочно. Поэтому мы написали книгу.
Она состоит из серий кратких очерков, каждый из которых посвящён одной тропинке, приводящей руководителей к сожалению о содеянном. Как правило, их побуждает к ошибочным действиям какой-то аспект управленческого фольклора, столь вездесущего и популярного, но зачастую некорректного. Мы и сами поддались искушению пройти по всем этим тропинкам. Если цель написания книги достигнута, она поможет вам избежать хотя бы некоторых ошибок.
Фольклор пестрит простыми рецептами: возьмите оценку трудоёмкости, данную сотрудником, и умножьте её на два. Не снижайте давления; не позволяйте людям работать дома, они станут филонить. На страницах книги есть какие угодно рецепты, кроме простых. Они привлекают ваше внимание к сложным потребностям человеческой индивидуальности, к острой внутриполитической обстановке офисной среды, к головоломке удержания ценных кадров, к интригующим и порой неимоверно раздражающим вопросам командной работы и наконец – к труднодостижимому состоянию удовлетворения.
Данный труд является для нас очень личным, поэтому время от времени повествование идёт от первого лица, и инициалы позволят вам понять, кому из авторов принадлежат эти слова.
Сентябрь 1987
Том Демарко
Камден, Мэн
Тим Листер
Нью-Йорк
I. УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМ РЕСУРСОМ
Мы, руководители, в большинстве своём подвержены одной характерной ошибке: мы склонны управлять людьми так, словно они – модульные компоненты. Вполне очевидно, откуда берётся эта тенденция. Вспомните, как происходит подготовка к руководству: считается, что мы вполне подходим на руководящие роли, если хорошо себя зарекомендовали в качестве исполнителей, техников и разработчиков. От исполнителей часто требуется организация ресурсов в модули: фрагменты программного кода, микросхемы и другие рабочие блоки. Подобным модулям присущи свойства чёрного ящика, так что их внутреннее своеобразие можно спокойно игнорировать. Они задуманы как предметы, имеющие стандартные интерфейсы.
Мы полагаемся на модульные методы в течение многих лет, и не удивительно, что в качестве начинающих руководителей пытаемся применить их для управления человеческими ресурсами. Увы, для человеческих ресурсов эти методы не совсем пригодны.
Первая часть этой книги начинает наше исследование совершенно иного способа думать о людях и управлять ими. И этот способ требует привыкания к совершенно не модульному характеру человеческого ресурса.
1. А в это время где-то гибнет проект
С тех пор как компьютеры стали доступны широким массам пользователей, разработчики создали, должно быть, десятки тысяч бухгалтерских программ. Вероятно, ещё десяток (или больше) таких проектов кто-то ведёт прямо сейчас, когда вы читаете эти строки. И как раз в это время один из них терпит крушение.
Представьте себе! Проект, не требующий никаких технических новшеств, разваливается на глазах. Бухгалтерский учёт – это колесо, которое изобретали заново столь часто, что многие разработчики-ветераны способны участвовать в таком проекте чуть ли не с закрытыми глазами. И все же подобные предприятия время от времени оканчиваются неудачей.
Предположим, после одной из таких катастроф вас попросили сделать вскрытие. (Мечтать не вредно: существует нерушимый отраслевой стандарт, запрещающий изучать провалы.) Предположим, что вам выпал шанс выяснить причины неудачи, прежде чем участники проекта успели разбежаться кто куда. Среди причин, потопивших проект, не будет ни слова о технологии. Можно с уверенностью сказать, что в наши дни системы бухгалтерского учёта технически возможны. Должно быть иное объяснение.
Начиная с 1977 года мы ежегодно проводили исследования проектов разработки и анализ их результатов. Мы оценивали размеры, стоимость, недостатки, факторы ускорения, а также соответствие развития проекта предполагаемым срокам. К настоящему моменту мы собрали более пятисот историй различных проектов, и в каждой из них мы видим реальный труд разработчиков[1].
Около пятнадцати процентов всех проектов закончились ничем – были отменены, прерваны, отложены или их результатом стали никому не нужные продукты. В случае крупных проектов картина ещё хуже. Крах постиг двадцать пять процентов проектов, длительность которых составляла от двадцати пяти человеко-лет[2]. В ранних исследованиях мы отбрасывали провалы и изучали данные прочих проектов. Однако начиная с 1979 года мы обязательно связывались с участниками неудавшихся проектов и узнавали, что пошло не так. В подавляющем большинстве случаев не было ни одной объясняющей неудачу причины из области технологии.
Чаще всего участники наших опросов в качестве причины краха называли «политику». Следует учесть, что люди трактуют это понятие достаточно широко. В «политику» входят такие несвязанные или слабо связанные между собой вещи, как проблемы коммуникации, проблемы с персоналом, разочарование в начальнике или заказчике, недостаточная мотивация и высокая текучесть кадров. Человек часто употребляет слово политика для описания любого аспекта работы, имеющего отношение к людям, но в языке есть гораздо более точный термин для таких аспектов: они составляют социологию проекта. Трудности действительно политического толка составляют лишь крохотное, незначительное подмножество всех трудностей.
Если считать проблему политической по природе, то в отношении к ней неизбежно появляется фатализм. Вы знаете, что способны справиться с техническими сложностями, но, если честно, кто из нас чувствует себя уверенно в области политики? Если же понять, что природа проблемы социологическая, а не политическая, то решить эту проблему будет намного проще. Социология проекта и команды может выходить за рамки вашей компетенции, но не способностей.
Как ни называй проблемы, связанные с людьми, именно они, вероятнее всего, станут причиной неприятностей в вашем следующем проекте, а вовсе не вопросы проектирования, реализации и методологии. По сути, именно эта мысль и проходит красной нитью через всю книгу:
1
Исследования проектов Демарко/Листера описаны в работах DeMarco, 1977 {18}; DeMarco, 1978 {19}; DeMarco, 1982 {20}; DeMarco и Lister, 1985 {22}.
2
Количество провальных проектов, требовавших от двадцати пяти человеко-лет работы, взято из работы Jones, 1981 {33}.