Entscheiden, was man nicht baut
Warum es so schwerfällt
Jede Anfrage klingt für sich vernünftig. Das Problem ist nicht das einzelne Feature, sondern die Anhäufung: Jede Ergänzung bringt Code zum Pflegen, einen Bildschirm zum Lernen und einen Randfall, der in sechs Monaten etwas anderes bricht. Die Kosten eines Features sind nicht die Entwicklungswoche, sondern all die Jahre danach.
Drei Filterfragen
Wer hat gefragt? Ein lauter Kunde ist kein Markt. Fragen Sie, wie viele Nutzer das in einer Woche berühren.
Was passiert ohne? Lautet die Antwort „etwas unbequemer“, kommt es nicht in die erste Version.
Was ersetzt es? Hat die Aufgabenliste eine feste Länge, verlangt jeder Eintrag einen Ausgang. Das ist ein gesünderes Gespräch als „lass uns das auch hinzufügen“.
Wie man Nein sagt
Nein kommt mit Grund und Ort: „nicht in dieser Version, weil die Kennzahl, der wir nachjagen, die Bearbeitungszeit ist und das sie nicht beeinflusst. Wir kommen nach der ersten Messung darauf zurück.“ Wer die Prioritäten versteht, hört auf, über sie zu streiten.
Führen Sie eine sichtbare Liste der Zurückstellungen. Sie verhindert die wiederkehrende Frage und ist die erste Anlaufstelle, wenn Zeit frei wird.
Im Detail
Ein Produkt, das mit zehn perfekt funktionierenden Fähigkeiten ausgeliefert wird, schlägt eines mit vierzig mittelmäßigen. Auch im Code: Jeder logische Zweig fügt einen zu testenden Pfad hinzu. Umfang zu kürzen ist nicht nur eine Geschäftsentscheidung — es ist die günstigste Architekturentscheidung, die Sie treffen.