Facebook Twitter Pinterest <Einbetten>
  • Alle Preisangaben inkl. USt
Auf Lager.
Verkauf und Versand durch Amazon. Geschenkverpackung verfügbar.
The Principles of Product... ist in Ihrem Einkaufwagen hinzugefügt worden

Lieferort:
Um Adressen zu sehen, bitte
Oder
Bitte tragen Sie eine deutsche PLZ ein.
Oder
+ EUR 3,00 Versandkosten
Gebraucht: Wie neu | Details
Verkauft von ---SuperBookDeals---
Zustand: Gebraucht: Wie neu
Kommentar: 100% Geld zurueck Garantie. Zustand Wie neu. Schneller Versand, erlauben sie bitte 8 bis 18 Tage fuer Lieferung. Ueber 1,000,000 zufriedene Kunden. Wir bieten Kundenbetreuung in Deutsch.
Möchten Sie verkaufen?
Zur Rückseite klappen Zur Vorderseite klappen
Hörprobe Wird gespielt... Angehalten   Sie hören eine Hörprobe des Audible Hörbuch-Downloads.
Mehr erfahren
Alle 2 Bilder anzeigen

The Principles of Product Development Flow: Second Generation Lean Product Development (Englisch) Gebundene Ausgabe – 29. Mai 2009

4.8 von 5 Sternen 4 Kundenrezensionen

Alle 5 Formate und Ausgaben anzeigen Andere Formate und Ausgaben ausblenden
Preis
Neu ab Gebraucht ab
Kindle Edition
"Bitte wiederholen"
Gebundene Ausgabe
"Bitte wiederholen"
EUR 37,98
EUR 24,70 EUR 29,58
12 neu ab EUR 24,70 5 gebraucht ab EUR 29,58
click to open popover

Wird oft zusammen gekauft

  • The Principles of Product Development Flow: Second Generation Lean Product Development
  • +
  • Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn))
Gesamtpreis: EUR 90,59
Die ausgewählten Artikel zusammen kaufen

Es wird kein Kindle Gerät benötigt. Laden Sie eine der kostenlosen Kindle Apps herunter und beginnen Sie, Kindle-Bücher auf Ihrem Smartphone, Tablet und Computer zu lesen.

  • Apple
  • Android
  • Windows Phone

Geben Sie Ihre Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.

Jeder kann Kindle Bücher lesen — selbst ohne ein Kindle-Gerät — mit der KOSTENFREIEN Kindle App für Smartphones, Tablets und Computer.


Produktinformation

Produktbeschreibungen

The Principles of Product Development Flow The dominant paradigm for managing product development is wrong; not just a little wrong, but wrong to its very core. Stagnant piles of idle work lengthen cycle time, delay vital feedback and destroy process efficiency. Yet today, these queues remain unmanaged. This landmark book defines a new approach, one based on solid economics and real science. It focuses on controlling the invisible and unme... Full description


Kundenrezensionen

4.8 von 5 Sternen
5 Sterne
3
4 Sterne
1
3 Sterne
0
2 Sterne
0
1 Stern
0
Alle 4 Kundenrezensionen anzeigen
Sagen Sie Ihre Meinung zu diesem Artikel

Top-Kundenrezensionen

Format: Gebundene Ausgabe Verifizierter Kauf
This is a reaö comprehensive book full of knowledge, advice and thoughtful insights on lean product development. It is not a novel and not a story which you can read in one row but worth every minute while reading bit by bit. It's hard to overestimate the value of this book, if you really want to understand the mechanics and the basics of lean (-agile) product development this is a must read.
Kommentar War diese Rezension für Sie hilfreich? Ja Nein Feedback senden...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte erneut versuchen
Missbrauch melden
Format: Gebundene Ausgabe
This book is a must read for everyone interested in product development flows and especially for all product development managers.

Summary of the book
--------------------

Don Reinertsen describes in his book 174 principles how to develop an improved, more profitable development flow.

He uses ideas from lean manufactoring, economics, queueing theory, statistics, the internet, computer operating system sesign, control engineering and maneuver warfare and adapts them to product development.

The author states that todays problems in product development are caused by failure to correctly quantify economics, blindness to queues, worship of efficiency,hostility to variability, worship of conformance, institutionalization of large batch sizes, underutilization of cadence, managing timelines instead of queues, absence of WIP constraints, inflexibility, noneconomic flow control, and centralized control.

He emphasizes that it is important to treat development decisions as economic decisions. This is in his opinion much better than chasing whichever proxy variable is popular at the moment.

Developing an economic framework and decisions rules help to quickly process the small, perishable economic decisions. The economic models and rules do not have to be perfect, because even imperfect rules improve decision making.

A decision rule that is missing in most companies today is a quantified cost of delay.

