Zum Inhalt springen

Bug oder Änderungswunsch: Warum die Unterscheidung hilft

Die Frage klingt nach Schuldzuweisung und ist in Wahrheit eine Frage nach der Erwartung: Sollte es anders sein, oder soll es anders werden? Die Antwort entscheidet über Dringlichkeit, Reihenfolge und Kosten.

  • Für wenAuftraggeber, Projektverantwortliche
  • NiveauZusammenarbeit
  • Lesezeitetwa 6 Minuten
  • Stand16. Oktober 2026

Das lernen Sie

  • Was beides unterscheidet — in einem Satz
  • Warum die Einordnung für beide Seiten nützlich ist
  • Wie man den häufigen Zwischenfall behandelt
  • Was in eine brauchbare Meldung gehört

Der Unterschied in einem Satz

Ein Fehler ist eine Abweichung von dem, was vereinbart war oder was bei Software dieser Art üblicherweise erwartet werden darf, etwa Abstürze, Datenverlust oder Sicherheitslücken. Ein Änderungswunsch ist eine Abweichung von dem, was man sich heute wünscht. Beides ist berechtigt; nur die Behandlung unterscheidet sich.

  • Fehler: Die Liste zeigt stornierte Aufträge als offen, obwohl abgesprochen war, dass storniert nicht offen ist.
  • Änderungswunsch: Die Liste soll zusätzlich nach Bearbeiter filtern können. War nie vereinbart, ist aber sinnvoll.
  • Nicht entscheidbar: Die Liste zeigt Aufträge ohne Positionen. Dazu wurde nie etwas gesagt.

Warum die Einordnung beiden hilft

Für Sie: Ein Fehler wird vorrangig behoben und ist innerhalb der Gewährleistung beziehungsweise im Rahmen eines Pflegevertrags in der Regel nicht gesondert zu vergüten; die genauen Bedingungen stehen im Vertrag. Ein Änderungswunsch wird eingeplant, abgeschätzt und bewusst entschieden — Sie bestimmen, ob er den Vorrang vor anderem bekommt.

Für uns: Fehler sind ein Qualitätssignal. Wenn in einem Bereich wiederholt welche auftreten, sehen wir uns den Bereich an, statt die Symptome einzeln zu beheben. Vermischt man beides, geht dieses Signal verloren — und eine lange Liste sagt dann nichts mehr darüber aus, wie es der Anwendung geht.

Ein Beispiel aus der Praxis

Der häufige Zwischenfall

Der dritte Fall oben ist der Alltag: Es war nie etwas vereinbart, und jetzt stellt sich heraus, dass die Software sich in einer Lage anders verhält als erwartet. Weder Fehler noch Wunsch, sondern eine Lücke in der ursprünglichen Beschreibung.

Wir behandeln das so: Die Lücke wird benannt, die gewünschte Regel wird festgelegt, und die Umsetzung wird wie eine Änderung eingeplant — ohne Diskussion darüber, wer sie hätte vorhersehen müssen. Dieser Streit kostet regelmäßig mehr als die Umsetzung.

Wenn die Lücke jemanden akut trifft, wird sie vorgezogen. Die Einordnung bestimmt die Reihenfolge, nicht die Dringlichkeit.

Was in eine brauchbare Meldung gehört

  • Was Sie getan haben — die Schritte, nicht die Zusammenfassung.
  • Was Sie erwartet haben.
  • Was stattdessen passiert ist, möglichst wörtlich.
  • Wann es war und unter welchem Benutzer. Das grenzt die Suche im Protokoll ein.
  • Ob es wiederholbar ist oder einmalig auftrat.

„Das Speichern geht nicht" kostet zwei Rückfragen. „Ich habe gestern gegen 14 Uhr als Frau Meier einen Auftrag mit drei Positionen gespeichert, erwartet habe ich die Übersicht, bekommen habe ich eine leere Seite — beim zweiten Versuch ging es" ist eine Fehlersuche, die am selben Tag beginnt.

Häufige Missverständnisse

Nur, wenn es so vereinbart war. Was nie besprochen wurde, kann die Software nicht wissen — deshalb ist der dritte Fall oben so häufig.

Er bedeutet, dass Sie entscheiden. Manche Wünsche sind in einer ohnehin anstehenden Änderung fast kostenlos mitzumachen — das sagen wir dazu.

Sie entsteht gemeinsam, denn sie hängt an der Vereinbarung. Wo nichts vereinbart war, gibt es keine einseitige Antwort.

Über den Autor

Fabian Lücker ist geschäftsführender Gesellschafter der PHP-Schmiede KG in Rheine und seit 2007 in der Softwareentwicklung tätig. Er verantwortet Entwicklung und Konzeption und schreibt hier über Entscheidungen, die in echten Projekten anfallen.