Kolumne: .NET Soft Skills

Die Chronik eines Projekts
Kommentare

Dies ist der erste Teil einer Kolumne, die sich um technische oder auch mal nicht technische Themen rund um .NET und Visual Studio dreht. Heute starten wir mit einem nicht technischen Thema, das aber trotzdem alle Entwickler betrifft. Ein aussichtsreiches .NET-Projekt ist gestorben und alle fragen sich warum.

Sehr geehrte Trauergemeinde! Wir sind heute hier zusammengekommen, um das .NET-Projekt XY zu begraben. 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 aus dem .NET-Umfeld. Sie können jedes Problem lösen. Doch was ist passiert, dass wir heute hier versammelt sind?

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 via Anwalt und versucht so viel Schadensersatz wie möglich herauszuholen. Alle sind enttäuscht, jeder sucht bei jedem die Schuld und alle sind unzufrieden. Da die beteiligten Entwickler sehr erfahren waren im .NET-Bereich und so gut wie alle Probleme lösen konnten, war das Projekt technisch gesehen also handhabbar. Am reinen Fachwissen kann es also definitiv nicht gelegen haben.

Am Anfang war der Projektstart

Wie heißt es so schön: „Zeig mir, wie du dein Projekt beginnst, und ich sage dir, wie es endet.“ Ich wurde erst in das Projekt geholt, als man merkte, dass die Anforderungen höher waren als die Entwicklungskapazitäten. Schon nach einem Tag 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. Zuerst fiel mir auf, dass es keinen richtigen Projektleiter gab. Natürlich hatte man jemanden als Projektleiter eingesetzt, aber diese Person war Grafiker, die relativ wenig Erfahrung mit der Leitung eines Projekts hatte. Das zweite große Problem war die fehlende Struktur bzw. die fehlenden Prozesse in der Entwicklung. Die Entwickler, die normalerweise ihrem normalen Angestelltenjob nachgingen, waren es gewohnt, dass jemand das Projekt in die Hand nimmt, plant und ihnen sagt, was sie tun sollen. Der direkte Kundenkontakt und das selbstständige Leiten der Entwicklungsarbeiten waren ihnen fremd.

Ablauf des Projekts

Die Kommunikation zwischen den Mitarbeitern des Projektteams und den Kunden geschah größtenteils über MSN. Der Kunde sagte über MSN: „Du, kannste da nicht nochmal schnell‘ nen Button einbauen?“ Der Entwickler sagte: „Mhh, ja, kann ich, aber welchen Sinn der da haben soll, versteh ich nicht“. Das Ende vom Lied war dann irgendein Button, dessen Sinn niemand verstand. Der Kunde, mit dem die Entwickler redeten, war aber nur ein Zwischenkunde, und deshalb war es des Öfteren so, dass das, was der Zwischenkunde wollte, oft nicht dem entsprach, was der Endkunde sich vorstellte.

Ein Problem, das die fehlenden Prozesse mit sich brachten, waren die fehlenden Dokumente. Kaum etwas wurde schwarz auf weiß festgehalten – Ausnahme waren ein paar Zeilen MSN-History. Es gab einige zu Beginn formulierte Meilensteine, die aber ausschließlich aus der Sicht des Kunden formuliert wurden. Der erste oder zweite Meilenstein war beispielsweise „Fertiges Datenbankdesign inklusive aller Tabellen“. Dass ein Datenbankdesign eigentlich nie fertig ist und fast immer mit der Software wächst, konnte der Kunde natürlich nicht wissen.

Auf meine fast täglich geäußerten Zweifel bekam ich fast immer zu hören: „Nico, für Dokumente haben wir keine Zeit. Außerdem arbeiten wir doch agile. Da braucht man keine Dokumente. Die sind im Moment des Schreibens schon veraltet. Während du da Dokumente schreibst, kann ich schon viele viele Features einbauen.“

Da ich „nur“ Entwickler und kein Projektleiter oder Hauptentwickler war, habe ich zwar immer die fehlenden Prozesse moniert, habe mich dann aber doch den Prozessen (falls man diese überhaupt so nennen kann) untergeordnet und einfach nach bestem Wissen und Gewissen entwickelt. Ich versuchte, mich an meine Erfahrungen zu halten und einige Dokumente zu schreiben. Diese hat aber erstens niemand gelesen und zweitens meinten alle, dass ich der langsamste Entwickler des Teams sei. Die anderen bauten ein Feature nach dem anderen. Es kamen kaum irgendwelche Patterns oder Strukturen im Quellcode vor – Hauptsache viele Features.

