„Feature versus Quality“ – Erfolgsfaktoren des Apolloprogrammes

Ich hoffe sehr, daß Sie einen schönen Start in das neue Jahr hatten.

Bekanntlich kann man aus der Geschichte sehr viel lernen. Ich habe mich deshalb in der ruhigen Zeit zwischen den Jahren u.a. mit der Website der NASA beschäftigt, auf der sehr viele Informationen zu den Raumfahrtprogrammen dokumentiert sind.

Die Mondlandung war zweifellos ein großes, innovatives Projekt, das mit sehr vielen Unwägbarkeiten zurechtkommen mußte, und in dessen Verlauf viele Innovationen entstanden sind.

Bei meinen Nachforschungen habe ich eine Dokumentation gefunden, die sich mit den Erfolgsfaktoren des Apolloprojektes beschäftigt, und die die Frage beantwortet, welche Arbeitsweisen zum Erfolg dieses großen Projektes beigetragen haben.

Vieles davon läßt sich unverändert in die heutige Zeit, und auf moderne Entwicklungsprojekte übertragen.

What Made Apollo a Success

Die Studie What Made Apollo a Success (siehe die Dokumentverweise, die ich in den weiterführenden Informationen zusammengetragen habe) ist nach der erfolgreichen Mondlandung entstanden, und sie fasst die sieben Erfolgsfaktoren zusammen, die dazu beigetragen haben, daß das Projekt erfolgreich war.

Verschiedene Autoren sind an dieser Studie beteiligt gewesen, und diese machen die folgenden Faktoren für den Erfolg verantwortlich:

2. DESIGN PRINCIPLES STRESSING SIMPLICITY. By Kenneth S. Kleinknecht.
3. TESTING TO ENSURE MISSION SUCCESS. By Scott H. Simpkinson.
4. APOLLO CREW PROCEDURES, SIMULATION, AND FLIGHT PLANNING. By Warren J. North and C. H.
Woodling.
5. FLIGHT CONTROL IN THE APOLLO PROGRAM. By Eugene F.
Kranz and James Otis Covington.
6. ACTION ON MISSION EVALUATION AND FLIGHT ANOMALIES. By Donald D. Arabian.
7. TECHNIQUES OF CONTROLLING THE TRAJECTORY. By Howard W. Tindall, Jr.
8. FLEXIBLE YET DISCIPLINED MISSION PLANNING. By C. C. Kraft, Jr., J. P. Mayer,
C. R. Huss, and R. P. Parten.

Mindestens die Faktoren #2, #3, #8 lassen sich sehr gut auf die allgemeine Produktentwicklung übertragen – insofern lohnt ein näherer Blick.

Entwurfsprinzipien

Im Kapitel DESIGN PRINCIPLES STRESSING SIMPLICITY schreibt S. Kleinknecht über die Entwufsprinzipien (Hervorhebungen durch mich):

„Build it simple and then double up on many components or systems so that if one fails the other will take over. …

Minimize functional interfaces between complex pieces of hardware. In this way, two organizations can work on their own hardware relatively independently. Examples in Apollo include the interfaces between the spacecraft and launch vehicle and between the command module and the lunar module.

Another design question for manned flight concerns the use of man himself. Here again, we find no simple rule as to how man should interface with his machine. Generally, tedious, repetitive tasks are best performed automatically; and selection of the best data source to use, selection of control modes, and switching between redundant systems are tasks best performed by the pilot.

…A tremendous amount of time and effort was spent to determine how the crew could best decide which data source to use and which of many redundant systems to rely on. This was always a basic mission-design consideration.“

Auf heutige Entwicklungsprojekte übertragen, ergeben sich die folgenden Leitsätze:

• Je simpler man das Produktdesign machen kann, desto besser.
• Technische Systeme (und Software) sollte man so auslegen, daß sie fehlertolerant sind.
• Modulares Design mit klar definierten Schnittstellen bevorzugen.
• Ein User Interface, das den Nutzer bei seinen Aufgaben unterstützt (wobei eine hohe Gebrauchsfähigkeit aus mehr besteht, als aus einer schönen Oberfläche).

