Wann Prozesse und Tools nutzlos sind

Stefan parkte den Wagen, stieg aus dem Auto und ging die 5 kleinen Treppenstufen zu seinem Haus hinauf. Müde öffnete er die Tür und hängte seine Jacke an die Garderobe. Anschließend ging er ins Wohnzimmer und ließ sich mit einem Seufzer in den Sessel fallen.

„Schwerer Tag heute?“, fragte ihn Johanna, seine Frau.

Stefan verzog das Gesicht. „Das kannst Du laut sagen!“, stöhnte er.

„Möchtest Du darüber reden oder soll ich Dich lieber in Ruhe lassen?“.

„Nein, ist schon Ok. Heute gab es wieder eins dieser unerfreulichen Treffen mit unserem Auftraggeber. Wir sind nicht rechtzeitig mit der Software fertig geworden und unser Ansprechpartner, Herr Krawinger, ist sauer. Ich kann ihn ja auch verstehen: Wir halten unsere Termine nicht ein und für ihn sieht es so aus, als ob wir keine vernünftige Arbeit leisten. Und das Ganze passiert ja nicht zum ersten Mal. Statt zu prüfen was wir in Zukunft besser machen können wird dann lieber nach Schuldigen gesucht. Ich als Projektleiter stehe dann natürlich besonders in der Kritik.“

„Wenn das Problem schon länger besteht, was hast Du dann dagegen unternommen?“, fragte ihn Johanna.

„Ich habe Clever & Smart Consulting damit beauftragt, eine Lösung zu finden. Die haben sich unser Projektmanagement ganz genau angeguckt und dann den Softwareentwicklungsprozess entsprechend angepasst. Ein solcher Prozess beschreibt die verschiedenen Phasen und deren Reihenfolge bei einer Softwareentwicklung und legt Rollen sowie Verantwortlichkeiten fest. Das ist sozusagen wie das Spielsystem einer Fußballmannschaft. Jeder hat seinen festen Platz und seine Aufgabe, und wenn alle gut zusammenarbeiten, führt das auch zum Erfolg. Wir entwickeln jetzt iterativ, d.h. wir nehmen uns kleine Einheiten vor, entwerfen und entwickeln diese komplett und benutzen das, was wir dabei über den fachlichen Hintergrund lernen für die nächsten Aufgaben. Dadurch sollte unsere Terminplanung sich eigentlich stabilisieren, zumindest in den späteren Phasen des Projektes. Aber irgendwie hat sich dadurch nicht allzu viel verändert. Im Wesentlichen haben wir immer noch die Probleme, die schon von Anfang an bestanden. Um ehrlich zu sein, bin ich im Moment ziemlich ratlos.“

„Was würdest Du denn als Dein größtes Problem ansehen?“, wollte Johanna wissen.

„Der Kunde kann uns einfach nicht genau genug beschreiben, was wir programmieren sollen. Meistens fehlen wichtige Informationen in den Anforderungsdokumenten. Das ist wie eine Landkarte mit lauter weißen Flecken: Wenn Du unbekanntes Terrain betrittst, triffst Du auf einmal auf unerwartete Hindernisse. Einige davon kannst Du vielleicht mit wenig Aufwand umgehen, bei anderen dagegen musst Du umkehren und einen neuen Weg suchen. Genau so ist das auch beim Programmieren. Darunter leidet dann das komplette Projektmanagement: Aufwandsschätzungen sind zu gering, Kosten zu hoch und mit den Terminen kriegen wir dann natürlich auch Probleme.“

„Ah!“, sagte Johanna.

„Lass mich raten, ist das ein ‚Ah, kein Wunder, so kann das auch nichts werden!‘?“

„Stimmt genau“, lächelte sie.

„Sieh an, und warum nicht?“

„Warum bekommen Kinder in der Grundschule keinen Taschenrechner?“, fragte sie zurück.

„Wie bitte?!“

„Warum bekommen Kinder in der Grundschule keinen Taschenrechner?“, fragte Johanna noch einmal.

