GEMEINSAM STARK

GEMEINSAM STARK

Zuhören als Element erfolgreicher Zusammenarbeit

VON BEAT STEINEGGER

(Veröffentlicht in Das Produktkulturmagazin Ausgabe 4 2017)

Der Dalai Lama sagte einmal, dass wir, wenn wir sprechen, nur das wiederholen, was wir schon wissen. Wenn wir aber zuhören, kann man unter Umständen etwas Neues lernen. Zuhören an erster Stelle des Software-Entwicklungsprozesses hört sich zunächst eher seltsam an, lohnt sich aber für alle Beteiligten. Denn das Zuhören spielt gerade bei der erfolgreichen Abwicklung von Projekten eine wichtige Rolle.

Oft versuchen Software-Firmen, eines ihrer Standardprodukte zu verkaufen, und merken erst im Entwicklungsprozess, dass sie den Standard unvorhergesehen verbiegen müssen. Ein dadurch ineffizienter und ineffektiver Prozess resultiert in einem vor allem kundenseitig unbefriedigenden Produkt. Eine längere Entwicklungszeit und höhere Kosten steigern das Frustrationspotential beim Kunden zusätzlich. „Nicht noch ein Software-Projekt bitte“ und Ähnliches ist dann zu hören. „Die Kosten werden sowieso überschritten, und lass’ uns lieber ein paar Monate länger einplanen als vorgesehen, die Software-Projekte dauern eh immer länger.“ Zugegeben, da ist was dran. Letzten Endes entscheidet aber nicht ein Unternehmen, ob es Software-Projekte umsetzen will, sondern die Digitalisierung. Schon jetzt steckt praktisch in jedem Produkt eine digitale Komponente; ganz zu schweigen von der Notwendigkeit, dass potentielle Kunden zukünftig fast ausschließlich digital erreicht werden können. Die Anforderungen an digitale Produkte werden immer komplexer. Nicht nur technologisch, sondern auch hinsichtlich der Bedürfnisse der Kunden. Längst reicht es nicht mehr aus, eine einfache Website zu erstellen; Multichannel und andere Buzzwords verlangen eine umfassende Strategie für das „Going digital“ von Unternehmen. Auch hier gilt: Nicht die Unternehmen entscheiden über die Kanäle, sondern die Kunden. 

Zuhören als ein Element des Manifests von e-sphere ist nicht nur geschrieben und schön umschrieben, es wird in Form von Storymapping gleich zu Beginn der Zusammenarbeit mit evidentia.med gmbh umgesetzt. Keine Zeile Code wird geschrieben, bevor die Vision „Reshaping World-wide Medical Education“ in eine zu Ende gedachte Story und letztendlich State-of-the-Art E-Business-Lösung konzipiert worden ist. Der Anspruch an eine digitale Boutique ist hoch. Der Kunde muss sich und sein Business verstanden fühlen, die digitale Boutique ist somit nicht nur Entwicklungspartner, sondern auch Facilitator. Sie unterstützt den Prozess, angefangen mit der Vision hin zur einer durchdachten E-Business-Lösung mit klarer Definition der Entwicklungszeit, der Kosten und der Scope. Bevor eine Zeile Code geschrieben wird.

Der Kunde war natürlich nicht begeistert, dass er primär auch mal seine eigene Zeit investieren muss. Storymapping ist keine Aufgabe von einem Tag, sondern ein Prozess, der sich über mehrere Tage oder Wochen hinziehen kann. Die Benefits des Storymappings waren schnell erkennbar und am Ende des Prozesses offensichtlich. Beide Seiten haben zwar viel Gedankengut und Zeit investiert, doch das Vertrauen, eine solide Basis für die Umsetzung des Projekts gelegt zu haben, überwiegt bei Weitem. In transparenter und aufrichtiger Art wurde die Vision heruntergebrochen in eine tolle Story im Rahmen eines vorab definierten Budgets- und Zeitrahmens. Das Wort „Nein“, auch wenn man es nicht gerne hört, wurde dabei von e-sphere oft gebraucht. Letztendlich war das aber der Schlüssel hin zu einem „minimum viable product“, quasi Version 1.0. Auf Basis des Storymappings und einiger Benchmarks werden anschließend die Wireframes erstellt für alle wesentlichen Sites der E-Business-Lösung. Ein Designer wurde im Anschluss beauftragt, in Zusammenarbeit mit e-sphere das Design zu entwickeln, natürlich unter Berücksichtigung der adaptiven Natur der Lösung. Der Vollständigkeit halber soll an dieser Stelle noch erwähnt werden, dass als Basis für die Umsetzung Broadleaf verwendet wurde und Java als Programmiersprache. Nur eine Randnotiz für den Kunden, der sich einzig dafür interessierte, eine State-of-the-Art E-Business-Lösung zu erhalten; Java, PHP, Broadleaf, SAP et cetera sind Begrifflichkeiten, Konzepte, Programmiersprachen, mit denen sich der Kunden nicht auseinandersetzen will. Auch ein Anspruch an eine digitale Boutique: Technologisch muss sie die Hausaufgaben gemacht haben. Auch bezüglich Suchmaschinenoptimierung will der Kunde keine Kompromisse eingehen. Die Lösung muss dahingehend optimiert sein und möglichst genau den Parametern von Google und Co. entsprechen. Man will schließlich auch gefunden werden ohne massiven Einsatz von kostenpflichtigen Services.