Das Ende des Projekts

Die Zeit schritt unweigerlich voran und der Kunde schaute immer wieder einmal ins Release. Es gab viele Bugs. Viele „mal eben schnell“ implementierte Features wurden im Durchschnitt drei bis vier Mal nachbearbeitet. Der Kunde bemängelte weiterhin, dass überhaupt nicht alle Features aus den Meilensteinen in der Software sind und die Entwicklung schon weit über den Zeitplan hinaus vorangeschritten war. Die Entwickler versuchten sich zu verteidigen, denn sie hatten doch ganz viel gebaut, was vorher nirgends erwähnt war, aber nun doch noch ganz schnell mit rein musste. Daraufhin konterte der Kunde: „Ja was denn?“ Und die Entwickler versuchten sich hier und da an einige Dinge zu erinnern, aber da niemand etwas schriftlich festgehalten hatte, war das schwer. Und egal, was die Entwickler sagten, der Kunde sagte immer: „Na das war doch aber klar, dass wir das mit in der Software haben wollten“. Die Stimmung war am Boden, alle fühlten sich betrogen und kaum jemand wusste, wo denn nun das eigentliche Problem war.

Und was hätte man besser machen können?

Der Kunde weiß selten exakt, was er eigentlich will. Vor allem dann nicht, wenn er nur ein Zwischenkunde ist. Nicht umsonst gibt es unter den Entwicklern das geflügelte Wort: „Was der Kunde will, ist oft nicht das, was der Kunde braucht.“ Die Entwickler im angeführten Beispiel dachten aber: „Der wird schon wissen was er will“. Sie waren dies aus ihrem täglichen Job gewohnt.

Bevor man ein Projekt startet, braucht man immer eine Spezifikation. Diese beinhaltet Abläufe in der Software – welche Rolle kann was in welcher Maske bewirken und wie wirken sich Änderungen auf andere Masken aus? Hier müssen Use Cases definiert und Rollen festgelegt werden. Ganz wichtig ist es außerdem, dass Änderungen nicht mal eben schnell nebenbei implementiert werden, da man bei größeren Projekten kaum die Nebenwirkungen abschätzen kann. Es bedarf eines Änderungsmanagements, das aus Entwicklern und Projektleitern aller Softwarebereiche besteht, die zusammen versuchen, das Ausmaß abzuschätzen.

Fazit

„Qualität zahlt sich immer aus.“ Ordnung muss eben doch sein. Deshalb sollte bei der Projektentwicklung für einen Kunden strukturiert vorgegangen werden. Das bedeutet konkret: Setzt euch hin, plant und entwickelt das Projekt, soweit es geht auf dem Papier (oder mit entsprechender Modellierungssoftware). Diese Dokumente bilden eine gemeinsame Basis. Wenn der Kunde irgendetwas erklärt, nehmt es mit in das Dokument auf, so wie ihr es verstanden habt. Wenn der Kunde es später liest, stellt er eventuell fest, dass er es so aber gar nicht gemeint hat und erklärt es erneut und hoffentlich so, dass es auch für euch verständlich ist. Wenn der Kunde keine Lust hat, das Dokument noch einmal 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 schon auf dem Papier durchdenken kann.

Solch ein Dokument gibt euch auch die Sicherheit, dass der Kunde später nicht einfach sagen kann, dass er das alles gar nicht so gemeint hat. Wenn dem Kunden beispielsweise auf einmal einfällt, dass die Software doch mandantenfähig sein soll, und ihr somit in alle 500 Tabellen noch einmal eingreifen und einiges an der Businesslogik der Software ändern müsst, dann könnt ihr das Dokument herausholen und sagen: „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 ca. X Euro mehr und von der Zeit her verschiebt sich das Ende des Projekts um zwei Wochen“. Bei solchen Aussagen ist es Gold wert, ein Dokument zur Hand zu haben, in dem alles schwarz auf weiß zu lesen ist. „Qualität bemerkt man erst dann, wenn sie fehlt.“

Nico Franze (Dipl.-Ing. (FH) für Technische Informatik – http://www.nfranze.de) ist freier Softwareentwickler im Bereich .NET. Er hat bei Microsoft die Prüfungen für MCPD und MCTS für .NET erfolgreich bestanden. Außerdem beschäftigt er sich intensiv mit Microsoft Dynamics NAV.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -