Lange schon wollte ich zu diesem Thema schreiben, eine gestrige Diskussion via Twitter gab nun den letzten Ausschlag, dies in die Tat umzusetzen. Den genauen Ursprung der Diskussion kenne ich nicht, da ich erst später dazu gestoßen bin. Unterhalten haben sich Ilker Cetinkaya und Mike Bild über die Entkopplung des inhaltlichen Codes von technisch motiviertem Code. Grundsätzlich bin ich ja der Meinung, dass eine derartige Entkopplung stattfinden muss, jedoch hing mir das Gespräch zu sehr am Code. Die Geschichte beginnt meiner Meinung nach schon weit früher …

Kommunikation von Anforderungen

Dass Anforderungen aufgenommen und analysiert werden müssen, ist weithin bekannt. Häufig werden Anforderungen in eine funktionale und nicht funktionale oder inhaltlich motivierte und technisch motivierte Struktur gegossen. Soweit noch nichts einzuwenden. Das Dilemma beginnt nun – aus meiner Sicht – wenn Anforderungen nicht auf das Wesentliche beschränkt werden, sondern bereits in der Spezifikation technisch beschrieben sind. D.h. es wird die Anforderung nicht inhaltlich beschrieben, sondern das technische Rahmenwerk innerhalb dessen die Anforderung erfüllt werden soll. Dies führt in weiterer Folge dazu, dass während der Übergabe von der Businessseite auf die technische Ebene zu sehr über technische Feinheiten (die zu diesem Zeitpunkt im Normalfall noch nicht feststehen) diskutiert wird, statt das notwendige fachliche Know-How zu vermitteln, damit eine entsprechende Bewertung durchgeführt werden kann.

Diskussion von technischer Spezifika auf Business-Ebene

Jede Seite möchte das Gegenüber verstehen. Die fachliche Seite möchte die technische verstehen. Die technische Seite muss die fachliche verstehen, um eine Bewertung herbeiführen und das Projekt schlussendlich umsetzen zu können. Noch dazu ist sich jeder Teilnehmer seiner Herkunft am nächsten. Das Resultat ist, dass in Abstimmungsmeetings (Kommunikation der Anforderungen an die Entwicklung) sehr häufig über technische Details diskutiert wird.

Vermutlich mag der eine oder andere Leser dies anders sehen (bitte um einen entsprechenden Kommentar), aber aus meiner Sicht muss die fachliche Seite nur wenige technische Informationen erhalten. Technische Detailfragen sind erst mal unerheblich und sind in einer anderen Zusammensetzung zu besprechen. Für die fachliche Ebene ist es wichtig, die Anforderungen zu vermitteln. Die Entwicklung muss verstehen, was der Kunde möchte und wie es funktionieren soll – nicht wie es abgebildet werden soll (abgesehen von nichtfunktionalen Anforderungen).

Nachteile der Diskussion technischer Umsetzungen/Details auf Business-Ebene:

  • Vermittlung der eigentlichen Anforderungen und des Ziels geraten in den Hintergrund.
  • Detaildiskussionen über technische Aspekte treiben die Abstimmung in Tiefen, die einen sinnvollen Know-How-Transfer verhindern.
  • Entstehende Spezifikationen mit technischen Vorgaben/Einschränkungen.
  • “Technische” Diskussionen zwischen Projektverantwortlichen und Kunden.

Erste Bewertung auf falscher Ebene

Das Hauptproblem besteht nun darin, dass die Projektverantwortlichen mit technischem Wissen versehen werden. Aufgrund der Herkunft mag teilweises Verständnis da sein – ist es aber in der Regel nicht. Aufbauend auf diesem Halbwissen werden nun weitere Abstimmungen (in Richtung Kunde etc.) vorgenommen. Weiterführend entsteht (durch das technische Hintergrundwissen) für den Projektverantwortlichen der Eindruck, dass von seiner Seite Schätzungen/Bewertungen durchgeführt werden können (ohne Abstimmung). Oft werden diese dem Kunden übermittelt. Zu einem späteren Zeitpunkt werden die finalen Anforderungen zur Bewertung an die Entwicklung übermittelt. Das Resultat sind meist Zahlen, die stark von der (bereits kommunizierten!!!) Bewertung des Projektverantwortlichen differieren.

