The Microwave With Feature Creep

Hi,

Meine Mikrowelle war kaputt.

Also: Eine neue muss her.

Ich habe hier aber einen kleinen Tick. Das betrifft alles unvergängliche das ich kaufe. Ich will einen Fehlkauf vermeiden. Lieber einmal mehr Geld ausgeben, als in zwei Jahren wieder neu kaufen.

Hier muss ich aufpassen nicht in einer Rabbit-Hole zu landen. Ich kann Stunden in das Lesen von Reviews versenken.

Aber was will ich überhaupt vergleichen?

Als erstes Kommt die Anforderungsanalyse

Bevor ich überhaupt zwischen Modellen vergleichen kann, muss ich mir klar werden was ich eigentlich brauche.

Meine alte Mikrowelle war fancy. Sie hatte 21 verschiedene Programme: Auftauen, Aufwärmen, Heißgetränke, Hühnchen, Suppe, Steak, Popcorn, Pizza, Burger, Sandwich, 5-Sterne-Menü….

Okay, vielleicht habe ich mir ein paar davon ausgedacht.

Aber es hat sich genauso angefühlt!

Die Mikrowelle konnte “alles”.

Als ich sie kaufte fand ich das cool. Ich könnte ja dadurch ganz viel Zeit und Energie sparen. Dann brauche ich ja nicht mehr so oft den Ofen anmachen.

Letztlich habe ich diese Funktionen nie genutzt

Die Grillfunktion lief genau einmal…

Ausversehen…

Und sie schmolz meine Plastikabdeckung. Nice!

Also, was brauche ich wirklich? Jedenfalls keine Grillfunktion.

Ich brauche auch keine Programme. In der Praxis hat jeder selbst die Dauer und die Leistung (Watt) eingestellt.

Wichtig ist mir eine lange Lebenszeit

Ich habe keine Lust in zwei Jahren schon wieder einen neue Mikrowelle zu kaufen.

Und wann ist etwas stabil? Wenn es einfach ist.

Viele Features heißt auch: Vieles kann kaputt gehen.

Feature Creep gibt es auch in der Softwareentwicklung

Was ich gerade an meine Mikrowelle beschrieben habe, gilt auch für die Sofwareentwicklung! Es ist leicht sich viele tolle Features auszudenken. Wir bauen sie alle fleißig ein. Aber brauchen wir sie auch? Werden sie wirklich benutzt? Oder sind sie nur “nice-to-have”?

Jedes Feature kommt mit Kosten.

Und das geht über die Implementierung hinaus.

Irgendwann wird es in deinem Feature ein Bug geben.

Dann muss sich wieder jemand damit auseinandersetzen.

Oder irgendwann erweiterst du einen Teil deiner Applikation und plötzlich musst du das “nice-to-have”-Feature mit berücksichtigen. Das kostet wieder Zeit.

Wir bauen einen Lasttest? Naja, das “nice-to-have”-Feature muss mit getestet werden.

In der Praxis haben wir nicht 1 solches Feature, nein. Wir haben 100 von der Sorte. Ist der Calendar-View bei der Eingabe wirklich nötig? Müssen die Kunden wirklich ihren Adminbereich branden? Ist es notwendig, dass der Kunde persönliche Notizen an seine Daten heften kann? Braucht die Mikrowelle wirklich ein Popcorn-Programm?

Konzentriere dich auf das wesentliche in deiner Anwendung

Du hast einen USP. Es gibt eine Kernfunktionalität.

Wegen dieser sind deine Kunden bei dir.

Alles andere ist zweitranging.

Am Ende habe ich übrigens diese Mikrowelle gekauft. Ohne Schnick-Schnack.

Rule the Backend,

~ Marcus