Das Hey-Joe-Prinzip

Lesetipps

1. Gut genug Prinzip
2. Open-Closed-Prinzip
3. Code Peer Reviews – ein Rückblick

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.

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.

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.

12 Kommentare »

• 
  

  Christian

  am 8. März 2010 um 08:02 Uhr

  Top Artikel! Ich frag mich, warum mir das alles so bekannt vorkommt.
  Der psychologische Teil zum Schluss trifft allerdings voll zu. Es ist schwer Prozesse zu etablieren, wenn Wertschätzung und Anerkennung dabei nicht berücksichtigt werden.

• 
  

  Marc Binder

  am 8. März 2010 um 08:56 Uhr

  Guter Artikel ja

  Zitat:
  “Reine Überzeugungsarbeit hilft hier nur wenig, es gilt immer auch die gefühlte Anerkennung bzw. das Job-Sicherheitsgefühl im Auge zu behalten.”e

  Das ist sowas von richtig!

• 
  

  Steven Klar

  am 8. März 2010 um 09:20 Uhr

  Bin mir nicht sicher ob ich das alles genau verstanden habe, ist das “Hey Joe”-Prinzip:

  - Arbeitgeber/Vorgesetzter kommt zum Entwickler und erklärt ihm das Problem, Entwickler setzt es um, oder schreibt es sicher irgendwie nieder, um es in naher Zukunft zu lösen (genannte Anerkennung).

  Ist das so richtig, oder hab ich da irgendwas übersehen/falsch verstanden?

• 
  

  Eberhard Huber

  am 8. März 2010 um 09:26 Uhr

  @Christian, Marc … danke

  @Steven … manchmal kommt auch der Chef mit “Hey Joe” um die Ecke. Das eigentliche “Hey Joe” Prinzip ist aber eher jenes, dass ein Kunde am Chef des Entwicklers vorbei eine Anforderung plaziert und sie der Entwickler dann umsetzt.

• 
  

  Steven Klar

  am 8. März 2010 um 10:35 Uhr

  @Ebberhard, Danke für die Erklärung.

• 
  

  Mirko

  am 8. März 2010 um 11:50 Uhr

  Hallo zusammen,
  ich denke es ist – bis zu einer bestimmten Größe – möglich und nötig Entwickler und Kunden zusammen zu bringen, sodass der Entwickler seine Anerkennung bekommt und damit eher über den Service Desk geht (neben anderen Vorteilen, die mir da noch einfallen). Zumindest hat mich das oft motiviert.

• 
  

  Dennis Becker

  am 8. März 2010 um 12:17 Uhr

  Bei uns nennt man das auch den “Flur-Funk” Finde ich persönlich passender.

• 
  

  Eberhard Huber

  am 8. März 2010 um 16:22 Uhr

  @Dennis … Flurfunk ist auch gut, der hat aber noch andere Seiten – oder? Ich kenne den Flurfunk auch als schnelles Kommunikationsmedium – zumindest schneller als die Hauspost

• 
  

  Tommy

  am 8. März 2010 um 18:24 Uhr

  Flurfunk ist doch eher so Gemunkel auf dem Gang, meines Erachtens. Bei uns gabs mal ne zeit lang deskspanking im support. Was sich aber nicht so auf die Motivation der Support-Damen auswirkte.

• 
  

  Sepp

  am 9. März 2010 um 10:49 Uhr

  Sehr guter Beitrag! Kannte das Prinzip vorher nicht.. zumindest nicht namentlich, denn solche oder sehr ähnliche Situationen hatte ich auch schon.

• 
  

  Eberhard Huber

  am 9. März 2010 um 11:55 Uhr

  @Mirko … die Wichtigkeit des Zusammenbringens zwischen Kunde und Entwickler steht außer Frage, es sollte aber kein exklusiver 1:1 Kontakt sein

  @Tommy … beim Begriff “deskspanking” muss ich jetzt passen

  @Sepp … Wiedererkennungswert ist gut.

  @all … gestern hat mir die Praxis noch einen wesentlichen Nachteil des Prinzips klar gemacht, den ich oben nicht erwähnt hatte. Eine “Hey Joe” Anforderung kann für den einen Anwender unglaublich wichtig und für den Entwickler auch plausibel sein, womöglich ist die Funktion für alle anderen Anwender aber unnütz bis ärgerlich. So einen Fall hatte ich gestern vorliegen :rolleyes:

• 
  

  Charly70

  am 3. April 2010 um 17:08 Uhr

  Dass etwas per Hey-Joe einprogrammiert wird, gib’s bei und nicht. Und wäre wohl auf ein Grund für eine Abmahnung. Wie um alles in der Welt sollen die Tester testen, wenn sie von der Änderung nichts erfahren?

  Dass Entwicklerkapazität für Supportanfragen, Analysen etc. per Hey Joe abgezogen wird, ist m. E. ein Scrum-inherentes Problem.
  Scrum ignoriert vollständig, dass Supporter, Vertriebler, etc. unvorhergesehen Entwickleruntersützung brauchen.
  Wenn der PO das nicht einplant, wird’s halt per Hey Joe gemacht, weil der Entwickler weiß, dass die Probleme auf jeden Fall auf seinem Schreibtisch landen. Er kann sie jetzt lösen (wo man noch etwas machen kann) oder nach dem nächsten Sprintmeeting (wenn’s zur Zeitbombe wurde, das unmögliche Angebot draußen ist, die Kundendaten zerschossen sind.)

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar