Es gibt einen Satz, den jede Person kennt, die schon einmal in einem Entwicklungsteam über nichtfunktionale Anforderungen diskutiert hat. Er fällt freundlich, meist mit einem Nicken, und er beendet die Diskussion zuverlässiger als jedes Gegenargument:

„Machen wir später.“

Gemeint sind damit fast immer dieselben Themen. Performance. Wartbarkeit. Sicherheit. Betriebskosten. Barrierefreiheit. Und seit einiger Zeit auch Nachhaltigkeit. In der Sprache der Softwareentwicklung heißen sie nichtfunktionale Anforderungen, und der Name ist schon das halbe Problem. Er sagt, was sie nicht sind.

Ich habe in fünfundzwanzig Jahren in IT-Organisationen kein Programm erlebt, in dem das anders gewesen wäre. Nicht weil dort schlechte Leute arbeiten. Sondern weil das System, in dem priorisiert wird, diese Themen strukturell benachteiligt.

Warum nichtfunktionale Anforderungen verlieren

Ein Feature hat drei Dinge, die eine nichtfunktionale Anforderung nicht hat.

Es hat einen Termin. Irgendjemand hat schließlich zugesagt, dass es im dritten Quartal da ist. Ein Termin erzeugt Druck, und Druck erzeugt Priorität.

Es hat einen Fürsprecher. Eine Person, die im Sprint Review fragt, wo es bleibt. Deshalb kommt eine Anforderung ohne Anwalt im Backlog nach unten, egal wie richtig sie ist.

Und es hat eine Zahl. Umsatz, Nutzerzahlen, Vertragsstrafe, eingesparte Bearbeitungszeit. Etwas, das man in eine Zeile schreiben kann.

Nichtfunktionale Anforderungen haben stattdessen ein Adjektiv. Sie sind „wichtig“. Sie sind „eigentlich überfällig“. Sie sind „ein Thema, das wir angehen sollten“. Und solange eine Anforderung nur eine Haltung ist, verliert sie gegen jedes Feature mit einem Datum. Nicht in einer offenen Auseinandersetzung, sondern leise, Sprint für Sprint, durch Verschieben.

Das erklärt auch, warum Leitbilder an dieser Stelle so wenig ausrichten. Ein Bekenntnis zu Nachhaltigkeit oder Qualität verändert die Priorisierungslogik nicht. Es fügt dem Wettbewerb um Kapazität nur eine weitere Haltung hinzu.

Der Moment, in dem sich das dreht

Was ich dagegen immer wieder erlebt habe: wie schnell dieser Mechanismus kippt, sobald jemand eine Zahl auf den Tisch legt.

Vorher lautet die Formulierung: „Da sollten wir mal drauf achten.“

Zunächst stimmen alle zu. Jemand sagt, man müsse das Thema größer aufhängen. Trotzdem entsteht keine Story im Sprint.

Nachher lautet sie: „Dieser Job kostet uns achthundert Euro im Monat und ließe sich halbieren.“

Jetzt fragt jemand, wie lange das dauert. Jemand anderes fragt, ob es auch für die anderen sechs Jobs gilt. Und plötzlich wird nicht mehr über Wichtigkeit diskutiert, sondern über Reihenfolge.

Dabei ist der Unterschied keine Frage der Überzeugungskraft. Es ist eine Frage der Vergleichbarkeit. Ein Backlog ist ein Ort, an dem Dinge gegeneinander abgewogen werden. Was keine Vergleichsgröße mitbringt, kann nicht abgewogen werden. Es kann nur bewundert oder vertagt werden.

Der Umweg, der keiner ist: Kosten und Nachhaltigkeit

An dieser Stelle lohnt ein genauerer Blick, denn er ist der eigentliche Hebel.

Nachhaltigkeit in der Softwareentwicklung wird meist als Wertefrage verhandelt. Das ist ehrenwert und in der Priorisierung wirkungslos. Es gibt aber einen Umstand, der die Sache entscheidend verändert: In der Cloud korreliert der Ressourcenverbrauch eng mit den Kosten.

Was Emissionen verursacht, ist im Wesentlichen Rechenzeit, Speicher und Datenübertragung. Genau das sind auch die Positionen auf der Rechnung. Wer die Laufzeit einer Abfrage halbiert, halbiert die CPU-Sekunden. Wer ein Datenformat verkleinert, überträgt weniger Bytes. Wer eine überdimensionierte Instanz verkleinert oder eine ungenutzte abschaltet, spart beides gleichzeitig. Dieselbe Maßnahme, zwei Effekte, ein Argument.

Deckungsgleich ist das ausdrücklich nicht, und die Unterschiede sind keine Randnotiz. Aber die Korrelation ist stark genug, um eine Diskussion zu tragen. Das ist der Grund, warum das Gespräch über Kilowattstunden regelmäßig im Sand verläuft und das über die Cloud-Rechnung fast nie. Es sind nicht zwei Themen. Es ist dasselbe Thema in zwei Sprachen, und nur eine der beiden hat ein Budget.

Wo die Korrelation trägt: ungenutzte und überdimensionierte Ressourcen, unnötige Wiederholungen und Neuberechnungen, zu große Datenmengen in Übertragung und Speicherung, permanente Dauerlast, wo Batchbetrieb genügen würde, ineffiziente Abfragen. Zusammen ist das der größte Teil dessen, was in der Praxis anfällt.

Wo die Rechnung nicht aufgeht

Es gibt vier Stellen, an denen die Korrelation bricht. Sie gehören zur Redlichkeit dazu.

Der Strommix. Dieselbe Rechenlast verursacht in einer Region mit hohem Anteil erneuerbarer Energien deutlich weniger Emissionen als anderswo. Auf der Rechnung sieht man davon allerdings nichts. Eine Verlagerung kann deshalb ökologisch viel bewirken und ökonomisch neutral bleiben.

Die Hardware selbst. Ein erheblicher Teil der Emissionen entsteht bei der Herstellung von Geräten und Servern, lange bevor sie eingeschaltet werden. Ökologisch spricht das zwar für lange Nutzung, ökonomisch oft für schnelleren Austausch gegen effizientere Modelle. Damit laufen die beiden Logiken auseinander.

Der Rebound-Effekt. Was billiger wird, wird mehr genutzt. Eine Effizienzsteigerung, die zu einem Vielfachen an Nutzung führt, kann die Bilanz verschlechtern, während die Stückkosten sinken. Dieser Zusammenhang ist alt. William Stanley Jevons beschrieb ihn 1865 an Englands Kohleverbrauch, der nach Einführung effizienterer Dampfmaschinen stieg statt zu sinken. Das Jevons-Paradoxon gilt für Rechenzentren genauso.

Rabatte und Reservierungen. Wer Kapazität langfristig bucht, senkt seine Kosten, ohne ein Watt zu sparen. Die Rechnung sinkt, der Verbrauch bleibt.

Daraus folgt kein Grund, die Kostenperspektive zu verwerfen. Es folgt eine Einordnung: Kosten sind ein sehr guter Näherungswert, kein Ersatz. Für die Frage, welche der zwanzig offenen Punkte in den nächsten Sprint gehören, ist ein Näherungswert vollkommen ausreichend. Für die Frage, ob ein Unternehmen seine Klimaziele erreicht, ist er es dagegen nicht.

Wer das für sich klärt, kann beides sauber trennen: Priorisierung über Kosten. Berichterstattung über Emissionen. Und die angenehme Erfahrung, dass die meisten Maßnahmen in beiden Richtungen wirken.

Drei Hebel, die nichtfunktionale Anforderungen priorisierbar machen

1. Eine einzige Kennzahl statt eines Dashboards. Wer fünf Metriken gleichzeitig einführt, hat die Diskussion wieder verloren, weil niemand mehr weiß, worauf zu optimieren ist. Eine Zahl, die alle verstehen und beeinflussen können, schlägt zehn präzise, die niemand anschaut.

2. Die Kennzahl in Geld übersetzen. Nicht, weil Geld das wichtigere Argument wäre, sondern weil es das anschlussfähige ist. Denn es gibt in jedem Unternehmen einen Prozess für Kostenentscheidungen. Für Haltungsentscheidungen gibt es keinen.

3. Sie in die Akzeptanzkriterien schreiben, nicht ins Leitbild. Was nicht in der Definition of Done steht, findet nicht statt. Priorisierung entsteht im Ticket, nicht im Workshop. Das ist der unspektakulärste der drei Punkte und der, an dem es am häufigsten scheitert.

Was bleibt

Der Reflex, das Thema größer aufzuhängen, ist verständlich und führt selten irgendwohin. Was hilft, ist kleiner: eine Zahl, die im selben Raum liegt wie die Entscheidung, und ein Ticket, in dem sie steht.

Wer nichtfunktionale Anforderungen durchbekommen will, muss sie nicht wichtiger machen, sondern vergleichbar.

Ich arbeite als Coach mit Fach- und Führungskräften in IT-Organisationen, die solche und andere Prioritätenkämpfe führen.