Umgang mit Änderungen

In Absatz INTRODUCTION, schreibt George M. Low über das Thema „Änderungen und Änderungsmanagement“ (Hervorhebungen durch mich):

„If the design has been verified and if a thorough test program has been completed, it should not be necessary to make any changes. Of course, this idealized situation does not exist in any program like Apollo where design, test, and flight often overlap and must be carried out at the same time. …

…Since it is not possible to eliminate all changes, we have to start with the premise that any change will be undesirable. That is, a change will void all previous test and flight experience and, no matter how simple, may have ramifications far beyond those identified by the initial engineering analysis.

Because changes must be made nevertheless, it becomes important to understand and to control them, no matter how small.“

Übersetzt in Leitsätze für unsere heutigen Entwicklungsprojekte bedeutet dies:

• Den Bedarf für Änderungen minimieren, und Änderungen nach Abschluss einer
  Projektphase nur geplant durchführen.
• Verwendung von Verfahren forcieren, mit denen man die Konsistenz des Produktes testen und sicherstellen kann, auch wenn Änderungen diese Konsistenz gefährden.
• Nachvollziehbarkeit der Änderungen muss sichergestellt werde, z.B. über eine entsprechende Planung (Scrum-Methode?).

Qualitätssicherung und Testen

In Abschnitt TESTING TO ENSURE MISSION SUCCESS, schreibt Scott H. Simpkinson, daß die Qualitätssicherung und speziell das Testen essentiell waren für den Erfolg des Programmes (Hervorhebungen durch mich):

„The single most important factor leading to the high degree of reliability of the Apollo spacecraft was the tremendous depth and breadth of the test activity. There are two general categories of tests:

(1) those made on a single prototype device (or on a few devices) to demonstrate that the design is proper and will perform properly in all environments and
(2) those made on each flight item to assure that there are no manufacturing errors and that the item will function as intended.

Both categories apply to individual parts, components, subsystems, systems, and entire [3] spacecraft. The first category includes development testing early in the design cycle and the very formal certification or qualification tests performed on test articles identical to the flight system. The second category covers acceptance testing.“

Übertragen auf ein heutiges Softwareprojekt bedeutet dies:

• Design Reviews und ähnliche Maßnahmen verwenden, um sicherzustellen, daß das
  Softwaredesign möglichst früh im Prozess fehlerfrei ist.
• Mockups und Prototypen verwenden, um möglichst viel über das Produktkonzept zu lernen (auch bei Kunden).
• Innerhalb des Produktbacklogs Testaktivitäten vorsehen, um die einzelnen Elemente des Produktes/ der Software zu testen (Unit tests, manuelle Tests, Integrationstests, etc).

Fazit

Das Apollo Programm war auch deshalb erfolgreich, weil man sich an einfache Arbeitsmethoden gehalten hat. Viele dieser Methoden kommen uns heute noch bekannt vor.

Aus den Erfolgsfaktoren kann man lernen, und es macht durchaus Sinn, einige der Prinzipen zu verwenden, um bessere Produkte zu entwickeln.

Weiterführende Informationen

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph).

Neu erscheinende Artikel gibt es über die (→Mailingliste), oder, indem Sie →mir auf Twitter folgen.In der Online Version finden Sie hier die versprochenen weiterführenden Links:

• →The Apollo Program
• →What Made Apollo A Success? (NASA SP-287, 1971)
• →DESIGN PRINCIPLES STRESSING SIMPLICITY
• →INTRODUCTION
• →TESTING TO ENSURE MISSION SUCCESS

This entry was posted on Montag, Januar 13th, 2014 at 8:09 pm. It is filed under PM-Themen, Thema des Tages and tagged with Qualität, Quality, Rapid Prototype, Rolle des PM, Strategie. You can follow any responses to this entry through the RSS 2.0 feed.