Gib dem Kunden nicht das, was er will, sondern das, was er braucht! Design Thinking in der Softwareentwicklung
Der Erstkontakt beim Kunden ist das Wichtigste. Nicht nur, damit man sich kennenlernt. Nicht nur, damit man ein Gesicht zum Namen hat. Es ist vor allem deshalb wichtig, weil der Kunde genau hier das erste Mal erzählt, wo ihn der Schuh drückt. Wer da nicht genau zuhört, kann ein Konzept komplett in die falsche Richtung lenken.
Der erste Kontakt
Nachdem beide Parteien sich brav vorgestellt haben und nun jeder weiß, was die Stärken des anderen sind, in welchen Märkten man sich bewegt etc. kommt der eigentliche Teil. Der wichtige Teil. Der, der schnell später wieder vergessen wird, verdrängt von weiteren Besprechungen, Telefonaten und Emails. Der Kunde wird erzählen, was ihn an der Ist-Situation stört. Und hier beginnt der Teil, bei dem der Software-Dienstleister genau zuhören sollte. Denn hier werden die Probleme geschildert, für deren Lösung sich der Kunde vertrauensvoll an das Unternehmen gewandt hat. Der Kunde hofft darauf, dass der Dienstleister ihn versteht und seinem Elend ein Ende bereitet.
Zuhören und verstehen - der große Unterschied
Da gibt es keinen Unterschied? Oh doch, den gibt es sehr wohl. Diesen Unterschied leben wir bei der WOGRA in allen Software-Projekten. Der Unterschied beginnt bei der Involvierung des kompletten Teams, das für das Projekt verantwortlich ist. Auch der Werkstudent, der nur einen kleinen Teil der Implementierung übernimmt, soll wissen, warum dieses Projekt dem Kunden einen Mehrwert liefert. Der Unterschied geht weiter über das Konzept. Wir hören nicht nur zu und erarbeiten dann ein Konzept, sondern wir gehen auch hier iterativ mit Prototypen vor. Der Kunde kann so immer wieder evaluieren, ob die vorgeschlagene Lösung genau die richtige ist oder nicht und wir arbeiten dieses Feedback ein. Am Ende steht ein Konzept, bei dem wir durch viele Gespräche mit dem Kunden genau verstanden haben, warum dies und das eben doch nicht die Lösung seines Problems ist. Gut, dass da nicht gleich nach dem Zuhören ein fertiges Konzept erstellt wurde. Der Unterschied endet auch nicht in der Produktivsetzung. Genauer gesagt, endet er gar nicht. Sobald eine Software produktiv ist, halten wir engen Kontakt mit dem Kunden, um zu erfahren, wie gut das System in die internen Abläufe integriert werden konnte.
Featurewünsche richtig einordnen
Schnell werden nach Produktivsetzung die ersten neuen Featurewünsche geäußert. Der Mehrwert wird erlebt und es eröffnen sich weitere Möglichkeiten, wie die Software das Unternehmen noch besser unterstützen kann. Hier kommt wieder der Unterschied zum tragen, denn wer weiß, wie sein Kunde "tickt" und was er mit der Umsetzung des Features eigentlich erreichen will, der kann auch das liefern, was der Kunde wirklich braucht.
Was der Kunde will - und was der Kunde braucht
Der Kunde will zunächst nur, dass ihm geholfen wird. Sein Problem soll beseitigt werden. Es macht den Eindruck, als wäre sowas ganz einfach. Ist es aber nicht. Denn der Kunde sagt selten klipp und klar, warum er dieses Problem beseitigt haben will. Welchen Mehrwert bringt es ihm? Wenn es dumm läuft, beseitigt man zwar das Problem des Kunden, schafft mit der Lösung aber gleich ein oder gar mehrere neue.
Ein Beispiel
Den Kunden stört seine lästige Excel-Tabelle. Ständig verändern die Mitarbeiter die Summen, weil sie sich nicht merken können, in welche Felder sie was eintragen sollen, damit am Ende die korrekte Summe berechnet werden kann. Die Mitarbeiter kriegen es einfach nicht auf die Reihe. Jetzt soll die Excel-Tabelle abgelöst werden. Sein Wunsch ist es, eine Webanwendung dafür zu bauen. So kommen die Mitarbeiter nicht mehr an die bösen Summenfelder ran, und können nix mehr kaputt machen. Im weiteren Gesprächsverlauf kommt heraus, dass einige Mitarbeiter eine eigene Version dieser Excel-Liste besitzen, in der sie Spalten umbenannt haben um sich besser zurecht zu finden. Oder sie haben sich eine eigene kleine Hilfstabelle gebaut, in der sie nur die Informationen verwalten, die für ihren Bereich wichtig sind und diese kopieren sie dann später in die große undurchsichtige Tabelle, die der Chef zur Auswertung braucht und die dann hinten und vorne nicht mehr stimmt.
Wer hats verstanden?
Wer nur zugehört hat, weiß, es soll eine Weblösung her, die die Excel-Tabellen ablöst, damit die Mitarbeiter die Business Logik dahinter nicht mehr zerstören können.
Wer allerdings verstanden hat, weiß, dass die Mitarbeiter total überfordert waren mit der Pflege der Excel-Tabelle. Und wer es verstanden hat, weiß auch, warum: Sie haben Datenfelder gesehen, die nicht in ihren Bereich gehören. Sie haben Business Logik gesehen, die sie nicht verstanden haben. Sie haben Spaltenbezeichnungen gelesen, die nicht in ihre Domäne gepasst haben. Dass eine Weblösung hier viele dieser Probleme in den Griff kriegt, ist eine Sache. Aber wer nur zugehört hat, der hat nicht verstanden, dass die Mitarbeiter scheinbar maßgebliche Probleme mit der Usability hatten. Wer nicht versteht, rennt beim ersten Prototypen oder gleich beim Konzept in die Falle, dass die Mitarbeiter später wieder überfordert sind und andere Probleme in der Handhabung der neuen Software haben. Wer versteht, berücksichtigt das gleich und kann sich sicher sein, dass der erste Prototyp bereits ein guter Weg zur Lösung des Problems ist.
Aber Design Thinking ist doch viel mehr!
Ja, da haben alle Experten Recht, die hier nun substanzielle Informationen zum Thema Design Thinking vermissen. Aber es gibt genug Fachartikel und Bücher dazu, die müssen wir nicht in einem einzigen Blog-Beitrag neu erfinden. Uns war und ist es wichtig, den Kerngedanken des Design Thinking in die Softwareentwicklung zu bringen, nämlich die Frage: Wo ist das Problem?
Design Thinking bei WOGRA
Die Frage nach dem Problem haben wir nicht nur beim Erstkontakt mit dem Kunden im Hinterkopf, sondern auch bei der Umsetzung der einzelnen Features. Nicht nur der Mitarbeiter, der das Konzept erstellt, trägt diese Frage immer mit sich herum, sondern auch jeder Entwickler. Bei der Implementierung hinterfragt auch jeder Entwickler, ob diese Umsetzung so Sinn macht oder ob ein anderer Ansatz für den Kunden besser wäre. Mit dieser flexiblen Feature Driven Entwicklung konnten wir bisher jedes Projekt so umsetzen, dass nicht hinterher eine Vielzahl an Änderungen gewünscht wurde, weil die Software nicht den gewünschten Mehrwert bringt. Was gewünscht wird, sind Erweiterungen, weil die Lösung, die wir präsentieren, die ist, die dem Kunden weiter hilft und bei der er sieht, dass sie noch viel mehr bieten kann.
WOGRA hilft mittelständischen und großen Unternehmen dabei , die komplexen Aufgaben der digitalen Transformation umzusetzen. Dabei unterstützt das Augsburger Unternehmen bei Themen wie der Verbesserung der Kundensicht und -erlebnisse, der Vereinfachung von Unternehmens-prozessen oder bei der Umsetzung neuer Geschäftsideen und –modelle. Geschäftsführer Wolfgang Graßhof und sein Team tun das, indem sie technologische Innovationen nutzen – Methodenkenntnisse anwenden – und die Innovationen in Zusammenarbeit mit den Kunden vorantreiben.
WOGRA bietet das Expertenwissen aus mehr als 100 Softwareprojekten. Mit seiner Lösungskompetenz schafft der Softwaredienstleister Lösungen, die seinen Kunden neue Einnahmequellen eröffnet, Kundenbeziehungen verbessert oder das Wissen aus dem Geschäftsalltag in neue Geschäftsideen und -modelle wandelt.
