Wie die Arbeit am FoodSoul-System abläuft: Von der Idee bis zum Ergebnis

Wir schätzen das Vertrauen unserer Partner und möchten daher so transparent wie möglich sein. In diesem Artikel erzählen wir, wie das Team aufgebaut ist, wie aus Ideen Funktionen werden, wie wir Prioritäten setzen und was hinter den Kulissen passiert, wenn einmal etwas schiefgeht.

FoodSoul — ein lebendiges System

FoodSoul ist nicht einfach nur eine App. Dahinter steht eine große Infrastruktur: CRM, Datenspeicherung und -schutz, Vorlagen für Websites und mobile Anwendungen sowie tausende Partnerrestaurants, jedes mit eigenen Bedürfnissen und Arbeitsabläufen.

Wir hören ständig zu: Wir sammeln Ideen von Partnern über den Support, aus dem direkten Austausch mit Kunden und von unseren eigenen IT-Analysten. All dies fließt in das Backlog ein – eine ständig aktualisierte Aufgabenliste, auf deren Grundlage die Roadmap für die Produktentwicklung erstellt wird.

Wie das Team und die Arbeitsstruktur aufgebaut sind

An FoodSoul arbeiten mehrere Spezialistengruppen, von denen jede ihren eigenen Verantwortungsbereich und ihre eigene Logik der Zusammenarbeit mit den anderen hat.

Support – die erste Kontaktlinie zu den Partnern. Sie nehmen Anfragen entgegen, analysieren das Problem und lösen es entweder direkt oder leiten es an den zuständigen Spezialisten weiter, der den entsprechenden Systembereich kennt.

Spezialisten der zweiten Linie – das sind Ingenieure, die sich in bestimmten Modulen besonders gut auskennen: Integrationen, mobile Anwendungen, CRM, Zahlungen. Sie prüfen, ob eine Anfrage eine Besonderheit der Funktionalität oder ein echter Fehler ist.

Analysten sammeln und strukturieren die Wünsche der Partner, bewerten, wie gefragt eine Änderung ist und wie sie andere Kunden beeinflussen könnte, bevor die Aufgabe in die Entwicklung geht.

Entwickler und Tester setzen die Aufgaben um und prüfen sie vor dem Release – von kleinen Korrekturen bis zu umfangreichen Funktionserweiterungen.

Projektleiter behalten die Prioritäten im Blick: Sie überwachen das Backlog, verteilen Aufgaben zwischen den Teams und sorgen dafür, dass Wichtiges nicht im Tagesgeschäft untergeht.

Die Arbeit ist zyklisch aufgebaut: Das Team überprüft regelmäßig das Backlog, bewertet neue Anfragen und Wünsche, plant die nächsten Aufgaben und verfolgt den Status der bereits in Arbeit befindlichen Themen. Dieser Rhythmus sorgt dafür, dass weder dringende Probleme noch die langfristige Produktentwicklung aus dem Blick geraten und gleichzeitig Vorhersehbarkeit erhalten bleibt: Der Partner kann jederzeit über den Support erfahren, in welchem Stadium sich seine Anfrage befindet.

Wie wir Prioritäten setzen

Wenn ein Problem auftritt, handeln wir nach einem der folgenden Szenarien.

Massenausfall – ein Fehler, mit dem innerhalb weniger Stunden oder eines Tages mehrere Kunden gleichzeitig konfrontiert sind. Das hat höchste Priorität: Tester und Entwickler werden sofort aktiv.

Kritischer Bug bei einem Kunden – wenn ein Fehler direkt den Umsatz oder den Ruf eines Partners beeinflusst, ist die Priorität ebenso hoch. Wir setzen Schlüsselressourcen ein und lösen das Problem in kurzer Zeit.

