Ein Blick hinter die Kulissen: So entsteht MADDOX
Wichtige Erfolgsfaktoren für einen Workshop sind:
MADDOX ist für die Nutzenden das, was sie vor sich auf dem Bildschirm sehen. Vom unsichtbaren Technologie-Stack auf dem Server im Hintergrund haben wir bereits verschiedentlich berichtet (MADDOX Systemarchitektur, NATS als Message Broker). In diesem Post soll es daher um die Entstehung dessen gehen, was die Nutzung von MADDOX definiert: Funktionen, Abläufe, Interaktionselemente wie Eingabefelder und Buttons, sowie die visuelle Gestaltung. Die Entwicklung dieser Kernmerkmale wird meist unter dem Begriff UX-Design (UX für User eXperience) zusammengefasst. Am Anfang steht als „Zieldefinition“ meist nur eine grobe Idee aus der Praxis für eine neue Funktion. Bspw. sollen Maschinenstopps in Form von Ereignissen in MADDOX erfasst, bearbeitet und protokolliert werden oder Kommentare sollen gelöscht werden können. An dieser Stelle gibt es meist den „Klingt logisch, machen wir; wie schwer kann das schon sein?!“-Moment. Inzwischen haben wir gelernt, dass dieser Schein nicht nur manchmal, sondern fast immer trügt.
Die wirklichen Herausforderungen offenbaren sich meist, wenn man die Idee aus Sicht der Nutzenden in allen Details und unter allen möglichen Randbedingungen durchspielt. Dann passen beispielsweise bestimmte Informationen oder Ansichten plötzlich nicht mehr auf einmal auf einen Tablet-Bildschirm. In bestimmten Sonderfällen erhält man undefinierte Zustände oder ein falscher Klick des Nutzenden hat irreversible Folgen. Gerade letzteres geht gerade auf Touch-Geräten sehr schnell. Sodass wir eine entsprechende interne Entwurfsrichtlinie haben, die wir liebevoll „Wurstfingerkompatibilität“ nennen.
Anschließend entwickeln wir bei komplexeren Funktionen zunächst Mock-Ups mit Adobe XD, dich sich als Klick-Dummy auch online bereitstellen lassen. Dadurch war es beispielsweise möglich, die inzwischen implementierte SAP-Schnittstelle nach der Klärung der Anforderungen dem Kunden binnen weniger Tage als testbares Mock-Up zur Verfügung zu stellen und weiteres Feedback für die Entwicklung zu sammeln.
Die folgende Übersicht zeigt einen Ausschnitt der vielen Mock-Up Ansichten, die in den letzten drei Jahren zusammen mit den UX-Designern bei unserem Partner Tyclipso entstanden sind.
Erst wenn wir und die Ansprechpartnerinnen und Ansprechpartner bei unseren Kunden mit dem Design, den Workflows und der Usability zufrieden sind, beginnt der eigentliche Entwicklungsprozess. In wöchentlichen Meetings zerlegen wir die Anforderungen in kleinere Tickets und ordnen sie der Front- Backend-Entwicklung zu. Insgesamt sind so in den letzten drei Jahren über 2.600 Tickets entstanden, von denen derzeit noch 210 offen sind. Über einen Meilenstein- und Release-Plan folgt die zeitliche Einordnung. Dabei stellen wir uns immer wieder aufs Neue dem Spagat zwischen der flexiblen, prioritätsgetriebenen Berücksichtigung von Kundenbedarfen (eine umfangreiche Änderung an der SAP-Schnittstelle konnten wir bspw. in anderthalb Wochen umsetzen), einer planbaren Entwicklungsroadmap und der Planungsunsicherheit der Implementierungsaufwände.
Mit den neuen Funktionen implementieren wir zugleich auch automatisierte Tests für Front- und Backend. Diese fangen die allermeisten Bugs bereits während der Entwicklung oder bei späteren Code-Änderungen automatisch ab. Zusätzlich wird jedes Release umfangreich manuell getestet (teils auf Testsystemen direkt in der Kunden-IT) und erst dann ausgerollt.
Dieser Beitrag hat 0 Kommentare