«Deadline. Роман об управлении проектами» — ключевые идеи из культовой книги о проектном менеджменте

Все принципы хорошего менеджмента описаны здесь в интересной и ненавязчивой форме бизнес-романа. Автор — Том Демарко — написал уже 13 книг, но Deadline считает своей самой сильной книгой. Он уверен — ее чтение добавит вам целых два года великолепного управленческого опыта, а захватывающий сюжет и наглядные примеры будут полезнее любого учебника.

Неслучайно эта книга стала настольной для сотен тысяч менеджеров на всем земном шаре. Она входит в список обязательного чтения по курсу «Управление проектами» во многих бизнес-школах по всему миру. Председатель совета
директоров Сбербанка отметил ее как одну из лучших бизнес-книг и добавил ее в библиотеку Сбербанка.

Если вы хотите прочесть только одну книгу по управлению проектами — прочтите эту

Почему мы решили издать эту книгу

Это просто находка для менеджера, который устал от чтения навязчивых руководств и историй успеха, а дзен-притчи о менеджменте не близки ему по духу.

Для кого эта книга

Для всех, кто управляет проектами (особенно в области ИТ).

И для тех, кто участвует в проектах.

От автора

Глаза мистера Томпкинса загорелись:

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

— В одну команду набрать только опытных специалистов, в другую — опытных и новичков, — продолжила Лакса.

Но мистер Томпкинс уже и сам проникся идеей и не собирался останавливаться.

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

— Все в ваших руках, Вебстер. Можете экспериментировать над всей Моровией, — Лакса кивнула в сторону Силиконовой поляны. — Вот она, первая в мире Лаборатория по управлению проектами.

Развернуть описание Свернуть описание

Том ДеМарко

Deadline. Роман об управлении проектами

Предисловие

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

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

С рассказами Гамоу я познакомился еще в подростковом возрасте. Как и мистер Томпкинс, я интересовался современной наукой, к тому времени уже прочел немало книг о квантовой механике и теории относительности. Но только после того, как мне в руки попали истории о незадачливом банковском клерке, начал наконец-то понимать, о чем вообще идет речь.

Меня всегда восхищало, как Гамоу сумел в столь интересной и ненавязчивой форме описать сложные научные постулаты. Мне показалось, что в такой же форме можно описать и некоторые принципы управления проектами. И я решил рассказать вам, уважаемый читатель, историю об опытном руководителе, который попал в некую воображаемую страну, где в различные правила управления вносились изменения «сверху». Так родилась (приношу свои глубочайшие извинения Джорджу Гамоу) идея этой книги - истории о менеджере по фамилии Томпкинс, который оказался в бывшей социалистической республике Моровии2 и был назначен руководителем проектов по созданию программного обеспечения.

Том Де Марко,

Камден, штат Мэн,

май 1997 года

Посвящается Салли (а кому же еще!)

Широчайшие возможности

Мистер Томпкинс устроился в последнем ряду Больдридж-1, главной аудитории «Крупной телекоммуникационной корпорации» (отделение в г. Пенелопа, штат Нью-Джерси). За последние несколько недель он провел тут довольно много времени на лекциях для увольняемых. Мистеру Томпкинсу и еще нескольким тысячам таких же, как он, профессионалов и менеджеров среднего звена, попросту указали на дверь. Ну, разумеется, никто не выражался столь грубо и прямолинейно. Обычно использовались фразы вроде: «сокращение штатов», или «в результате уменьшения размеров компании», или «оптимизация размеров компании», или же - и этот вариант был самым замечательным из всех - «предоставляем свободу выбора другой работы». Для этой последней фразы сразу же изобрели аббревиатуру: СВДР. Томпкинс и был одним из таких СВДР.

Сегодня в Больдридж-1 должна была состояться очередная лекция на тему «Широчайшие возможности прямо перед нами». Как говорилось в программке, данный цикл лекций представлял собой «более ста часов крайне увлекательных тренингов, пьесок, музыкальных интерлюдий и прочих мероприятий для новоиспеченных СВДР» - и все за пять недель. Сотрудники отдела по работе с персоналом (которых никто не увольнял) были убеждены, что стать СВДР - величайшее счастье, только вот остальные почему-то этого не понимают. Конечно же, им самим очень хотелось стать СВДР. Честное слово. Но, увы, пока не везет. Нет-нет, сэр, пока еще им предстоит нести свое бремя: регулярно получать зарплату и продвигаться по службе. А сейчас они поднимутся на сцену и мужественно продолжат свой нелегкий труд.

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

