Wie entsteht ein neues Feature?

Wie entsteht ein neues Feature?

Eine SaaS-Lösung wie Regiondo entwickelt und verbessert ständig Features, um den aktuellen Anforderungen des Marktes gerecht zu werden. Unterschiedliche Nischen des Marktes für Aktivitäten erfordern unterschiedliche Funktionen und Anpassungen. Kunden wünschen oft neue Features oder eine veränderte Rechtslage macht es erforderlich. Was aus individueller Sicht vielleicht leicht aussehen mag, bringt viele Stolperfallen mit sich und ist komplizierter, als man denken würde.

Also, wie lange dauert es, bis eine neue Funktion für Ihre Buchungslösung entwickelt ist? Das werden wir heute betrachten.

Wissen Sie was „SaaS“ – Software as a Service – bedeutet? Lesen Sie unseren Artikel, der SaaS und On-Premise gegenüberstellt!

 

Beispiel für einen Entstehungsprozess

01. Idee

Am Anfang steht die Idee oder Anfrage für eine neue Funktion oder sogar ein Upgrade einer bereits bestehenden. Sie kann von gesetzlichen Anforderungen, Kunden oder der Produktabteilung stammen. Da es mehrere Aufgaben auf einmal gibt, müssen sie nach Priorität geordnet werden, da auch die Anzahl der Programmierer nicht unendlich ist. Die Feature-Priorität hat also auch Auswirkungen auf die Entwicklungszeit.

Bei der Entwicklung einer Komplettlösung für die Freizeitindustrie sammeln wir Anfragen von Kunden nach neuen Features, bevor sie entwickelt werden und bewerten deren mögliche Auswirkungen. So stellen wir sicher, dass individuelle (laute) Kundenwünsche nicht bevorzugt, sondern an den Bedürfnissen des Marktes ausgerichtet werden. 

02. Spezifikationen

Angenommen, unsere Idee hat nun die höchste Priorität.

Jetzt muss jemand eine Anfrage für die Entwickler schreiben. Der Verfasser der Anfrage kann aus dem Kundenservice oder dem Produktmanagement stammen. Diese Anfrage muss alle Anweisungen und Spezifikationen enthalten, die ein Entwickler benötigt, um die neue Funktion zu programmieren. Es geht nicht nur um die ungefähre Funktionsweise, sondern auch um die genaue Ausführung mit allen Details und Abhängigkeiten.

Einige Features haben einen großen Einfluss auf viele andere Features, sodass dieser Schritt des Prozesses eine Menge Arbeit und Zeit für den Verfasser der Anfrage in Anspruch nehmen kann.

Außerdem kann ein Feature zu mehren abzweigenden Anfragen führen. Wenn die neue Funktion verschiedene Teile des Systems betrifft, sollte es für jede neue Aufgabe unterschiedliche Anfragen geben.

Des Weiteren könnte die Anfrage nur auf einer Idee basieren. Das bedeutet, dass der Verfasser herausfinden muss, wie er das erwartete Ergebnis erzielen kann, bevor alle Abhängigkeiten geklärt sind.

Um mehr Zuversicht für ein neues Feature zu haben, wird ein Dummy erstellt, der intern und mit ausgewählten Kunden getestet wird, um ein frühzeitiges Feedback zum geplanten Feature zu erhalten.

Um einen langen Entwicklungsprozess zu vermeiden, versuchen wir, neue Features auf ein sinnvolles Minimum an Komplexität zu reduzieren. Es ist einfacher und effizienter, eine bestehende Funktion zu erweitern, als eine neue mit enormer Vielschichtigkeit zu erstellen. Der Zeitbedarf und die Risikobewertung sind bei komplexen Features sehr hoch und es gibt auch keinerlei Rückmeldung dazwischen.

Meistens beziehen wir den Projektbeteiligten ein, der das Feature vorgeschlagen hat, um seine Ideen einzubringen und sicherzustellen, dass verschiedene Sichtweisen in den Prozess einbezogen werden. Danach gibt es zwei Möglichkeiten:

  1. Der Beteiligte stimmt dem Feature zu.
  2. Der Beteiligte stimmt nicht zu und das Feature muss überarbeitet werden.

 03. Entwicklung

Nachdem also die Idee eine Anfrage mit einer Spezifikation hat, wird die Entwicklung gestartet!

Wir arbeiten weiter, weil sich alle über die Ergebnisse einig waren. Die Anfrage ist nun beim Entwickler.

Je nach Anfrage variiert der zeitliche Rahmen. Nachdem der Code erstellt wurde, wirft ein zweiter Entwickler einen Blick darauf, um logische Fehler zu vermeiden, bevor er etwas beeinflussen kann.

Sobald der Code überprüft wurde, geht die Anfrage an den Tester. Um sicherzustellen, dass Testprozesse die aktuelle Version der Buchungslösung nicht beschädigen, setzen wir Testumgebungen ein. Wenn es also Fehler gibt (Probleme mit neuen oder bestehenden Funktionen), können wir diese beheben, bevor wir das neue Feature veröffentlichen.

 04. Testen und Sammeln von Feedback

Der Tester sammelt potenzielle Fehler und testet verschiedene Szenarien (es gibt immer viele verschiedene zu testen, um sicherzustellen, dass alle gut funktionieren).

Nach der ersten Testphase in der ersten Umgebung gibt es eine zweite, um sicherzustellen, dass das neue Feature reibungslos funktioniert.

Wenn in beiden Testumgebungen kein Fehler mehr vorhanden ist, ist das Feature einsatzbereit!

Normalerweise funktioniert alles gut, aber der Tester überprüft auch die Live-Version nur für den Fall der Fälle.

 

Warum können Fehler auftreten, wenn ein neues Feature nach verschiedenen Testumgebungen aktiv ist?

Der Grund dafür ist die Vielfalt der Freizeitindustrie. Die Nutzer von Regiondo haben unzählige Möglichkeiten gefunden, ihr Freizeitangebot in ihren Ticketshops zu präsentieren und damit sind unzählige Szenarien verbunden, die nie im Voraus getestet werden können.

Qualität braucht Zeit

Wie Sie sehen können, haben wir eine umfassende Qualitätskontrolle durchgeführt, bevor wir neue Features einführen. Dies erfordert natürlich Zeit und Arbeitskraft.

Wenn Sie also ein neues Feature erwarten, entschuldigen Sie uns für längere Entwicklungszeiten oder Features, die überarbeitet werden müssen. Dies ist Teil eines komplexen Systems wie Regiondo. Wir tun jeden Tag unser Bestes, um Ihnen so schnell wie möglich die besten Features zur Verfügung zu stellen.

Regiondo arbeitet kontinuierlich an neuen Features und Erweiterungen. Werfen Sie einen Blick auf unsere neuen Features und Updates 🙂

Demo vereinbaren

 

Vereinbare eine persönliche Produktdemo oder erstelle jetzt kostenlos dein eigenes Konto

Bringe dein Unternehmen mit Regiondo auf das nächste Level - der Einstieg ist kostenlos und ohne Kreditkarte möglich.