Ich bin jetzt seit über 20 Jahren im IT-Bereich, davon einige Zeit als Entwickler, und wenn ich ein immer wiederkehrendes Muster sehe, dann, dass diejenigen, die versuchen unnötigen Druck auf Entwickler oder Techniker auszuüben, fast immer das Gegenteil erreichen. Das verstehen sie meistens nicht, weil sie sich im Recht sehen. Aber es ist eigentlich ganz einfach zu verstehen.
In diesem Artikel werde ich mich eines Instruments bedienen, dessen Urheber ich nicht kenne, und ich wäre superdankbar, wenn das jemand aufklären könnte. Irgendwann vor 20 Jahren brachte mir das mal ein IBMler oder so bei, und ich finde es immer noch beeindruckend.
Das Instrument funktioniert so: In der Grafik ist ein Projektgegenstand als Quadrat aufgezeichnet mit 4 Dimensionen, Qualität, Quantität, Geld und Zeit. Und in der Mitte ist die Produktivität des Teams, P. Wenn ich etwas ändern möchte, zum Beispiel den Liefergegenstand in weniger Zeit erhalten, dann muss ich die Fläche von P anders verteilen, denn die Fläche von P bleibt immer gleich. Ich kann also P auf der Achse der Zeit nach unten schieben (daher das Minus für weniger) und muss dann aussuchen, wie viel ich von den anderen Parametern Qualität, Quantität und Geld ich modifizieren möchte, damit die Fläche von P gleich bleiben kann. Ich kann zum Beispiel sagen, ok, dann gehe ich bei der Quantität runter (Richtung -), oder bei Quantität runter und bei Geld hoch, wie auch immer. Aber ich muss halt irgendwo was ändern, um die Änderung eines Parameters ändern zu können. Das ist ganz gut zu sehen in dem zweiten Bild.
Denn hier wurde das genau durchgeführt: Weniger Zeit, dafür aber auch weniger Quantität. Vollkommen logisch, oder?
Nun ist es aber so, dass manche denken, sie könnten P vergrößern, indem sie Druck ausüben. Das ist manchmal auch so. P kann temporär vergrößert werden. Und wenn wir ehrlich sind, wenn man das nicht akzeptiert, dann ist man in dieser Branche falsch. Gehört dazu. Weil man zum Beispiel weiß, dass von einem Launch-Datum sehr viel abhängt. Weil man selber viel investiert hat an Herzblut und sein Baby zum Laufen bekommen möchte. Er muss also gar nicht immer von außen kommen, der Druck. Denn wenn ein Entwickler die Notwendigkeit sieht, dann wird sie oder er immer alles dafür tun, dass es funktioniert. Ist so eine Art Ehrencodex. Ich kann schlecht damit leben, wenn ich nicht richtig abgeliefert habe, obwohl ich es versprochen habe. Und mir sind dann auch die Nachtschichten egal.
Allerdings kann P nicht ewig vergrößert werden. Irgendwann ist der Ofen aus. Man kann nicht mehr. Oder man sieht nicht mehr ein, warum immer so schlecht geplant wird. Oder, noch schlimmer, man sieht nicht, warum überhaupt P vergrößert werden muss, wenn Gründe angeführt werden, die am Ende des Tages nicht wirklich sinnvoll oder sogar übertrieben sind. Ich habe während der Dotcom-Zeit mal zufällig mitbekommen, dass eine Produktmanagerin sagte, dass der Druck auf mein Team immer hoch bleiben müsse. Das war nicht für meine Ohren bestimmt. Aber sie hatte auch nicht eingesehen, warum das nicht gesund ist. Irgendwann gehen die Leute. Und dann gehen meistens die Besseren. Die, die nicht gut sind und auch nicht bereit sind, die Extra-Meile zu gehen, die bleiben. Und die, die bereit sind zu investieren, weil sie ihren Job verdammt gerne machen, die gehen. Weil sie es nicht einsehen. Ständiger Druck bringt also nichts, ganz im Gegenteil. Kurzfristig vielleicht, aber man zahlt zigfach drauf, weil die Besten gehen. Und dann ist P noch kleiner. Und es dauert lange, bis ein neuer Kollege so eingearbeitet ist, dass P wieder auf dem alten Stand ist.
Schlimmer noch, man macht sich sich als Druckgeber auch noch unglaubwürdig. Vor allem wenn es dann heißt “Wir müssen doch zusammenhalten im Team.” Das ist so wie “Mensch, ja, Du trägst mich zwar auf Deinen Schultern, aber wir müssen zusammenhalten, also geh doch noch mal weiter.” Manchmal meinen diese Menschen es auch gar nicht so. Sie haben selber Deadlines und sie geben den Druck auch noch weiter. Ok. Aber wenn ein Team eh schon sehr viel zu tun hat und dann noch jemand kommt, dann darf man sich auch nicht wundern, dass P eben nicht größer geht, wenn es eh schon freiwillig (!) vom Team vergrößert wurde. Und dann wird das eben irgendwann nicht mehr getan.
Hinzu kommt, dass jede Eskalation nur noch mehr Zeit kostet. Jede E-Mail, wann etwas fertig wird, jedes Meeting, nichts führt dazu, dass der Tag mehr Stunden hätte. Im Gegenteil. Man klaut den Menschen, die die Arbeit tun müssen, einfach nur noch Zeit, die sie eigentlich bräuchten, um ihre Aufgaben zu erfüllen. Jedes “Ich brauche das aber unbedingt heute noch” bedeutet eben nicht, dass der Tag dadurch mehr Zeit hätte oder andere Deadlines aufgegeben werden können. Das müsste eigentlich auch dem Druckgeber klar sein. Aber so wird es eben gerne gespielt. Mit dem gegenteiligen Effekt.
Wie kann man das lösen? Ich zeichne zum Beispiel immer gerne dieses Quadrat auf. Und erkläre, dass P nur temporär vergrößert werden kann, wenn ich glaubhaft machen kann, warum. Manche Entwickler erhöhen P intrinsisch. Aber eben auch nicht ewig. Und ich werde mich immer vor mein Team stellen, wenn P eben nicht weiter sinnvoll erhöht werden kann und der Druckgeber auch noch unfair spielt. Die Erfahrung zeigt auch, je weiter der Druckgeber verständnistechnisch von dem entfernt ist, was die Entwickler tun, desto größer der unnötige Druck. Erfahrungen aus 20 Jahren. Trotz aller neuen Methoden, Prozesse… nichts hat die Gültigkeit von diesem Quadrat verändern können. Take it or leave it.