Spinnt man diesen Fall weiter, ergeben sich zwei Möglichkeiten:

  1. Die bereits dem Kunden kommunizierte Bewertung muss nach oben (ganz selten nie nach unten) korrigiert werden. Dies löst auf Seiten des Kunden einige Vorgänge aus, die in der Regel vermieden werden wollen.
  2. Die Umsetzung muss so beschnitten werden, dass der bereits kommunizierte Aufwand eingehalten werden kann.

Beides sind Lösungen, die wenig vorteilhaft sind. Eine weitere Implikation besteht dadurch, dass sich dieser Vorgang in die Entwicklung weiter zieht. Die Bewertungen der Entwicklung sind aus Sicht der Projektverantwortlichen »falsch«. Ergo muss am technischen Grundgerüst eingespart werden (die vereinbarten Funktionalitäten müssen nach wie vor untergebracht werden). Hier beginnt nun das nächste Übel: Der entstehende Code wird auf die notwendige »Abkürzung« Rücksicht nehmen müssen. Um dies zu erreichen wird inhaltlicher Code mit technischem/infrastrukturellem Code vermischt, da nur so die »verlorene Zeit« gutgemacht werden kann.

Natürlich hängt dies auch sehr stark vom Entwicklungsteam ab. Erfahrungsgemäß werden jedoch in Zeiten des Stresses Abkürzungen genommen. Dies resultiert (zu einem späteren Zeitpunkt) in einer schlecht erweiterbaren und wartbaren Applikation. Es wäre auch nicht das erste Mal, dass ein Auftraggeber durch die dadurch entstehenden Kosten (oftmals sind nicht die Kosten ausschlaggebend, sondern die Fehleranfälligkeit, Aufwand für notwendige Abstimmungen, Nervenbelastung etc.) eine Neuentwicklung bei einem anderen Anbieter in Auftrag gibt und eine gehörige Investition auf sich nimmt.

Trennung zwischen technischem und inhaltlichem Code

Aus Entwicklersicht kann ein Projekt nur dann erfolgreich umgesetzt werden, wenn folgende Faktoren erfüllt sind (es lassen sich sicherlich weitere finden):

  • Die Anforderungen müssen bekannt, verständlich und vollständig sein.
  • Die Bewertung wurde durch die Entwicklung durchgeführt. An dieser Bewertung ist nicht zu rütteln. Bei Engpässen der Ressourcen muss (und das sollte es ohnehin) mit Prioritäten gearbeitet werden.
  • Die Bewertung der Entwicklung stellt die Diskussionsgrundlage zwischen Projektverantwortlichen und Kunden dar. An dieser Stelle kann über Prioritäten oder Änderung der Funktionalität diskutiert werden. Bei Änderungen ist eine erneute Bewertung durch die Entwicklung notwendig.

Ist dies gegeben, besitzt die Entwicklung die Möglichkeit ein Projekt ordentlich zu planen und zu starten (bei Null und nicht im Minus). Die Verantwortung über die Umsetzung liegt hier eindeutig bei der Entwicklung, da sämtliche Einflussfaktoren minimiert wurden. Tatsächlich besteht die Möglichkeit, einen stabilen Unterbau zu erstellen und darauf sämtliche kundenspezifischen Funktionalitäten zu implementieren. Daraus lässt sich bereits ableiten, dass es sinnvoll ist, infrastrukturellen Code vom inhaltlichen zu trennen. Dies ist sinnvoll, da sie ohnehin unterschiedliche Bereiche abdecken (Login-Funktionalität, Persistenz, Metadaten, Vorgabe div. Patterns etc.). Die fachliche Funktionalität setzt darauf auf und verfeinert die durch die Basis gebotenen Möglichkeiten.

