Ein Jahr MAC Paygate! Im Februar 2020 wurde die Multi-PSP-Innovation gelauncht. Grund genug einmal nachzufragen, wie es so läuft. Tjark Onnen ist fast von Anfang an dabei. In einem Gespräch berichtet er über seine Rolle als Paygate Product Owner, harmonischen Code und wie man für Entwickler optimale Arbeitsumgebungen schafft.

 

Moin Tjark, du bist seit dem 1. Mai 2020 Product Owner vom MAC Paygate. Was genau ist dein Job?

Tjark: Erstmal zum Produkt MAC Paygate. Das MAC Paygate ermöglicht sichere Zahlungstransaktionen über unterschiedliche Zahlungsanbieter. Dabei stellt das Paygate eine einheitliche Schnittstelle bereit, sodass z. B. ein Shop mit nur einer Schnittstelle verschiedene Zahlarten anbinden kann. Das ist nicht nur ein enormer Vorteil bei der Shopanbindung, auch die Omnichannel-Software DiVA setzt bei der Verarbeitung von Zahlungstransaktion voll auf das Paygate.

Und gemäß meiner Aufgabe als Product Owner* bin ich laut Definition für den wirtschaftlichen Erfolg, der Wertmaximierung und für die Qualität des Produktes verantwortlich. Tatsächlich haben wir in der MAC diese Position aber noch einmal aufgeteilt.

*(Anmerkung: Product Owner ist ein Begriff aus Scrum, einem Vorgehensmodell der agilen Softwareentwicklung.)

 

Wie ist die Aufteilung entstanden?

Tjark:

Ich komme aus der Software-Entwicklung und habe eine Sichtweise, welche die Produktqualität deutlich über die Wirtschaftlichkeit stellt. Ist aber kein Problem, denn um die Wirtschaftlichkeit kümmert sich ein anderer Kollege und ich habe einen enormen Freiraum bei der Sicherstellung der Produktqualität.

 

Kannst Du das genauer erklären?

Tjark:

Ja, dafür muss ich etwas ausholen. Das Paygate wurde in der MAC von Grund auf neu entwickelt und ein neues Projekt macht anfänglich enorme Fortschritte, da weder auf aktiv genutzte Implementierungen noch auf veraltete oder unbekannte Codeabschnitte geachtet werden muss.

Diese schnellen Fortschritte führen oft zu einer überhöhten Erwartung bezüglich der Entwicklungsgeschwindigkeit. Aber jede Zeile Code ist eine potenzielle Fehlerquelle und benötigt bei der weiteren Entwicklung eine gewisse Aufmerksamkeit. Mit anderen Worten, je größer die Codebasis umso langsamer wird die Entwicklung.

Und mein „enormer Freiraum“ spiegelt sich in der Tatsache wider, dass die Codequalität hier über den Funktionsumfang priorisiert wird. Das habe ich in dieser Konsequenz bei keinem anderen Arbeitnehmer erlebt.

 

Was bedeutet dies konkret?

Tjark: Unser Credo ist, dass die Qualität des Programmcodes mit dem Funktionsumfang nicht zu stark leiden soll. Neue Funktionen dürfen nicht einfach auf den bestehenden Code „obendrauf“ programmiert werden, sondern müssen sich harmonisch einfügen. Dafür muss der bestehende Code allerdings oft angepasst werden, um wieder ein stimmiges Gesamtkunstwerk zu ergeben.

 

Kann dieses Vorgehen nicht zu Fehlern in Bereichen führen, die gar nichts mit der Neuerung zu tun haben?

Tjark: In der Tat. Daher werden Erweiterungen oft so programmiert, dass so wenig bestehender Code wie möglich „berührt“ wird. Im Ergebnis gibt es oft „doppelten“ Programmcode mit praktisch gleicher Funktionalität. Und damit komme ich wieder zurück zu meiner vorherigen Aussage: „Jede Zeile Code ist eine potenzielle Fehlerquelle“.

 

Wie habt ihr dieses Dilemma gelöst?

Tjark: Indem wir von Anfang an auf eine vollständige Testabdeckung gesetzt haben und permanent ein Codereview durchführen. Nur Funktionen, die eine fast vollständige automatische Testabdeckung haben, können in den „Stage“-Branch geschoben werden. Ferner sind die Richtlinien bei Codestyle so hoch, dass ein „Quick-And-Dirty“ schon in der Findungsphase der Codierung nicht so leicht ist.

Diese „Best Practices“ kennen wir nicht nur, wir leben sie in diesem Projekt.

 

Drücken diese hohen Anforderungen dann nicht enorm auf die Entwicklungsgeschwindigkeit?

Tjark: Ja, und wie. Aber die Entwicklungsgeschwindigkeit nimmt mit dem Fortschreiten der Entwicklung nicht ab. Wir habe also keine schnelle, aber eine relativ gleichmäßige Entwicklungsgeschwindigkeit, mit der man besser planen kann.

Sicherlich bleiben trotzdem Bugs nicht aus und diese werden, je nach Dringlichkeit, dann ohne Rücksicht auf Schönheit und Eleganz gelöst. Dennoch erfolgt nach dem Bugfixing immer ein gründliches Aufräumen.

Auf diese Weise wird ein großes Vertrauen in die eigene Software aufgebaut. Das nimmt den Entwicklern auch viel Stress beim Update ins Live-System.

 

Wieso ist Vertrauen in die eigene Software für Entwickler so wichtig?

Tjark: Beim Paygate handelt es sich ja um ein Produkt, bei dem es direkt um Geld geht. Ein ausgesprochen sensibles Thema. Hier gibt es praktisch keine Fehlertoleranz. Diese Verantwortung spürt man auch als Entwickler. Entsprechend muss das Umfeld bei den Entwicklern so optimal wie möglich sein.

 

Was ist ein optimales Umfeld für Entwickler?

Tjark: Da Entwickler mehr „Mensch“ sind, als viele glauben, gibt es nicht das optimale Umfeld. Aber wenn die Faktoren Ruhe, Rückhalt und ein klares Ziel vorhanden sind, kommt man in der Regel in Richtung Optimum.

Zudem sind Entwickler nicht diese Stereotypen, die einsam im Keller vor sich hin werkeln, sondern unterscheiden sich in ihren Charakteren mehr in Künstler, Pragmatiker, Teamworker, Einzelkämpfer, usw. Jeder Typ hat seine Stärken und Schwächen und diese sollten je nach Aufgabe entsprechend eingesetzt werden.

Wenn man z. B. zwei Entwickler hat, die gut zusammenarbeiten können, dann halbiert man zwar die Anzahl an produzierten Codezeilen, verdoppelt aber das Code-Wissen und verdreifacht die Qualität.

Trotzdem darf diese Art der Entwicklung nicht „befohlen“ werden, da ein eher introvertierter Entwickler am effektivsten arbeitet, wenn er sich in einem Zustand der absoluten Konzentration befindet. In diesem Zustand, der auch als „Tunnel“ oder „Flow“ bezeichnet wird, sollte ihm keiner dazwischen quatschen.

 

Wie schaffst du für die Entwickler ein individuell optimales Arbeitsumfeld?

Tjark: Indem ich mit ihnen spreche, ihre Bedürfnisse ernst nehme und Scrum als Projektmethode verfolge. Bei uns gibt es eine klare Grenze zwischen einer Planungs- und einer Umsetzungsphase. Während in der Planungsphase viel zwischen den Entwicklern, Projektmanagern und Kunden besprochen und diskutiert wird, müssen in der Umsetzungsphase die äußeren Einflüsse so gering wie möglich gehalten werden. Sobald ich den Satz höre: „Ich würde gerne einfach mal in Ruhe etwas fertig machen“, schrillen die Alarmglocken.

 

Was machst Du dann?

Tjark: Während der Wechsel von der Planungs- in die Umsetzungsphase für das Dev-Team ein klar festgelegter Zeitpunkt ist, sind viele Prozessbeteiligte von diesem harten Schnitt oft irritiert. Plötzlich fehlen die Entwickler in den Kundenmeetings und Mails werden nicht mehr vom Entwickler selbst, sondern von mir als Product Owner beantwortet.

Sicherlich ist die direkte Kommunikation mit dem Entwickler schneller als mit mir als Mittler, aber die Gefahr, dass ein Entwickler plötzlich statt Entwicklungs- nur noch Projektarbeit macht, ist ausgesprochen groß. Und wenn ein Entwickler nicht mehr mitentwickelt, bleibt sein „Codewissen“ stehen und er muss dieses Wissen erst wieder zeitintensiv aufholen.

Außerdem unterbinde ich auf diese Weise „den kurzen Dienstweg“, der zwar immer eine schnelle Lösung bietet, aber das Produkt sowohl in der Funktionalität als auch in der Codequalität etwas „verdreckt“ und eine Planung unnötig erschwert.

 

Klingt so als ob Du die Entwickler in einen Raum einschließt.

Tjark: Fast. Ich habe das Glück, dass mein Büro eine Glasfront zu dem Flur hat, der direkt zu den Entwicklerbüros führt. Ich sitze dann da wie Zerberus und fange alle „kurze Frage“, „könnt ihr mal eben“, „wie lange braucht ihr (noch)“, usw. ab.

Anfangs haben ich auch orange Verkehrskegel, wie man sie von Straßenabsperrungen kennt, vor die Dev-Büros gestellt, um ein deutliches Signal zu setzen. » mehr zum Thema Fokuszeit

Jetzt sind zwar alle Entwickler und Projekt-Manager im Homeoffice, aber das Konzept des ungestörten Arbeitens während der Fokuszeit hat sich bei allen Beteiligten rechtzeitig vor Corona eingeprägt.

 

Wie geht es mit dem MAC Paygate weiter?

Tjark: Wir haben sehr viele Anfragen für weitere Anbindungen und Erweiterungen. Arbeit ist also ausreichend vorhanden. Ich setze aber alles daran, das Verhältnis zwischen Qualität und Geschwindigkeit ausgewogen zu halten. Es gibt keine „Mach-mal-eben-Lösungen“.

Der Erfolg gibt uns für diese Haltung letztlich recht und mit dem Paygate haben wir ein ausgesprochen gutes Produkt entwickelt, dass auch noch in Zukunft nicht nur den Entwicklern, sondern vor allem den Kunden gefällt.