INTERNET WORLD Business





IT-PROJEKTUMSETZUNG

Reibungsverluste vermeiden

Eine bessere Logik für die Recommendation Engine, eine komfortablere Warenkorbansicht, eine Facebook- Anbindung – von der Idee bis zur Umsetzung von IT-Projekten im E-Commerce kann viel schiefgehen

Kompliziert: Ein IT-Projekt ist ein stetig wachsender Prozess, der vom Auftraggeber ständige Aufmerksamkeit erfordert

Ein E-Commerce-Projekt ist notwendigerweise ein Software- Projekt. Wer aber hätte je davon gehört, dass Software- Projekte in harmonischer Freude verliefen? Warum tun sich Software- Entwickler so schwer, einfach das zu programmieren, was man von ihnen haben will? Es kommt wieder und wieder zu Reibungsverlusten in E-Commerce- Projekten, weil Auftraggeber, das heißt Online-Shop- Betreiber, Internet-Dienstleister oder Agenturen, und auftragnehmende Software-Entwicklung sich missverstehen. Kosten, Zeit und Nerven werden strapaziert, weil es einfach nicht so vorangeht, wie der Auftraggeber es sich wünscht.

Woran das liegt? Beiderseitig spricht und schreibt man doch Deutsch; reicht das denn nicht? Eine gemeinsame Wort- beziehungsweise Schriftsprache ist zwar eine günstige Voraussetzung für weniger Reibungsverluste, doch hinreichend ist sie noch lange nicht. Viel wichtiger als sie ist ein gemeinsames Verständnis davon, was Software als Produkt darstellt und wie Software deshalb überhaupt hergestellt werden muss. Leider macht die Software-Entwicklung als Branche im Allgemeinen gewöhnlich keinen guten Job, ihrer Kundschaft ein Bild davon zu vermitteln, „wie das mit der Software eigentlich funktioniert“. So sitzen sich immer wieder der sprichwörtlich introvertierte Programmierer und der fordernde Auftraggeber gegenüber – und reden aneinander vorbei. Vier Kommunikationsmuster lassen sich dabei beobachten, die einen Projekterfolg erschweren. Antimuster heißen sie, weil es kontraproduktive Muster sind.

Antimuster #1: Einkaufszettel für ein Jahr

Typisch für Software-Projekte ist, dass die Entwicklung mit der Umsetzung eines umfangreichen Lastenhefts beauftragt wird. Das Lastenheft spezifiziert mehr oder weniger detailliert, systematisch, verständlich, was sich der Auftraggeber alles von der neuen beziehungsweise überarbeiteten Software wünscht. Das reicht von der Farbgebung der Benutzerschnittstelle bis zu Rabattregelungen je nach Kundengruppe und Kaufhistorie.

Nicht selten enthält ein Lastenheft Stoff für Monate oder gar Jahre der Programmierung. Immerhin konkretisiert es die Wünsche vieler Anwendergruppen, die von der Software morgen profitieren sollen. Für die einen soll Funktionalität überhaupt zur Verfügung gestellt werden, für die anderen soll sie leichter zu bedienen sein, für Dritte soll die Software schneller laufen oder sicherer werden und so fort. Software ist mithin eine Projektionsfläche für unterschiedliche Vorstellungen davon, wie die Arbeit oder gar das Leben morgen leichter sein sollen. Dass Auftraggeber eine Menge Wünsche an Software haben, ist ganz natürlich. Und Software soll auch Wünsche erfüllen. Kontraproduktiv ist jedoch der Umgang mit diesen Wünschen. Sie in ein dickes Lastenheft zu pressen, das dann im Verlauf von Monaten oder Jahren abgearbeitet wird, widerspricht der Natur von Wünschen: Die ändern sich nämlich ständig. Wer ein Lastenheft mit Stoff für viele Monate füllt, verhält sich wie jemand, der einen Einkaufszettel für viele Monate zusammenstellt. Er glaubt zu wissen, worauf er in drei Monaten Hunger hat, was er in fünf Monaten abends trinken möchte oder wie viele Flaschen Bier für Gäste er im nächsten halben Jahr braucht. Dass Gäste kommen, dass gegessen und getrunken werden muss, ist keine Frage. Aber was, wann und wie viel genau, ist unbekannt. Übertragen auf das Umfeld eines Software-Projekts muss das Lastenheft als Einkaufszettel für die nächsten Monate oder gar Jahre ausgelegt sein. Warum? Weil die Software-Entwicklung nach Projektende nicht mehr verfügbar ist? Weil ganz sonnenklar ist, wie die eigenen Wünsche heute und in Monaten aussehen werden? Weil Software nur in einem Stück hergestellt werden kann wie ein Auto oder Haus? Oder weil das Budget haarklein für eine lange Zeit geplant werden muss? Es ist wohl eine Mischung von allem. Allerdings eine ungute, kontraproduktive Mischung, weil sie dem Missverständnis aufsitzt, dass überhaupt gewusst werden kann, was auf Monate oder Jahre hinaus gewünscht und relevant ist.