Reducing Queues is the key to improve product development performance. The hidden cost of queues are often overseen. They are the hidden source for most development waste, because they increase cycle time, expenses, variability and risk and they slow feedback, reduce quality, and decrease motivation.
Lesen Sie weiter... ›
Kommentar 6 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich? Ja Nein Feedback senden...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte erneut versuchen
Missbrauch melden
Format: Gebundene Ausgabe
Eine sehr gute Hilfe für alle, die ihre Produkt-Entwicklung vollständig und flexibel, optimiert auf Entwicklungsziele ausrichten wollen.

Ein paar Erkenntnisse aus dem Buch zum Anfüttern:

(1) Entwicklungsergebnisse sollen Profit bringen. Alle Aktivitäten sollten darauf ausgerichtet sein und sich daran messen. Stellgrößen sind insbesondere Entwicklungskosten, Herstellkosten, Produkt-Features, Time-to-Market und Risko/Versicherungen. Nicht die Optimierung einer Stellgröße bringt den Erfolg, sonders das aktive stetige Einstellen des richtigen Arbeitspunktes für alle Stellgrößen zusammen.

(2) Entscheidungskurven für a oder b ergeben U-Kurven, die in der Regel ein breites Minimum haben. Das bedeutet, solange die Entscheidung nicht auf dem Rand der U-Kurve liegt, liegt man nicht weit vom Optimum weg. Die Entscheidung kann also mit einer beruhigenden Ungenauigkeit getroffen werden.

(3) Mehr Auslastung von Entwicklern führt bei Änderungen und Taskwechsel zu relativ mehr Overhead. Die effiziente Ausnutzung von Entwicklern liegt eher in der Größenordnung von (z.B.) 65-75% als bei 90-100%. Das genaue Optimum muss im eigenen Unternehmen gefunden werden.
Kommentar 5 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich? Ja Nein Feedback senden...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte erneut versuchen
Missbrauch melden
Format: Kindle Edition Verifizierter Kauf
A new view, interesting principles and good ideas but sometimes I miss the link to concrete actions and samples. Worth for reading for all product development leads with a strong desire to change things.
Kommentar War diese Rezension für Sie hilfreich? Ja Nein Feedback senden...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte erneut versuchen
Missbrauch melden

Die hilfreichsten Kundenrezensionen auf Amazon.com (beta) (Kann Kundenrezensionen aus dem "Early Reviewer Rewards"-Programm beinhalten)

Amazon.com: 4.5 von 5 Sternen 75 Rezensionen
6 von 6 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Reviewing as I read along, love it so far 18. Juni 2014
Von Brett L. Schuchert - Veröffentlicht auf Amazon.com
Format: Kindle Edition Verifizierter Kauf
I got this book on 2014/06/17 and I've read into Chapter 3.

Chapter 1 is somewhat different from the other chapters in that rather than being a series of principles, it provides an overall view of practice orthodoxy and how many of these closely held beliefs are based on secondary or proxy variables. The chapter continues with an overview of several examples and then summarizes and discusses where things are going in the rest of the book as well as the layout. The first chapter is great. I did expect it to end a bit sooner than it did (I was thinking in terms of self-referential, small batch sizes), but I'm not sure a shorter chapter would have been better.

The second chapter introduces the approach for the rest of the book as well as the model underpinning the principles. The approach works for me. I imagine myself reading this book, going back and creating queue cards for each of the principles, then periodically looking up individual ones and refreshing my memory. It seems like a book I can keep going back to and reading just because I want 5 minutes of good reading.

For some context, I'm a software developer. I learned about the Theory of Constraints (ToC) before I really learned software development processes in depth. When I did being the software process journey, it was under the OO umbrella, so incremental and iterative, feedback, etc. This learning, however, I've recently realized (by first reading Kanban and now this book) was heavily influenced by the ToC. At the beginning of this century, I jumped on the XP and Scrum bandwagons, even working with a few of the original signatories on the manifesto for agile development.

ToC came up a number of times while coaching. Moving from ToC to thinking in terms of Kanban isn't much of a leap to me. However, since I was applying things I learned and internalized, things that seem obvious to me are often not obvious to my customers or even my colleagues (yes, sometimes I'm wrong, but often I'm not). For example, at many, many places I've been, companies claim they are practicing continuous integration or even continuous delivery, but then their builds are broken (red) 80+ % of the time. This is a huge cost to productivity, morale, feedback, etc. This is one example of many such examples that, in in the context of ToC are obvious bottlenecks, which cause queueing. If I look with lean glasses, many of these are worthy of stopping the line, but people march on, building up queues of work to be committed, which lead to more broken builds, integration problems, demoralization, etc.

However, what seems obvious to me doesn't seem obvious to others. More importantly, many people don't even see that there's a problem at all! They think, for example, when developers complain about being blocked due to the build being broken, it's just developers complaining about a minor glitch, but it is more typically a systemic problem.

