Digitalprojekte fielen auch 2022 auf die Nase – und werden ebenso im Jahr 2023 und in den folgenden Jahren fröhlich damit weitermachen. Das klingt heiterer, als es wirklich ist. Sich das Scheitern eines Projekts einzugestehen, ist schmerzhaft und meist teuer für alle Beteiligten. Von Geld über Status bis zum persönlichen Anspruch an sich selbst.
Ein überraschend häufiger Grund ist noch immer, dass Projekte nicht das liefern, was der Kunde wirklich benötigt.
Methoden allein helfen nicht
Es wurden viele Modelle & Ideen entwickelt, um sicherzustellen, dass wir die richtigen Leistungen erbringen. Mittels KANO-Modell werden die Leistungsanforderungen identifiziert, die in umfangreichen Anforderungserhebungen ermittelt wurden. Später in der Entwicklung setzen wir QA-Teams ein, um den Erfolg abzusichern. Und doch haben wir nicht geliefert, was benötigt wird.
Wie kann es sein, dass – nicht selten – völlig an den Bedürfnissen des Kunden vorbeigearbeitet wird?
Wichtige Projekte ziehen Menschen extrem an
Je komplexer und bedeutsamer ein Projekt, desto mehr Menschen haben ein Interesse daran. Sie wollen nicht nur informiert, sondern involviert werden. Die Zahl der Kommunikationsverbindungen wächst. Häufig damit auch die Entfernung zwischen Problemlösern und Problemeigentümern, den Entwicklern und dem Anwender. Comic Agilé hat das schön auf den Punkt gebracht.
In Digitalprojekten haben wir hohe Komplexitäten und Abhängigkeiten. Jeder will involviert werden. Dabei sollten wir aktiv daran arbeiten, den Weg zwischen Anwender und Entwickler zu verkürzen. Die Transaktionskosten, also die Zahl der Mittelsleute im Projekt, aktiv senken.
Veränderungen sind normal
“Das geht doch nicht[, ohne XYZ]!” – Das höre ich immer wieder. Man hat sich eingerichtet und denkt auf bestimmte Roller und Personen angewiesen zu sein. In den seltensten Fällen ist dem wirklich so.
Dabei ist stetige Veränderung der Normalzustand, ob es uns passt oder nicht. Wir sollten hinterfragen, ob die Prozesse so noch wirklich ergebnisorientiert sind. Oder ob wir Mittelsleute beschäftigen, um sie beschäftigt zu halten.
Gleiches gilt für Prozesse. Die Prozesse innerhalb derer wir heute arbeiten haben wir gestern geschaffen. Es gibt keinen Grund, diese nicht heute für ein besseres morgen zu verändern.
Entwicklerpraktika für mehr Verständnis
Ich erzähle gern von einem krasseren Beispiel aus meiner Karriere. Ich war in einem größeren Projekt in Süddeutschland verantwortlich für etwa 100 Entwickler. Der Kunde, eine Behörde, saß in Norddeutschland. Durch Compliance-Vorgaben und Bürokratiegewächse wirkte der Comic Agilé noch harmlos. Zusätzlich waren die Entwickler mit der Fachdomäne überhaupt nicht verbunden und konnten sich nur auf dicke Anforderungsspezifikationen stützen.
Nach wenigen Reviews und einigen Gesprächen war mir klar. Wir müssen die Distanz zwischen Entwicklern und Anwendern stark reduzieren.
In Absprache mit meinem Kunden organisierte ich für meine Entwickler eine “Klassenfahrt” in den Norden. Wir konnten die künftigen Anwender in ihrer Arbeit beobachten. Es wurden extrem viele Fragen gestellt und intensive Diskussionen geführt. Die Entwickler saßen mit den Anwendern am Platz und erkannten, was benötigt wird.
Performance Boost durch Nähe & Verständnis
Die wenigen Tage vor Ort wirkten noch lange nach. Es gab ein völlig anderes Verständnis für die dokumentierten Anforderungen, bei Unklarheit wurde schneller zum Hörer gegriffen und unklare Anforderungen wurden angepasst.
Die nächsten Review-Termine waren ein Fest! Die Entwickler erzählten nicht mehr, welches Feature sie entwickelt haben, sondern sie erklärten, welche Probleme nun gelöst sind. Welchen Vorteil der Anwender jetzt dadurch hat.
Im Projektverlauf haben wir noch zwei dieser Trips unternommen. Generell versuche ich in Projekten meine Problemlöser regelmäßig dem Problem auszusetzen. Je nach Situation auch 1-2 Tage im Projekt.
Money well spent?
“Das ist doch viel zu teuer und eine Verschwendung, wenn ein hoch bezahlter Entwickler mehrere Tage unproduktiv beim Kunden sitzt!”
Ganz und gar nicht. Im Gegenteil! Es gehört zur Aufgabe eines Entwicklers, das zu lösende Problem zu verstehen.
Außerdem werden durch die unbedarfte Beobachtung Arbeitsweisen und Bedürfnisse der Anwender entdeckt, die in keiner Dokumentation stehen. Ganz zu schweigen von dem extremen Mehrwert, der dadurch entsteht, dass der Entwickler die Fachdomäne kennenlernt.
Wenn Entwickler ohne fremde Impulse das Produkt im Sinne der Anwender besser machen, setzt das enorme Potenziale frei. Es stärkt die Selbstorganisation & das Ownership um ein Vielfaches mehr als jeder Workshop.
Was ist beim Versuch, die Kommunikation und das Verständnis zu verbessern, schon zu verlieren?
Setzt eure Entwickler auf den Schoß eurer Anwender!
Thanks Luxshan Ratnaravi for allowing me using your comic strip 🙂