Der Vorteil liegt daran, dass ein höherer Grad an Wiederverwendbarkeit und verbesserte Testbarkeit erreicht wird. Zudem wird es einfacher, Implementierungen zu erweitern bzw. zur Gänze auszutauschen. Im Idealfall kann derselbe Grundstock für weitere Projekte herangezogen werden, wodurch deren Gesamtaufwand wesentlich verringert werden kann.

Projektverantwortliche in die Mangel nehmen

Ein Entwicklungsteam kann viele Änderungen vornehmen um produktiver, schlagfertiger und flexibler zu sein. Der Entwicklungsprozess als solches umfasst jedoch nicht nur Entwickler, sondern auch »höhere« Ebenen. Diese müssen sich einem gewählten Modell versprechen und am selben Strang ziehen. Dazu gehört eine klare Trennung der Verantwortlichkeiten. Kompetenzüberschreitungen darf es einfach nicht geben. Sobald es zu einer solchen kommt, gerät das gesamte Projekt in Gefahr, da sich die eine Seite nicht mehr ausschließlich auf das Wesentliche konzentrieren kann und die andere Seite mit falschen Vorgaben arbeiten muss.

Fazit

Dies ist ein Lernprozess, der von beiden Seiten ernst genommen werden muss. Es wird »günstiger« (also wartbarer, erweiterbarer, bla bla) Code gewünscht. Die Verantwortung hierfür liegt jedoch nicht ausschließlich in der Entwicklung. Die Vorzeichen müssen bereits in viel früheren Schritten korrekt gesetzt werden.

Über den Autor

Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler und Fotograf. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.