На сиденье напротив он выложил сегодняшний набор подарков от фирмы: две толстые записные книжки и прочие мелочи были упакованы в красивую матерчатую сумку с логотипом компании и надписью: «Наша компания худеет, поэтому все остальные могут набирать вес». Поверх сумки легла бейсболка с вышивкой: «Я - СВДР и горжусь этим!» Томпкинс потянулся, нахлобучил бейсболку на глаза и уже через минуту мирно спал.

В это время хор сотрудников по работе с персоналом громко пел на сцене: «Широчайшие возможности - распахнем перед ними дверь! Распахнем!» По замыслу исполнителей, слушатели должны были хлопать в ладоши и подпевать: «Распахнем!» Слева от сцены стоял человек с громкоговорителем и подбадривал публику воплями: «Громче, громче!» Несколько человек вяло хлопали, но подпевать никто не хотел. Однако весь этот шум начал пробиваться даже в «мертвую зону», где спал мистер Томпкинс, и, наконец, разбудил его.

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

Я ничего не пропустил? - обратился он к незнакомке. Та продолжала наблюдать за сценой.

Всего лишь самое важное.

Может быть, вы мне вкратце обрисуете?

Они предлагают вам убраться, но при этом просят не менять телефонную компанию, через которую вы звоните по межгороду.

Еще что-нибудь?

Ммм… вы проспали почти что целый час. Дайте-ка я вспомню. Нет, пожалуй, больше не было ничего интересного. Несколько забавных песенок.

Понятно. Обычное торжественное выступление нашего отдела по работе с персоналом.

Ооо! Мистер Томпкинс проснулся… как бы поточнее сказать?… в состоянии легкой озлобленности.

Вы знаете больше, чем я, - мистер Томпкинс протянул ей руку. - Очень приятно, Томпкинс.

Хулигэн, - представилась женщина, отвечая на рукопожатие. Теперь, когда она повернулась к нему, он мог рассмотреть ее глаза: не просто темные, а практически черные. И смотреть в них ему очень понравилось. Мистер Томпкинс обнаружил, что краснеет.

Ээээ… Вебстер Томпкинс. Можно просто Вебстер.

Какое забавное имя.

Старинное балканское имя. Моровийское.

А Хулигэн?

Хм, девичья неосмотрительность моей мамочки. Он был ирландцем с торгового судна. Симпатичный палубный матрос. Мама всегда была неравнодушна к морякам. - Лакса усмехнулась, и Томпкинс вдруг почувствовал, что его сердце забилось сильнее.

А, - наконец нашелся он.

Мне кажется, я вас уже где-то встречал, - это прозвучало как вопрос.

Встречали, - подтвердила она.

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

Вам тоже предоставили свободу выбора?

Нет? Остаетесь в этой компании?

Опять не угадали.

Ничего не понимаю.

Я здесь не работаю. Я шпионка.

Он засмеялся.

Скажете тоже!

Промышленный шпионаж. Слыхали о таком?

Конечно.

Вы мне не верите?

Ну… вы просто совершенно не похожи на шпионку.

Она улыбнулась, и сердце мистера Томпкинса опять забилось. Конечно же, Лакса была похожа на шпионку. Более того, она словно была рождена для того, чтобы стать шпионкой.

Ээээ… я хотел сказать, не совсем похожи.

Лакса покачала головой.

Я могу доказать это.

Потом отцепила нагрудную карточку с именем и фамилией и протянула ему.

Томпкинс посмотрел - на карточке стояло имя «Лакса Хулигэн», а под ним фотография. «Погодите-ка…» - он пригляделся повнимательнее. Все вроде бы выглядело как надо, однако ламинирование… Нет, никакой это не ламинат. Карточка была просто закатана в пластик. Он оттянул прозрачную пленку, и фотография выпала наружу. Под ней находилась другая фотография, на которой был изображен какой-то седоватый мужчина. А имя оказалось наклеенным на кусок липкой бумаги поверх карточки! Отодрав и его, он прочел: «Сторгель Вальтер».

Знаете, уж больно непрофессионально выглядит такая подделка.

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

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

Книга адресована менеджерам по управлению проектами в области информационных технологий.

Предисловие

В одном из этих рассказов, например, мистер Т. проснулся во Вселенной, где скорость света составляла всего лишь пятнадцать миль

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

Том Де Марко,

Глава 1

Широчайшие возможности

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

Фантастика?

Нет. Вообще-то - учебник по управлению проектами. В форме фантастического романа.

Как вам такое? Встречайте обзор книги Тома ДеМарко «Deadline. Роман об управлении проектами»!

Том ДеМарко

Том ДеМарко - глава международной консалтинговой компании Atlantic Systems Guild, специализирующейся на построении сложных бизнес-систем, управлении рисками, реинжиниринге, построении здоровой корпоративной культуры. Также она оказывает помощь в судебных разбирательствах, связанных с программным обеспечением. Член Ассоциации по вычислительной технике (Association for Computing Machinery) и Института инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers).

Сюжет

Похищенному Вебстеру Томпкинсу предстоит поднять экономику небольшой коммунистический страны Моровии.

В его распоряжении бесконечные человеческие и денежные ресурсы. Против Вебстера выступают бюрократия, тупое начальство и сжатые сроки.

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

Вот только несколько тем, которые затрагиваются в книге:

Подбор персонала.
Мотивация сотрудников.
Разрешение конфликтов внутри компании.
Продолжительность рабочего дня, сверхурочная работа.
Сокращения и переводы сотрудников.
Начальник-самодур.

Как же надоели учебники!

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

Полезно? Угу.

Скучно? О, да!

Толстую книгу Deadline я проглотил за три дня. Приключения Вебстера затягивают, хотя тема «учебника» мне была не очень-то интересна.

Художественный формат делает любой учебник интереснее и полезнее. Почему он так редко применяется в бизнес-литературе?

Резюме

Интересный роман об управлении проектами. Яркие герои, юмор, извилистый сюжет - всё на месте.

Пишите в комментариях!

А какие художественные книги о бизнесе и саморазвитии читали вы?

Не всегда бизнес литература оставляет такое приятное послевкусие, как книга Тома ДеМарко "Deadline. Роман об управлении проектами". В ней автор в очень интересной манере рассказывает об управлении IT-проектами - основные принципы менеджмента излагаются в художественной форме от имени главного героя, толкового руководителя мистера Томпкинса. Таким образом книга читается довольно легко, а ситуации, в которые попадают герои книги и то, как они из них выходили, успешно можно применять на практике.

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

"И все же хотелось бы представить, что где-то на земле есть место, где цель проекта - качество, а не сроки.
Но, наверное, такого не бывает." Мистер Томпкинс

1. Людям нужно давать ту работу, для которой они подходят лучше всего

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

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

2. Для успешной работы людям необходимы перемены

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

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

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

3. Угрозы подчиненным не повышают их производительность

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

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

4. Для успеха проекта в команде должны быть хорошие отношения

Удивительно было узнать мнение автора о том, что менеджер никак не может непосредственно повлиять на формирование хороших отношений внутри своей команды. Менеджер может создать нужную обстановку для зарождения здоровых отношений в команде, заложить фундамент и не препятствовать развитию этих отношений. Автор считает, что для успеха проекта одни из ключевых факторов - это слаженная команда и эффективные коммуникации со всеми остальными сотрудниками. В прочем мы, в E-PAGES, уделяем как раз этим пунктам особое внимание!

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

Основная задача менеджера - создать фундамент для построения крепкой слаженной команды с теплыми и дружественными отношениями внутри.

5. Повышение производительности команды требует больших усилий

"- Но ведь должен же быть какой-то шаг… какое-то несложное мероприятие, которое повысило бы производительность моих программистов. Ну, к примеру…
- Нет-нет, в нашем деле не может быть никаких несложных мероприятий, нельзя вот так взять и быстренько поднять производительность работы."

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

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

6. Нужно сокращать потери

"Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно."

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

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

7. Увеличение количества людей в команде не означает, что работа будет закончена раньше срока

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

Один из создателей методологии Scrum, Джефф Сазерленд, не рекомендует создавать команды из более чем семи человек. Ведь количество каналов коммуникации у команды уже из 10-ти человек равна 45! Это огромная нагрузка на менеджера, с которой качественно справиться одному человеку очень сложно.

8. Нужно собирать статистику о результатах своей работы

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

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

9. Давление на своих подчиненных увеличивает их производительность всего на 6%

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

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

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

10. Большие команды на старте проекта - вредны

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

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