5 Gründe warum Entwickler noch praxisorientierter Arbeiten müssen

Wie Entwickler eine Brücke zum Nutzer schlagen
1 Kommentar

Zunehmend mehr Unternehmen und Entwickler erkennen, dass das Feedback aus der Praxis in ihre Produktentwicklung mit einfließen muss. Doch auf dem Weg zu einem kundenzentrierten Arbeiten sind einige Hürden zu überwinden.

Eigentlich sollte man davon ausgehen, dass Entwickler ihre eigenen Anwendungen kennen und diese genau auf den Nutzer anpassen. Doch wie kommen die Nutzererfahrung und das Feedback zum Entwickler? Heutzutage unterliegen IT-Abteilungen großer Unternehmen einer sehr hohen Dynamik, die mitunter zulasten der Transparenz gehen kann.

Damit die Beziehung von Entwickler und Anwender kein tragisches Ende wie bei Romeo und Julia nimmt und die beiden Liebenden doch noch zueinander finden, gibt es einen kurzen Rückblick, Einblick, und Appell an Software-Häuser, Kunden und Nutzer, zuzuhören und das Schweigen zu brechen! Wir widmen uns nachfolgend 5 unglücklichen Umständen und den Best Practices für eine praxisorientiertere Entwicklung.

Umstand #1 – One-Man-Show

Teilweise existiert die Vorstellung des einsamen „Rockstar“-Entwicklers, der eine Anwendung von A bis Z entwickelt, um damit eine ganz spezielle Anforderung zu erfüllen. Diese Einzelgänger gibt es durchaus – nur nicht in großen Unternehmen. Naturgemäß haben diese unabhängigen Entwickler, zumindest zu Beginn, beim Programmieren ihre eigenen Bedürfnisse im Sinn. Oftmals sind sie selbst intensive Nutzer ihres eigenen Produkts. Bei umfangreichen Unternehmensanwendungen mit großem Funktionsumfang jedoch ist das fast nie der Fall. Entwickler und Nutzer haben selten direkte Berührungspunkte.

Umstand #2 – Der Code in der Montagestraße

Wohl kaum ein Entwickler wird in seiner Freizeit aus reiner Freude ein CRM-System oder ein Finanzanalysepaket programmieren. In traditionellere Unternehmensanwendungen fließt also nicht so viel Herzblut wie in Projekte, die den Entwickler persönlich begeistern. Zusätzlich existiert häufig eine immense Codebasis, die bereits mehrere Jahre alt ist, was im Übrigen öfter der Fall ist. Es ist üblich, dass Unternehmensprodukte über Jahrzehnte hinweg weiterentwickelt werden, sodass Entwickler den gesamten Code nicht immer kennen. Sie programmieren ihren Anteil, führen die Unit-Tests durch und geben an ein anderes Team ab, das für Integration und User Acceptance zuständig ist. Anwendungsentwicklung ist also eine Art anonyme Montagestraße für Code.

Umstand #3 – Isolierte Beschaffungsprozesse im Unternehmen

Ein weiterer Grund für diese Kluft in der Unternehmens-IT ist gleichzeitig auch für andere Schwachstellen verantwortlich: Endnutzer von Produkten treten selten mit den Softwareherstellern in Kontakt. Dieser beschränkt sich nämlich oft auf den Einkäufer im eigenen Unternehmen, der das Budget freigibt, sodass die Systemadministratoren, die das Produkt jeden Tag nutzen, oftmals keinen Kontakt mit dem Anbieter haben. Das macht es für Entwickler schwierig, die Bedürfnisse des eigentlichen Kunden einzuschätzen. Beiden Seiten entgeht somit eventuell wertvolles Feedback aus erster Hand.

Umstand #4 – Der Elfenbeinturm

