Die Chronik eines Projektes

Es war ein sehr aussichtsreiches Projekt. Vielversprechend, anspruchsvoll, innovativ und zukunftssicher, alles in .NET. Die entstehende Software sollte weltweit eingesetzt werden. Klasse... Wer träumt nicht von solch einem Projekt. Die beteiligten Entwickler sind fähige Leute im .NET-Umfeld. Sie können jedes Problem lösen. Das Projekt begann auf einer grünen Wiese. Sprich, man konnte alles selbst designen, planen und entwickeln. Es gab kaum technische Vorgaben.

Heute redet man über dieses Projekt nur noch mit Anwälten und versucht so viel Schadensersatz wie möglich herauszuholen. Alle sind enttäuscht, jeder sucht bei jedem die Schuld und alle sind unzufrieden… Was war passiert????

Die Entwickler sind fähige Leute, die in .NET alle möglichen Probleme lösen können. Technisch gesehen war das Projekt also handhabbar. Bei diesem Projekt arbeiten die Entwickler direkt mit dem “Kunden”. Diese Entwickler bzw. Programmierer sind normalerweise Angestellte, die von irgendeinem Projektleiter gesagt bekommen, was sie machen sollen und vllt. auch wie sie es machen sollen. Das oben angesprochene Projekt war ein Projekt auf selbstständigen Basis mit direktem Kundenkontakt… Und da ist auch schon das erste Problem.. Der “Kunde”. Eine ominöse Person oder Institution, die viele tolle Ideen hat aber leider oft nicht selbst genau weiß, was sie will. Wenn dann noch die eigentliche Leitung des Projektes gänzlich versagt, ist das Projekt zum Scheitern verurteilt… Egal wie gut die Entwickler sind. Ab einer bestimmten Größenordnung eines Projektes ist eine gute strukturierte Planung einfach unabdingbar. Ansonsten weiss niemand, was er machen soll. Die Entwickler sind Anfangs super motiviert und bauen und machen was das Zeug hält.. Obwohl der Kunde mehrfach pro Monat ein Release erhält, kommt erst nach langer langer Zeit heraus, dass das meiste, was die Entwickler tolles gebaut haben, gar nicht das ist, was der Kunde wollte. Wie kann sowas passieren? Hat sich der Kunde das alles nicht angeschaut? Oder gab es einfach nur zu wenig oder falsche Kommunikation? Hat der Kunde gedacht, “Na die Entwickler da machen das schon…”?

Ich wurde in das oben genannte Projekt geholt, weil die Anforderungen die Entwicklungskapazitäten überstiegen. Schon nach ein paar Tagen habe ich moniert, dass die Prozesse in diesem Projekt äußerst ungünstig ablaufen und dass das später zu großen Problemen führen kann. Der Kunde, der eigentlich nur Mittelkunde ist, redet ab und zu mit dem echten Endkunden (eine große Firma) und redet dann wieder ab und zu mit den Entwicklern. Natürlich alles via MSN. Ich sagte, Leute, lasst uns Dokumente erstellen, wo wir explizit aufschreiben, was wir entwickeln werden. Lasst uns aufschreiben, wie wir die Aufgabenstellung verstanden haben. Wenn der Kunde das nochmal gegenliest, dann kommen vllt. hier und da noch Dinge heraus, die wir übersehen oder falsch verstanden haben. Ich bekam als Antwort: “Nico, für Dokumente haben wir keine Zeit. Wir arbeiten agile. Da braucht man keine Dokumente. Die sind im Moment des Schreibens schon veraltet.” Ja. Da ich nur nebenläufiger Entwickler war und kein Projektleiter, habe ich zwar immer wieder betont, dass ich denke, dass diese Arbeitsweise irgendwann ein Nachspiel haben wird, habe mich aber noch den Prozessen (falls man es so nennen kann) untergeordnet und habe einfach nach besten Wissen und Gewissen entwickelt.

Ich schreibe diesen Blog-Eintrag, weil ich euch allen einen Rat aufgrund dieser Erfahrungen geben möchte. Es mag vllt. komisch klingen, aber es ist ein gewisser Lernprozess, mit dem Phänomen “Kunde” umzugehen. Das bedeutet: es gibt unterschiedliche Arten von Kunden. Die einen kommen mit einem 800-Seiten Pflichtenheft an, was entweder die IT-Abteilung oder andere IT-Spezialisten entwickelt haben. Dieses Pflichtenheft beantwortet alle Fragen und man braucht einfach nur noch losentwickeln. Dies ist sehr schön, aber auch sehr selten der Fall.

Die gänzlich andere Art von Kunden stellt sich hin und sagt: “Herr Franze, ich habe hier dieses Problem. Machen sie, dass es geht!” Dieses Satz “Machen Sie, dass es geht” habe ich schon öfter gehört. An dieser Stelle muss man wieder unterscheiden.

Die einen meinen damit, dass sie nur das Problem kennen, aber keine Ahnung haben, wie die Lösung aussehen könnte. Dafür bin ich ja dann da. Ich (respektive ihr, die das hier lest) seit die Entwickler der Lösung. Das bedeutet, dass ihr nicht einfach nur irgendein kleines Progrämmchen programmiert, ihr versetzt euch in die Lage des Kunden, versteht ihn und sein Problem und entwickelt mit ihm gemeinsam eine Lösung.

