Отличная книга. Написана в форме художественной, а не деловой форме, легкое изложение, но при этом в конце каждой главы – важные тезисы.

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

Рекомендую прочесть книгу не только project manager'ам, но и всем, кто занимается разработкой программного обеспечения. ( )

Interesting option : try to make a project management book as a novel. I am not convinced by the business points, probably obvious enough but the book is really funny to read. ( )

Der Klassiker unter Projektmanagement-Büchern. Genial geschriebenes Buch mit sehr wertvollem Inhalt und sehr vielen Wahrheiten für einen Projekt-Manager.
Ich kann das Buch immer und immer wieder lesen und finde immer und immer wieder neue alte Wahrheiten, wie z.B. 'EIne Aufgabe benötigt MINDESTENS so lange, wie man ihr Zeit gibt!'

Wirklick empfehlenswert! ( )

In this book you follow along as a fictional project manager copes with a slew of issues, discoveries and revelations in the midst of his impossible project.
For me the genius in this book lies in the protagonist keeping a journal of lessons learned from each day on the project. On my first day at work since completing the book, I unconsciously wrote myself a note in the same exact style employed in the book ("Build one phone, not six applications").

Here's a taste of some of my faves form the book - but you really must read for yourself because much of the learning takes place within the book's narrative.

* No matter how serious the threat, the work still won't get done on time if the time originally allocated for it was not sufficient.
* Think of a jelled team - ready and willing to take on a new effort - as one of the project deliverables
* The danger of standard processes is that people will miss chances to take important shortcuts
* There is no way to get projects to perform substantially beyond the norm without making large reductions in the total amount of debugging time
* Keep meetings small by making it safe for unessential people not to attend.
* Awful suspicion: Projects that set out to achieve "aggressive" schedules probably take longer to complete than they would have if started with more reasonable schedules. ( )