Seit Jahren schon bin ich in diversen Projekten eingebunden. Die Themen reichen von Web2.0 bis ERP, doch eines haben alle gemeinsam, die Art und Weise der Realisierung. Immer wieder ist geplant, konzeptioniert und gesteuert worden. Und immer wieder ist der Termin verpasst worden. Und wieder sind Kunden oder Auftraggeber verärgert. Und wieder stehen die Entwickler wie begossene Pudel da.

Man sollte schon meinen, dass in den letzten 20 Jahren der Wunsch nach mehr Zufriedenheit auf ganzer Linie immer größer geworden ist. Viele Beiträge, so wie dieser, in den Foren oder Blogs suggerieren einem das auch. Insofern verwundert es doch, dass trotz allem noch so viele von Misserfolgen berichten.

Ich möchte mich mit diesem Post auf die Suche  nach einer möglichen Ursache machen, denn ich hab da so einen Verdacht. Doch zunächst die berühmte IST-Aufnahme.

IST (bzw. IST-Analyse)

Der WunschAm Anfang eines jeden Projektes steht die Idee oder vielmehr ein Wunsch, formuliert vom Kunden. Dieser Wunsch kann als Idealbild der Lösung betrachtet werden, aber er ist nicht greifbar. Damit er von Entwicklern erfasst werden kann, wird eine Anforderungsspezifikation geschrieben. Das ist der erste Schritt der Wunschtransformation. Das Idealbild ist zum ersten mal verändert worden und ganz sicher auch schon das erste mal interpretiert worden. Kurz, es ist nicht mehr das Bild, das der Kunde von der Lösung hat. Dumm nur, dass ihm und den anderen Beteiligten das nicht bewusst ist.

Die Anforderungsspezifikation bestimmt ab nun an den Alltag der Entwickler, Architekten, Tester, Product Manager und vielen anderen mehr. Sie bildet die Grundlage für die Formulierung von Aufgabenpaketen und Schätzungen. Bei jeder Umwandlung von Anforderung (vormals Wunsch) zu Aufgabenpaket oder Schätzung entsteht wieder Schwund an der Wunschlösung. Hier ein Beispiel, das jeder nachvollziehen kann:

Wunsch: „Ich möchte, dass einem Mitarbeiter eine Adresse zugeordnet werden kann.“
Anforderung: „Zuordnung von Adressdaten zu einem Mitarbeiter“
Aufgabenpaket: „Speichern von Adressdaten zu einem Mitarbeiter“
Schätzung: 2PT

Das kann jeder nachvollziehen – oder.

So wenig und klein dieses Beispiel auch erscheint, ist es doch Sinnbild für das Große und Ganze, für das eigentliche Problem. Einige stimmen mir jetzt zu, andere wundern sich und sehen kein Problem. Die, die mir zustimmen sind schon oft in dieser Falle gewesen und haben des Pudels Kern entdeckt. Für die Anderen möchte ich mit einer Frage auf das Problem hinweisen: „Aus welchen Daten besteht denn die Adresse?“ Und weil es so schön ist, setze ich noch eine Frage nach um den Fokus zu schärfen: „Sollen die Daten auch geändert werden können?“

Hoffentlich erkennt der ein oder Andere nun den besagten Kern des Problems, es fehlen Informationen. Und ohne diesen Informationen ist das Geschätzte von vornherein ein „magic value“. (Abgesehen davon, dass auch ich kein Verfechter der Schätzungen bin, siehe hier)

Sollten bis hierhin zusammen mit dem Kunden keine Gegenfragen geklärt worden sein, so ist das Projekt ab jetzt zum Scheitern veruteilt und es wurde noch nicht mal eine Zeile Code geschrieben.

Der Schrei

Aaahhhh – es ist Zeit in Panik auszubrechen.

Ja liebe Entwickler, ihr seid nicht Schuld an der Misere, oder doch? Wer hat den vergessen zu fragen, aus welchen Daten die Adresse besteht und ob die Daten geändert, gelöscht oder sogar mehrere Adressen zugeordnet werden sollen? Wer hat vergessen zu fragen, wie das im Prozess der Gesamtlösung von Statten gehen soll, das mit der Adresszuweisung? Ach so, das war der Andere, der die Anforderungsanalyse geschrieben hat, der hat’s vergessen. Gut so, Kopf aus der Schlinge genommen, durchatmen.

Das schmeckt bitter, da bleibt ein komisches Gefühl. Und recht so, es muss ein schlechtes Gewissen bleiben, denn in der Firmenphilosophie steht doch drin, dass ihr ein Team seid und dazu gehört auch:  „Unterstütze deine Kollegen, wo und wann du kannst“ Also wäre es an euch gewesen, dem Anforderungsanalysten die Fragen zu stellen.

SOLL (bzw. Ideal)

Licht am Ende des Tunnels

Wenn ich oben vernünftig geschrieben habe, dann sollte nun erkennbar sein, was ich jetzt als SOLL-Zustand beschreiben möchte.

Da der Kunde in den meisten Fällen gar nichts von der Komplexität von Software weiß, sind wir dazu verpflichtet, ihm dieses bildlich zu machen, indem wir nachfragen, wie er sich seinen Wunsch genau vorstellt. Je mehr wir mit ihm darüber reden, desto mehr Wunschtransformation findet statt. Und was ein richtig guter Nebeneffekt ist, er nimmt Abstand von Killerfeatures, die den Koplexitätsgrad ins unermessliche steigen lassen. Wirklich, das ist so. Und wenn er sich von diesen Features nicht verabschiedet, dann kennt er zumindest die Problemzonen des Systems und ist sich bewusst darüber, dass die Lösung nicht mal eben schnell erstellt ist.

Also ist in einer idealen Welt die Situation so, dass der Kunde seinen Wunsch äußert und das Team, das die Lösung umsetzen soll, ganz eng mit dem Kunden zusammen die Anforderungen hinterfragt und klärt.

Klar, verstanden, los gehts…

Aber nicht doch, das ist zu einfach, denn ich habe noch Hausaufgaben auf. Ich behaupte nämlich, dass es noch etwas gibt, das in dieses ideale Bild eingebaut werden muss. Bisher habe ich nur die Grundierung beschrieben, es fehlen noch Motiv, Bildkomposition, Material und die Farben.

Die nun noch fehlenden Punkte möchte ich in weiteren Posts ausfüllen, doch zunächst soll hierüber diskutiert werden. Unter Umständen habe ich ja eine völlig falsche Sicht auf die aktuelle Projektlage.

~Jan

Advertisements