Was kostet eine App? Teil 3: Die 5 teuersten Don'ts in der Webentwicklung

Die Implementierung von sekundären Features in das Produkt, bevor es releasefähig ist. Häufig entsteht dies durch das verständliche Bedürfnis, das Produkt vermeintlich ansprechender oder nützlicher zu machen (Premature Scaling). Hier kann das gemeinsame Commitment auf einen schnellen Release mit einigen Grundfeatures Abhilfe schaffen. Auf diesem Gedanken beruht auch die Methodik des Lean Startups: ob ein weiterführendes Feature gebraucht wird und wie genau es aussehen soll, darauf geben erste Erfahrungen mit dem bereits veröffentlichten Prototypen hervorragend Aufschluss. Wie es mit einer App weitergeht, das lässt sich präzise "in freier Wildbahn" betrachten und planen.

Mit jeder Zeile Quellcode, die einem Projekt hinzugefügt wird, steigt auch die Zahl an Abhängigkeiten innerhalb des Quellcodes. Und je größer eine Software wird, desto anfälliger wird sie auch für Bugs. Die Mechanismen, um dies zu vermeiden (Design Patterns, Best Practices, Testing usw.), sind so effektiv wie selbstverständlich – und erhöhen doch selbst im routiniertesten Team den Arbeitsaufwand. Daher gilt auch nach Veröffentlichung des ersten Prototypen: die punktgenaue Auswahl von Featuresets schafft die beste Voraussetzung für eine reibungslose Implementierung.

Eine nachträgliche Änderung an einer Spezifikation zu einem Zeitpunkt, wenn diese bereits (teil-)umgesetzt wurde – wenn z.B. eine Bestellzusammenfassung aufgrund eines Vetos aus der Rechtsabteilung nochmal überarbeitet werden muss. Die wichtigsten Produktfeatures sollten allen internen Prüfungs- und Entscheidungsinstanzen vorher absegnen, bevor es im Backlog steht und es an dessen Implementierung geht. In der Realität ist das häufig nicht immer möglich. Deshalb ist eine enge Feedbackschleife mit den wichtigsten Stakeholdern wichtig: sie hilft, fehlerhafte Vorgaben schnell zu korrigieren.

Eine zwar funktionierende, aber unsaubere Lösung, die z.B. aufgrund von Zeitdruck eingesetzt wurde. Solche technischen Schulden werden oft mit dem Versprechen aufgenommen, man werde sie beizeiten durch die "richtige" Lösung ersetzen. De facto passiert das eher selten, das Provisorium macht eher unzufrieden. Unsere Erfahrung zeigt: die Entscheidung für eine solide, skalierbare Umsetzung zahlt sich langfristig aus.

In den Nischen von User Interface Designs verbergen sich manchmal unvorhergesehene Untiefen. Sie werden offenbar, wenn etwa ein Testuser fragt "was passiert, wenn ich da hinklicke?", "wo kann ich das einstellen?" oder "wie sieht der leere Warenkorb aus?". Wenn diese Fragen ein mieses Gefühl hinterlassen oder auch nur im engeren Team zu Unsicherheiten führen, ist Vorsicht geboten. Was also tun? Langfristig ist das provisorische Weitercoden keine gute Idee, denn versteckte Untiefen sind Vorboten von teuren Refactorings. Skelett und Grundlage eines User Interfaces sollte immer die User Experience sein. Produktive Teams begreifen ungeklärte UX-Fragen als Chance, um die Lücken in den User Stories zu füllen. Dazu holen sie sich am Besten Entwickler:in, Designer:in sowie die wichtigsten Entscheider:innen ans Drawing Board.