Standard-Bug – eine vom Support angenommene Anfrage, die nicht wie eine Katastrophe aussieht. Sie wird von einem Spezialisten der zweiten Linie bearbeitet, der das System gut kennt. Es gibt zwei Möglichkeiten: Entweder stellt sich heraus, dass es sich um eine Besonderheit der Funktionalität handelt, die nicht berücksichtigt wurde – dann wird dem Kunden die Lösung erklärt; oder das Problem existiert tatsächlich, dann geht es an den Projektleiter, wird im Aufgabenmanagementsystem mit Priorität und Verantwortlichem festgehalten und der Reihe nach umgesetzt. Der Support-Spezialist verfolgt den Status und informiert den Kunden, sobald die Aufgabe erledigt ist.

Minor-Bug – ein Fehler, der die Systemfunktion nicht beeinträchtigt, aber behoben werden muss: Tippfehler, verschobenes Interface-Element, falsche Buttonfarbe. Solche Aufgaben werden bearbeitet, wenn keine höher priorisierten Anfragen vorliegen.

Wünsche – wir verfolgen aufmerksam, was die Partner sich wünschen. Wenn dieselbe Bitte von mehreren Kunden kommt, steigt die Priorität und wir nehmen sie in die Analyse auf. Jede Änderung betrifft sofort alle Partner, nicht nur den, der sie angefragt hat. Deshalb holen wir vor der Umsetzung Feedback von verschiedenen Kunden ein, damit Verbesserungen für die einen keine Nachteile für die anderen bringen. Das ist ein zusätzlicher Schritt, aber genau dieser macht die endgültige Entscheidung ausgewogener.

Warum Bugs entstehen

Die Entwicklung eines komplexen Produkts ist so aufgebaut, dass Fehler ein regelmäßiger Teil des Prozesses sind – keine Ausnahme. Daraus ergibt sich diese Komplexität.

Das System wächst. Je mehr Funktionen, Integrationen und Nutzungsszenarien es gibt, desto mehr Schnittstellenpunkte gibt es, an denen verschiedene Systemteile miteinander interagieren. Das Team testet die typischsten Szenarien, aber alle Kombinationen im Voraus abzudecken, ist selbst für das erfahrenste Team physisch unmöglich.

Jeder Partner nutzt das System auf seine eigene Weise. Tausende Betriebe – das sind tausende einzigartige Arbeitsprozesse. Das Verhalten der Nutzer unter realen Bedingungen ist immer vielfältiger, als es in Testszenarien vorgesehen werden kann, und manche Abweichungen zeigen sich erst bei echten Daten.

Eine Änderung beeinflusst die andere. Wenn ein Entwickler ein Modul verbessert, kann das angrenzende Funktionen betreffen. Je größer das System, desto länger die Abhängigkeitsketten zwischen den Teilen, und desto sorgfältiger muss jede Änderung geprüft werden.

Das Umfeld ändert sich ständig. Browser, Betriebssysteme und externe Dienste, mit denen wir integriert sind, werden aktualisiert. Was gestern funktionierte, kann sich nach einem Update eines Drittanbieters anders verhalten, und wir verfolgen solche Änderungen, um schnell reagieren zu können.

Anforderungen werden im Prozess präzisiert. Manchmal wird eine Funktion genau wie geplant umgesetzt, aber im realen Einsatz zeigt sich, dass die Idee weiterentwickelt werden sollte. So wird das Produkt mit jeder Iteration präziser.

Wir betrachten dies als normalen Teil des Wachstums eines komplexen Systems und arbeiten ständig daran, es stabiler, schneller und komfortabler für jeden Partner zu machen – durch intensiveres Testen, eine klare Teamstruktur und kontinuierliches Feedback von unseren Kunden.

Wenn Sie auf ein Problem stoßen oder eine Idee teilen möchten, schreiben Sie dem Support von FoodSoul. Jede Anfrage gelangt zum richtigen Spezialisten und geht nicht verloren. Wir sind für Sie da!

Mit freundlichen Grüßen,

Project Manager FoodSoul