Eine Prio-Hierarchie, drei Kategorien, fünf Meilensteine, sechs goldene Regeln.
Wer das verinnerlicht, briefet sauber und vermeidet 80 % der typischen Reibung.
Bug > Deadline > Feature
Die wichtigste Regel der ganzen Seite. Wenn drei Anfragen gleichzeitig kommen, gewinnt immer der Bug, dann die Deadline, dann das Feature. Ohne diese Hierarchie eskaliert jedes Projekt.
1
Bug
Höchste Prio
Etwas Live-Wichtiges ist kaputt.
Beispiele
Formular sendet nicht · Link ins Leere · Layout bricht auf Mobile · Förder-Rechner gibt Fehler
Was tun
Sofort an Renana, sie eskaliert. Deploy auch außerhalb Plan möglich (außer Freitag).
Ticket mit Deadline-Datum. Renana plant ein, ggf. wird ein Feature verschoben — nicht der Termin.
3
Feature
Etwas Neues, was vorher nicht da war.
Beispiele
Neuer Block-Typ · Filter für Ladesäulen-Karte · Neue Newsletter-Anmeldung · Buchungs-Flow
Was tun
Ticket im Backlog. Wird gegen die nächste Phase / Sprint / Meilenstein geplant.
Was ist was? Bug, Schönheitsfehler, Feature
Falsche Kategorie kostet Zeit, weil die Anfrage im Backlog im falschen Topf landet. Drei Definitionen, drei Abgrenzungen — wechsle zwischen den Tabs, um zu vergleichen.
Bug
Was es ist
Eine Funktion, die laut Konzept oder Briefing existieren soll, tut nichts oder etwas Falsches. Ein Bug ist immer eine Abweichung von einer vereinbarten Spezifikation — nicht von einem ungeschriebenen Erwartungswert.
Wie du's erkennst
Drei Tests: Hat es vorher funktioniert? Stand es im Briefing? Sind Nutzerinnen blockiert? Wenn mind. einer mit Ja zu beantworten ist, ist es ein Bug.
Nicht damit verwechseln
Eine Funktion, die nie spezifiziert wurde (= Feature). Eine Optik, die nicht gefällt aber funktional ok ist (= Schönheitsfehler). Ein Missverständnis darüber, wie etwas funktionieren sollte (= Spezifikations-Lücke, kein Bug).
Beispiel
Förder-Antragsformular sendet trotz Klick keine Mail. Das war im Briefing spezifiziert ("nach Absenden Bestätigungsmail an Antragsteller"), funktionierte vorher und blockiert die Nutzerin. Klassischer Bug.
Schönheitsfehler
Was es ist
Optische Abweichung ohne funktionale Auswirkung. Kosmetisch, nicht blockierend. Die Funktion erfüllt ihren Zweck — sie sieht nur nicht ganz so aus, wie das Designsystem es vorgibt.
Wie du's erkennst
2px Abstand off, Hover-Farbe leicht daneben, Schrift wirkt eine Spur zu dünn auf einem bestimmten Gerät, Icon ist 1px verschoben. Niemand bricht deshalb einen Kauf ab.
Nicht damit verwechseln
Nicht „schnell zwischendurch" einbauen — jede Mini-Änderung erfordert Test, Review, Deploy. Wandert deshalb ins Sammel-Ticket und wird gebündelt mit anderen Schönheitsfehlern in einem Wartungs-Slot deployed.
Beispiel
Auf der ÖPNV-Seite ist der Abstand zwischen Fahrplan-Header und der ersten Verbindung 14px statt 16px. Sieht der Designer, sieht sonst niemand — landet im Sammel-Ticket für den nächsten Wartungs-Sprint.
Feature
Was es ist
Eine neue Funktion, ein neues Element, eine neue Variante — etwas, das vorher nicht spezifiziert war und das die Software um eine Fähigkeit erweitert. Auch „kann das auch X?" ist meistens ein Feature.
Wie du's erkennst
Es soll etwas tun, was bisher nicht im Briefing oder Konzept stand. Drei Faustregeln: Steht es nicht im Konzept? Feature. Erweitert es eine Komponente um einen neuen Modus? Feature. Würde ein Entwickler dafür mehr als 2 Stunden brauchen? Vermutlich Feature.
Nicht damit verwechseln
Neue Inhalte in einer bestehenden Element-Struktur sind kein Feature, sondern Pflege (Redakteur füllt Felder). Eine neue Variante eines bestehenden Elements (z.B. „die Card auch in Hochformat") ist hingegen ein Feature.
Beispiel
E-Ladesäulen-Karte soll zusätzlich nach Schnelllade-Fähigkeit filtern können. Filter war im Briefing nicht enthalten — neues Feature, eigenes Ticket, Vorlauf 1-2 Wochen, Backlog statt sofort.
Faustregel: „Hat es vorher funktioniert?" → Bug. „War es im Briefing?" → Bug, sonst Feature. „Sieht nur schlecht aus, tut aber was es soll?" → Schönheitsfehler.
Meilensteine: vom Projektstart zum Live
Die Bug-Deadline-Feature-Hierarchie greift nicht erst beim Live-Bug — sie wird ab Projektstart geplant. Fünf Meilensteine, jeweils mit einer Freigabe. Ab jeder Freigabe verschiebt sich, was Bug, was Feature, was Pflege ist.
M1 · Woche 1-2
Konzept-Freigabe
Inhaltsplan und Designkonzept stehen. Kundenfreigabe schriftlich. Ab hier sind Konzept-Änderungen ein Feature.
M2 · Woche 3-5
Design-Freigabe
Figma-File durchgespielt mit Frontend, Mobile/Desktop. Kundenfreigabe schriftlich. Ab hier sind Design-Änderungen ein Feature.
M3 · Woche 6-8
Frontend-Freigabe
Astro-Build durchgeklickt. Pixel-Abnahme. Ab hier sind Frontend-Änderungen ein Feature, Schönheitsfehler kommen ins Sammel-Ticket.
M4 · Woche 9-11
TYPO3-Freigabe
Pflegeoberfläche getestet, Redakteur hat einen Probedurchlauf gemacht. Ab hier sind Pflege-Änderungen ein Feature.
M5 · Woche 12+
Go-Live
Deployment, Monitoring, Stabilisierung. Erste Woche: nur Bugs werden deployed, alles andere geht ins Wartungs-Backlog.
Warum schriftliche Freigaben?
Ohne schriftliche Freigabe wird jede spätere Änderung zur Diskussion: „Habt ihr nicht gemeint, dass...?". Mit Freigabe ist klar: alles vor Datum X war Konzept, alles danach ist Feature mit Vorlauf.
Sechs goldene Regeln
Sie ersetzen kein Briefing und kein Gespräch. Aber sie verhindern, dass dieselben Reibungspunkte jede Woche neu auftauchen.
01
Tickets in Awork an Renana
Kein Direkt-Ping an Devs. Renana priorisiert und ordnet ein.
02
Früh briefen
Jeder Tag Vorlauf spart einen Tag Stress. Unklare Briefings verdoppeln jeden Wert.
03
Kundenfeedback sortiert weitergeben
50 Punkte bunt gemischt sind für Devs unbrauchbar. Nach Bug, Feature, Content sortieren.
04
Nachfragen statt annehmen
Impact einer Änderung kann nur eine Entwicklerin einschätzen. Niemals raten.
05
„Kleine Änderungen" sind selten klein
Fünf Minuten oder drei Tage. Sieht einfach aus, ist es selten.
06
Freitag = kein Deploy
Bugs eskalieren wir anders. Am Wochenende sitzt niemand am Hebel.
Tickets & Awork
Alles, was Arbeitszeit kostet, ist ein Ticket in Awork an Renana. Teams ist für drei Fälle reserviert — sonst gehen Anfragen verloren.
Standard-Weg
Awork-Ticket an Renana
Neue Anfrage vom Kunden
Änderung an Design, Frontend, Backend, Content
Bugs, Schönheitsfehler, Feature-Wünsche
Alles, was Aufwand bedeutet
Ausnahme
Teams nur für drei Fälle
Akute Brände (Live-Seite down)
Kurze Rückfragen zu offenen Tickets
Echtzeit-Klärung während laufender Arbeit
Direkt-Pings an Devs sind unsichtbar für Renana und unplanbar für das Team. Auch „nur eine kurze Frage" ist ein Ticket — sonst geht Kapazität verloren.
Vorlaufzeiten & Kundenfeedback
Realistische Werte für ein klar gebrieftes Vorhaben. Unklare Anforderungen verdoppeln jeden Wert. Vor jedem Ticket steht das Sortieren von Feedback.
Realistische Vorlaufzeiten pro Änderungstyp
Art der Änderung
Vorlauf
Text- oder Bildaustausch
1-2 Tage
Bestehendes Element anpassen
3-5 Tage
Neues Element / kleines Feature
1-2 Wochen
Neues Projekt / Relaunch-Baustein
4+ Wochen
„Heute live"
nur echte Bugs
Keine Treffer.
Kundenfeedback nach Kategorie weiterleiten
Kategorie
Wohin
Bug
Reparatur-Ticket, Prio-Eskalation
Feature-Wunsch
eigenes Ticket, nachgelagert
Schönheitsfehler
Sammel-Ticket
Content-Änderung
an Content, nicht an Devs
Missverständnis
Rückfrage an Kunden vor Weitergabe
Keine Treffer.
Sechs typische Fallstricke
Wenn du einen davon erkennst, bremse ab und kommuniziere — bevor das Ticket geschrieben wird.
„Kann man das schnell machen?"
Ohne Kontext nicht einschätzbar. Immer nachfragen.
Late-Stage-Änderungen
Eine Änderung in Woche 8 kostet das Fünffache einer in Woche 2.
Feature-Nachschüsse während Testing
Bringen die Regression-Testkette durcheinander.
Content kommt nach Launch
Dann war „launch-ready" nur Simulation.
Unklare Freigabeketten
Wer auf Kundenseite entscheidet, früh klären.
Ungefilterte Feedback-Listen
50 Punkte bunt gemischt sind für Devs unbrauchbar.
Szenarien aus dem Alltag
Vier Situationen, die jede Woche vorkommen. Klick, um die richtige Reaktion zu sehen.
Der Kunde sagt: „Kann man das schnell ändern?"
Nachfragen, was genau, für wann, gibt es ein Briefing? Dann Ticket in Awork an Renana. Niemals „ja, machen wir bis morgen" zusagen, ohne den Impact zu kennen.
→ Goldene Regel 04
Es ist Freitag 16 Uhr und ein Bug ist gemeldet. Deploy heute?
Eskalation an Renana. Nur echte Live-Bugs rechtfertigen einen Freitag-Deploy. In allen anderen Fällen Montag morgen.
→ Goldene Regel 06
Du bekommst 50 Punkte Kundenfeedback bunt gemischt. Was tust du als erstes?
Vorsortieren nach Bug, Feature, Schönheitsfehler, Content, Missverständnis. Pro Kategorie ein Ticket. Erst dann an Renana weitergeben.
→ Goldene Regel 03
Ein Designer pingt dich auf Teams: „Ich hab ein Problem mit dem Hover-State, kannst du Brandon fragen?"
Schreib es als Ticket in Awork an Renana. Sie ordnet es ein. Direkt-Ping an Brandon umgeht die Planung und ist unsichtbar für das Team.