This books presents a model based on economics. One thing that I observed myself observing about the book was that I thought it might be over emphasizing one dimension, cost of delay, or one approach, economics. However, "all models are wrong, some are valuable." While I had this observation, I didn't find anything wrong about the conclusions, and in fact find my self thinking "yes and," so I've kept reading. So while this model may be wrong in some ways (I'm not aware of any), I clearly see immediate and near-term value for me with its use.

What this model does is allow me to speak to upper management, and maybe middle management using a language they are likely to appreciate. I'm able to justify things like slack using economic models, so that I might be better able to communicate with them. So rather than talking about the flexibility and agility that well under 100% utilization might offer, instead I can discuss the cost of delivery related to high utilization (lack of slack). My primary failing up until now is not being able to explain what seems intuitive to me in a way that bridges the communication gap. This model seems to give me another way to both think about it and communicate it.

I have not finished reading the book, but in the the spirit of small batch sizes, this is my first delivery. I'll be making updates as I read the book. I am already confident that I'll finish this book and that I can recommend it to people. It'll have to really work hard to go under a 5 star review.

Finally (so far): my impression so far reading the book is that it seems well researched, brings together a number of disciplines in a non-trivial manner and seems to come form someone who legitimately has many good years of experience, not just the same 1 year of experience repeated over and over.
53 von 54 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Challenges Orthodox Thinking On Every Side 12. August 2010
Von Amazon Customer - Veröffentlicht auf Amazon.com
Format: Gebundene Ausgabe Verifizierter Kauf
I won't repeat what others have said except that this new standard on lean product and software development challenges orthodox thinking on every side and is required reading. It's fairly technical and not an easy read but well worth the effort.

For the traditionalist, add to cart if you want to learn:

- Why prioritizing work "on the basis of project profitability measures like return on investment (ROI)" is a mistake
- Why we should manage queues instead of timelines
- Why "trying to estimate the amount of work in queue" is a waste of time
- Why our focus on efficiency, capacity utilization, and preventing and correcting deviations from the plan "are fundamentally wrong"
- Why "systematic top-down design of the entire system" is risky
- Why bottom-up estimating is flawed
- Why reducing defects may be costing us money
- Why we should "watch the work product, not the worker"
- Why rewarding specialization is a bad idea
- Why centralizing control in project management offices and information systems is dangerous
- Why a bad decision made rapidly "is far better" than the right decision made late and "one of the biggest mistakes a leader could make is to stifle initiative"
- Why communicating failures is more important than communicating successes

For the Agilist, add to cart if you want to learn:

- Why command-and-control is essential to prevent misalignment, local optimization, chaos, even disaster
- Why traditional conformance to a plan and strong change control and risk management is sometimes preferable to adaptive management
- Why the economies of scale from centralized, shared resources are sometimes preferable to dedicated teams
- Why clear roles and boundaries are sometimes preferable to swarming "the way five-year-olds approach soccer"
- Why predictable behavior is more important than shared values for building trust and teamwork
- Why even professionals should have synchronized coffee breaks

And the list goes on and on and on.

My favorite sections are Reducing Batch Size, which I use in my Agile courses, The Human Side of Feedback, and Achieving Decentralized Control, on "what we can learn from military doctrine."

Mind-expanding! Bonus: the author includes his email address and promptly responds to inquiries.
5.0 von 5 Sternen A breath of fresh air 29. Januar 2016
Von Trevor Crosse - Veröffentlicht auf Amazon.com
Format: Kindle Edition Verifizierter Kauf
This book is a refreshing read. Product developers have normalized and internalized bad practices for so long that it's often impossible to see why we so often fail. Too many fundamentally bad ideas have become so ingrained that we often forget to examine them. Things like phase gated project management and 'full utilization of resources' are taken for granted as much as the air we breath. When things do go wrong managers usually try and "fix" things by doing the same things but with more intensity

Reinertsen clears this away and looks at the product development cycle from holistic perspective. When you approach the problem from a Total Lifecycle Profits perspective some forms of apparent 'waste' are really not. Implementing two options in parallel knowing you will throwing one away may very well be less wasteful then implementing just your preferred option - only to discover too late that it won't work.

His focus on queues and queuing theory is critically important. All processes and business have queues but too often we don't think of them that way. It's just the pile of work we need to get done - which is completely different from a queue right? Looking for hidden queues and treating them properly is the key to improving many processes.

I particularly enjoyed his discussion of efficient 'resource utilization'. A road network that is 100% utilized is gridlocked. A computer server with a pinned CPU and full memory is clogged and overloaded. A FedEx truck packed with every cubic inch of space is impossible to unload efficiently. Why then do managers assume that an employee with 'only' 90% of their 'capacity' spoken for is in desperate need of another project? Reinertsen cuts through this nonsense.

This is a new form of Scientific Management. Most previous attempts have treated people like clockwork parts in a machine. Differences were seen as a problem to be eliminated. If everything and everyone were the same then Efficiency would be achieved! All re-work was seen as inherently bad and a sign of a flawed process. Instead, by focusing on flow Reinertsen shows that in many cases variability is the key to adding value. With small batch sizes, parallel queues and fast feedback re-work can actually result in much better products and higher profits.

This book doesn't not provide a capital P Process that a business can implement as a magic wand. Instead it provides a set of tools and a way of thinking that can guide each organization to discover how to achieve flow in their own domain.

I highly recommend this book to executives, managers, product developers and "in the weed" workers. It's applicable across a wide variety of industries. While the details of developing new furniture or the next great cloud application are going to be very different the principles and tools are the same.
1 von 1 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Engaging with this book will teach you a framework for analyzing product dev. process-- invaluable 15. Oktober 2016
Von Max Wallace - Veröffentlicht auf Amazon.com
Format: Gebundene Ausgabe Verifizierter Kauf
Reinertsen is not afraid to be rigorous and intellectual, and the result stands head-and-shoulders above most other books on product development. I wish more authors had the courage to tackle "difficult" concepts.

There were some helpful, concrete insights, but more important, this book will help you develop a mental framework for analyzing product development process. This understanding will set you free from the Agile vs. Waterfall cargo-cultism that permeates the tech industry.
6 von 6 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Audacious and Pathbreaking 27. Mai 2011
Von Tom K. - Veröffentlicht auf Amazon.com
Format: Gebundene Ausgabe Verifizierter Kauf
Donald Reinertsen's latest book on new product development aspires to making a global and historical impact. He systematically applies the theory and best practices of lean manufacturing, economics, queuing theory, statistics, web communications, operating systems, control engineering and military science to the new product development process. He summarizes these insights in 8 themes and 175 principles. Examples and graphs illustrate the concepts.

This is a dense book. The target audience of marketing MBA's, industrial engineers, project and general managers will be challenged. It requires some familiarity with lean manufacturing, economics and operations research. The principles are illustrated but not obvious. The quality, lean manufacturing, Toyota Production System, theory of constraints and technical sources are briefly referenced. The rationale for existing (stage-gate) best practices is not explained. Limits and trade-offs are not discussed.

Nonetheless, this is an audacious and path breaking book. Product development practitioners can learn and apply the principles of this book.
Economics trumps simple versions of quality paradigms. Expected net lifetime value is king. Marginal cost/benefit analysis rules. Global optimums outweigh local ones. Proxy measures undermine optimal economic decision-making. Decisions matter, precision does not. Priority features/competitive advantages matter most. Economic rules of thumb allow decentralized decisions. Cost of delay is managed through an explicit value of time.

Queuing theory manages delays. Project and task cycle times drive the cost of delay. Long queues increase defects, variability and risks. Misplaced high efficiency and utilization goals lead to delays, increased costs and disastrous momentum. Communications links between adjacent processes matter more than bottleneck capacity. Simple views that delays, variability, inventory or waste are evil or have infinite cost lead to bad decisions. Queues are everywhere in product development.

Measure variability with a payoff function. It can be negative or positive. Testing generates information value. Statistics based steps reduce variation, such as smaller tasks and time horizons. Counterbalance and design reuse offset variability. Economic priorities, faster iterations and early high risk actions minimize the impact of variability.
Smaller task batch sizes reduce variability and cycle time, accelerate feedback, improve engagement and reduce risk and overhead. Large batches increase costs, delay progress and may spin out of control. Optimum batch sizes are small and can be found through trial and error. Combine features in separately developed and tested modules. Smaller batches are more beneficial than capacity increases. Large batches impact every step of product development.

Detailed planning and control of tasks is costly. It is more effective to control the work in process between major functions. As with TPS or Theory of Constraints, managing the flow of released product from stage to stage improves final results. Many scheduling, prioritization, resource and recovery strategies can minimize task WIP. A blended generalist/specialist staff skills profile offers flexible capacity.

The flow of activities through product development can be managed. Use forecasts and share information between adjacent stages. Use cadence to set routine start/stop times. Synchronize tasks so that dependent events flow smoothly. Sequence tasks and change priorities based upon risk and incremental economic value added. Build in flexible paths and spare resources.

Develop rapid feedback systems. Employ early warning systems and value at risk triggers to escalate reviews. Align activities through training, incentives and templates. Adjust decisively when required. Use frequent communication to build teams and short queues to build urgency. Employ flow metrics.

Decentralize decision making to speed the flow and avoid management bottlenecks. Provide high level structure in the form of rough-cut plans, rules of thumb, intentions, templates and sequences.

The principles in this book can be applied to any operations or development process. The value added is limited only by the time invested.
Waren diese Rezensionen hilfreich? Wir wollen von Ihnen hören.