Warum Ihre 'einfache' Softwareänderung 8 Stunden statt 30 Minuten dauert

Himanshu Sharma Updated October 19, 2025
Warum Ihre 'einfache' Softwareänderung 8 Stunden statt 30 Minuten dauert

Sie haben nach einer scheinbar einfachen Änderung gefragt. Vielleicht die Aktualisierung eines Benachrichtigungszeitpunkts, die Änderung eines Berichtsfilters oder das Hinzufügen eines neuen Feldes zu einem Formular.

In Ihrem Kopf ist das eine Sache von 30 Minuten. Eine Stunde, wenn wir großzügig sind. Dann komme ich mit einer Schätzung von 6-8 Stunden zurück, und Sie denken sich: ‘Was zum Teufel?’

Ehrlich gesagt? Manchmal wünschte ich, es wäre so unkompliziert, wie es von außen aussieht.

Lassen Sie mich erklären, was passiert. Es ist komplizierter, als es aussieht.

Warum eine „kleine“ Änderung gar nicht so klein ist

Was Sie an der Oberfläche sehen, sind 10 % dessen, was darunter passiert.

Nehmen wir an, Sie möchten ändern, wann eine E-Mail zur Aufgabenerinnerung gesendet wird. „Ändern Sie es einfach von heute auf morgen.“

Sicher, das ist eine Zeile Code. Aber

  • Welches System sendet diese E-Mail?

  • Gibt es andere Stellen, die das „Fälligkeitsdatum“ anders definieren?

  • Was ist mit wiederkehrenden Aufgaben im Vergleich zu einmaligen Aufgaben?

  • Müssen wir die Benutzeroberfläche anpassen?

  • Wird dies die Eskalations-E-Mails des Managers unterbrechen?

  • Was ist mit den Benachrichtigungen der mobilen App?

Diese eine Zeilenänderung berührt sechs verschiedene Teile des Systems.

Wenn wir nicht alle davon überprüfen, wird Ihr Betriebsteam unglücklich sein, wenn Probleme auftreten.

Was passiert

Hier ist, was passiert, wenn wir Ihre „einfache“ Anfrage erhalten:

Stunde 1: Herausfinden, wo zum Teufel diese Logik steckt. Selbst in WeWeb und Retool müssen wir herausfinden, wo die Logik liegt. Ist sie im Workflow? Ein Trigger? Sie könnte in einer alten Integration versteckt sein, die noch aus der Zeit stammt, als wir anfingen zusammenzuarbeiten. Das sind 30 Minuten verschwendete Suche, vorausgesetzt, wir erinnern uns gut an das System.

Stunde 2-3: Alle Stellen identifizieren, an denen diese Änderung etwas kaputt machen könnte. Wir wollen vermeiden, etwas anderes zu beschädigen, während wir Ihre ursprüngliche Anfrage beheben.

Stunde 4-5: Die Änderung vornehmen und testen. Und zwar richtig testen, nicht nur 2 Minuten herumklicken. Wir müssen sicherstellen, dass wir nichts anderes kaputt gemacht haben. Wir können eine Änderung nicht einfach veröffentlichen und das Beste hoffen.

Wir müssen es auf einem Staging-Server testen. Wird die Benachrichtigung korrekt ausgelöst? Erreicht sie die richtigen Personen? Wenn es sich um ein internes Tool für Ihr Team handelt, ist eine schnelle Stichprobe in Ordnung (ca. 20 Minuten). Aber wenn es kundenorientiert ist? Ein falscher Schritt und Ihre Kunden werden mit Spam überflutet.

Stunde 6-8: Dinge aufräumen, die wir zufällig gefunden haben. Wenn wir schon dabei sind, können wir auch die drei anderen Dinge reparieren, die mit Klebeband zusammengehalten werden. Dann stellen wir es bereit. Selbst mit Low-Code ist das nicht sofort erledigt. Rechnen Sie mit weiteren 15-30 Minuten.

Warum es sich schlimmer anfühlt, als es sollte

Ein Großteil dieser Komplexität ist unnötig. Sie existiert, weil:

  • Systeme unter Druck schnell gebaut werden

  • „Schnelle Lösungen“ sich im Laufe der Zeit ansammeln

  • Niemand Zeit hat, das Fundament aufzuräumen

  • Wir immer nur Brände löschen, anstatt sie zu verhindern

Ein Haus zu renovieren, während Menschen darin wohnen, ist eine Herausforderung. Man kann nicht einfach Wände einreißen.

Was nun?

Wir könnten diese eine Zeilenänderung vornehmen und sie in 2 statt 8 Stunden als erledigt betrachten. Aber dann wird die nächste ähnliche Anfrage ebenfalls 8 Stunden dauern. Und die danach auch.

Selbst die einfachsten Dinge zu ändern, wird schwierig, wenn das System zu kompliziert ist.

Wir müssen die Dinge reparieren, nicht nur eine temporäre Lösung anwenden.

Ja, es kostet anfangs mehr. Aber es ist der Unterschied zwischen:

  • Jedes Mal 8 Stunden aufwenden, wenn Sie eine kleine Änderung benötigen

  • 1-2 Stunden für dieselbe Änderung aufwenden, sobald wir die Dinge aufgeräumt haben

Es ist keine „sexy“ Arbeit. Es gibt keine neuen Funktionen zum Vorzeigen. Aber es ist der Unterschied zwischen einem System, das für Sie arbeitet, und einem, das gegen Sie arbeitet.

Unterm Strich Diese „einfache“ Änderung dauerte 8 Stunden, weil sich das System im Laufe der Zeit entwickelt hat. Es ist auf eine Weise komplex, die von außen nicht offensichtlich ist.

Ich blähe die Schätzungen nicht auf. Ich bin ehrlich darüber, was es braucht, um die Arbeit zu erledigen.

Die Hauptfrage ist nicht: „Warum dauert das so lange?“, sondern: „Wie können wir das nächste Mal beschleunigen?“

Himanshu Sharma Gründer, NocodeAssistant

Himanshu leitet NocodeAssistant, eine Entwicklungsagentur, die interne Tools und SaaS-Produkte für wachsende Unternehmen erstellt. Seit 2019 hat er direkt mit jedem Kunden zusammengearbeitet – dieselbe Person vom Kick-off bis nach dem Launch.

Auf LinkedIn verbinden

Zusammenarbeiten

Your developer quoted 8 hours for a 30-minute change. There's a reason for that.

30 minutes to scope a rebuild that actually cuts maintenance time.

Book the call Kostenlos · 30 Min · Unverbindlich