Die anderen meinen mit diesem Satz, dass sie glauben, wie die Lösung aussieht, und wenn sie selbst ein wenig C# oder VB könnten, könnten se das schnell selbst programmieren. Dass da vllt. ein Jahr Entwicklungszeit dahinter steht und man nebenbei noch Client-Server-Wissen sowie Datenbank-Knowhow braucht, weiß natürlich am Anfang keiner. Der Kunde steht eigentlich schon am Ziel und denkt, dass er uns Entwickler mit einigen kurzen Sätzen auch zum Ziel bringen kann. Damit wir die entsprechende Lösung genauso bauen können, wie er sich das vorstellt. Leider klappt das nur oft so nicht, weil der Kunde vllt. keine technische Erfahrung hat oder oft aneinander vorbeigeredet wird. Der Kunde ist am Ziel und wundert sich, dass wir (der Entwickler) da nicht auch einfach ankommen…

Zusammenfassung:

Was ich damit sagen möchte ist das Folgende. Wenn ihr ein Projekt für einen Kunden entwickelt, (ich rede hier nicht von Hello-World-Applikationen, sondern vllt. mit Client, Server und Datenbank und mit einer Dauer von ca. einem Mann-Jahr), dann versucht strukturiert vorzugehen. Das bedeutet, setzt euch hin und plant und entwickelt das Projekt, vorerst so weit es geht auf dem Papier (oder in Word oder so). Diese Dokumente bilden eine gemeinsame Basis. Der Kunde erklärt euch irgendwas. Ok, nehmt das mit ins Dokument auf, so wie ihr es verstanden habt. Wenn der Kunde das später noch einmal liest, dann sagt er vllt. “Ähh, so hab ich das aber nicht gemeint… Das sollte doch so und so sein..”. Wenn der Kunde keine Lust hat, das Dokument nochmal zu lesen, dann kann euch niemand einen Vorwurf machen. Ich sage nicht, dass ein solches Dokument immer 100%ig vollständig und korrekt ist (das ist es nie), aber es gibt doch schon viele Dinge, die im Vorfeld auffallen können und die man auch einfach schon auf dem Papier durchdenken kann. Vor allem Dinge, die nur nebenbei erledigt werden müssen, aber trotzdem essentiell sind. Zum Beispiel Tests, oder ein ordentliches Setup-Paket. Wie wird die Software später installiert? und wie kommen Initialdaten in die Datenbank? Wie ist der Ablauf im Programm. Von welchen Masken aus kommt man auf welche und wann sind wie welche Kommandos möglich?

Dieses Dokument verleiht euch auch sehr viel Sicherheit. Später, wenn der Kunde sagt, dass er das so alles gar nicht gemeint hat, könnt ihr das Dokument herausholen und sagen: “Guck mal, so steht’s hier, und so hab ichs gebaut…” Wenn dem Kunden später auf einmal einfällt, dass die Software doch mandantenfähig sein soll, und ihr somit in alle 500 Tabellen nochmal eingreifen müsst und einiges an der Businesslogik der Software ändern müsst, dann könnt ihr ebenfalls das Dokument herausholen und sagen: “Äh, ich hab in dem Dokument gerade mal nach dem Wort Mandant gesucht und es nicht gefunden. Es wurde im Vorfeld nichts von Mandanten gesagt. Deswegen kostet diese Anpassung nun leider xxx € mehr und von der Zeit her verschiebt sich das Ende des Projektes um zwei Wochen”. Bei solchen Aussagen ein Schwarz-auf-Weiss-Dokument zur Hand zu haben ist echtes Gold wert. Es gibt Kunden, die haben ganz viele tolle Ideen, Träume und Wünsche, die man auch alle gerne umsetzen kann, aber leider wird dabei immer der Kosten- und auch der Zeitrahmen unangetastet gelassen. Sprich, die Entwickler sollen mal eben schnell nebenbei hier ein Haufen Features einbauen, aber es darf keine Zeit und somit auch kein Geld kosten. Das Resultat ist, dass die Qualität leidet. Und wenn die Software den ganzen Tag nur abstürzt, hat auch niemand gewonnen.

So. Hier unten zeige ich nochmal das “magische Dreieck”, welches symbolisiert, dass Zeit, Kosten und Qualität immer zusammenhängen. Man kann nicht eines verändern, ohne die anderen Punkte unangetastet zu lassen. Erhöht man die Qualität, so kostet das Zeit und somit Geld. Spart man an Zeit, weil alles schnell schnell fertig werden muss, so verringert das die Qualität, und im Endeffekt steigert das sogar die Kosten. Weil später einen Bug finden, dauert länger, als es gleich richtig zu machen. Natürlich ist niemand mehr in der Lage, diesen Fehler den Problemen zu Beginn des Projektes zuzuschreiben. Es ist halt einfach nur ein fataler Bug in der Software.

Magisches Dreieck für Kosten – Zeit – Qualität:
Quelle: http://www.realtime-solutions.de/softwareentwicklung/projektmanagement/index.php

wirkliche Zusammenfassung:

Ich appelliere an alle Softwareentwickler und Programmierer, die etwas von sich halten. Nehmt euch die folgenden Sätze zu herzen.

“Qualität zahlt sich aus”

“Qualität bemerkt man immer erst dann, wenn sie nicht da ist”

Arbeitet ordentlich, macht nichts schnell schnell, das geht eh nur nach hinten los (wie gesagt, wir reden hier nicht von einem winzigen hello-world-Projekt) und versucht hier und da immer mal auch ein wenig Dokument zu produzieren, wo drin steht, was ihr wie macht. So ist es auch anderen Entwickler möglich, sich ggf. in eure Software einzuarbeiten.