Antimuster #2: Nach Auftragserteilung verreist

Typisch für Software-Projekte ist auch, dass Auftraggeber nach Überreichung des umfangreichen Lastenhefts an die Software- Entwicklung geduldig auf die Umsetzung ihrer Wünsche warten; immerhin sind ja exakte Abgabetermine und Abgabeleistungen vertraglich vereinbart. So geduldig sind sie sogar, dass sie sich wochen- oder monatelang ohne Zwischenergebnisse wohlfühlen.

Rückt ein Meilenstein näher, dann stellen Auftraggeber zwar die Ohren auf und horchen, ob die vereinbarten Leistungen denn auch buchstäblich eingehalten wurden. Der Projektleiter wird zum Rapport gebeten. Bis dahin jedoch gilt eher: „Lasst uns in Ruhe mit dem Software- Kram. Macht euren Job, Programmierer. Im Lastenheft steht alles drin, was ihr braucht. Wir haben uns schon genug Mühe damit gegeben.“

Verständlich ist eine solche Haltung – nur leider nicht hilfreich. Jeder, der schon einmal eine Immobilie renovieren oder bauen hat lassen, weiß das auch. Kein Bauherr würde auf die Idee kommen, sein Objekt monatelang Architekt oder Bauträger zu überlassen. Eine Projektleitung zu haben, ist eine gute Sache, befreit jedoch nicht davon, immer wieder selbst vor Ort die Qualität zu prüfen oder Entscheidungen zu treffen. Die übliche Projektleitung ist für die Einhaltung des Plans zuständig. Sie ist eine antreibende und koordinierende Instanz. Das Ergebnis abnehmen oder auf inhaltliche Fragen Antwort geben kann und soll sie jedoch nicht. Dafür ist der Auftraggeber zuständig. Ist der Auftraggeber jedoch nach Auftragserteilung auf längere Zeit nur schwer erreichbar, dann bleiben Dinge auf der (Software-)Baustelle unentschieden liegen oder werden von den Ausführenden entschieden. Dass das zu einigen Abweichungen vom Wunschbild führen kann, aus denen Frust oder gar anwaltliche Auseinandersetzungen entstehen, weiß jeder, der sich länger als ein paar Tage auf Architekt, Bauträger oder Handwerker blind verlassen hat. Trotz aller Mühe bei der Formulierung des Lastenhefts ist es einfach nicht zu vermeiden, dass während der Ausführung immer wieder Rückfragen entstehen oder ad hoc Entscheidungen getroffen werden müssen, weil wohlformulierte Wünsche am Ende doch nicht wie geplant realisierbar sind. Das gilt für Immobilienprojekte und umso mehr für Software-Projekte. Auch das ist eine zentrale Erkenntnis der Software-Entwicklung aus vielen schmerzhaften Erfahrungen.

Antimuster #3: Ein Wort ist einfacher als tausend Bilder

Auch wenn das Lastenheft überbewertet ist, was Umfang und Absolutheit und Unabänderlichkeit angeht, ist zweifellos eine Formulierung von Anforderungen nötig. Sie nur mündlich und in persönlicher Begegnung mit den Software-Produzenten vorzutragen ist – außer in trivialen Projekten – nicht möglich. Was sollte das Lastenheft aber enthalten? Oft ist es wohlstrukturierter Text, garniert mit Grafiken. Wie sonst sollten von der Software-Entwicklung zu schulternde Lasten beschrieben werden? So produzieren Sitzungen Berge an Papier, die vermeintlich präzise, vermeintlich vollständig, vermeintlich nützlich, in jedem Fall aber trocken sind.

Im Fokus steht dabei die Produktion von Anforderungen, das Dokumentieren, das Aufschreiben. Wünsche sollen Software-Entwicklern verständlich gemacht werden. Und damit das schnell geht, werden viele Worte gemacht. Denn die Formulierung von Anforderungen in Worten sollte jeder, der einen Wunsch hat, beherrschen.

Leider kosten viele schnell geschriebene Worte alle weiteren Beteiligten viel Zeit. Auch führen sie schwerer als gedacht zum gewünschten Ergebnis. Der Grund:Worte sind notorisch unpräzise für die Beschreibung von Ursache-Wirkungs-Zusammenhängen. Aber um nichts anderes geht es bei Software: Zu einer Ursache soll eine gewünschte Wirkung produziert werden.

