I. Управление человеческим ресурсом

Том Демарко, Тимоти Листер

Человеческий фактор: успешные проекты и команды

Tom DeMarco, "Peopleware: Productive Projects and Teams"

Аннотация

Книга Тома Демарко и Тимоти Листера «Человеческий фактор: успешные проекты и команды» — перевод 2-го издания всемирно известного бестселлера об управлении проектами разработки ПО. Первое издание содержало революционные по тем временам (1987 г.) идеи, которые выдержали проверку временем. Авторы скорректировали свои выводы и добавили несколько новых глав. Ценность этой книги в том, что в ней описываются принципы, за каждым из которых стоит реальная история. Все главы содержат наблюдения и новаторские подходы, которые заставят читателей и руководителей увидеть важные вопросы в новом, более разумном ракурсе. С юмором и мудростью, обретёнными за годы руководства и консультирования, Демарко и Листер демонстрируют, что сложнейшие проблемы разработки ПО имеют человеческую, а не техническую природу. Они не дают простых ответов, но дают правильные, подкреплённые научными исследованиями. Издание предназначено в первую очередь руководителям проектов, но будет полезно и рядовым программистам.

«Не обращайте внимания на человека за портьерой», — говорит Великий Оз.
Волшебник Страны Оз

Всем друзьям и коллегам,
которые научили нас не обращать внимания
на человека за портьерой.

· Отзывы на первое издание

· Благодарности

· Предисловие ко второму изданию

· Предисловие к первому изданию

I. УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМ РЕСУРСОМ

· 1. А в это время где-то гибнет проект

2. Сделал чизбургер — продай его

3. Вена ждёт тебя

4. Качество? Если успеем

5. Ещё раз о законе Паркинсона

6. Лаетрил

· II. ОФИСНАЯ СРЕДА

7. Мебельная полиция

8. «С девяти до пяти здесь совершенно невозможно работать»

9. Экономия на пространстве

· ИНТЕРМЕДИЯ

10. Работа ума и работа тела

11. Телефон

12. Верните дверь на место

13. Танцы с зонтиком

· III. ПОДХОДЯЩИЕ ЛЮДИ

14. Фактор Хорнблауэра

15. Как нанять жонглёра

16. Счастлив работать здесь

17. Самоизлечение системы

· IV. СОЗДАНИЕ ПРОДУКТИВНЫХ КОМАНД

18. Целое больше суммы его частей

19. Чёрная Команда

20. Травля команд

21. Ужин со спагетти

22. Открытое кимоно

23. Химия формирования команд

V. УДОВОЛЬСТВИЕ ОТ РАБОТЫ? ЗДЕСЬ?

24. Хаос и порядок

25. Свободные электроны

26. Хольгер Датчанин

· VI. НАСЛЕДИЕ PEOPLEWARE

27. Снова о травле команд

28. Конкуренция

29. Программы модернизации процессов

31. Человеческий капитал

32. Обучение организаций

33. Самый страшный грех в руководстве — это…

· Библиография

Отзывы на первое издание

«Демарко и Листер — одновременно и великолепные рассказчики, и проницательные наблюдатели в области руководства проектами.»

Джон Тейлор (John H. Taylor), E.I. du Pont de Nemours & Co.

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

Журнал PC World

«Авторы подкрепляют свои утверждения эмпирическими данными, полученными в ходе исследований, участие в которых приняли более 900 программистов и аналитиков. Все главы содержат наблюдения и новаторские подходы, которые заставят читателей и руководителей увидеть важные вопросы в новом более разумном ракурсе. Изложенные идеи важны, а книга заслуживает места на книжной полке любого руководителя разработкой ПО и любого консультанта по управлению.»

Т. Кейперс Джоунс (Т. Capers Jones)

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

Алан Кемпбелл (Alan Campbell),

Computing, Лондон

«…представляет в новом свете поведение людей в проектах по разработке.»

Тому Мацубара (Tomoo Matsubara),

Hitachi Software Engineering Co., Ltd.

«…их наблюдения постигают суть вещей. И в результате получается мудрость.»

Уэйр Майерс (Ware Myers),

IEEE Computer Society

Благодарности

К первому изданию

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

Точно так же создание книги, даже столь небольшой, как эта, требует усилий множества людей. У нас, конечно, не было стилистов, осветителей и их ассистентов, однако нам оказали огромную помощь друзья и коллеги, сыгравшие роли насмешников, авторов изящных оборотов, упрямых читателей рукописи, разоблачителей идей, рассказчиков смешных историй, корректировщиков тона повествования, уничтожителей обособленных причастных оборотов, обнаружителей глупостей, а также истребителей слишком многочисленных для одной войны боевых историй. Отдельно следует упомянуть нашего редактора Дженис Уормингтон (Janice Wormington), которая направляла наши усилия и щедро делилась своей энергией, своими знаниями и своим (обычно) хорошим юмором.

Марк Уоллес (Mark Wallace) из Information Engineering и Линда Прауз (Linda Prowse) из Hewlett-Packard великодушно и терпеливо, причём много раз, читали ранние варианты рукописи, предлагая многочисленные улучшения. Каждый из перечисленных далее является (сознательно или неявно) автором по меньшей мере одной идеи: Колин Кордер (Colin Corder), Арт Дэвидсон (Art Davidson), Венди Икин (Wendy Eakin), Джас-тин Коднер (Justin Kodner), Стив Мак-Менамин (Steve McMenamin), Лу Мацукелли (Lou Mazzucchelli), Нэнси Мибон (Nancy Meabon), Кен Орр (Ken Orr), Мейлир Пейдж-Джоунс (Meilir Page-Jones), Джон Пал мер (John Palmer), Джеймс и Сюзанна Робертсон (James, Suzanne Robertson), Джон Тейлор (John Taylor), Дэйв Томела (Dave Tommela). Мы находимся в особом долгу перед профессиональными разработчиками, принимавшими участие в наших исследованиях производительности и в «военных манёврах» в период с 1977 по 1987 годы. Спасибо всем.

Изложенная на страницах книги философия является отчасти продуктом деятельности заботливых и доброжелательных руководителей, с которыми нам приходилось работать. Упомянем Джонни Йоханессена (Johnny Johanessen) и Эла Стокерта (Al Stockert) из Bell Telephone Laboratories, Свен-Олофа Рефтмарка (Sven-Olof Reftmark) и Гарри Нордстрома (Harry Nordstrom) из шведского отделения Philips, Жерара Бовена (Gerard Bau-vin) из La SLIGOS, Рона Хестера (Ron Hester), который теперь работает в IMI Systems, Билла Плогера (Bill Plauger) из Whitesmiths, Ltd., Нэнси Римкус (Nancy Rimkus) из American Express, а также Джерри Винера (Jerry Wiener), где бы он ни был.

Ко второму изданию

Благодарности за издание 1999 года мы выражаем сотрудникам издательства Dorset House — Дэвиду Мак-Глинтоку (David McGlintock), Майклу Лумельски (Michael Lumelsky), Мэтту Мак-Дональду (Matt McDonald), а также Венди Икин (Wendy Eakin) — за редактуру и мудрые советы относительно новых глав. За особую проницательность и более общие советы спасибо Петеру Хрушке (Peter Hruschka), Стиву Мак-Менамину (Steve McMenamin), Марку Вейзу (Mark Weisz), Брюсу Тейлору (Bruce Taylor), известному как Walter «Bunny» Formaggio, Джеймсу Баху (James Bach), Ричарду Коэну (Rich Cohen), Тому Мацубара (Tomoo Matsubara), Цуенео Ямаура (Tsueneo Yamaura), а также Вероне Чард (Verona Chard).

Предисловие ко второму изданию

Мы пишем эти слова по горячим следам десятой годовщины первого издания «Peopleware».

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

Кроме того, мы обнаружили, что можем ещё очень многое сказать по теме. Наш собственный опыт в вопросах управления человеческим ресурсом продолжал расти в процессе проектного консультирования и работы с руководителями наших клиентов. Медленно, но верно исполин Хольгер Датчанин приходил в движение. (Чтобы понять, о чем речь, прочтите главу 26.) Когда он призывает вас, игнорировать этот зов можно только на свой страх и риск. Вот так появилось второе издание.

Перечитывая «Peopleware» постаревшими глазами, мы обнаружили нечто такое, что не было очевидным в момент выхода первого издания: эта книга не столько собрание очерков (так мы обозначили её содержимое в предисловии к первому изданию), сколько книга историй. За каждым из описанных принципов стоит своя история. Существует и другая история — о том, как эти принципы повлияли на наши собственные карьеры.

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

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

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

Август 1998

Том Демарко

Камден, Мэн

Тим Листер

Нью-Йорк

Предисловие к первому изданию

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

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

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

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

Данный труд является для нас очень личным, поэтому время от времени повествование идёт от первого лица, и инициалы позволят вам понять, кому из авторов принадлежат эти слова.

Сентябрь 1987

Том Демарко

Камден, Мэн

Тим Листер

Нью-Йорк

I. УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМ РЕСУРСОМ

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

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

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

1. А в это время где-то гибнет проект

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

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

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

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

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

Суть вопроса

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

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

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

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

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

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

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

Миражи высоких технологий

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

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

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

2. Сделал чизбургер — продай его

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

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

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

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

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

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

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

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

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

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

Допустимость ошибок

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

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

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

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