Das Hey-Joe-Prinzip

Durch | 12. Oktober 2012

Der Begriff des Hey-Joe-Prinzips entstammt 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.
  • Problematische Altlasten in großen Systemen bestehen häufig aus Bergen von Hey-Joe-Anforderungen.

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. In allen übrigen Kontexten überwiegen die Nachteile.

Was ist also zu tun, wenn das Hey-Joe-Prinzip eingedämmt werden soll. Reine Überzeugungsarbeit hilft hier nur wenig, die psychologischen Gründe erschweren eine rein fachliche Diskussion. Wenn Mitarbeiter sich verstärkt dem Hey-Joe-Prinzip zuwenden weist es darauf hin, dass das Bedürfnis nach Anerkennung auf dem anderen Weg nicht befriedigt wird. Es ist daher besonders wichtig die gefühlte Anerkennung bzw. das Job-Sicherheitsgefühl im Auge zu behalten.

 

6 Gedanken an “Das Hey-Joe-Prinzip

  1. Dr. Eberhard Huber Beitragsautor

    Hallo Sarah,

    ich befürworte das Prinzip ja nicht 😉 – ich versuche zu verstehen warum sich das Prinzip so hartnäckig hält. Die in einem Satz umrissene Ausnahme in der das Prinzip okay ist

    “Wirklich Sinn macht das Hey-Joe-Prinzip nur in 1:1 Beziehungen zwischen Kunden und Entwickler.”

    ist genau genommen ein theoretisches Konstrukt. Solche 1:1 Beziehungen gibt es praktisch nicht (mehr). Eine der möglichen prozessualen Antworten auf “Hey-Joe” im betrieblichen Kontext wäre in der Tat “ITIL” – dem Ruf könnte ich mich anschließen,

    LG Eberhard

  2. Sarah

    Ich bin zufällig auf diesen Artikel gestossen – nach nun bald 5 Jahren interessiert mich, ob Sie nach wie vor der gleichen Meinung sind? Persönlich würde ich in der beschriebenen Situation die Rechte in Frage stellen und nach ITIL “schreien”…klar das Hey-Joe Prinzip wird damit nicht 100 % eliminiert – immerhin zu mindestens 50 %!

    Gruss aus der Schweiz, Sarah

  3. Dr. Eberhard Huber Beitragsautor

    Hallo Gebhard, da hast Du wohl recht. Da fällt mir noch das Gebet für Kraft, Geduld und Weisheit ein …

    Kraft, Dinge zu ändern, die sich ändern lassen
    Geduld, Dinge zu ertragen, die sich nicht ändern lassen
    und Weisheit beides voneinander zu unterscheiden.

  4. Gebhard Borck

    oder sich mit all der gegebenen Intelligenz und Vernunft damit abfinden, dass es Hey-Joe immer geben wird 😉 … naturgesetzgleich

Kommentarfunktion ist geschlossen.