Für eilige LeserInnen: Ein emotionales Plädoyer für den Rational Unified Process und systematisches Projektmanagement bei der Software-Entwicklung.
Vorab: vier der sechs Kapitel sind von Gerhard Versteegen geschrieben, die Kapitel 5 und 6 sind zudem mehr als Ergänzung zu betrachten.
Das mit den Buchtiteln ist so eine Sache: Entweder sind sie so abstrakt, dass sie eigentlich nichts aussagen und kaum unterscheidbar sind, oder sie sind ganz einfach falsch. Hier trifft irgendwie beides zu. Prozesse werden hier nicht beschrieben und über sie hinweggegriffen schon gleich gar nicht. Es geht vielmehr um die Verbindung von Software Engineering mit Projektmanagement unter besonderer Berücksichtigung des RUP mit Exkursionen zum V-Modell und anderen Software-Standards.
Ob Ihnen das Buch gefallen und dann auch nutzen wird, hängt davon ab, ob Sie sich gerne angesprochen fühlen. Gerhard Versteegen führt Sie im emotionalen (eine Seite ohne Ausrufezeichen ist die Ausnahme) Plauderton ("Bereits in meinem ersten Buch ... habe ich vor über vier Jahren ...") durch seine Erfahrungen aus zahlreichen Softwareprojekten und aus seiner Beschäftigung mit Vorgehensmodellen. Wenn Sie selbst Informatiker sind und Sie Verantwortung in einem Softwareprojekt haben, wird Ihnen der Stil der direkten Ansprache vermutlich gefallen und Ihre Hemmschwellen zur Akzeptanz der Inhalte reduzieren. VertreterInnen anderer Fachgebiete könnten sich hingegen ein wenig ausgegrenzt fühlen. Sogar eine gewisse Arroganz gegenüber den problembeladenen Software-Ingenieuren könnte sich bei der Lektüre einstellen.
Es handelt sich also um ein Insider-Buch. Sozusagen Informatiker unter sich, die mit den Tücken des Kunden, des Teams und der Technik kämpfen.
Nun zum eigentlichen Inhalt des Buchs:
Kapitel 1 startet mit kurzen Vorstellungen des Rational Unified Processes und des V-Modells. Alsdann gerät es zu einen Gewaltmarsch durch alle Aspekte der Projektleitersituation. Anforderungen an seine Persönlichkeit und Führungsqualitäten werden diskutiert, vor allem aber die vielfältigen Untiefen und Klippen der langen Fahrt zum Ergebnis. Hierzu gehören die beständigen Änderungswünsche genauso wie Personalfluktuation oder der rasante technologische Fortschritt.
Für's Gemüt und weniger für den Verstand ist das zweite Kapitel, in dem der Autor über die branchenspezifischen Gefahren und Probleme von Softwareprojekten berichtet. Dabei sollte "Gemüt" nicht falsch verstanden werden: Es geht darum, die intuitive Wahrnehmung für weiche Faktoren zu schulen, die überraschend schnell zu harten Hindernissen für den Projekterfolg werden können. In meinen Augen ist dies vielleicht sogar das stärkste Kapitel des Buchs.
Anders verhält es sich bei Kapitel 3, das der Autor selbst für das zentrale hält. Dem kann ich nicht zustimmen. Gerhard Versteegen fällt wie ein Kindergartenkind auf die trivialste Falle der Software-Industrie herein: Er glaubt durch die Beschreibung von MS Project Projektmanagement-Methoden vermitteln zu können. "Solchem Blödsinn lässt sich eigentlich fachlich nicht mehr viel entgegensetzen" (S. 13), möchte man da dem Autor dessen eigenen Worte aus einem anderen Zusammenhang heraus gerne entgegenschleudern. Da er an besagter Stelle aber fortfährt: "doch sollte man die Geduld nicht verlieren ..." möchte auch ich Verständnis für dieses Vorgehen äußern. Schließlich entspricht es dem weit verbreiteten Niveau, dass Projektleiter statt einer Ausbildung nur ein Werkzeug erhalten. (Überlegen Sie mal: Würden Sie sich von einem Informatiker operieren lassen, nur weil er ein Skalpell geschenkt bekommen hat? Aber Projekte soll er mit einem Programm managen ...)
Oh, jetzt hätte ich vor lauter Ärger fast die anderen Teile des dritten Kapitels überschlagen. Hier reihen sich ohne erkennbare Verbindung das Lob des Projekttagebuchs, ein wenig Risikomanagement, die grob vereinfachte Zeitplanung mit den Meilensteinen des RUP, Management by Commitment, Vergabe von Unteraufträgen und Programmierrichtlinien aneinander.
Empfehlenswerter, wenn auch elementar ist wiederum Kapitel 4, das sich mit dem Berichtswesen und dem Reporting beschäftigt. Die Kommunikation mit dem Kunden und Management über den Fortschritt des Projekts fällt erfahrungsgemäß Fachleuten schwer. Hilfreich sind da die Hausmittel und Vorgehensweisen, die der Autor beschreibt. Wenn denn Autor und Springer-Verlag wenigstens selbst die deutsche Sprache beherrschen würden! Der Plural von "Status" ist nun mal ebenfalls "Status", und zwar mit langem "u". (Wer es mir nicht glaubt, möge bitte im Fremdwörterlexikon nachschlagen. Status und Passus haben die Pluralendung "-us", da sie nach der lateinischen u-Deklination gebeugt werden.) Aber auf Seite 154 finden wir: "Zu unterscheiden sind verschiedene Stati". Als Informatiker werden Sie zum Glück auch von den anderen sprachlichen Holprigkeiten nicht all zu viel merken, aber anscheinend kann sich selbst ein Springer-Verlag kein anspruchsvolles Lektorat mehr leisten. Zum Glück geht es inhaltlich interessant weiter: Projekt kontra Linie, Führung ohne Disziplinarverantwortung und Umgang mit dem Ergebnisdruck sind Thema eines beim Berichtswesen integrierten Exkurses.
Weiter geht es im Kapitel 5 mit angeblich großen Softwareprojekten. Sie haben richtig gelesen, ich habe "angeblich" geschrieben. Denn was wir da lesen lässt einen entweder an der Realität großer Softwareprojekte oder an der Kompetenz des Autors zweifeln. Nun war Prof. Dr. Bernd Hindel in einem für IT bekannten Großkonzern und in den Geschäftsführungen mittelständischer Sofware-Unternehmen. Es ist also eher anzunehmen, dass deutsche Großprojekte im Softwarebereich tatsächlich so dilettantisch geführt werden, wie hier beschrieben (Autobahnmaut? Arbeitslosengeld? ...). Kann es denn wirklich sein, dass jedes neue Projekt ohne Vorlage von Grund auf neu geplant wird? Nehmen wir als Vergleich den Anlagenbau, da ist nun wirklich jede Großturbine etwas völlig neues und einzigartiges. Aber selbstverständlich greift da der Projektmanager in die Vorlagenkiste und passt den Standardplan inklusive Zeit- und Aufwandsschätzungen an den nächsten Auftrag an. Und mit MS Project wird man bei echten Großprojekten nicht wirklich glücklich werden, da gibt es z.B. OPX2, Planta, Primavera, um nur einige adäquate Tools anzuführen. Meine Empfehlung: Lesen Sie dieses Kapitel als Einführung in systematisches Projektmanagement für kleine und mittlere Projekte. Die Softwareindustrie ist für Großprojekte noch nicht reif.
Zu guter Letzt geht es endlich doch noch um Prozesse! In Kapitel 6 wird das obligatorische Praxisbeispiel durchgekaut, das Verlage immer in Projektmanagementbüchern haben wollen, warum ist mir schleierhaft. Ich habe es erst gar nicht gelesen. Ich finde nämlich Golf nicht wirklich prickelnd, erst recht nicht ein GPS-System für Golf-Cars. Wenn es um fiktive Praxisbeispiele geht, ziehe ich doch lieber Tom deMarco vor.
