Wie wir den Selfservice Rechnungsprüfung entwickeln
Nach Abschluss der Usability-Tests durch das UX-Team analysierten unsere Entwickler:innen die Mockups, um die einzelnen Funktionalitäten des Selfservices zu identifizieren. Akribisch zerlegten wir Funktion für Funktion in sogenannte User-Stories. Eine User-Story erzählt eine prägnante „Geschichte“ über die Aktionen der Nutzer:innen in der jeweiligen Anwendung. User-Stories brechen somit das große Ganze in kleine Häppchen auf, was insbesondere drei Vorteile mit sich bringt:
- User-Stories beschreiben die Wünsche der Anwender:innen.
- User-Stories reduzieren Komplexität. Die Entwicklung kann direkt starten, weil die Anforderungen leicht zu verstehen sind, wodurch die Software den Kunden früher zur Verfügung steht
- User-Stories begünstigen ein iteratives Vorgehen. Sowohl die künftigen Benutzer:innen als auch das Entwicklungsteam erkennen frühzeitig Fortschritte und können ggf. nachjustieren sowie flexibler auf Trends oder neue gesetzliche Vorgaben reagieren.
Beispiele für User-Stories zum Selfservice Rechnungsprüfung
- Als Rechnungsprüfer:in werden mir die zum Beleg zugehörigen Rechnungsdokumente angezeigt, um diese prüfen zu können.
- Als Rechnungsprüfer:in kann ich direkt bei Login die Sprache wechseln, um den Selfservice auf Englisch zu bedienen
In Absprache mit dem Produktmanagement priorisierten wir die unterschiedlichen User-Stories für unsere Entwickler:innen und steckten so auch den Funktionsumfang ab. Bescheidenheit war dabei eine Tugend, auch wenn es uns manchmal schwerfiel. Es galt eine gute Balance zu finden, um sowohl eine attraktive Oberfläche zu kreieren als auch mit Einfachheit zu begeistern.
Kunden profitieren von einer agilen Entwicklung
Die Weichen waren gestellt – unser Entwicklungsteam konnte in den ersten Sprint starten. Ein Sprint ist ein Arbeitspaket für den Zeitraum von zwei Wochen, das vom Team selbstorganisiert festlegt wird. Sprints sind Bestandteil des sogenannten Scrum-Modells, nach dem unsere Entwicklung arbeitet. Es handelt sich dabei um ein Rahmenwerk aus definierten Rollen, Abläufen und Prinzipien, wie den Sprints. Das agile Vorgehen nach dem Scrum-Modell verschafft uns die Flexibilität, bereits im nächsten Sprint auf neue Ideen und Anforderungen unserer Kunden reagieren zu können.
Der Selfservice entsteht so Stück für Stück. Das Layout, die Abstände, das mobile Verhalten einzelner Seiten, die Navigation – mit jedem Sprint füllen wir den Selfservice weiter mit Leben. Aktuell bauen wir u. a. Buttons, Tabellen und Schnittstellen. Dabei spielen Details eine große Rolle: Als unsere Architekten z. B. vom Fachteam erfuhren, dass es Rechnungsbelege mit bis zu 1250 Positionen gibt, hatte dieses scheinbar kleine Detail einen großen Einfluss auf die Architektur der Schnittstelle zwischen Belegpositionen und dem ERP-System.
Die Zeit der Reviews beginnt
Während die Entwicklung zügig voranschreitet, klären wir letzte Fragen. Um beispielsweise sicherzugehen, dass wir alle Anforderungen an die Barrierefreiheit berücksichtigt haben, lassen wir den neuen Selfservice von Menschen mit Sehbehinderungen testen. Ziel ist es, die Verständlichkeit und Erwartungskonformität der Software noch weiter zu erhöhen.
Barrierefreiheit, Schnittstellen, Design, Installation und Bereitstellung – so lauten unsere nächsten Stationen. Wir nehmen Sie mit: In die anstehenden Reviews binden wir unterschiedliche Kunden ein, damit sie den neuen Selfservice aus verschiedenen Blickwinkeln kritisch beäugen. Auf diese Weise entsteht eine Lösung, mit der ERP tatsächlich Spaß macht und für alle einfach wird.