Auch methodisch muss eine digitale Boutique fest verankert sein. Dabei spielt es für den Kunden wiederum keine Rolle, ob jetzt ganz zeitgemäß agil entwickelt wird oder doch nach klassischen Methoden. Er muss das Vertrauen haben, dass die digitale Boutique die für sein Projekt beste Methode anwendet unter Berücksichtigung von Zeit, Kosten und Scope. Des Weiteren hat der Kunde während der Entwicklungszeit ein großes Interesse daran, möglichst wenig Zeit aufzuwenden. Auch wenn er nicht darum herumkommt, Zeit für das Testing und die finale Abnahme zu investieren, so soll der Aufwand diesbezüglich auf ein Minimum beschränkt werden. Hier gilt ebenso, dass das Zuhören das zwischen den Zeilen Versteckte zum Vorschein bringt und das implizite Wissen in Form einer relativ abstrakten Vision in eine klare und zu Ende gedachte Story umgesetzt wird. Der Aufwand für das Testing und für die Abnahme können so in für den Kunden erträglichen Grenzen gehalten werden.

Getreu der agilen Methode – zweifellos der klassischen Wasserfall-Methodik in diesem spezifischen Projekt vorzuziehen – wurde der erste Sprint definiert, dann der zweite und so weiter. Der Kunde wurde eingeladen, entweder vor Ort oder virtuell an den Besprechungen der Sprints teilzunehmen. Natürlich konnte der Kunde die Zeit dafür nicht immer aufbringen. Durch die profunde, lückenlose und stringente Definition der Story zu Beginn war dies auch nicht nötig. Funktional waren die Eckpunkte klar und deutlich festgelegt. Kleinere Anpassungen, vor allem beim Design, wurden laufend implementiert. Auf Scope-Änderungen konnte gänzlich verzichtet werden, da das Storymapping die E-Business-Lösung zu Ende gedacht hat. „Nein“ wurde seitens von e-sphere auch wieder oft gesagt, dies aber nur, um unnötige Scope-Änderungen zu vermeiden. Solche Vorschläge außerhalb der Scope werden in den Backlog gefüllt für zukünftige Versionen der E-Business-Lösung. Das definierte „minimum viable product“ sollte entsprechend eins zu eins umgesetzt werden, um somit Kosten- und Terminüberschreitungen zu vermeiden.

Gemäß dem Zeitplan wurde die E-Business-Lösung mit Inhalt gefüllt. Dem Kunden wurde empfohlen, von allen Content-Typen mindestens ein fertiges Beispiel, besser jedoch mehrere Beispiele hochzuladen, um ungemütliche Entdeckungen bei der Abnahme zu vermeiden. Letzte Bugs und kleinere Anpassungen am Design konnten vorgenommen werden. Mit einer stringenten Kultur, gemachten Hausaufgaben hinsichtlich der Technologie und einer klaren Methodik wird eine digitale Boutique höchsten Ansprüchen genügen können und dem Kunden eine Reise anbieten, die mehr ist als ein weiteres Software-Projekt. Eine Reise, die sowohl für e-sphere als auch für evidentia.med gmbh eine in neue Gefilde war. Sie endete mit prdportal.org und fing an mit Zuhören.

Gefällt Ihnen dieser Artikel? Legen Sie ihn in Ihren Warenkorb!

e-sphere.ch

BEAT STEINEGGER

Beat Steinegger ist studierter Betriebswirt. Seit Jahren beschäftigt er sich mit den Erfolgsfaktoren für die Entwicklung und erfolgreiche Umsetzung von digitalen Strategien. Zusammen mit seinen Geschäftspartnern konzipierte er prdportal.org, ein online Fortbildungsportal für Neurologen weltweit ganz nach dem Motto „Reshaping Worldwide Medical Education”.

Picture credit © Alex Treadway/ Getty Images


Leave a comment

Please note, comments must be approved before they are published