Präzise Aufträge erhöhen die Produktivität

Ein im Alltag der Softwareentwicklung nicht seltenes Szenario: Es werden Aufträge ausgeführt, die äusserst unklar formuliert sind, oder solche, welche die Entwickler sich selber gegeben haben. Das führt zu einer latenten Unzufriedenheit der Entwicklungsteams, die ihren Ausdruck in Geringschätzung für Kunden und das eigene Management findet. Das Ergebnis ist, dass man auch dann nicht bekommt, was man will, wenn man einen klaren Auftrag formuliert. Denn für viele Softwareentwickler ist das tatsächliche Erfüllen von klaren Aufträgen etwas ziemlich Unbekanntes.


Die meist einzige Möglichkeit als Kunde oder Chef, sich bei den Entwicklungsteams Respekt zu verschaffen, sind Code-Reviews. Wenn man nur eine Abstraktionsstufe höher steigt und mit dem Entwicklungsteam über Patterns diskutiert, wird man meistens bereits in die Kategorie der Unwissenden eingeordnet und inhaltlich genauso ignoriert wie die normalen Kunden oder Manager. Das hat zwei Gründe: Erstens sind viele Praktiker mit Abstraktionen überfordert. Zweitens haben viele nie gelernt, mit vernünftigem Feedback zu arbeiten, weil sie dieses nie bekommen haben.

Ich erlebe es häufig, dass ich auf mein Nachfragen, was den tatsächlich implementiert worden sei, zuerst diffuse oder widersprüchliche Antworten bekomme, die sich dann scheinbar im Laufe der Diskussion konkretisieren. Aber nur scheinbar. Tatsächlich versucht mein Gegenüber in diesen Gesprächen herauszufinden, was ich gerne höre, um mir dann genau das zu erzählen – und sich diese Erzählung nicht einmal bis zur nächsten Diskussion merkt, bei der er dann etwas völlig anderes erzählt.


Besonders grotesk wird es, wenn man bei einer Diskussion einvernehmlich konkrete Beschlüsse fasst auf der Basis der Angaben der Entwicklungsteams, beispielsweise das Datenmodell ändert. Und wenn sich dann einige Wochen später herausstellt, dass etwas völlig anderes implementiert wurde und der konkrete Beschluss unsinnig war: «Ja, ich habe auch nie verstanden, warum wir hier dieses Datenfeld einfügen sollten.» Nicht selten klopft einem in solchen Augenblicken ein Managementkollege auf die Schulter, um väterlich zu erklären:

«Schau, das ist doch gar nicht unsere Aufgabe, uns mit solchen Details zu beschäftigen. Wir haben Wichtigeres zu tun.» Denn auch auf Seiten von Managern und Kunden ist der Frust riesengross, und sie kompensieren ihn ihrerseits mit Geringschätzung für die Softwareentwickler. So hat jeder seinen Frust und sein Verhaltenskästchen. Dem steht gegenüber, dass es auch anders geht: mit viel weniger Frust und viel mehr Produktivität. Es gibt Kunden, die viel Zeit dafür aufwenden, ihre eigenen Wünsche zu klären und den Entwicklern mitzuteilen. Sie zahlen in der Regel weniger Geld und bekommen mehr Qualität. Und es gibt Manager, die sich nicht auf Personalführung beschränken, sondern sich Zeit nehmen für die inhaltliche Führung der tatsächlichen Entwicklungsarbeit.

Ihre Teams sind sehr produktiv, weil sie klare Vorgaben bekommen, den eigenen Fortschritt an den Vorgaben messen können und zusätzlich durch das faire, weil sachlich kompetente Feedback des Chefs motiviert werden. Doch das setzt voraus, dass Chef und Kunde in ihren jeweiligen Bereichen kompetent sind und sich Zeit nehmen für inhaltliche Präzision und Kontrolle. Mit einem oberflächlichen «Machen Sie mal!» kann man keine hohe Produktivität in der Softwareentwicklung erzielen.