Wie macht man seine Kunden glücklich?

Nun, man könnte das mit Schokolade, Wein, Dumping Preisen, etc. machen … Aber am besten funktioniert es über laufende, gute Kommunikation und die aktive Einbindung des Kunden in den gesamten Entwicklungsprozess des Projekts. Klingt jetzt sehr abstrakt, aber was heißt das konkret?

Vielleicht kennt ihr ja den kurzen Informatikerwitz: „Woran erkennt man einen extrovertierten Informatiker?“ … hier lange Pause machen um dem Gegenüber Zeit zum Nachdenken zu geben … Antwort: „Wenn er mit dir spricht, schaut er dabei auf deine Schuhe.“

Ok, der Witz kommt wahrscheinlich besser an, wenn man ihn hört. Trotzdem steckt in ihm ein Körnchen Wahrheit. Der beste Entwickler wird einen Kunden nicht glücklich machen können, wenn er es nicht schafft, mit dem Kunden auf Augenhöhe zu kommunizieren und gemeinsam mit dem Kunden die bestmögliche Lösung zu erarbeiten. „Ah, und das war’s?“ Nicht ganz.

Dann ist zwar die technische Umsetzung zwar sehr gut, der Kundenwunsch aber noch lange nicht erfüllt. Es ist daher wichtig, dass jemand, der Informatik studiert und sich schon jahrelang mit programmieren beschäftig, technisch komplexe Sachverhalte auch einfach erklären kann. Dadurch kann auch jemand ohne den entsprechenden technischen Background Entscheidungen treffen. Entscheidungen, die einen Einfluss auf das geplante Projekt und dessen Output haben.

Vor dem Kunden-Projekt …

Es ist daher meiner Erfahrung nach äußerst wichtig, dass auch der Softwareentwickler, der Projektleiter und das gesamte Team den Kunden, seine Zielgruppe und den geplanten Anwendungsfall verstehen. Auch ein gewisses Maß an Branchenwissen ist für eine gute Lösung notwendig. Denn ansonsten passiert es leider oft, dass am Kundenwunsch oder noch schlimmer, am Anwenderwunsch vorbeientwickelt wird.

Hier wird meiner Meinung nach oft das meiste Geld verschwendet – in der Konzeption und Umsetzung von technischen Lösungen, die ein Kunde so nicht braucht, bzw. die die Anwender nicht brauchen oder sinnvoll verwenden können. Wenn man daher schon im Vorfeld des Projektes genau klärt, wer die Softwarelösung (App, Website, etc.) wie verwenden wird und was dabei für ein Ergebnis erzielt werden soll, können oft von Anfang an Irrwege erkannt oder entschärft werden.

Wir sind daher dazu übergegangen, mit interessierten Kunden zu Beginn eines geplanten Projekts Technologie-Workshops abzuhalten. Ein solcher Workshop dient also hauptsächlich dazu, neue, noch unbekannte Technologien vorzustellen, den Kunden, seine Anwender und die Branche zu verstehen und gemeinsam eine gute Lösung zu erarbeiten.

Klassische Fragen, die gemeinsam in einem Workshop erarbeitet werden, sind dabei z.B.:

• Was sind die Ziele des Projekts?

• Existieren Vorstellungen über das Endresultat des Projekts?

• Gibt es möglicherweise konkrete und in Zahlen fassbare Ziele?

• Welche Zielgruppe soll erreicht werden, bzw. wer sind die Anwender?

• Wem soll das Projekt schlussendlich am meisten nützen?

• Welche Rolle spielt das Projekt in der Unternehmensstrategie?

• Wo liegen die Risiken, die einen erfolgreichen Projektabschluss bedrohen könnten?

Erst wenn diese Fragen beantwortet sind, wird eine Technologie ausgewählt, die für das geplante Projekt am besten passt. Deshalb kommt es durchaus häufig vor, dass man über eine Augmented Reality (AR) App ins Gespräch kommt und am Schluss ein Online 3D Produktkonfigurator oder eine Website umgesetzt wird. Oder jemand Interesse an Bluetooth Beacons zeigt, die passendere Lösung aber in einer AR App liegt. Oder es kommt vor, dass jemand, sagen wir mal, einen Porsche haben will aber nur das Budget für einen Fiat Panda hat 😉

Wenn man bedenkt, wie leicht solche grundlegenden Richtungsänderungen in einer frühen Phase möglich sind, macht es durchaus Sinn, sich in der Konzeption ausreichend Zeit zu nehmen. Diese spart man nämlich später in der Entwicklung meistens mehrfach wieder ein. Ist die Entwicklung erst einmal begonnen bzw. die Software sogar schon im Einsatz, lassen sich Änderungen und Fehlerbehebungen nur noch sehr schwer durchführen und sie kosten sehr viel Zeit, Geld und Energie.

Während des Kunden-Projekts …

Was genau passiert aber, wenn das Projekt startet und man nach erfolgreicher Konzeptionsphase genau weiß oder zu wissen glaubt, was der Kunde braucht? Man startet natürlich mit der Softwareentwicklung. Dann sieht der Kunde monatelang nichts, die Spannung steigt. Und dann, plötzlich, nach langer Zeit, wie aus dem Nichts: „Tadaa, hier ist deine fertige App, Website oder sonst irgendwas, lieber Kunde“. Voller Stolz und freudiger Erwartung auf die Kundenreaktion übergibt man das fertige Produkt und dann passiert oft folgendes: Kunde: „Das hab ich mir aber ganz anders vorgestellt!“ Oder: „Das hab ich nicht bestellt.“

Diese Dinge passieren zumindest leicht, wenn man nach dem klassischen und überall bekannten Wasserfall Modell arbeitet. Sprich: Zuerst wird geplant, konzipiert, dann umgesetzt, getestet und fertig. In den letzten Jahren hat sich allerdings ein Projektmanagement System in der IT entwickelt, das wesentlich besser für die Softwareentwicklung und kreative Prozesse im Allgemeinen geeignet ist. Dieses System nennt sich Scrum. Der große Unterschied zum Wasserfallmodell ist hier, dass es ein iterativer Ansatz ist, in dem auch der Kunde stark eingebunden wird.

Wir leben dieses System in der Praxis

Wir leben dieses System in der Praxis, indem wir z.B. dem Kunden in ein- bis zweiwöchigen Abständen Zwischenversionen der Software zukommen lassen, die er dann schon selbst testen und dazu Feedback geben kann. Dieses System hat daher viele Vorteile. Der Kunde bekommt dadurch schon während der Entwicklung einen Eindruck vom fertigen Endprodukt und kann zwischen den Iterationen (Sprints) Einfluss auf die Entwicklung nehmen. Außerdem werden viele Probleme erst sichtbar, wenn man die Software „in Händen hält“. D.h. man entwickelt mit diesem System das fertige Endprodukt viel stärker gemeinsam mit dem Kunden.

Um diesen doch noch abstrakten Software-Entwicklungsprozess sichtbar zu machen, verwenden wir das frei verfügbare Online Tool Trello. Damit wird es möglich, die gesamte Entwicklung für den Kunden sehr transparent zu halten. Er kann dabei zu jeder Zeit von überall nachsehen, welche Tasks auf „ToDo“, „InProgress“ und „Done“ sind. Zudem gehen keine Informationen im Posteingang des Projektleiters oder Entwicklers unter, der gerade auf Urlaub ist. Außerdem können klare Zuständigkeiten der Tasks und Due Dates definiert werden. Dieses Vorgehen trägt enorm zur Strukturierung des Projekts bei und es bleiben offene Tasks weniger häufig zwischen mehreren Personen liegen.

Seit wir dieses System in Kombination mit regelmäßigen persönlichen oder telefonischen Kurzmeetings verwenden, bekommen wir gefühlt 80% weniger E-Mails und Telefonanrufe mit Fragen zum aktuellen Projektstatus. Das erleichtert das Leben auf beiden Seiten enorm. Man kann sich voll und ganz auf die Umsetzung des Projekts konzentrieren.

Nach dem Kunden-Projekt …

Wir haben in den letzten Jahren folgendes gelernt: Wenn das Projekt abgeschlossen ist, ist es noch lange nicht abgeschlossen. Oft kommen erst in der praktischen Anwendung der User Probleme auf, die man vorher nicht bedacht hat oder nicht bedacht haben könnten. Deshalb ist es wichtig, sich auch nach Projektabschluss ausreichend Zeit für Verbesserungen, Updates und Weiterentwicklungen zu reservieren.

Wir sammeln dazu das Feedback – richtig erraten, im Trello. Dadurch wird es möglich, schon während und nach dem Projekt sinnvolle neue Features und Erweiterungen zu bündeln und in späteren Versionen zu veröffentlichen.

Achja, den wichtigsten Punkt hätte ich fast vergessen. Wenn man seine Kunden vor, während und nach dem Projekt glücklich gemacht hat, ist natürlich die Zeit gekommen sich beim Kunden zu bedanken und zu feiern! Jetzt stellt sich mir natürlich die Frage, ob einen Blog Beitrag zu schreiben auch ein Projekt ist. Hm, ich würde sagen, ja! 😉

Wir möchten auch gerne mit dir kommunizieren… Melde dich doch für unseren Newsletter an!