Dass sich ein Endverbraucher direkt beim Entwickler-Team meldet, ist nahezu auszuschließen. Umgekehrt werden sich beschäftigte Entwickler nicht die Mühe machen und fürsorglich beim Endnutzer nachfragen, ob alles gut funktioniert. Schade eigentlich. Entwickler sitzen erstmal in ihrem Elfenbeinturm und bauen sich die Welt wie es ihrer Meinung nach funktionieren müsste. Für die Endnutzer ist oftmals nicht ganz klar, wie sie sich mit Benutzererfahrung an die Hersteller und somit auch die Entwickler wenden können. Ein kollaborativer Prozess, der Hauptnutzer, Entwickler und Produktmanager involviert, bietet dabei aber die besten Chancen auf die erfolgreiche Entwicklung eines Produkts, das von seinen Anwendern tatsächlich gerne genutzt wird.

Umstand #5 – Aufatmen und auf dem richtigen Kurs bleiben

Es hat sich vieles getan. Viele Unternehmen, gerade Anbieter für Unternehmenssoftware, haben erkannt, dass es wichtig ist zuzuhören. Ebenfalls kommt der Top-Down-Mechanismus zur Auswahl von Software-Tools in Unternehmen glücklicherweise immer seltener zur Anwendung. Die Zeiten, als der Chef eingekauft hat, was er für richtig gehalten hat, sind endgültig vorbei. Es zeigen sich deutliche Anzeichen für das Entstehen einer Feedback-Kultur. Nicht nur im Unternehmen, sondern auch Softwareanbieter und –hersteller haben die Relevanz von Benutzererfahrungen aus der Praxis für ihr Produkt erkannt. Das direkte Feedback der Nutzer einer Software kann schon mal über die Zukunft der Software entscheiden. Auch in der Programmierung ist es wertschöpfend, „social listening“ in das Produktmanagement einfließen zu lassen.

Jede Lösung braucht einen Architekten

Man sieht am Massenphänomen Social Media, dass sich Menschen gerne virtuell mitteilen, austauschen und sich auch Hilfe suchen, (man denke an die How-to-Anfragen und -Angebote) so auch zu Software. Soziale Medien oder Drittanbieter-Foren sind für Entwickler Kanäle, um wertvolles Feedback zu erhalten. Zudem bieten Softwareanbieter immer öfter eigene, lokale Feedback-Plattformen wie Kundenforen oder andere Feedbacktools direkt auf ihren Websites an. Wir sehen zunehmend Instanzen wie ein Social Media-Team, das die Augen und Ohren auf allen Kanälen hat und dieses direkte Feedback als dezidiertes Wissen an die Produkt-Teams zurückspielt.

Eine weitere Lösung, um die Brücke vom Entwickler hin zum Nutzer zu schlagen, könnte ein Solution Architekt sein. Gerade im Bereich der Unternehmenssoftware kann er als Bindeglied fungieren und übersetzt das direkte Kundenfeedback in handlungsfähigen Input für die Entwickler- oder Produktmanagement-Teams. Eine Instanz wie der Solutions- oder Software-Architekt, der bei der Produktentwicklung eingebunden ist, filtert die gesammelte Benutzererfahrung, kanalisiert sie, und leitet sie vor allem an die richtigen Teams weiter.

Der Trend ist klar – zunehmend mehr Unternehmen und Entwickler erkennen, dass das Feedback aus der Praxis in ihre Produktentwicklung mit einfließen muss. Wer das direkte Feedback nicht aufgreift, sei es durch dezidierte Teams oder anders geschaffene Ressourcen, entgeht einem wertvollen Input. Priorisierungen bei Produkt-Releases oder sogar das Vermeiden eines Shitstorms, welcher Unternehmen bekanntlich viel Geld oder den Ruf kostet, sind der Beachtung des Kunden- und Community-Feedbacks zu verdanken. Für jedes Problem gibt es eine Lösung. Hier heißt sie wie so oft Kommunizieren.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

1 Kommentar auf "Wie Entwickler eine Brücke zum Nutzer schlagen"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Veronika Schäfer
Gast

Schöner Artikel!
Hinzu kommt meiner Meinung nach in modernen Unternehmen noch der holistische DevOps-Ansatz, der diese Brücke (4) ja schlagen soll.
https://www.eduup.de/blog/devops-erklaerung-definition
Mit Sicherheit ist auch dieser kein Allheilmittel, allerdings habe ich schon wirkliche positive Veränderungen durch die Implementierung von DevOps in verschiedenen Unternehmen erlebt.

X
- Gib Deinen Standort ein -
- or -