Das Hey-Joe-Prinzip.

Heute geht es weder um Beziehungsdramen wie sie in dem gleichnamigen Lied besungen werden noch um Prozesse im Service-Desk. Wobei hinzuzufügen ist, dass langjähriges Hey-Joe-Anforderungsmanagement sich durchaus zum Wartungsdrama entwickeln kann. Der Begriff des Hey-Joe-Prinzips entstammt genau genommen dem Service Umfeld ist aber ebenso häufig in der Softwareentwicklung zu finden. In der Wikipedia findet sich eine knappe und treffende Definition:

Das Hey-Joe-Prinzip beschreibt die Auswirkungen der im IT-Support problematischen “Nachbarschaftshilfe” (Peer Support), die dabei den vorgesehenen Arbeitsprozess (Workflow) umgeht. Das geschieht, indem der Anwender die Hilfe für eine Problemlösung über eine inoffizielle Anfrage in seinem firmeninternen Bekanntenkreis erfragt, anstelle den eigentlich dafür vorgesehenen Service Desk zu kontaktieren, was plakativ mit „Hey Joe…“ beschrieben wird.

Für einen Anforderungssteller ist das ein höchst verführerisches Prinzip. Wenn der angesprochene Programmierer sich die Zeit nimmt, die Anforderung wirklich umzusetzen, ist das schneller als jeder Dienstweg. Die Probleme tauchen dann in der Regel später an anderer Stelle auf:

• Es treten leicht Terminkollisionen auf, da der Entwickler auch Aufgaben aus dem normalen Entwicklungsprozess erhält.
• Die Hey-Joe-Anforderungen sind meistens weder fachlich noch technisch gut dokumentiert – “auf dem kurzen Dienstweg ist so etwas schließlich nicht nötig” 
• Problematische Altlasten in großen System bestehen häufig aus Bergen von Hey-Joe-Anforderungen.

[sc:adsense]

Da irgendwann aufgrund der Altlasten auch die Hey-Joe-Geschwindigkeit sinkt, überwiegen die Nachteile und es sollte eigentlich ein Leichtes sein für alle einzusehen, dass es besser wäre sich von diesem Prinzip zu verabschieden. Die Realität sieht aber oft anders aus, das Prinzip hält sich mit erstaunlicher Hartnäckigkeit. Das hat mehrere Gründe, der erste liegt im psychologischen Bereich ein weiterer liegt in einem Missverständnis begründet. Zu guter Letzt gibt es tatsächlich Konstellationen in denen das Prinzip Sinn machen kann, diese werden dann gerne als leuchtende Beispiele zitiert, wenn mal wieder erbittert um die Einhaltung des Prozesses diskutiert wird.

Ein Schlüssel zum Verständnis sind die Begriffe “Nachbarschaftshilfe” und “peer” aus der Definition. “Nachbarschaften” und “peer-groups” vermitteln ein Gefühl von Heimat und Sinnhaftigkeit. Der Entwickler enthält direkte Anerkennung von einem Kunden, das liefert Sinnhaftigkeit für die Arbeit. Im direkten Dialog zwischen Anforderer und Programmierer und schnellem gemeinsamen Erfolgserlebnis entsteht das Gefühl gut, wirkungsvoll und sinnvoll gearbeitet zu haben. In einem hoch regulierten Prozess arbeiten viele Entwickler ohne direkten Kundenkontakt, die Anerkennung wird oft vom Projekt- oder Abteilungsleiter abgeschöpft. Die Empfänglichkeit für einen Hey-Joe Ruf ist dann oft nur ein Verlangen nach direkter Anerkennung. Direkte Anerkennung ist noch wichtiger als das Salz in der Suppe. Wenn dann noch eine Unsicherheit des Arbeitsplatzes hinzukommt erscheint ein Ausweichen auf das Hey-Joe- Prinzip gewissermaßen als Rückversicherung. Es erscheint als Möglichkeit sich unentbehrlich zu machen.

Das erwähnte Missverständnis besteht darin, dass “Agile Entwicklung” mit “ohne Prozess” übersetzt wird. Im agilen Manifest heißt es “interaction over processes” und nicht “without processes”. Auch wenn z.B. Scrum mit wenigen Artefakten und Rollen auskommt, so ist der Vorgang der Anforderungserhebung und Umsetzungsplanung hoch reguliert und stellt genau genommen einen “interaktiven Prozess” dar.
Wirklich Sinn macht das Hey-Joe-Prinzip nur in 1:1 Beziehungen zwischen Kunden und Entwickler. Diese finden sich in sehr kleinen Projekten oder in großen Altsystemen, die von (aussterbenden) Spezialisten gewartet werden.

Was ist also zu tun, wenn das Hey-Joe-Prinzip eingedämmt werden soll. Die psychologischen Gründe erschweren eine rein fachliche Diskussion. Reine Überzeugungsarbeit hilft hier nur wenig, es gilt immer auch die gefühlte Anerkennung bzw. das Job-Sicherheitsgefühl im Auge zu behalten.

[sc:adsense]

Nachbemerkung: Der Artikel ist aus der Perspektive der Entwicklung geschrieben. Die psychologischen Momente gelten natürlich auch auf der Seite des Anforderers aus der Fachabteilung. Die Vermittlung des guten Gefühls funktioniert wechselseitig. Mit einer erfolgreich und schnell umgesetzte neue Funktion kann man sich auch schmücken.