„Ich habe Dich schon verstanden, aber was hat das mit meinen Problemen zu tun?“, wunderte sich Stefan.

„Nun, Du hast gesagt, dass ihr neue Tools verwendet. So ein Taschenrechner ist doch auch ein tolles Tool. Damit können die Kinder viel schneller rechnen. Trotzdem wird er in der Grundschule nicht eingesetzt, und zwar weil er kein Verständnis vermitteln kann. Ein Taschenrechner wird Dir niemals erklären können, warum es geschickter ist, 2*25 statt 25*2 zu rechnen. Er wird außerdem verhindern, dass Du für eine schwierigere Aufgabe im Kopf Überschlagsrechnungen machst. Und bei Textaufgaben ist er auch keine große Hilfe weil es da erst einmal darum geht, aus der Aufgabenstellung eine mathematische Darstellung zu entwickeln. Prozesse und Tools sind vor allem organisatorische Hilfsmittel. Und sie sind gut, um organisatorische Probleme zu lösen.“

„Aber sie taugen nicht viel wenn man ein inhaltliches Problem hat...“, ergänzte Stefan den Gedanken.

„Genau, bei inhaltlichen Problemen muss man die Ursache erkennen und verstehen. Wenn Du das geschafft hast, kann ein Tool oder ein neuer Prozess durchaus sinnvoll sein. Aber vorher nützen sie nicht viel.“

„Wenn ich das auf mein Projekt übertrage heißt das, ich muss mir anschauen, welche Informationen wir auf jeden Fall vom Kunden benötigen, damit unser Projektmanagement verlässlicher wird. Ich könnte z.B. eine bestehende Anforderung nehmen und um all die Dinge ergänzen, welche wir erst im Laufe der Entwicklung herausgefunden haben. Dann versuche ich Muster und Fragen zu entwickeln, mit denen wir diese fehlenden Informationen beim nächsten Mal gleich zu Beginn ermitteln können. Wenn wir das schaffen, dann werden wir auch ein viel zuverlässigeres Projektmanagement hinkriegen.“

Ein breites Grinsen erschien auf Stefan’s Gesicht. „Du bist unglaublich, weißt Du das?“.

Johanna zwinkerte ihm zu: „Ja, ich weiß!“

Am nächsten Tag fuhr Stefan beschwingt in die Firma. Er machte sich eine Tasse Kaffee und setzte dann ein Meeting mit seinem Entwicklerteam um 10:00 Uhr an. Pünktlich trafen sich alle im Besprechungsraum.

Stefan ließ kurz den Blick in die Runde schweifen. Sein Team bestand aus drei Entwicklern, die zur Zeit für die Software der Videothek ‚Video pur!‘ zuständig waren.

Andreas war ein Seniorentwickler und mehr oder weniger der Kopf der Gruppe. Er war Ende 40 und arbeitete bereits seit über 10 Jahren für die Firma. Aufgrund seiner Erfahrung traf er meistens die kritischen Entscheidungen und wurde auch häufig von den anderen um Rat gebeten.

Boris war Mitte 30 und vor 5 Jahren aus der Ukraine nach Deutschland gekommen. Inzwischen hatte er sich gut eingelebt und arbeitete seit 18 Monaten mit Andreas zusammen.

Natalie hatte gerade ihr Studium beendet und war vor drei Monaten neu ins Team gekommen. Sie schien gut mit den anderen beiden auszukommen und war fleißig dabei, sich in die neue Materie einzuarbeiten.

Stefan räusperte sich:

„Ihr habt sicherlich schon von dem Treffen gestern mit Herrn Krawinger von ‚Video pur!‘ gehört. Na ja, was soll ich sagen: Ich hatte schon entspanntere Meetings.“

Stefan zog eine leichte Grimasse und die Teammitglieder grinsten vorsichtig. Ein bisschen unwohl fühlten sie sich schon, immerhin hatte der Flurfunk schon gemeldet, dass es einigen Ärger gegeben hatte.

