Vertrauen ist der Schlüssel

Wie ist Softwareentwicklung ohne Deadlines möglich?

Selim Baykara

(c) Shutterstock / Dooder

Als Programmierer hat man es nicht leicht. Ständig muss man Überstunden machen, zudem soll man immer am Ball bleiben, um die neuesten Entwicklungen nicht zu verschlafen. Und dann ist da noch die Sache mit den Deadlines.

Fast jeder Entwickler hat wohl schon mit solchen Fristen zu tun gehabt, und der Grund, warum sie so verbreitet sind, ist auch relativ klar: Für Vorgesetzte sind sie ein praktisches Mittel, um sicherzustellen, dass ein Projekt zu einem bestimmten Termin auch abgeschlossen ist. Die Erfahrung zeigt aber, dass sich viele Entwickler beim besten Willen nicht in der Lage sehen, realistische Prognosen abzugeben, geschweige denn, die gesetzten Fristen einzuhalten.

Einen Ausweg aus dem Dilemma bietet der Entwickler Dan Milstein. Auf seinem Blog führt er aus, wie er es in der Vergangenheit geschafft hat, zur Zufriedenheit des ganzen Unternehmens Software zu entwickeln, ohne ständig ein Damoklesschwert in Form von Deadlines über sich schweben zu haben. Sein Lösungsvorschlag ist verblüffend simpel: Man sollte sich erst gar nicht auf das Spiel mit den Deadlines einlassen!

Garantien für den Misserfolg

Milstein macht ein Beispiel: Der Chef ruft Sie zum Meeting, präsentiert eine Spezifikation und fragt, ob das Entwickler-Team in der Lage ist, das Projekt in drei Monaten umzusetzen. Vier typische Reaktionen wären dann:

1.) Den Chef sofort nach Unklarheiten in der Spezifikation fragen.

2.) Den Chef auf später vertrösten und die Spezifikation mit ins Team nehmen.

3.) Seinem Ego nachgeben und der gesetzten Deadline zustimmen.

4.) Blockieren und die Deadline strikt ablehnen.

Alle vier Reaktionen sind laut Milstein Garantien für den Misserfolg. Resultat wird im Wesentlichen ein Stück Software sein, mit dem niemand zufrieden ist. Niemand.

Aber was kann man sonst tun?

Statt gleich auf die Deadline-Frage einzugehen, rät Milstein dazu, den Chef höflich aber bestimmt nach dem Unternehmen, seiner Situation, seinen Zielen, seinem Geschäftsmodell, etc. zu fragen. Zwischen dem, was konkret als Softwarelösung gefordert wird, und dem, was das Unternehmen damit eigentlich bezwecken will, besteht nämlich oft ein Unterschied. Als Entwickler muss man sich deshalb in erster Linie nicht an die konkret geforderte Spezifikation halten, sondern herausfinden, was damit eigentlich gemeint ist bzw. welchem konkreten Geschäftsziel die Spezifikation dienen soll.

Es geht darum, das eigentliche Problem zu verstehen, und nicht die vorgeschlagene Lösung. Zitiert wird ein Beispiel von Laura Klein: Wenn jemand sagt, er will einen Toaster im Auto haben, meint er eigentlich damit, dass er morgens zu wenig Zeit hat zu frühstücken.

Entwickler sollten also nicht sofort losrennen und quasi „den Toaster ins Auto einbauen“, sondern zunächst einmal das Problem verstehen und dann nach einer Lösung suchen. Schließlich wurde man als Entwickler nicht eingestellt, um stur Spezifikationen in Code zu gießen, sondern um dazu beizutragen, dem Geschäftsmodell zum Erfolg zu verhelfen. Erst wenn man die Einsicht gewinnt, wie genau die vorgeschlagene Spezifikation dem Unternehmensziel dienen soll, kann man auch erkennen, dass gewisse Teile der Spezifikation wichtig, andere hingegen zu vernachlässigen sind. Nur dann kann man zu einem gegebenen Termin eine Software abliefern, mit der die Vorgesetzten zufrieden sind.

Entwicklung versus Management?

Positiver Nebeneffekt: Durch die Kommunikation über Geschäftsziele bekommen die Manager das Gefühl, es mit jemandem zu tun zu haben, der ernsthaft am Unternehmenserfolg interessiert ist. Auf der anderen Seite werden die Geschäftsleute so wirklich in den Entwicklungsprozess eingebunden – die Fronten zwischen Manager- und Entwickler-Gruppe brechen auf. Durch die Verlagerung des Schwerpunktes auf die zu bewältigende Herausforderung rückt zudem die Fixierung auf eine Deadline in den Hintergrund – ohne dass etwaige Fristen dadurch irrelevant würden.

Und die Deadline?

Nun hatte der Chef aber ja nach Deadlines gefragt. Wie antworten?

Laut Milstein sollte der Entwickler am Ende eines Gespräches eine Zusammenfassung des zentralen Unternehmensziels geben, indem er möglichst viele Worte wiederholt, die der Chef selbst verwendet hatte. Er sollte zu erkennen geben, dass er das Problem verstanden hat und auch die vorgeschlagene Art und Weise, wie die Spezifikation das Problem lösen soll. Dann kommt ein Satz wie: „Großartig, jetzt kann ich herausfinden, mit welchen technischen Mitteln wir die Spezifikation am besten umsetzen können. Ich komme bald mit mehr Infos auf Sie zurück!“

Vertrauen ist der Schlüssel

Im Grunde geht es immer darum, Vertrauen zu gewinnen. Nur wenn zwei Partner einander vertrauen, dass sie die Lage angemessen beurteilen, kann ein Projekt erfolgreich abgeschlossen werden, sagt Milstein. Entwickler müssten sich sicher sein, dass von unternehmerischer Seite aus die richtigen Entscheidungen getroffen würden, die Geschäftsleute wiederum müssten das Gefühl haben, dass die Software auch wirklich die angemessene Lösung für das jeweilige Problem sei.

Softwareentwicklung ist damit letztlich eine Form von Lernprozess für das ganze Unternehmen, da beide Seiten – Entwickler und Geschäftsleute – ein Gefühl für die Anforderungen der Gegenseite entwickeln  und ihre Erwartungen von Zeit zu Zeit auch entsprechend modifizieren müssen.

Aufmacherbild: Deadline. Cartoon Vector Illustration von Shutterstock / Urheberrecht:  Dooder

Verwandte Themen:

Geschrieben von
Selim Baykara
Selim Baykara
Selim Baykara studiert Anglistik, Amerikanistik und Soziologie an der Johannes-Gutenberg-Universität Mainz.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: