What do you think?
Rate this book
The Deadline
Book by Tom DeMarco
310 pages, Paperback
First published July 31, 1997
209 people are currently reading
2993 people want to read
About the author
Tom DeMarco
33 books224 followersTom DeMarco is the author of fifteen books, including five novels, a collection of short stories and the rest business books. His most recent work is a seemingly jinxed love story, The One-Way Time Traveler.
Before that he wrote Dark Harbor House, and before that Slack and Peopleware and The Deadline.
Before that he wrote Dark Harbor House, and before that Slack and Peopleware and The Deadline.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 194 reviews
March 1, 2012
Книга обязательна к прочтению для начинающих и действующих менеджеров, предпринимателей, руководителей, прочее.
Автор в увлекательной форме выложил все типичные ошибки управления проектами, указал типичные «грабли», а также показал методы и способы их устранения. Данными методами и способами книга не ограничивается так как здесь приведены и принципы на которых они работают. В общем очень хорошая книга, которая поможет не только реализовать разнообразные проекты более эффективнее, но и намного раньше сроков их сдачи.
Автор в увлекательной форме выложил все типичные ошибки управления проектами, указал типичные «грабли», а также показал методы и способы их устранения. Данными методами и способами книга не ограничивается так как здесь приведены и принципы на которых они работают. В общем очень хорошая книга, которая поможет не только реализовать разнообразные проекты более эффективнее, но и намного раньше сроков их сдачи.
June 8, 2018
Отличная книга. Написана в художественной, а не деловой форме. Легкое изложение, но при этом в конце каждой главы – важные тезисы.
Я и сам – разработчик с многолетним опытом, но, несмотря на это, всё равно нашёл для себя несколько очень важных моментов, касающихся этапа проектирования, «ценности» свехурочной работы, отношений в коллективе.
Рекомендую прочесть книгу не только project manager'ам, но и всем, кто занимается разработкой программного обеспечения.
Я и сам – разработчик с многолетним опытом, но, несмотря на это, всё равно нашёл для себя несколько очень важных моментов, касающихся этапа проектирования, «ценности» свехурочной работы, отношений в коллективе.
Рекомендую прочесть книгу не только project manager'ам, но и всем, кто занимается разработкой программного обеспечения.
December 25, 2017
Brilliant, once again, a brilliant book on management. The author combined an interesting artistic novel with very useful educational material on personnel management. I'll just say it, it's an awesome book, and it's a great pity that it did not hit me at least 6-7 years ago.
--------------
Гениальная, еще раз повторюсь, гениальная книга об управлении. Автор соединил интересный художественный роман с очень полезным учебным материалом по управлению персоналом. Скажу просто, обалденная книга, и очень жаль что она мне не попала еще хотяб 6-7 лет назад.
I read books on Scribd or Google Books by
Readlax Chrome Extension
--------------
Гениальная, еще раз повторюсь, гениальная книга об управлении. Автор соединил интересный художественный роман с очень полезным учебным материалом по управлению персоналом. Скажу просто, обалденная книга, и очень жаль что она мне не попала еще хотяб 6-7 лет назад.
I read books on Scribd or Google Books by
Readlax Chrome Extension
November 5, 2011
Четыре основных правила менеджмента
1. Найти нужных людей
2. Дать им ту работу, для которой они больше всего подходят
3. Не забывать о мотивации
4. Помогать им сплотиться в одну команду и работать так дальше
Анонимная система оповещений менеджера о задержках в проекте.
Постоянно работать со списком рисков и триггеров-симптомов.
Сокращать ненужные усилия.
День в начале проекта такой же важный как и день в конце.
Важна работа над «предчувствиями».
Сверхурочная работа не помогает, поскольку люди знают что будут сидеть допоздна и могут дольше делать собрания и никуда не торопиться. Проекты со сверхурочной работой заканчиваются не раньше проектов с адекватным рабочим днём.
Поможет что-то более сложное:
принимать на работу новых сотрудников,
придумывать способы мотивации персонала,
развивать командные отношения и поддерживать боевой дух, <12>привлекать к проекту грамотных людей, <13>устранять из процесса разработки все малоэффективные действия, <14>реже устраивать совещания, <15>не давать людям работать сверхурочно, <16>сократить работу над документацией.
Тяжело договариваться. Гораздо легче выступать посредником.<17>Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»
Нам кажется, что самое страшное — не знать чего то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.
Пригласить всех. Начинать выбирать самых важных (кто принесёт наибольшую пользу вне собрания) и отпускать их. Уходя, они оставляют свои просьбы и вопросы залу.
Из книги:
1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.<22> 5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.
Отрицательная мотивация
1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.<25> 3. Более того, если люди не справятся, вам придется выполнить свои обещания.
Части тела, необходимые для управления проектами<26> 1. Для руководства нужны сердце, нутро, душа и нюх.
2. Так что:<28> • руководить надо сердцем;<29> • чувствовать нутром;<30> • вкладывать в команду и проект душу;<31> • иметь нюх на всякую ерунду и бессмыслицу.
Повышение производительности
1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
2. Повышение производительности — результат долгосрочных усилий.
3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко»10.
Управление рисками
1. Чтобы управлять проектом, достаточно управлять его рисками.<38> 2. Создайте список рисков для каждого проекта.<39> 3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.<40> 4. Оцените вероятность возникновения и стоимость каждого риска.<41> 5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.<42> 6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.<43> 7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.
Играй в защите
Сбор метрических данных<51> 1. Определяйте размер каждого проекта.<52> 2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.<53> 3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).<54> 4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.<55> 5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.<56> 6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.
Что дает давление сверху
1. Люди не начнут быстрее соображать, если руководство будет давить на них.
2. Чем больше сверхурочной работы, тем ниже производительность.<61> 3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.<62> 4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.
Сердитый начальник
Туманные спецификации
1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.
Конфликт<70> 1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.<71> 2. Процесс создания и распространения программных систем — прямотаки рассадник всевозможных конфликтов.<72> 3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.<73> 4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
6. Тяжело договариваться. Гораздо легче выступать посредником.<76> 7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.
Кто такой катализатор проекта<78> 1. Существуют людикатализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
2. Посредничество — еще одна сфера, в которой людикатализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»
Человеку свойственно ошибаться
1. Нам кажется, что самое страшное — не знать чегото. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.
О персонале<82> 1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какуюто работу).
2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.<84> 3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.<85> 4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!
1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
2. Каждому проекту нужна какаято церемония или ритуал.
3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.<89> 4. Защищайте людей от оскорблений и ругани Начальства.
5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чегото очень боятся.<91> 6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)
О патологической политике (еще раз) <92> 1. Эту патологию невозможно вылечить снизу.<93> 2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.<94> 3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.
Злоба и скупость
1. Злоба и скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.<97> 2. Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.<98> 3. Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина — страх и боязнь провала.
Основы здравого смысла<99> 1. У проекта должно быть два срока сдачи — запланированный и желаемый.
2. Эти сроки должны быть разными.
1. Найти нужных людей
2. Дать им ту работу, для которой они больше всего подходят
3. Не забывать о мотивации
4. Помогать им сплотиться в одну команду и работать так дальше
Анонимная система оповещений менеджера о задержках в проекте.
Постоянно работать со списком рисков и триггеров-симптомов.
Сокращать ненужные усилия.
День в начале проекта такой же важный как и день в конце.
Важна работа над «предчувствиями».
Сверхурочная работа не помогает, поскольку люди знают что будут сидеть допоздна и могут дольше делать собрания и никуда не торопиться. Проекты со сверхурочной работой заканчиваются не раньше проектов с адекватным рабочим днём.
Поможет что-то более сложное:
принимать на работу новых сотрудников,
придумывать способы мотивации персонала,
развивать командные отношения и поддерживать боевой дух, <12>привлекать к проекту грамотных людей, <13>устранять из процесса разработки все малоэффективные действия, <14>реже устраивать совещания, <15>не давать людям работать сверхурочно, <16>сократить работу над документацией.
Тяжело договариваться. Гораздо легче выступать посредником.<17>Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»
Нам кажется, что самое страшное — не знать чего то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.
Пригласить всех. Начинать выбирать самых важных (кто принесёт наибольшую пользу вне собрания) и отпускать их. Уходя, они оставляют свои просьбы и вопросы залу.
Из книги:
1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.<22> 5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.
Отрицательная мотивация
1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.<25> 3. Более того, если люди не справятся, вам придется выполнить свои обещания.
Части тела, необходимые для управления проектами<26> 1. Для руководства нужны сердце, нутро, душа и нюх.
2. Так что:<28> • руководить надо сердцем;<29> • чувствовать нутром;<30> • вкладывать в команду и проект душу;<31> • иметь нюх на всякую ерунду и бессмыслицу.
Повышение производительности
1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
2. Повышение производительности — результат долгосрочных усилий.
3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко»10.
Управление рисками
1. Чтобы управлять проектом, достаточно управлять его рисками.<38> 2. Создайте список рисков для каждого проекта.<39> 3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.<40> 4. Оцените вероятность возникновения и стоимость каждого риска.<41> 5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.<42> 6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.<43> 7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.
Играй в защите
Сбор метрических данных<51> 1. Определяйте размер каждого проекта.<52> 2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.<53> 3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).<54> 4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.<55> 5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.<56> 6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.
Что дает давление сверху
1. Люди не начнут быстрее соображать, если руководство будет давить на них.
2. Чем больше сверхурочной работы, тем ниже производительность.<61> 3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.<62> 4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.
Сердитый начальник
Туманные спецификации
1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.
Конфликт<70> 1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.<71> 2. Процесс создания и распространения программных систем — прямотаки рассадник всевозможных конфликтов.<72> 3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.<73> 4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
6. Тяжело договариваться. Гораздо легче выступать посредником.<76> 7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.
Кто такой катализатор проекта<78> 1. Существуют людикатализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
2. Посредничество — еще одна сфера, в которой людикатализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»
Человеку свойственно ошибаться
1. Нам кажется, что самое страшное — не знать чегото. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.
О персонале<82> 1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какуюто работу).
2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.<84> 3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.<85> 4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!
1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
2. Каждому проекту нужна какаято церемония или ритуал.
3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.<89> 4. Защищайте людей от оскорблений и ругани Начальства.
5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чегото очень боятся.<91> 6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)
О патологической политике (еще раз) <92> 1. Эту патологию невозможно вылечить снизу.<93> 2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.<94> 3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.
Злоба и скупость
1. Злоба и скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.<97> 2. Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.<98> 3. Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина — страх и боязнь провала.
Основы здравого смысла<99> 1. У проекта должно быть два срока сдачи — запланированный и желаемый.
2. Эти сроки должны быть разными.
October 17, 2017
Fiction format made it easier to read and even somewhat fun. I did not always agreed with explanations (%thing% is true because it's true), but nonetheless I think the book gave me a few insights and made me refresh my perspective, so that's good.
As a fiction it is bad: flat characters, deus ex machina is the only thing that moves anything in the narrative, but I guess that's the life of a manager, the end is boring and at the same time illogical.
As a fiction it is bad: flat characters, deus ex machina is the only thing that moves anything in the narrative, but I guess that's the life of a manager, the end is boring and at the same time illogical.
January 22, 2021
A roman about project management! I would never have expected how much fun this could be. If you work in a corporation you MUST read this. Seems that all problems that I had in corporations are a never ending cycle...
April 4, 2018
Буле корисна всім хто працює з людьми.
І не лише в ІТішних командах
І не лише в ІТішних командах
May 11, 2025
There are a lot of business novels. There are far fewer good novels about business. But there seems to be only one fantasy, espionage, business comedy about project management – “The Deadline”. A fictional country with an absurd business case to make it the largest software exporter, a kidnapped project manager, and some questionable management practices. One thing is known for sure: this novel is from the last century, which means “very old” in IT.
Is it bad though? No. It actually explains some good project management and business practices. Although most of those good things are now considered more common sense. At the same time, there are some questionable practices explained there (such as selecting team members based on intuition alone) that can lead to some undesirable outcomes. Therefore, I am sure that this book will not bring any value-add to experienced project managers. But I'm not sure if it will bring any value to those inexperienced.
Is it bad though? No. It actually explains some good project management and business practices. Although most of those good things are now considered more common sense. At the same time, there are some questionable practices explained there (such as selecting team members based on intuition alone) that can lead to some undesirable outcomes. Therefore, I am sure that this book will not bring any value-add to experienced project managers. But I'm not sure if it will bring any value to those inexperienced.
July 9, 2010
A pretty interesting read that brings across 101 ideas that Mr DeMarco has found in his many years of helping make projects operate better.
While the story won't win any prizes, the ideas covered are quite topical and well described. If you are looking for an occasionally amusing, easily digestible way to take in some key concepts of software program management, than this is the book for you.
Do note that there are a few derogatory comments directed towards CMM and lean development (in the 90s meaning of lean). For the most part, I think his comments are well made and quite apt. He's not really anti those those things but he does make a point that if they are used incorrectly they will do more harm than good (and that they often hide deeper, nastier problems)
While the story won't win any prizes, the ideas covered are quite topical and well described. If you are looking for an occasionally amusing, easily digestible way to take in some key concepts of software program management, than this is the book for you.
Do note that there are a few derogatory comments directed towards CMM and lean development (in the 90s meaning of lean). For the most part, I think his comments are well made and quite apt. He's not really anti those those things but he does make a point that if they are used incorrectly they will do more harm than good (and that they often hide deeper, nastier problems)
September 14, 2014
Another one must-read if you are working as a project/sales/marketing/pr/hr/brand manager in IT.
Helps to get better understanding of what these tech geeks are doing and what motivates them
Helps to get better understanding of what these tech geeks are doing and what motivates them
January 15, 2020
One of the best books on software development. As a PM I could easily feel myself in the shoes of the main character.
February 25, 2016
Вредная книга. Автор исходит из странной идеи, что "художественное" оформление нонфикшн книги избавляет его от необходимости обосновывать свои идеи.
В этой книге команда, провалившая проект может найти обоснования (внешние - на нас давили, заставляли овертаймить и, страшно подумать, ставили сроки) своей неудачи. Но вряд ли кто-то найдёт рецепт для успешного выполнения проекта.
Впрочем, одно достонство у книги есть. В конце глав главный персонаж выписывает менеджерскую common wisdom (это относится только к первой трети глав). Во эти фразы, мне кажется, полезно всегда держать перед глазами. Они самоочевидны, но это не мешает руководителям проектов всегда их забывать.
В этой книге команда, провалившая проект может найти обоснования (внешние - на нас давили, заставляли овертаймить и, страшно подумать, ставили сроки) своей неудачи. Но вряд ли кто-то найдёт рецепт для успешного выполнения проекта.
Впрочем, одно достонство у книги есть. В конце глав главный персонаж выписывает менеджерскую common wisdom (это относится только к первой трети глав). Во эти фразы, мне кажется, полезно всегда держать перед глазами. Они самоочевидны, но это не мешает руководителям проектов всегда их забывать.
Read
June 2, 2022Я думаю, что многим руководителям стоит прочесть данное произведение и задуматься о том, насколько их страхи руководят их действиями по отношению к их сотрудникам. В целом читается легко и дает пищу для размышлений, для меня как для начинающего проектного менеджера было довольно полезно.
June 22, 2017
Хорошая книга с интересным замыслом. Помогает систематизировать имеющиеся знания об ��правлении, предлагает иной взгляд на устоявшиеся вещи, не лишена юмора. Признаюсь, что я оказалась заложницей названия "Роман об управлении проектами" и ожидала большего. Хотя для справедливой оценки реализации авторского замысла необходимо ознакомиться с источником его вдохновения - рассказами 1930-х русского физика Георгия Гамова.
Interesting book with bright ideas helps to systematise the existing knowledge of management, offers a different view on the established issues, is not without humour. I was deceived by the title "Novel about project management", so I expected more. Although for a complete understanding of the author's intention it is necessary to get acquainted with the source of his inspiration - the stories of the 1930s written by the Russian physicist Georgy Gamov.
Interesting book with bright ideas helps to systematise the existing knowledge of management, offers a different view on the established issues, is not without humour. I was deceived by the title "Novel about project management", so I expected more. Although for a complete understanding of the author's intention it is necessary to get acquainted with the source of his inspiration - the stories of the 1930s written by the Russian physicist Georgy Gamov.
December 16, 2024
Попередньо додавав цю книгу в бажане після прочитання «Мети» Голдратта. І це дійсно ще один чудовий варіант ознайомлення з менеджментом через подачу матеріалів в вигляді художньої літератури. Це має сюжет, це розкриває основні тези книги через взаємодію персонажів і це вчить тебе чогось. Сам сюжет набагато більш примітивний, ніж к Голдрата, тому 4
«Well, you don't make it happen at all. You let it happen.
You create an atmosphere where it can happen. And then, if you're lucky, it does happen.»
«lead with the heart,
t r u s t your gut (trust your hunches),
build soul into the organization,
develop a nose for bullshit.»
«Ask new hires to undertake one project at exactly the level of competence they have already proved, to defer real stretch goals till the next time.»
«That's what we do as managers. Apply people where their skills and talents can really shine. That's what management is all about.»
«PEOPLE UNDER PRESSURE DON'T THINK FASTER”
«We need to acknowledge conflict and give it
some respect»
«Now every time you come face to face with a
conflict, I want you to school yourself to repeat the following little mantra: 'Negotiation is hard; mediation is easy»
«Well, you don't make it happen at all. You let it happen.
You create an atmosphere where it can happen. And then, if you're lucky, it does happen.»
«lead with the heart,
t r u s t your gut (trust your hunches),
build soul into the organization,
develop a nose for bullshit.»
«Ask new hires to undertake one project at exactly the level of competence they have already proved, to defer real stretch goals till the next time.»
«That's what we do as managers. Apply people where their skills and talents can really shine. That's what management is all about.»
«PEOPLE UNDER PRESSURE DON'T THINK FASTER”
«We need to acknowledge conflict and give it
some respect»
«Now every time you come face to face with a
conflict, I want you to school yourself to repeat the following little mantra: 'Negotiation is hard; mediation is easy»
June 2, 2019
Крута книга, корисна як для початківців так і для досвідчених менеджерів. Написана у вигляді пригодницької історії і читається легко, на одному подиху. У кожному розділі є короткий підсумок, що позволяє виділити головну суть і закріпити отримані знання. Обов’язкова до прочитання :)
February 8, 2025
Эта книга – путеводитель по классическим проблемам, с которыми сталкивается любой проектный менеджер. Из нее можно почерпнуть идеи решений этих проблем и даже получить своего рода валидацию чувств. Особенно благодарна за резюмирование уроков в конце каждой главы.
Не ожидала, что формат художки сделает чтение таким увлекательным – невозможно было оторваться
Не ожидала, что формат художки сделает чтение таким увлекательным – невозможно было оторваться
June 24, 2019
Книга написана более 20 лет назад, но не теряет своей актуальности до сих пор.
April 23, 2015
Дуже давно хотів прочитати цю книжку і чесно кажучи, дуже задоволений, що прочитав, тому що це чудова книжка. В легкій і цікавій формі роману, написано про проектний менеджмент.
Головний герой, містер Томпкінс, в колишньому крутий менеджер, якого викрадає агент КГБ вигаданої країни Моровії, для того, щоб він втілив 6 проектів по створенні програмного забезпечення, маючи при цьому майже безлімітні ресурси. Як завжди, протягом проекту виникає мільйон проблем, з якими змушений справлятися містер Томпкінс. Проблеми описані майже, як навчальні кейси, що дає дуже багато навчального підтексту - майже кожний розділ покриває якусь проблему чи ситуацію, які часто виникають під час реалізації проекту - нереалістичні дедлайнами, проблеми планування, ризик менеджмент, роботу в команді, важливість проектної документації і напевне одну з найбільших проблем - важких стейкхолдерів. В кінці кожного розділу є виділені основні уроки і інколи навіть короткі рекомендації, як поводитися в тій чи іншій ситуації і що потрібно для успіху в проектах. Всього є 101 урок, який я собі уважно занотовував в Evernote з надією, що буду перечитувати і користуватися.
Автором цієї книжки, є Том ДеМарко, відомий консультант та автор багатьох книжок. Він спеціалізується на розробці бізнес процесів, керування ризиками і в принципі проектному менеджменті. Свого часу отримав премію за "lifetime contribution to the field of computing", що говорить про його досвід. Хочу також прочитати його книжку "Waltzing With Bears: Managing Risk on Software Projects", про управління ризиками.
Мені особисто книжка видалася дуже цікавою, через те, що я займаюся проектним менеджментом, я взяв до себе багато ідей і уроків. Думаю, що ця книжка мала б бути цікавою, як проектним, так і звичайним менеджерам. Enjoy reading it!
Моя оцінка: 9/10.
Головний герой, містер Томпкінс, в колишньому крутий менеджер, якого викрадає агент КГБ вигаданої країни Моровії, для того, щоб він втілив 6 проектів по створенні програмного забезпечення, маючи при цьому майже безлімітні ресурси. Як завжди, протягом проекту виникає мільйон проблем, з якими змушений справлятися містер Томпкінс. Проблеми описані майже, як навчальні кейси, що дає дуже багато навчального підтексту - майже кожний розділ покриває якусь проблему чи ситуацію, які часто виникають під час реалізації проекту - нереалістичні дедлайнами, проблеми планування, ризик менеджмент, роботу в команді, важливість проектної документації і напевне одну з найбільших проблем - важких стейкхолдерів. В кінці кожного розділу є виділені основні уроки і інколи навіть короткі рекомендації, як поводитися в тій чи іншій ситуації і що потрібно для успіху в проектах. Всього є 101 урок, який я собі уважно занотовував в Evernote з надією, що буду перечитувати і користуватися.
Автором цієї книжки, є Том ДеМарко, відомий консультант та автор багатьох книжок. Він спеціалізується на розробці бізнес процесів, керування ризиками і в принципі проектному менеджменті. Свого часу отримав премію за "lifetime contribution to the field of computing", що говорить про його досвід. Хочу також прочитати його книжку "Waltzing With Bears: Managing Risk on Software Projects", про управління ризиками.
Мені особисто книжка видалася дуже цікавою, через те, що я займаюся проектним менеджментом, я взяв до себе багато ідей і уроків. Думаю, що ця книжка мала б бути цікавою, як проектним, так і звичайним менеджерам. Enjoy reading it!
Моя оцінка: 9/10.
February 8, 2019
DeMarco tries to make a novel out of illustrations of project management principles. His protagonist is an experienced software project manager who's given near complete power to make a project management laboratory -- to set up quasi-scientific tests of various PM principles and let them play out. There are consultants who drop by to be wise, and a cartoonishly villanous executive to make life difficult for Our Hero. And every chapter ends with Our Hero writing down a couple of adages in his notebook, things like "people under pressure don't think any faster" or "negotiation is hard; mediation is easy" or "the defining characteristic of pathological politics is that goals of personal power and influence come to override the natural goals of an organization" or "it's not what you don't know that kills you...it's what you know that isn't so."
I'm torn. This is an easy read, for the most part. Parts of it are very software specific (and so not very useful to me), parts of it are pretty dated (this was written in 1997). I agree with DeMarco's basic principle that if you hire good people, treat them well, and let them do their job, you'll get good results. This is a very people-centered approach to project management, which I appreciate.
But I think DeMarco's goal was to write something that would help readers remember these principles, and I don't know that he succeeds. There are so MANY adages in the book, over a hundred of them. I think that dilutes the impact, leaves me with a general feeling of "don't overlook the people stuff, the soft-skills factor", rather than really crystallizing all the lessons for me.
I read this long ago, don't regret re-reading it now. But I'm not sure that I'd recommend it to others.
I'm torn. This is an easy read, for the most part. Parts of it are very software specific (and so not very useful to me), parts of it are pretty dated (this was written in 1997). I agree with DeMarco's basic principle that if you hire good people, treat them well, and let them do their job, you'll get good results. This is a very people-centered approach to project management, which I appreciate.
But I think DeMarco's goal was to write something that would help readers remember these principles, and I don't know that he succeeds. There are so MANY adages in the book, over a hundred of them. I think that dilutes the impact, leaves me with a general feeling of "don't overlook the people stuff, the soft-skills factor", rather than really crystallizing all the lessons for me.
I read this long ago, don't regret re-reading it now. But I'm not sure that I'd recommend it to others.
February 22, 2020
The Deadline: A Novel about Project Management– це (несподівано) роман про управління проектами американця Тома Демарко. Хоча технічно це і роман, але цю книгу можна вважати нон-фікшн підручником з проектного менеджменту. Просто інформацію подано у формі захоплюючої вигаданої історії.
Досвідчений менеджер Вебстер Томкінс їде працювати в країну колишнього соцтабору, що ставить на меті стати світовим лідером із розробки програмного забезпечення. На шляху до успіху головному герою доводиться проходити усі етапи проектів: від запуску і до закриття. Він управляє ризиками та реагує на них. Знаходить потрібних людей та працює пліч-о-пліч з самовіданною командою. Бореться з токсичними людьми та впливом політичних інтересів. Словом все те, з чим зустрічаються проектні менеджери в щоденній роботі.
Інформація подана кмітливо та структуровано. Так після кожного розділу нам демонструють нотатки із записника містера Томкінса, де він фіксує найвагоміші уроки засвоєні в процесі роботи. З цих нотаток можна скласти своєрідні Правила життя проектного менеджера із сотні коротких, але інформативних висновків.
Якщо ви так чи інакше задіяні в розробці програмного забезпечення, в The Deadline ви неодноразово впізнаєте себе, колег та епізоди з повсякденної рутини. Для менеджменту – mustread. Новачкам буде корисно, а досвідчені управлінці зможуть вдосталь посміятись.
8,5/10
Досвідчений менеджер Вебстер Томкінс їде працювати в країну колишнього соцтабору, що ставить на меті стати світовим лідером із розробки програмного забезпечення. На шляху до успіху головному герою доводиться проходити усі етапи проектів: від запуску і до закриття. Він управляє ризиками та реагує на них. Знаходить потрібних людей та працює пліч-о-пліч з самовіданною командою. Бореться з токсичними людьми та впливом політичних інтересів. Словом все те, з чим зустрічаються проектні менеджери в щоденній роботі.
Інформація подана кмітливо та структуровано. Так після кожного розділу нам демонструють нотатки із записника містера Томкінса, де він фіксує найвагоміші уроки засвоєні в процесі роботи. З цих нотаток можна скласти своєрідні Правила життя проектного менеджера із сотні коротких, але інформативних висновків.
Якщо ви так чи інакше задіяні в розробці програмного забезпечення, в The Deadline ви неодноразово впізнаєте себе, колег та епізоди з повсякденної рутини. Для менеджменту – mustread. Новачкам буде корисно, а досвідчені управлінці зможуть вдосталь посміятись.
8,5/10
October 24, 2016
Эта книга понравилась мне меньше, чем Кирпичи 2.0, к сожалению.
В книге главный герой - Вебстер Томпкинс, которого только что уволили с работы по причине того, что компания решила сократить расходы, ну и Вебстера заодно тоже.
На очередном семинаре/тренинге для сокращённых сотрудников Вебстера "похищает" таинственная и загадочная женщина Лакса и транспортирует в пост-советскую страну Моровию, где ему предстоит стать руководителем огромного проекта. Тут и начинаются приключения Мистера Томпкинса.
В общем-то было не только увлекательно, но и очень полезно наблюдать за тем, как Вебстер работал над проектом, преодолевал препятствия и исправлял ошибки. Я много нового узнала о менеджменте проектов и поняла, что могу улучшить некоторые моменты в своей работе.
Ещё понравилось, что в конце каждой главы приведены основные тезисы (в форме того, чему Мистер Томпкинс научился).
Я думаю, эта книга будет полезна всем, и её будет интересно читать, потому что она написана не сухим техническим языком теории, а в форме увлекательной истории. Ставлю этой книге 3.5/5☆ только за то, что мне местами было скучновато.
В книге главный герой - Вебстер Томпкинс, которого только что уволили с работы по причине того, что компания решила сократить расходы, ну и Вебстера заодно тоже.
На очередном семинаре/тренинге для сокращённых сотрудников Вебстера "похищает" таинственная и загадочная женщина Лакса и транспортирует в пост-советскую страну Моровию, где ему предстоит стать руководителем огромного проекта. Тут и начинаются приключения Мистера Томпкинса.
В общем-то было не только увлекательно, но и очень полезно наблюдать за тем, как Вебстер работал над проектом, преодолевал препятствия и исправлял ошибки. Я много нового узнала о менеджменте проектов и поняла, что могу улучшить некоторые моменты в своей работе.
Ещё понравилось, что в конце каждой главы приведены основные тезисы (в форме того, чему Мистер Томпкинс научился).
Я думаю, эта книга будет полезна всем, и её будет интересно читать, потому что она написана не сухим техническим языком теории, а в форме увлекательной истории. Ставлю этой книге 3.5/5☆ только за то, что мне местами было скучновато.
August 8, 2014
From all the books on project management I've ever read this one is the easiest one to read. It's a novel! The plot is quite easy and predictable but still much funnier than plain book on business training.
As for the content - some of the ideas are simple and well-known (mythical man-month, inefficiency of negative motivation and overtime work, etc.) but some of them were new to me (e.g., conflicts resolution, two finish dates for the project, etc.). I definitely recommend this book but it's not a "silver bullet" (because there's no such :)).
As for the content - some of the ideas are simple and well-known (mythical man-month, inefficiency of negative motivation and overtime work, etc.) but some of them were new to me (e.g., conflicts resolution, two finish dates for the project, etc.). I definitely recommend this book but it's not a "silver bullet" (because there's no such :)).
February 8, 2017
DNF
I was forced to read this book by my UNCLE! He liked this book very much. He wanted me to read this book also, but I didn't focus this book because I was reading HP and The Chamber of Secrets. So I couldn't read this book.
There is not a fair reason to DNF this book. I did Because This book isn't MY TYPE. This book is about team management and I am not interested in that...
Maybe in future I will read this book but not NOW!
I gave this book 2.5 stars to neutralize the scale! *sigh*
I was forced to read this book by my UNCLE! He liked this book very much. He wanted me to read this book also, but I didn't focus this book because I was reading HP and The Chamber of Secrets. So I couldn't read this book.
There is not a fair reason to DNF this book. I did Because This book isn't MY TYPE. This book is about team management and I am not interested in that...
Maybe in future I will read this book but not NOW!
I gave this book 2.5 stars to neutralize the scale! *sigh*
April 23, 2011
as stated in many reviwes.this book is great to read about software project management concepts without sleeping over the book or gaining a headache...
August 12, 2012
Прекрасний літературний підхід до управління ІТ-проектами та пояснення "на пальцях" сутності проектного менеджменту із конкретними художніми прикладами
March 1, 2024
project management at its best. 1997 and still very solid and valid advice.
March 8, 2021
The book in 3 sentences
Mr Tompkins loses his managerial job at a big telecommunications company. He then finds himself on a more significant year-long project with various problems impeding work and preventing him from meeting the deadline. The book has been written as fiction and is filled with Mr Tompkins' learnings as he takes on this big project.
Impressions
Initially published in 1997, thankfully many, of the habits suggested by the protagonists are now standard in the tech industry. It is nice to understand better why we have developed such practices and what can happen if we don't follow best practices. The book compounds what I already know and occasionally offers new ideas I can try at my workplace.
An example of compounding my knowledge is the advice to keep meeting attendees to a minimum to assure they are effective, before conducting a meeting having clear goals and at the end of the meeting, making sure there are action items. Where I work currently, these are known, but they can often slip, so this book offers a reminder of best practices.
Mr Tompkins uses his new role as a chance to perform experiments on the team, which occasionally feel cruel. The potential distress of changing direction, changing rules and duplicating effort would mess with moral. I should probably remember the events are a mere vehicle to communicate wisdom to the reader. Most of the conversations in the book are between people in management, missing the crucial part of communicating change and plans to an engineering team, but perhaps Mr Tomkins` is too high up the food chain to do so.
The book contains fantastical characters; at points, they are caricatures, their quicks intentionally serve a purpose to strengthen further the allegories contained inside the book. The book has many humorous moments and shocking plot twists. Lots of the events that trigger Mr Tompkins problems are crazy but relatable; most of the solutions are practical and can be a lesson to readers. With the exception of finding a spare engineering team at his disposal. At points, it can be absurd how much wealth is at Mr Tompkins' disposal, the ability to fly in the best experts to advise him with the problems he faces, but of course, this helps the pace of the book. I suppose we too have experts at our disposal by the content of this book and the thousands of books and talks at our disposal online.
Who should read it
I struggle to read books about management, but this was written in an incredibly engaging way. If more books about product management were written in this style, I would read them all the time. I would recommend this book to anyone who works in product development, indiscriminate of seniority, as the content is easy to consume. The book is perfect for companies who lack structure or new companies attempting to develop their culture. This book is also suitable for people entering the industry to help them identify good habits.
How the book changed me
Unfortunately, I don't think the book was that impressive in regards to its content, but very well done in regards to execution. I wish more books about management were written in such a charming way.
My top three quotes
A lot of these quotes won't resonate as they don't have the allegory that inspired them. Here are a few of my favourite quotes.
"Lean and Mean is a formula developed in failing companies by the people responsible for the failure. It is the opposite of any organisation's natural goal: to be prosperous and caring. Whenever you hear the phrase 'lean and mean' replace it with what it really connotes: Failing and Frightened".
"Conflict deserves respect. Conflict is not a sign of unprofessional behaviour."
"Remember: Anger = Fear. Managers who inflict abusive, angry behaviour on their subordinates are almost always doing it because they're afraid."
Mr Tompkins loses his managerial job at a big telecommunications company. He then finds himself on a more significant year-long project with various problems impeding work and preventing him from meeting the deadline. The book has been written as fiction and is filled with Mr Tompkins' learnings as he takes on this big project.
Impressions
Initially published in 1997, thankfully many, of the habits suggested by the protagonists are now standard in the tech industry. It is nice to understand better why we have developed such practices and what can happen if we don't follow best practices. The book compounds what I already know and occasionally offers new ideas I can try at my workplace.
An example of compounding my knowledge is the advice to keep meeting attendees to a minimum to assure they are effective, before conducting a meeting having clear goals and at the end of the meeting, making sure there are action items. Where I work currently, these are known, but they can often slip, so this book offers a reminder of best practices.
Mr Tompkins uses his new role as a chance to perform experiments on the team, which occasionally feel cruel. The potential distress of changing direction, changing rules and duplicating effort would mess with moral. I should probably remember the events are a mere vehicle to communicate wisdom to the reader. Most of the conversations in the book are between people in management, missing the crucial part of communicating change and plans to an engineering team, but perhaps Mr Tomkins` is too high up the food chain to do so.
The book contains fantastical characters; at points, they are caricatures, their quicks intentionally serve a purpose to strengthen further the allegories contained inside the book. The book has many humorous moments and shocking plot twists. Lots of the events that trigger Mr Tompkins problems are crazy but relatable; most of the solutions are practical and can be a lesson to readers. With the exception of finding a spare engineering team at his disposal. At points, it can be absurd how much wealth is at Mr Tompkins' disposal, the ability to fly in the best experts to advise him with the problems he faces, but of course, this helps the pace of the book. I suppose we too have experts at our disposal by the content of this book and the thousands of books and talks at our disposal online.
Who should read it
I struggle to read books about management, but this was written in an incredibly engaging way. If more books about product management were written in this style, I would read them all the time. I would recommend this book to anyone who works in product development, indiscriminate of seniority, as the content is easy to consume. The book is perfect for companies who lack structure or new companies attempting to develop their culture. This book is also suitable for people entering the industry to help them identify good habits.
How the book changed me
Unfortunately, I don't think the book was that impressive in regards to its content, but very well done in regards to execution. I wish more books about management were written in such a charming way.
My top three quotes
A lot of these quotes won't resonate as they don't have the allegory that inspired them. Here are a few of my favourite quotes.
"Lean and Mean is a formula developed in failing companies by the people responsible for the failure. It is the opposite of any organisation's natural goal: to be prosperous and caring. Whenever you hear the phrase 'lean and mean' replace it with what it really connotes: Failing and Frightened".
"Conflict deserves respect. Conflict is not a sign of unprofessional behaviour."
"Remember: Anger = Fear. Managers who inflict abusive, angry behaviour on their subordinates are almost always doing it because they're afraid."
January 15, 2021
I guess trying to teach about Project Management while telling a story will always have impact on the quality of one or both of those goals.
The premise of the story is already completely unbelievable to me. Buying a former soviet country, and the people just accepting that. One of the main character abducting people and they find that very charming. The whole love story is nothing short of cringeworthy. Very few interactions between the main character and his future wife are told. How and why they fall in love, besides the fact that she is good looking and "edgy" with all her funny criminal activity, is left in the dark. I was unpleasantly surprised. It is also unclear why those weird transactions (buying countries and making an IPO) is even in the book. DeMarco could have done the same with a privatized former soviet company. It would have made more sense. Sometimes I suspected these shenanigans were supposed to be humorous.
The project management part has some good and true lessons to be learned. Some of the scenarios are very close to reality which makes some of the unrealistic stuff even weirder. Also the whole diary thing is so on-the-nose that I feel it is just bad writing. In 2021 some of the lessons are quite outdated. Especially the absence of agile methodologies is obvious. And it is clear why: The premise of just copying existing software gets rid of many of the uncertainties that make the agile approach perform better than traditional waterfall methodology.
Many of the characters seem taken directly from an Ayn Rand novel. The idea of these super productive people whose benevolent reign over the peoples of the world for the betterment of all and their own profit is not something that I feel is how the world works.
Overall I cannot recommend this book. IF you are interested in project management, you should read a more modern book, if you are interested in a good story, look elsewhere.
The premise of the story is already completely unbelievable to me. Buying a former soviet country, and the people just accepting that. One of the main character abducting people and they find that very charming. The whole love story is nothing short of cringeworthy. Very few interactions between the main character and his future wife are told. How and why they fall in love, besides the fact that she is good looking and "edgy" with all her funny criminal activity, is left in the dark. I was unpleasantly surprised. It is also unclear why those weird transactions (buying countries and making an IPO) is even in the book. DeMarco could have done the same with a privatized former soviet company. It would have made more sense. Sometimes I suspected these shenanigans were supposed to be humorous.
The project management part has some good and true lessons to be learned. Some of the scenarios are very close to reality which makes some of the unrealistic stuff even weirder. Also the whole diary thing is so on-the-nose that I feel it is just bad writing. In 2021 some of the lessons are quite outdated. Especially the absence of agile methodologies is obvious. And it is clear why: The premise of just copying existing software gets rid of many of the uncertainties that make the agile approach perform better than traditional waterfall methodology.
Many of the characters seem taken directly from an Ayn Rand novel. The idea of these super productive people whose benevolent reign over the peoples of the world for the betterment of all and their own profit is not something that I feel is how the world works.
Overall I cannot recommend this book. IF you are interested in project management, you should read a more modern book, if you are interested in a good story, look elsewhere.
This entire review has been hidden because of spoilers.
February 6, 2020
Тонким слоем размазаны корректные банальности вроде падения скорости работы при переработках или стоимости и целесообразности увеличения команды.
Но я с трудом смог дослушать до конца - почти весь текст книги это какая-то инфантильная фантазия, и непонятно зачем она в нагрузку к project management.
Чтобы было развлекательно и интересно? Но эта фантазия ни разу не интересна и просто глупа.
Кроме того в книге есть и вредные советы по project management - например когда руководитель, управляющий тысячами разработчиков, начинает лезть внутрь процесса разработки, по сути ничего не понимая, и продвигая порой вредные в общем случае подходы. Которым может быть место в конкретных командах и конкретных ситуациях, но не в большой организации как общий подход.
Надо отдать должное, что в принципе руководитель в книге действует верно - не изобретает и не читает популярных книжек, а одобряет инициативы снизу. Но возникает вопрос - нафига эти инициативы двигать через несколько уровней управленческой вертикали вверх, а потом спускать на всех без разбору с самого верха.
Опытный управленец ничего в этий книге не найдет.
Начинающему разработчику книга могла бы быть полезной - для понимания, насколько руководители проеектов не понимают что реально программисты делают. Это не потому что они глупые - они просто профессионалы в совсем иной области. Поэтому разработчику для собственного психического здоровья надо научиться относится к этому философски и просто вежливо "забивать", когда руководителя заносит и он залетает в не свою область.
Но психоделическая нудная история, занимающая большую часть книги, не дает мне рекомендовать хоть кому-то тратить на нее время.
Но я с трудом смог дослушать до конца - почти весь текст книги это какая-то инфантильная фантазия, и непонятно зачем она в нагрузку к project management.
Чтобы было развлекательно и интересно? Но эта фантазия ни разу не интересна и просто глупа.
Кроме того в книге есть и вредные советы по project management - например когда руководитель, управляющий тысячами разработчиков, начинает лезть внутрь процесса разработки, по сути ничего не понимая, и продвигая порой вредные в общем случае подходы. Которым может быть место в конкретных командах и конкретных ситуациях, но не в большой организации как общий подход.
Надо отдать должное, что в принципе руководитель в книге действует верно - не изобретает и не читает популярных книжек, а одобряет инициативы снизу. Но возникает вопрос - нафига эти инициативы двигать через несколько уровней управленческой вертикали вверх, а потом спускать на всех без разбору с самого верха.
Опытный управленец ничего в этий книге не найдет.
Начинающему разработчику книга могла бы быть полезной - для понимания, насколько руководители проеектов не понимают что реально программисты делают. Это не потому что они глупые - они просто профессионалы в совсем иной области. Поэтому разработчику для собственного психического здоровья надо научиться относится к этому философски и просто вежливо "забивать", когда руководителя заносит и он залетает в не свою область.
Но психоделическая нудная история, занимающая большую часть книги, не дает мне рекомендовать хоть кому-то тратить на нее время.
Displaying 1 - 30 of 194 reviews