„Es geht mir nicht darum, mit dem Finger auf jemanden zu zeigen und zu sagen ‚Du bist Schuld!‘“, fuhr Stefan fort, „aber ich möchte sehr gerne solche unangenehmen Situationen in Zukunft vermeiden. Schließlich ist das nicht unbedingt ein Aushängeschild für die Firma, wenn wir nicht in der Lage sind, unsere Zusagen einzuhalten.

Gestern hatte ich ein sehr interessantes Gespräch mit meiner ‚häuslichen Beraterin‘ und sie hat mich auf einen wichtigen Punkt hingewiesen: Solange wir nicht die Ursache unserer Probleme verstehen, werden uns neue Softwareentwicklungsprozesse und Tools auch nicht weiterbringen. Deshalb sitzen wir jetzt hier. Ich möchte gerne mit Euch erarbeiten, wo genau die Defizite bei der Umsetzung der Anforderungen liegen und was wir in Zukunft dagegen machen können. Dazu sollten wir uns vielleicht eine Anforderung vornehmen, welche uns viele Schwierigkeiten bereitet hat.“

„Das ist nicht schwer“, sagte Boris spontan. „Nehmen wir doch einfach den letzten Change Request für die Ergänzung des Erscheinungsjahres des Films. Da haben wir praktisch alles zweimal entwickelt.“

„Mindestens!“, stöhnte Andreas.

„Ok, dann schauen wir uns doch einmal die Beschreibung dafür genau an.“, sagte Stefan. Er öffnete das zugehörige Dokument und projizierte es auf die Leinwand:

„Hmm, sieht eigentlich ganz simpel aus. Inwiefern weicht die jetzige Implementierung von der Beschreibung ab?“, fragte Stefan die Anderen.

„Das Hauptproblem lag darin, dass die Angabe des Erscheinungsjahres allein nicht ausreichend war.“, sagte Boris. Er hatte diesen Change implementiert. „Es musste auf jeden Fall noch der Monat ergänzt werden. Das hat der Kunde aber erst gesehen, als wir die Entwicklung schon abgeschlossen hatten und es in den Abnahmetest ging.“

„In Ordnung“, sagte Stefan, „hat jemand einen Vorschlag, wie wir den Kunden dazu bringen sich vorher über so etwas Gedanken zu machen?“.

Eine Weile grübelten alle vor sich hin. Dann meinte Andreas: „Ich glaube, wir gehen das Problem von der falschen Seite an. Man braucht ein gewisses Know-How, um eine gute Anforderung schreiben zu können.

In der Software-Analyse geht es darum, zentrale Bestandteile einer Anwendung zu identifizieren und sie zueinander in Beziehung zu setzen. Auch ein Softwareentwickler braucht Zeit und Erfahrung, um das zu lernen. Wir können nicht wirklich erwarten, dass ein Kunde, der ansonsten mit Softwareentwicklung nichts am Hut hat, die nötigen Qualifikationen dafür besitzt.

Nehmen wir als Beispiel das Erscheinungsjahr des Films. Laut Anforderung sollte es bei den Daten für den Ausleihvorgang hinterlegt werden. Mit entsprechend geschultem Blick sehen wir schnell, dass es dort eigentlich nicht hingehört weil das zu Redundanzen führt und dass man es besser bei den Filmdaten speichert. Der Kunde dagegen ist fokussiert auf sein aktuelles Problem und kümmert sich nicht um Redundanzen. Deshalb denke ich, dass wir selbst dafür verantwortlich sein sollten die Anforderungen zu definieren.“, schloss er. „Natürlich muss der Kunde sein Fachwissen beisteuern, aber wir haben das entsprechende Know-How für die Analyse und wissen, worauf wir achten und wo wir nachhaken müssen.“

Stefan machte sich eine entsprechende Notiz. „Boris, du hast den Change implementiert und weißt am meisten darüber. Hast Du eine Idee, wie man von vornherein erkannt hätte, dass der Monat fehlt? Wonach hätten wir suchen müssen?“.

„Wir müssen nach dem Zweck fragen, nach der ursprünglichen Motivation für den Change.“, antwortete Boris nach einer Weile. „Der Kunde hat uns zwar gesagt, dass er die Information für einen Report benötigt. Aber das ist nicht seine eigentliche Motivation: Niemand entwickelt Reports, weil er so gerne einer Maschine zuguckt wie sie Papier bedruckt.