Wie diese Produktion funktioniert, ist dabei eigentlich egal. Gäbe es einen Zauberstab, der mit magischer Kraft Ursache in Wirkung verwandeln könnte, wäre das jedem Auftraggeber recht. Lastenhefte spiegeln diese Lösungsindifferenz jedoch nicht wider. Stattdessen machen sie viele Worte um die Transformation – und beschreiben die Ursachen mit ihren Wirkungen oft nur schwammig. Ursache und Wirkung sind abstrakte Begriffe in diesem Zusammenhang. Eingabedaten/Input und Ausgabedaten/Output hingegen sind sehr konkret. Lastenhefte sind in vielerlei Hinsicht sehr beredt; aus welchen Eingabedaten welche Ausgabedaten zu produzieren sind, spezifizieren sie oft allerdings nicht genau. Dabei wäre das die wichtigste Angabe, um Software nicht nur in Auftrag zu geben, sondern am Ende festzustellen, ob der Auftrag auch erfüllt wurde.

Je härter, präziser, detaillierter, formaler, automatisch überprüfbarer die Akzeptanzkriterien für eine Software, desto besser. Statt lang und breit im Lastenheft zu beschreiben, dass eine Addition zu realisieren ist, sollten die Seiten mit Input-Output- Paaren gefüllt werden: „Für die Eingabe (1,0) wird 1 als Ergebnis erwartet; (1,2) ergibt 3; (2,1) ergibt ebenfalls 3“ und so fort. Das funktioniert auch für Input/Output, der umfangreicher ist. Solange Lastenhefte nicht genau definieren, was akzeptable Eingaben mit ihren akzeptablen Ausgaben sind, haben es Software-Entwicklung und Auftraggeber schwer, festzustellen, ob die Software vollständig, korrekt und fertig ist.

Antimuster #4: Nürnberger Trichter

Software kann nur entwickelt werden für das, was Software-Entwickler verstanden haben. Wie aber kommen Software-Entwickler zu diesem nötigen Verständnis? Auftraggeber glauben immer wieder, dass das Lesen des Lastenhefts ausreiche. Als Ideal gilt die Kommunikation durch eine Einbahnstraße. Einer schreibt, der andere liest. So kostet es ja auch wenig Zeit; das ist immer wünschenswert.

Leider werden nicht alle Wünsche wahr. So auch nicht dieser von einem Nürnberger Trichter. Denn nichts anderes wünschen sich viele Auftraggeber. Sie würden ihre Anforderungen gern über einen Trichter in die Software-Entwicklung kippen, die wie ein Fleischwolf daraufhin Software ausspuckt.

Das geht jedoch ganz allgemein an jeder lernpsychologischen Realität vorbei – und im Speziellen widerspricht es der Komplexität von Anforderungen an Software. Die sind nämlich meist so umfangreich und auch noch unbewusst, dass sie nicht vollständig dokumentiert werden können. Was im Lastenheft steht, ist mithin notwendig lückenhaft, missverständlich, widersprüchlich oder gar fehlerhaft. Es möglichst „in einem Rutsch“ an die Software- Entwicklung „zu übertragen“ ist zum Scheitern verurteilt. Auch dies ist eine gesicherte Erkenntnis der Software-Entwicklung aus vielen gescheiterten Projekten.

Fazit

Alle wollen natürlich das Beste für ein E-Commerce-Projekt. Immer wieder ist es jedoch mühsam, bis Auftraggeber und Software-Entwicklung dieses Beste auch erreichen. Das ist kein böser Wille, sondern liegt an einem unterschiedlichen oder gar falschen Verständnis davon, wie Software-Entwicklung funktioniert.

Besserung ist möglich, wenn Missverständnisse und kontraproduktive Verhaltensweisen aufgedeckt werden. Vier solche Antimuster beschreibt dieser Artikel. Sie zu kennen, ist ein erster Schritt, um Reibungsverluste in E-Commerce-Projekten zu vermeiden. Auftraggeber, die verstehen, dass ihre Wünsche flüchtiger sind, als sie glauben, dass Software-Entwicklung nicht über längere Zeit ohne persönliche „Begehung der Software-Baustelle“ verlaufen darf, dass nur klare Akzeptanzkriterien zu punktgenauer Zufriedenheit führen, und zuallererst Verständnis für die Anforderungen harte Lernarbeit auf beiden Seiten bedeutet – diese Auftraggeber werden mit ihren E-Commerce-Projekten langfristig einen klaren Vorteil gegenüber den Projekten anderer haben. ❚

Ralf Westphal

Weitere Bilder
comments powered by Disqus