Entwicklung als Schatzsuche

Deadlines und Development: Wie man sinnvoll mit Termindruck umgeht

Thomas Gude

© Shutterstock / GUDKOV ANDREY

Deadlines – Entwickler werden immer wieder von ihnen heimgesucht. Bedrohlich schreitend wie ein Komodowaran, sich langsam heranschleichend, vertrauen sie stets darauf, dass ihre Opfer im entscheidenden Moment zu überfordert sind. Ihre Beute zerkleinern sie dann mit ruckartigen Kopfbewegungen; also, die Warane, nicht die Deadlines. Wer ihnen erliegt, leidet eher an Erschöpfung und Entnervung. Das muss nicht sein. Der Schlüssel zum Überleben: zusammenarbeiten und die Gefahr garnicht erst aufkommen lassen.

Nun sind die Beschwerden über Deadlines kein neues Phänomen und ebenfalls keines, das nur in der IT-Welt bekannt ist. Warum sorgt das Thema aber gerade dort für so viele Probleme? Viktor Charypar hat als Ursache ein falsches Verständnis des Entwicklungsprozesses ausgemacht.

Entwicklung als Schatzsuche

Er versucht die Sache anhand eines Beispiels zu erläutern. Kunden würden sich Software-Programmierung häufig zu mechanisch vorstellen, was der Realität aber kaum Rechnung trage. Charypar bemüht das Bild der Errichtung eines Hauses. Dabei liegt ein Bauplan vor, der von den Arbeitern – häufig zum wiederholten Male – ausgeführt wird. Da das Vorhaben bekannt ist, kann eine vergleichsweise genaue Angabe über die benötigte Zeit bis zur Fertigstellung gemacht werden.

Anders bei der Software-Entwicklung: hier gibt es keinen exakt auf ein Problem zugeschnittenen Plan, der nur noch in mechanischen Arbeitsschritten vollzogen werden muss. Stattdessen muss überhaupt erst das Problem definiert werden, denn das ist häufig genug nicht wirklich klar. Im Prinzip ist Software-Entwicklung eben dieser Prozess der Problemdefinition, gewissermaßen in Tateinheit mit der Lösungsfindung. Da diese stets von neuem angegangen werden muss, ist zwar eine informierte Schätzung über den Entwicklungszeitraum grob möglich, eine akkurate Eingrenzung jedoch nicht. Jonathan Hochman erinnert dementsprechend daran, dass etwas Glück ebenfalls eine Rolle spielt:

Writing code is like a treasure hunt.

Der Faktor Zufall sollte also berücksichtigt werden. Er steht aber genau im Widerspruch zur Idee der Deadline. Die festen Ansagen, die sie fordert, werden vom Zufall über den sprichwörtlichen Haufen geworfen. Im schlimmsten Fall erweisen sie sich als zu knapp gesetzt. Dann leidet der Workflow des Teams, die Gesundheit der Teammitglieder und letztendlich die Qualität des Produkts.

Erschwert wird die Problemdefinition dadurch, dass häufig nicht klar ist, was der Kunde überhaupt will, weil es ihm nämlich selbst nicht ganz klar ist. Dabei geht es meistens um die Spezifikation der gewünschten Features, deren endgültige Gestalt erst während der Entstehung des gesamten Produkts wahrnehmbar wird. Aber wie soll das Team das Projekt des Kunden umsetzen, wenn ihm die Details seiner Vision unbekannt sind. Damit dringen wir zum Kern des Problems vor.

Kooperation fördern

Deadlines gehen von einer Trennung von Kunde und Team aus: der Auftrag wird abgegeben, es wird gewartet, am Fertigstellungstermin ist die Enttäuschung schließlich groß. Deadlines schreiben diese schlechte Form der Arbeitsteilung fest und nötigen Entwicklern auf, ihre Job als genau den mechanischen Prozess zu betrachten, der oben als unpassend kritisiert wurde. Doch wer Forderungen nur stoisch abarbeitet, wird seinem Auftraggeber kein Partner sein können, soll heißen: jemand der das Geschäftsmodell voranbringt. Im Interesse beider Parteien ist eine andere Art von Zusammenarbeit nötig.

Diese beinhaltet ein differenzierteres Kommunikationsverhalten. Statt nur die Liste der Features vorzulegen bzw. abzustottern, sollten Entwickler und Kunden gemeinsam eruieren, welche Features wirklich wichtig sind und was sie leisten sollen. Die Entwickler sollen ein möglichst präzises Bild von den Ideen und Prioritäten ihrer Auftraggeber bekommen, um die Spezifikationen entsprechend ausarbeiten zu können. Während dieses Gesprächs ergibt sich noch dazu die Gelegenheit, die eigene Expertise einzubringen, Einschätzungen über das Ausmaß einzelner Softwart-Aspekte abzugeben, Überflüssiges auszusortieren und Vorschläge zu machen, die das Projekt abrunden.

Lesen Sie auch: Wie ist Softwareentwicklung ohne Deadlines möglich?

Während des Entwicklungsprozesses macht es für Kunden Sinn, Präsenz zu zeigen. So können nicht nur Fehlentwicklungen frühzeitig gestoppt werden, sondern außerdem noch neue Features ausgearbeitet werden. Währenddessen schält sich langsam aber sicher ein Bild über das Projekt heraus, was gleichzeitig realistische Einschätzungen über die Dauer der Programmierung erlaubt. Abstrakte Deadlines treten so zunehmend in den Hintergrund und werden durch konkretere, gemeinsam erarbeitete Zeiträume ersetzt.

Fazit

So bricht die Front zwischen Programmierern und Kunden auf, die Arbeit verwandelt sich in ein gemeinsames Projekt. Nicht nur vereinfacht dieser Prozess den Entwicklern ihre Aufgabe, auch die Auftraggeber bekommen das Gefühl, mit Leuten zusammenzuarbeiten, die Interesse am Projekt haben. Sofern sie überhaupt noch notwendig sind, verwandeln sich Deadlines, die sonst als Forderung von außen kommen, in das Ergebnis eigener, souveräner Entscheidungen. Damit verlieren sie auch ihren Raubtiercharakter, der sie den Komodowaren sonst so ähnlich macht.

Aufmacherbild: Komodo dragon is on the ground via Shutterstock / Urheberrecht: GUDKOV ANDREY

Verwandte Themen:

Geschrieben von
Thomas Gude
Thomas Gude
Thomas Gude studiert Buch- und Medienpraxis an der Goethe Universität Frankfurt am Main und arbeitet seit August 2015 als Werkstudent bei Software & Support Media. Vorher hat er Politikwissenschaft und Politische Theorie in Hannover und Frankfurt am Main studiert.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Deadlines und Development: Wie man sinnvoll mit Termindruck umgeht"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Maddin
Gast
Diese Aussage könnte man wirklich in Granit meißeln und auf den Mond schiessen, damit es auch die Ausserirdischen kapieren, bovor sie auf die Erde kommen und sich über die unprofessionelle Software-Entwicklung wundern. „Anders bei der Software-Entwicklung: hier gibt es keinen exakt auf ein Problem zugeschnittenen Plan, der nur noch in mechanischen Arbeitsschritten vollzogen werden muss. Stattdessen muss überhaupt erst das Problem definiert werden, denn das ist häufig genug nicht wirklich klar. Im Prinzip ist Software-Entwicklung eben dieser Prozess der Problemdefinition, gewissermaßen in Tateinheit mit der Lösungsfindung. Da diese stets von neuem angegangen werden muss, ist zwar eine informierte Schätzung über… Read more »