„Das ist nur eine Sekunde“
Jeder, der an der Erstellung oder Wartung einer Website, App oder eines Systems arbeitet, kennt diese Aussage.
„Könnt ihr nur diesen Button ändern?“
„Das ist wirklich eine kleine Korrektur.“
„Bitte verschiebt nur dieses Element.“
„Kann man das schnell machen?“
„Das sind doch bestimmt 5 Minuten Arbeit?“
Und manchmal ist dem tatsächlich so.
Manchmal dauert das Ändern der Button-Farbe nur wenige Minuten. Manchmal reicht ein Klick, um einen Tippfehler zu beheben. Manchmal öffnet der Entwickler den Code, sieht es, ändert eine Zeile und fertig.
Das Problem ist, dass nicht jede Änderung, die aus Nutzersicht klein erscheint, aus Systemsicht ebenfalls klein ist.
Und noch größer wird das Problem, wenn solche „kleinen Änderungen“ zehn, zwanzig oder hunderte Mal im Monat vorkommen. Dann passiert etwas Interessantes.
Das Unternehmen kann den Eindruck haben, dass es eigentlich nichts Großes bestellt. Gleichzeitig verbringt das IT-Team einen beträchtlichen Teil seiner Zeit mit genau diesen kleinen Aufgaben.
Und hier stellt sich die Frage: Was kostet wirklich ein Button „Korrigiert das schnell“?
Fangen wir mit einem einfachen Beispiel an
Stell dir vor, die Marketingabteilung schickt an das Softwarehaus die Nachricht:
„Hey, wir müssen nur den Text auf dem Button ändern. Statt ‚Angebot prüfen‘ sollte dort ‚Angebot entdecken‘ stehen. Das ist eine kleine Sache, macht das bitte schnell.“
Klingt banal. Technisch kann das aber ganz anders aussehen.
Der Entwickler muss:
1. Das Ticket analysieren
Wo befindet sich der Button?
Ist er nur an einer Stelle vorhanden?
Tritt er auf mehreren Seitenvarianten auf?
Ist der Text direkt im Code eingetragen?
Wird er über ein CMS gesteuert?
Betrifft die Änderung Desktop- und Mobilversion?
Ist der Button Teil einer Komponente, die anderswo wiederverwendet wird?
2. Die Änderung durchführen
Text ändern.
Komponente umbauen.
Inhalte im CMS aktualisieren.
Oder Code anpassen.
3. Das Ergebnis prüfen
Sieht der Button weiterhin korrekt aus?
Passt der Text in den verfügbaren Bereich?
Funktioniert alles auf dem Smartphone?
Hat die Änderung andere Stellen beeinflusst?
4. Testen
Ist der Button klickbar?
Leitet der Link dahin, wo er soll?
Ist kein Fehler entstanden?
5. Rollout
Wenn ein Deploy nötig ist, muss die Änderung in die Produktionsumgebung gebracht werden.
Und plötzlich stellt sich heraus, dass: „Nur Text ändern“
nicht unbedingt heißt: „Nur 5 Minuten Arbeit“.
Was kann eine kleine Änderung kosten?
Nehmen wir ein sehr konservatives Szenario an.
Der Entwickler verbringt:
- 15 Minuten mit Analyse,
- 20 Minuten mit Implementierung,
- 15 Minuten mit Tests,
- 10 Minuten mit Vorbereitung und Deployment.
Insgesamt: 60 Minuten Arbeit.
Und hier ist ein wichtiger Punkt: Wenn der Stundensatz des Teams z. B. 200 Zloty netto beträgt, kostet eine scheinbar kleine Änderung etwa: 200 Zloty netto.
Aber das ist noch nicht alles. Im realen Prozess können noch hinzukommen:
- Übergabe des Tasks,
- Präzisierung des Umfangs,
- Fragen an den Kunden,
- Warten auf Rückmeldung,
- Prüfung durch die anfragende Person,
- Nachbesserungen nach Feedback,
- erneutes Deployment.
Eine Stunde kann also sehr leicht zu zwei Stunden werden. Und aus einer kleinen Änderung können mehrere Stunden Arbeit des gesamten Teams werden.
Am teuersten ist oft nicht die Ausführung
Das mag paradox klingen. Manchmal dauert die eigentliche Ausführung 10 Minuten. Aber die Vorbereitung kostet weitere 20 Minuten. Dann kommen Tests, Deployment, Kommunikation und Context-Switching hinzu.
Und gerade dieser letzte Punkt wird oft unterschätzt.
Context Switching – die versteckten Kosten kleiner Aufgaben
Ein Entwickler arbeitet an einem großen Feature. Er hat den Code offen. Er analysiert, ist fokussiert.
Plötzlich kommt die Nachricht: „Hey, nur eine kleine Sache. Kannst du den Button korrigieren?“
Der Entwickler unterbricht seine Arbeit. Öffnet das Ticket. Checkt die Seite. Sucht die Stelle im Code. Führt die Änderung durch. Testet. Deployed. Kehrt zur vorherigen Aufgabe zurück...
Und dann muss er sich erinnern: „Woran war ich eigentlich gerade?“
Das ist genau das Context Switching, also das Wechseln des Kontexts. Und das kann sehr kostspielig sein. Nicht, weil jede einzelne Änderung viel Arbeit beansprucht, sondern weil jede Änderung den gedanklichen Prozess unterbricht.
Je komplexer die Aufgabe, desto teurer ist die Rückkehr zur Arbeit. Deshalb sind 10 Mikroaufgaben nicht immer 10 × 10 Minuten. In der Praxis kann das deutlich mehr bedeuten.
Ein Button ist nichts. Hundert Buttons sind schon ein Prozess.
Angenommen, das Unternehmen schickt dem technischen Team:
- 20 kleine Änderungen pro Monat,
- jede dauert im Schnitt 45 Minuten.
Das ergibt: 15 Stunden Arbeit pro Monat.
Bei einem Satz von 200 Zloty netto: 3000 Zloty netto pro Monat.
Pro Jahr: 36.000 Zloty netto.
Und das sprechen wir nur über 20 kleine Aufgaben pro Monat. Ohne große Features. Ohne Produktentwicklung. Ohne neue Module. Ohne Integrationen. Ohne Design.
Nur: „ändern“, „korrigieren“, „verschieben“, „hinzufügen“, „löschen“.
Stellt man sich eine Organisation vor, in der solche Aufgaben 50 oder 100 Mal pro Monat auftreten, sieht die Skala ganz anders aus...
Mikroaufgaben haben noch einen weiteren Preis – sie blockieren Entwicklung
Das ist ein zentraler Punkt des Ganzen.
Wenn ein Entwicklerteam 20 % seiner Zeit mit kleinen Korrekturen verbringt, kann es diese 20 % nicht in Produktentwicklung investieren. Das klingt trivial, ist in der Praxis aber oft nicht sichtbar.
Das Unternehmen fragt: „Warum ist das neue Feature noch nicht fertig?“
Der Entwickler antwortet: „Weil wir viele laufende Themen hatten.“
„Welche denn?“
„Korrekturen, kleine Änderungen, Updates, kleine Tasks.“
Jede einzelne war klein. Aber zusammen bildeten sie einen großen Block an Arbeit. Es ist ein bisschen wie mit Notifications auf dem Handy. Eine Benachrichtigung stört nicht. Zehn schon. Hundert? Plötzlich stellen wir fest, dass wir den ganzen Tag mit Reagieren verbracht haben.
Mit Mikroaufgaben ist es ähnlich.
„Kleine Aufgabe“ ist nicht immer eine kleine Aufgabe
Man sollte auch verstehen, dass nicht jede Änderung gleich ist. Textänderung im CMS kann wirklich ein paar Minuten dauern.
Eine Textänderung in der Anwendung kann jedoch erfordern:
- die Komponente zu finden,
- Code zu ändern,
- Übersetzungen zu aktualisieren,
- Tests durchzuführen,
- die App neu zu bauen,
- zu deployen.
Die Änderung eines Feldes kann Modifikationen in erfordern:
- Frontend,
- Backend,
- Datenbank,
- API.
Die Änderung eines Elements im System kann andere Elemente beeinflussen.
Deshalb macht die Frage: „Wie lange dauert die Änderung dieses Buttons?“
ohne Kenntnis der Systemarchitektur oft keinen Sinn.
Zuerst muss geprüft werden. Erst dann kann geschätzt werden.
Warum sagt der Entwickler manchmal: „Ich muss das prüfen“?
Das ist kein Ausweichen. Oft ist es ein Zeichen von Professionalität.
Ein guter Entwickler sollte nicht einfach versprechen: „Klar, fünf Minuten.“
wenn er nicht weiß, was darunter liegt.
Er sollte sagen: „Ich schaue nach, wo dieses Element verwendet wird und gebe Bescheid.“
Das kann 10 Minuten dauern. Aber diese 10 Minuten können später mehrere Stunden an Problemen ersparen. Denn die teuerste Änderung ist oft nicht die, die eine Stunde dauert.
Die teuerste ist die, die:
- eine andere Funktion kaputt macht,
- einen Fehler in Produktion verursacht,
- einen dringenden Rollback erfordert,
- weitere Tickets erzeugt,
- die Intervention mehrerer Personen nötig macht.
Deshalb ist Analyse vor der Änderung Teil der Arbeit und keine Zeitverschwendung.
Wie kann der Kunde die Kosten für Mikroaufgaben senken?
Es geht nicht darum, auf das Melden kleiner Änderungen zu verzichten. Kleine Änderungen sind normaler Teil der Produktentwicklung. Es geht darum, sie gut zu managen.
1. Kleine Aufgaben bündeln
Anstatt zu schicken:
„Ändert den Button.“
„Korrigiert noch die Überschrift.“
„Und fügt nebenbei diesen Link hinzu.“
„Und verschiebt noch dieses Element.“
sammelt sie besser zu einem Paket.
Das Team kann mehrere Änderungen in einem Arbeitszyklus durchführen.
Weniger Kontextwechsel.
Weniger Kommunikation.
Weniger Deploys.
Geringere Kosten.
2. Prioritäten setzen
Nicht alles ist dringend.
Wenn jede Aufgabe den Status:
URGENT
hat, ist eigentlich keine wirklich dringend.
Teile die Aufgaben in:
- kritische,
- wichtige,
- geplante,
- kosmetische.
So kann das Team effizienter arbeiten.
3. Überlege, ob die Änderung Code erfordert
Wenn das Unternehmen regelmäßig ändert:
- Texte,
- Bilder,
- Banners,
- Links,
- Nachrichten,
dann ist das Problem vielleicht nicht die Geschwindigkeit des Entwicklers.
Vielleicht ist das Problem die Architektur.
Wenn jede Inhaltsänderung einen Entwickler erfordert, sollte über ein CMS oder ein Admin-Panel nachgedacht werden.
Ein gut gestaltetes System sollte es Business-Anwendern ermöglichen, selbst Änderungen vorzunehmen, die wirklich keine Entwicklerintervention erfordern.
Ein gutes System sollte die Frage beantworten: Wer soll diese Änderung durchführen?
Das ist eine wichtige Gestaltungsregel. Nicht jede Änderung sollte an den Entwickler gehen.
Wenn das Marketing selbst:
- Text ändern,
- ein Bild austauschen,
- einen Artikel hinzufügen,
- die Reihenfolge einer Sektion ändern,
kann, macht es keinen Sinn, einen Entwickler einzubinden.
Der Entwickler sollte sich mit dem beschäftigen, was seine Kompetenzen erfordert.
Also unter anderem:
- Neue Features entwickeln,
- Systemweiterentwicklung,
- Integrationen,
- Optimierung,
- Sicherheit,
- Architektur,
- Technische Problemlösungen.
Ansonsten zahlt das Unternehmen den Entwickler für Arbeit, die ein Systemnutzer selbst hätte erledigen können.
Das ist ein bisschen so, als würde man einen Automechaniker fürs Tanken bezahlen. Er kann es zwar, aber braucht man das wirklich?
Wann sollte man sagen: „Machen wir es anders“?
Wenn dieselbe Bitte regelmäßig auftaucht, lohnt es sich, innezuhalten und zu fragen:
Warum müssen wir das jedes Mal manuell tun?
Wenn wir jede Woche dieselbe Änderung am selben Element verlangen, sollten wir vielleicht:
- eine Option im CMS,
- eine Konfiguration,
- ein Admin-Panel,
- Automatisierung,
- ein Self-Service-Tool
einrichten. Ein einmaliger Aufwand für so eine Lösung kann größer sein. Aber danach kann jede weitere Änderung Sekunden statt Stunden dauern.
Das ist der Unterschied zwischen: Bezahlen für jede einzelne Änderung und Investieren in ein System, das Änderungen selbst ermöglicht.
Mikroaufgaben und das Modell der Zusammenarbeit mit einem Softwarehaus
Das ist auch ein wichtiges Thema für Kunden.
Wenn die Zusammenarbeit mit dem Softwarehaus ausschließlich nach dem Modell „wir melden – ihr schätzt – wir akzeptieren – ihr macht“ funktioniert, kann jede kleine Änderung zusätzlichen organisatorischen Overhead erzeugen.
Daher funktionieren bei kontinuierlicher Zusammenarbeit oft besser:
- Stundenpakete,
- Wartungsabonnements,
- ein festes Team,
- ein Backlog,
- regelmäßige Sprints,
- vereinbarte Deploy-Fenster.
Das heißt nicht, dass jeder Kunde dasselbe Modell wählen sollte. Es geht darum, die Zusammenarbeit an die Art des Projekts anzupassen.
Wenn ein Unternehmen eine Änderung pro Monat benötigt, kann ein aufwändiger Prozess überflüssig sein. Wenn es 50 Tasks pro Monat schickt, kann das Fehlen eines Prozesses sehr teuer werden.
Soll jede Änderung abgerechnet werden?
Das kommt darauf an.
In manchen Projekten macht minutengenaue Abrechnung Sinn. In anderen erzeugt sie mehr Administration als Einsparung.
Darum lohnt es sich, die Zusammenarbeit ganzheitlich zu betrachten.
Die wichtigste Frage ist nicht: „Was hat diese eine Änderung gekostet?“
Besser ist: „Was kostet uns die Art, wie wir alle Änderungen managen?“
Wenn das Unternehmen 200 Zloty für eine Änderung zahlt, dafür aber Fehler vermeidet und die Sicherheit hat, dass alles korrekt funktioniert, kann das vernünftig sein.
Wenn es hingegen jeden Monat mehrere Tausend Zloty für dutzende ähnliche Mikroaufgaben zahlt, lohnt es sich zu prüfen, ob das Problem nicht systemisch gelöst werden kann.
Die teuersten Worte in der IT?
Vielleicht sind es: „Das ist nur eine kleine Änderung.“
Nicht weil kleine Änderungen schlecht wären. Sie sind notwendig.
Ein digitales Produkt lebt. Kundenbedürfnisse ändern sich. Der Markt ändert sich. Marketing ändert sich. Technologie ändert sich. Änderungen sind normal.
Das Problem beginnt, wenn die Organisation die kumulierten Kosten nicht sieht.
Eine kleine Änderung? – Kein großes Ding.
Zehn? – Noch nicht viel.
Hundert? – Das ist schon ein Prozess.
Und wenn es mehrere solcher Prozesse gibt? Plötzlich gibt das Unternehmen Geld nicht für Produktentwicklung aus, sondern für ständige Korrekturen von Kleinigkeiten.
Anstatt Buttons zu zählen, zählt Zeit
Gut gemanagte Produktentwicklung bedeutet nicht, dem Kunden das Melden kleiner Änderungen zu verbieten.
Sondern zu wissen:
- welche Änderungen wirklich einen Entwickler benötigen,
- welche selbst gemacht werden können,
- welche automatisiert werden sollten,
- welche gebündelt werden sollten,
- welche wirklich dringend sind,
- welche geplant werden können,
- welche systemisch gelöst werden sollten.
Denn manchmal ist die beste Antwort auf: „Korrigiert das schnell.“
nicht: „Okay, machen wir.“
sondern: „Überlegen wir, warum wir das in einem Monat wieder korrigieren müssen.“
Hier hört das Softwarehaus auf, nur ein Ausführer zu sein, und wird zum technischen Partner. Ein guter Partner führt nicht nur Tickets aus.
Er hilft auch zu sehen, dass manchmal die günstigste Änderung nicht die ist, die wir schneller ausführen. Die günstigste ist die, die wir nicht hundertmal wiederholen müssen.
Und genau deshalb kann ein Button „Korrigiert das schnell“ eine Stunde kosten.
Aber ein gut gestaltetes System kann dafür sorgen, dass die nächsten hundert solchen Änderungen in wenigen Minuten selbst erledigt werden.
Das ist keine Einsparung an Entwicklern. Das ist eine Investition in bessere Prozesse, bessere Architektur und eine klügere Nutzung der Zeit des gesamten Teams.
