Текст книги "Человеческий фактор: успешные проекты и команды"
Автор книги: Том ДеМарко
Соавторы: Тимоти Листер
сообщить о нарушении
Текущая страница: 1 (всего у книги 16 страниц) [доступный отрывок для чтения: 6 страниц]
Человеческий фактор: успешные проекты и команды
«Не обращайте внимания на человека за портьерой», – говорит Великий Оз.
Волшебник Страны Оз
Всем друзьям и коллегам, которые научили нас не обращать внимания на человека за портьерой.
Отзывы на первое издание
«Демарко и Листер – одновременно и великолепные рассказчики, и проницательные наблюдатели в области руководства проектами.»
Джон Тейлор (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]1
Исследования проектов Демарко/Листера описаны в работах DeMarco, 1977 (18); DeMarco, 1978 (19); DeMarco, 1982 (20); DeMarco и Lister, 1985 (22).
[Закрыть].
Около пятнадцати процентов всех проектов закончились ничем – были отменены, прерваны, отложены или их результатом стали никому не нужные продукты. В случае крупных проектов картина ещё хуже. Крах постиг двадцать пять процентов проектов, длительность которых составляла от двадцати пяти человеко-лет[2]2
Количество провальных проектов, требовавших от двадцати пяти человеко-лет работы, взято из работы Jones, 1981 (33).
[Закрыть]. В ранних исследованиях мы отбрасывали провалы и изучали данные прочих проектов. Однако начиная с 1979 года мы обязательно связывались с участниками неудавшихся проектов и узнавали, что пошло не так. В подавляющем большинстве случаев не было ни одной объясняющей неудачу причины из области технологии.
Суть вопроса
Чаще всего участники наших опросов в качестве причины краха называли «политику». Следует учесть, что люди трактуют это понятие достаточно широко. В «политику» входят такие несвязанные или слабо связанные между собой вещи, как проблемы коммуникации, проблемы с персоналом, разочарование в начальнике или заказчике, недостаточная мотивация и высокая текучесть кадров. Человек часто употребляет слово политика для описания любого аспекта работы, имеющего отношение к людям, но в языке есть гораздо более точный термин для таких аспектов: они составляют социологию проекта. Трудности действительно политического толка составляют лишь крохотное, незначительное подмножество всех трудностей.
Если считать проблему политической по природе, то в отношении к ней неизбежно появляется фатализм. Вы знаете, что способны справиться с техническими сложностями, но, если честно, кто из нас чувствует себя уверенно в области политики? Если же понять, что природа проблемы социологическая, а не политическая, то решить эту проблему будет намного проще. Социология проекта и команды может выходить за рамки вашей компетенции, но не способностей.
Как ни называй проблемы, связанные с людьми, именно они, вероятнее всего, станут причиной неприятностей в вашем следующем проекте, а вовсе не вопросы проектирования, реализации и методологии. По сути, именно эта мысль и проходит красной нитью через всю книгу:
Серьёзные проблемы в нашей работе имеют не столько технологическую сколько социологическую природу.
Многие руководители готовы согласиться с тем, что сталкиваются больше с человеческим фактором, нежели с техническими сложностями.
Однако они редко учитывают это на практике. Они руководят так, будто их главной заботой является именно технология. Они проводят столько времени в размышлениях о самых запутанных и интересных головоломках, которые предстоит решать подчинённым, будто сами собираются делать эту работу, а не руководить коллективом. Они находятся в вечном поиске технологического прибамбаса, который должен автоматизировать часть работы (более подробно об этом эффекте рассказано в главе 6 «Лаетрил»), тогда как направление их деятельности, связанное с человеческим ресурсом, зачастую получает низший приоритет.
Причиной такому феномену служит отчасти процесс воспитания среднего руководителя. Его учили тому, как выполнять работу, а не как руководить работой. Редко когда новый руководитель может похвастаться чем-то, что указывало бы на его способность или склонность к руководству. У них мало опыта руководства и отсутствует осмысленная практика. Но каким же образом новым руководителям удаётся убедить себя, что они могут спокойно тратить большую часть своего времени на размышления о технологии и совсем чуть-чуть (или нисколько) на размышления о человеческой стороне проблемы?
Миражи высоких технологий
Ответ, возможно, кроется в явлении, которое мы окрестили миражами высоких технологий. Это распространённая убеждённость людей, имеющих дело с любым аспектом новой технологии (а кто из нас не имеет?), что они работают в сфере действительно высоких технологий. Они потворствуют развитию этой иллюзии, объясняя на какой-нибудь вечеринке, что работают «в области компьютеров» или же «в области телекоммуникаций» или занимаются «электронным переводом денежных средств», намекая тем самым, что принадлежат к миру высоких технологий. Между нами говоря, обычно это не так. Исследователи, совершающие фундаментальные прорывы в перечисленных областях, действительно из мира высоких технологий. А мы лишь используем результаты их труда. Компьютеры и прочие элементы новых технологий служат нам для организации собственных предприятий. Наши рабочие единицы – команды, проекты и взаимосвязанные рабочие группы, а потому наша область деятельности – преимущественно человеческое взаимодействие. Наш успех напрямую зависит от качественного человеческого взаимодействия всех участников предприятия, а наши неудачи являются прямым следствием недостатка человеческого взаимодействия.
Главная причина, по которой мы склонны сосредоточивать усилия на технической, а не на человеческой стороне работы, – вовсе не приоритет первой перед второй. Технические вопросы проще решать. Гораздо проще организовать установку нового оптического привода, чем выяснить, почему Хорас в замешательстве или почему Сьюзен выражает недовольство компанией уже после нескольких месяцев работы. Человеческие взаимодействия сложны, их проявления не бывают очевидными и прозрачными, но они имеют большее значение, чем любой другой аспект работы.
И если вы концентрируетесь больше на технологии, чем на социологии, то уподобляетесь персонажу водевиля, который потерял ключи на тёмной улице, а ищет их на соседней, потому что, как объясняет он сам: «Там не так темно».
2. Сделал чизбургер – продай его
Разработка по природе своей отличается от производства. Однако руководителям предприятий по разработке и смежных с ними свойственен образ мышления, уходящий корнями исключительно в производственную среду.
Представьте на секунду, что вы – менеджер местного предприятия быстрого питания. Перечисленные ниже меры повышения эффективности производства, причём в любой комбинации, будут полностью оправданны:
• Исключить ошибки. Заставить машину (коллектив) работать гладко, насколько возможно.
• Занять жёсткую позицию в отношении сотрудников, склонных филонить на рабочем месте.
• Считать служащих взаимозаменяемыми винтиками.
• Оптимизировать стабильное состояние. (Даже не задумываясь о том, как производство вышло на полную мощность или каким образом его возможно остановить.)
• Стандартизировать процедуру. Делать все по инструкции.
• Исключить эксперименты – за это получают деньги те, кто сидит в штаб-квартире.
Подобные меры были бы разумными для бизнеса быстрого питания (или любой производственной среды), но вы работаете в другой сфере. Подход «сделал чизбургер – продай его» может стать фатальным для вашей разработки. Он способен лишь подавить дух сотрудников и отвлечь их внимание от проблем, подлежащих решению. Такой стиль управления противоречит сути работы.
Чтобы эффективно управлять людьми в области интеллектуального труда[3]3
В этой книге термины «работники интеллектуального труда», «участники разработки», «работники интеллектуальной сферы» употребляются для обозначения людей, которые зарабатывают на жизнь головой.
[Закрыть], необходимо принимать меры, противоположные перечисленным выше. Эти противоположные меры описаны в последующих разделах.
Допустимость ошибок
Для большинства работников, занятых в сфере интеллектуального труда, допускаемые время от времени ошибки – вполне естественная и безопасная составляющая деятельности. Но иногда между ошибкой в работе и грехом проводятся почти библейские ассоциации. Для того чтобы изменить подобное отношение, необходимо принять действительно серьёзные меры.
В разговоре с группой руководителей проектов по разработке программного обеспечения мы представили стратегию, которую считаем случаем итеративного проектирования. Идея заключается в том, что некоторые проектные решения изначально содержат недостатки, и такие решения следует выбрасывать, а не пытаться исправить. При проектировании следует ожидать появления подобных тупиков. Усилия, потраченные на тупиковую разработку, – небольшая цена за возможность начать с чистого листа. К нашему удивлению, многие руководители считают, что такой подход станет неразрешимой политической проблемой для их собственного начальства: «Как мы можем выбросить продукт, в производство которого наша компания вложила деньги?» Похоже, они считают, что лучше все же спасать дефектный вариант, пусть это в перспективе и обойдётся дороже.
Поощрение атмосферы, не позволяющей допускать ошибки, просто заставляет людей занимать оборонительные позиции. Они не пробуют подходы, способные закончиться отрицательным результатом. Вы же поощряете такое поведение, пытаясь упорядочить процесс и использовать жёсткие методологии, ради исключения ошибок запрещающие сотрудникам принимать ключевые стратегические решения. Любые меры, препятствующие совершению ошибок, могут лишь ненамного поднять уровень технологии, а вот социология команды может пострадать весьма серьёзно.
Противоположный подход – поощрение нечастых ошибок. Время от времени спрашивайте у своих подчинённых, с какими тупиковыми ситуациями они столкнулись, и постарайтесь объяснить, что ответ «такого не было» – не самый лучший. Когда люди совершают ошибки, их следует поздравлять, потому что они получают деньги в том числе и за ошибки.
Менеджмент, простецкое определение
Менеджмент – понятие достаточно сложное, чтобы ему можно было дать простое определение, однако этот нюанс ускользнул от одного менеджера высшего звена, с которым мы общались на профессиональном конвенте в Лондоне. Своё понимание предмета он суммировал так: «Менеджмент – это умение пинать сотрудников». Это равнозначно мнению, что руководители в основном думают, а подчинённые лишь выполняют их волю. Опять же, для производства чизбургеров это, быть может, вполне продуктивный подход, но и только; он не действует для предприятия, в котором люди работают головой, а не руками. В подобной сфере мозг каждого участника должен участвовать в процессе. Посредством пинков вы сможете в лучшем случае активизировать сотрудников, но не добиться от них творческого подхода, вдумчивости и изобретательности.
Даже если бы воздействие на пятую точку давало кратковременный прирост производительности, в перспективе оно могло бы оказаться не столь полезным: нет ничего более обескураживающего для любого работника, чем чувство, что его собственной мотивации не хватает и потому требуются «добавки» со стороны начальства.
Самое печальное в таком подходе к руководству – это то, что он практически никогда не оправдан. Большинство сотрудников любят свою работу, и чаще всего не требуются жёсткие меры, чтобы они продолжали работать. Напротив, может возникнуть необходимость сделать так, чтобы они работали меньше, но более осмысленно (эту идею мы развиваем в главе 3).
Человеческие запчасти
В производственной сфере людей удобно считать частями рабочего механизма. Когда часть механизма износилась, её заменяют на другую. Замена совместима с оригиналом, поэтому новую можно, грубо говоря, заказать по каталогу.
Многие руководители проектов по разработке придерживаются такого же подхода. Они идут на все, убеждая себя, что нет незаменимых людей. Из страха, что ключевой человек уйдёт, они заставляют себя считать, что ключевых людей попросту не существует. Разве не в этом, в конце концов, сущность менеджмента – делать так, чтобы работа не останавливалась в случае ухода отдельных людей? Эти руководители ведут себя так, словно существует волшебный магазин человеческих запчастей, куда можно позвонить с примерно такой просьбой: «Пришлите мне нового Джорджа Гарденайера, только пусть он будет не такой дерзкий».
Один мой клиент поднял вопрос о повышении зарплаты одному из превосходных сотрудников и, к своему удивлению, узнал, что этому человеку нужно нечто другое, не деньги. Сотрудник сообщил, что дома у него часто появляются хорошие идеи, но работа через медленный коммутируемый терминал слишком неудобна. Не может ли компания провести ему домой выделенную линию и купить высокопроизводительный терминал? Компания так и сделала. В последующие годы она даже создала и обставила для этого сотрудника маленький домашний офис. Но этот мой клиент – нетипичный случай. Интересно, что сделал бы менее восприимчивый руководитель? Слишком уж многие руководители остро реагируют на любые попытки сотрудников подчеркнуть собственную индивидуальность.
Т. Д.
Вот один пример такого менее восприимчивого руководителя, взятый из жизни. Этот начальник крайне остро реагировал на индивидуальность своих подчинённых. Один весьма талантливый сотрудник большую часть года проводил на площадках клиентов и, как следствие, жил на командировочные. Анализ расходов этого сотрудника показал, что расходы на питание сильно отличаются от расходов других «путешественников» по этой статье. На еду он тратил в полтора раза больше других. В негодующем открытом письме начальник заклеймил «гастрономического преступника». Между прочим, общие расходы этого сотрудника не выбивались из ряда: излишние расходы на еду он компенсировал экономией в других областях. Он не обходился компании дороже, он просто был не таким, как все.
Уникальность каждого человека – постоянный раздражитель для руководителя, слепо уверовавшего в стиль управления, взятый из производственной сферы. Руководитель, умеющий работать с людьми, напротив, осознает, что именно уникальность участников является залогом активности и эффективности внутрипроектных отношений.
Стабилизация проекта означает его смерть
Образ мышления, характерный для производства, находящегося в стабильном состоянии, особенно плохо сочетается с ведением проектов. Мы склонны забывать, что самоцель существования проекта состоит в том, чтобы выйти из бизнеса. Единственное стабильное состояние в жизни проекта – трупное окоченение. Управление проектом должно сосредоточиваться на динамике его развития, разумеется, за исключением случаев, когда вы управляете проектом уже прерванным или находящимся на грани отмены. Но почему-то ценность людей для нового проекта мы вычисляем, исходя из их стабильных показателей: сколько кода они могут написать или сколько могут задокументировать. И слишком мало внимания уделяем тому, какой именно качественный вклад каждый из них может внести в развитие предприятия.
Несколько лет назад я вёл курс проектирования в одной фирме, и один из менеджеров высшего звена буквально преследовал меня просьбой оценить некоторых слушателей (сотрудников его проекта). Особенно его интересовала одна женщина. Его сомнения выражались так: «Не совсем понимаю, какая польза от неё проекту – она не гениальный разработчик, не очень разбирается в тестировании, да и вообще в чём-либо ещё». Небольшое расследование выявило любопытный факт: за двенадцать лет работы в компании эта женщина участвовала исключительно в проектах, закончившихся гигантским успехом. Её вклад был неочевиден, но проект с её участием неизменно был удачным. Понаблюдав за ней на занятиях с неделю и переговорив с её коллегами, я пришёл к выводу, что эта женщина – великолепный катализатор. В её присутствии команда начинала работать легко. Она помогала людям общаться и ладить. Проекты с её участием не были скучными. Попытавшись донести эту мысль до руководителя, я потерпел неудачу. Он попросту не считал катализатор жизненно необходимым для проекта.
Т. Д.
Катализатор важен, потому что проект постоянно находится в движении. Человек, способный заставить проект шевелиться, стоит двух, просто выполняющих работу.
У нас есть время только выполнить работу, но не думать о ней
Если на вас лежит ответственность за выполнение задания, какую долю времени следует потратить непосредственно на выполнение? Не сто процентов. Необходимо предусмотреть время на мозговые штурмы, на изучение новых подходов, на поиск экономичных решений, на чтение, подготовку, да и просто безделье.
Вспоминая годы, когда мы сами руководили проектами, мы пришли к заключению, что подходили к этому вопросу неправильно. Слишком много времени тратили на попытки получить результат и недостаточно на ключевой вопрос: а нужны ли вообще эти результаты? Принцип стабилизированных чизбургеров даже рядом не валялся с идеей о размышлениях на работе. Единственная его цель – по максимуму свести все усилия к действию. Если надо как-то объяснить недостаток времени на размышления, то этим объяснением всегда становятся сжатые сроки. Можно подумать, существует работа, не подверженная давлению сроков.
Потребность в более взвешенном подходе возрастает по мере того, как растут ставки. Лишь когда требуются поистине титанические усилия, мы начинаем постигать другой режим, в котором больше времени уделяется размышлениям о работе и меньше собственно выполнению работы. Чем больше требуется героических усилий, тем важнее, чтобы люди в команде учились взаимодействовать эффективно и получать от этого удовольствие. Именно проект, сдача которого запланирована на нереальную фиксированную дату, более всего нуждается в частых мозговых штурмах и даже в неформальной проектной тусовке или любом подобном мероприятии – во всем, что помогает объединить отдельных участников в эффективное целое.