Der Zweck des Reports bestand darin herauszufinden, wie lange es, vom Erscheinungsdatum an gerechnet, dauert bis ein Film nicht mehr häufig ausgeliehen wird. Daraufhin kann man dann Maßnahmen treffen, z.B. entsprechende Rabatte für selten ausgeliehene Filme oder das Entfernen aus dem Lager. Sobald man diesen Hintergrund kennt, kann man viel besser überprüfen, ob die Vorschläge und Angaben des Kunden sinnvoll sind.“

„Genau!“, ergänzte Andreas, „der Kunde hat uns sozusagen schon seine eigene unvollständige Lösung beschrieben, statt erst einmal zu sagen welches Problem eigentlich gelöst werden soll. Das hat auch etwas damit zu tun, dass in der Anforderungsbeschreibung schon konkret auf Bestandteile der Anwendung Bezug genommen wurde. Man kann den Zweck einer Anforderung leichter erkennen, wenn der Kunde sein Problem beschreibt ohne auf technische Begriffe wie Datenbank, Eingabemaske, Report et cetera zurückzugreifen.“

„Ok“, sagte Stefan, „das macht Sinn. Also schlagt ihr vor, dass wir dem Auftraggeber eine Liste mit Richtlinien zur Verfügung stellen, die er für die Beschreibung seiner Anforderungen nutzen soll?“

„Nein, ich glaube das ist keine gute Idee!“, meldete sich Natalie zu Wort. „Ich denke, dass Anforderungen am besten im direkten Gespräch geklärt werden. Deswegen finde ich es sehr wichtig, sich persönlich mit den Fachexperten des Kunden zu treffen. Da können wir sofort jede Unklarheit ansprechen und klären.

Wie Andreas schon sagte, wir haben das Know-How für die Analyse und sollten ein solches Treffen leiten. Wir überlegen uns vorher, welche Informationen wir benötigen, also z.B. Zweck der Anforderung, beteiligte Daten und Formate sowie der Ablauf der betroffenen Geschäftsprozesse. Und dann erstellen wir daraus ein Dokument und der Kunde genehmigt es.“

Alle waren sich einig, dass dieses Vorgehen Sinn machte. Nach dem Treffen blieb Stefan noch eine Weile sitzen und protokollierte stichwortartig die Ergebnisse des Meetings. Er hatte dabei das gute Gefühl, sich auf dem richtigen Weg zu befinden.

Den Rest des Tages verbrachte er damit, eine Präsentation über das neue Verfahren zu erstellen, die er in den nächsten Tagen den beteiligten Entscheidungsträgern sowohl in seiner Firma als auch beim Kunden vorführte.

Schon die ersten Erfahrungen mit dem neuen Verfahren waren sehr ermutigend. Die Kunden nahmen es sehr positiv auf, bei der Definition der Anforderungen von Stefan’s Team unterstützt zu werden. Die Aufwandsschätzungen und damit auch das Projektmanagement stabilisierten sich deutlich. Auch wenn es immer noch vorkam, dass größere Fehler in der Anforderungsbeschreibung erst nach der Entwicklung gefunden wurden, nahm deren Häufigkeit sichtbar ab.

Im Laufe der nächsten 12 Monate verfeinerten Stefan und sein Team ihre Methode und erarbeiteten weitere Richtlinien für die Klärung von Anforderungen. Dabei stellten sie fest, dass es nicht nur inhaltliche Probleme zu bewältigen galt: Manchmal waren die Menschen ein viel größeres Problem.

Eine klare und eindeutige Kommunikation zwischen allen Beteiligten wurde zuweilen zu einer echten Herausforderung. Es gab sogar Situationen, in denen Stefan auf die Hilfe eines Kommunikationstrainers zurückgriff, um Konflikte in den Griff zu bekommen und konstruktive Gespräche zu ermöglichen.

Und hier endet die Geschichte – vorläufig.