3 Kommentare

  • Wie viele erlebte Projekte kommen mir da in den Sinn. Schon oft musste ich die Ideen des Kunden, was die Technik betrifft, widerlegen.

    Am erfolgreichsten war dies in einem Projekt, bei dem es um Datenmigration ging. Es wurde ein neues ERP System eingeführt und Daten, die über verschiedenste Systeme verteilt waren, von einer alten AS 400 bis zu Oracle basierten moderneren Anwendungen mussten zusammengefasst werden. Nun war von Seiten des Kunden ein kleines Expertenteam zusammengestellt worden, dass die Regeln definierte, und diese konnten sich recht schnell ändern, da war auch jede Menge "Reverse Engineering" im Spiel.

    Ich kam dazu, nachdem ein VB Programmierer, der den jeweiligen Import in einem einzigen Programm dann jeweils abhandeln sollte, schlichtweg aufgegeben hatte (bzw, die Differenzen wurden so gros, dass er gegangen wurde). Und von mir wurde erstmal das selbe Vorgehen erwartet, mit seinem Code als Grundlage.

    Ich beschäftigte mich erstmal eine Woche mit seinem Code und den Andorderungen, musste sagen dass grundsätzlich an seinem Code nichts auszusetzen war, aber dass die Idee, dass auf diese Art umzusetzen, völlig unproduktiv war unter den gegebenen Voraussetzungen. Ich verbrachte einen Monat damit, etwas ganz anderes, als bestellt aufzubauen. Ein System, dass Schnittstellen zu Quell- und Zielsystem bereitstellte und die Datenaufbereitung über flexibel verwaltbare T-SQL Regeln mit Kommentierung über ein HTML Interface bereitstellte. Nach Beendigung setzten drei weitere Leute parallel die Regeln um, fast in Echtzeit zu den frischen Vorgaben.
    Das bedeutete aber, dass ich einen Monat lang ständig Leute beruhigen musste, die erwarteten, dass ich nun wenigstens mal eine Regel in Code umsetze, weil die Denkweise nicht klar war.
    Ich lieferte nicht einen Fisch nach dem anderen, sondern ein Fischernetz. Das Projekt war am Schluss auch ein grosser Erfolg, aber genaugenommen habe ich meinen Auftrag nie Erfüllt, sondern im Gegenteil, gewissermassen von ganz unten eine Palastrevolution angezettelt. Das hätte auch schief gehen können, zumal ich zu der Zeit selbstständig war.

    Eine andere heisse Situation war zu beginn einer Anstellung. Meine erste Aufgabe war es, die Probleme mit einem Dienstleister bei der Umsetzung einer gewünschten Software in den Griff zu bekommen. Nur stellte sich eben auch dort heraus, dass das Problem nicht am Dienstleister, sondern an der technsichen Vorgabe lag. Man hatte ein organisch gewachsenes Exel Sheet aus der HR Abteilung, dass man nun "professionalisieren" wollte, indem man es via Access in eine "richtige Datenbankanwendung" umsetzen lies. Da waren schon einiges tausend Franken hinein geflossen und letztlich musste ich ihnen vermitteln, dass das Projekt selbst der Fehler ist, denn Access kann nicht so flexibel auf die sich ständig ändernden Regeln eingehen, die bei diesem Excel Sheet fast an der Tagesordnung waren. Statt einfach neu eine Regel zu verändern oder eine neue Spalte einzufügen, hätte es bei Access jeweils einer Softwareanbpassung bedarft, ein Kostengrab ohne Ende, nur wegen dieser fixen Idee, dass Excel nicht "professionell" genug ist.

  • Hallo Norbert,

    vielen Dank für den Post. Bin leider erst jetzt zum lesen gekommen. Nun, ich hoffe ich habe deine Kernaussage richtig verstanden. Separation of Concern. Trenne technisches von fachliches. Trenne Zuständigkeiten, Verantwortung und Abhängigkeiten wo es geht. Zwei Punkte finde ich allerdings etwas genauer betrachtet problematisch.

    "Die Anforderungen müssen bekannt, verständlich und vollständig sein."

    1) Das sind sie leider nie und werden es vermutlich nie. Die Welt ist einfach zu komplex. Dennoch sollte ein Rahmenwerk stehen. "Möchten sie einen Polo oder möchten sie ein Porsche 911 oder vielleicht einen Passat mit vielen Zuladungsmöglichkeiten. Automatik oder Schaltgetriebe .. usw.?" Der Rahmen sollte schon stehen und auf Papier, Unterschrieben feststehen.

    2) "…einen stabilen Unterbau zu erstellen und darauf sämtliche kundenspezifischen Funktionalitäten zu implementieren…" Ist das gut? Selbstbeschäftigung in Infrastruktur ohne direkten Kundennutzen? Nicht an alles, in jeder Detailstufe, kann gedacht werden. Hier ist weniger mehr würde ich sagen. Dann erst technisches von fachlichem trennen.

    Cheers, Mike

  • Hallo Mike,

    vielen Dank für deinen Beitrag.

    Ad 1) Zugegeben, ich habe mich nicht genau genug ausgedrückt. Das was ich damit sagen wollte trifft deine Aussage. Anforderungen werden in der Realität in der Tat nie vollständig sein. Aber sie sollten im beschriebenen Kontext möglich vollständig sein, damit vermittelt wird, was da eigentlich gewollt wird und nicht, dass nach dem Lesen der Anforderungen mehr offene Fragen existieren als davor.

    Ad 2) Dies ist aus meinem aktuellen Kontext erwachsen und zu wenig abstrahiert. Das ist natürlich abhängig vom Zusammenspiel vieler Faktoren (Team, Strategie und Co.). Bei reinen Kundenprojekten ist natürlich das Ziel, diese umzusetzen und möglichst wenig "Nebenrauschen" zu erzeugen. Dennoch ist es sicherlich sinnvoll (entwickelt sich aber ohnehin meist nebenher mit) immer wiederkehrende Aufgaben in ein Set zu gießen, das auch für weitere Projekte eingesetzt werden kann.

    Norbert