Learnings, Fazit und Übergabe an die CHRIST IT

Wo kann man die CHRIST Reparaturannahme sehen? Welche Erkenntnisse haben sich aus der sehr intensiven Zusammenarbeit ergeben? All das und mehr erfahrt ihr im letzten Teil unserer CHRIST Story.

von Johanna

|

29. December 2021

29.12.2021

|

Lesedauer: ca. 6 Minuten

Was bisher in unserer CHRIST-Story geschah:

In den Teilen eins bis drei haben uns Constantin und Michael geschildert, in welchen Schritten und auf welchem Wege das MVP der Reparaturannahme entstand. 

Dieser vierte und letzte Teil beschäftigt sich vor allem mit den Erkenntnissen und Learnings aus dem Projekt, streift den Übergang der Verantwortung vom brandpfeil DEV-Team zur CHRIST IT sowie Anpassungen am „Tech-Stack“ des MVPs. 

Wie bisher berichten Constantin Klause, CHRIST, und Michael Friedrich, brandpfeil unter behutsamer Anleitung durch Johanna von Estorff

Das Endprodukt

Johanna: Allmählich kommen wir zum Ende unseres Projektes: Constantin, könntest du uns bitte einmal erklären, wie das Endprodukt letztendlich aussieht, welche Besonderheiten es gibt und inwiefern es sich vom „Vorgänger“ unterscheidet?

Constantin: Einen „richtigen Vorgänger“ gibt es ja gar nicht. Wir haben gemeinsam etwas komplett Neues gebaut. 

Das alte Produkt entsprach in etwa dem, was wir in Sprint eins „so nebenbei mitgemacht“ haben. Unser jetziges Produkt ist eher das Fünf- bis Zehnfache: Es gibt eine Baumlogik, mit der man über Entscheidungsfragen bzw. Entscheidungsbäume zu einer Eingrenzung kommt, die aktiv ist. Vorher gab man seine Uhrenmarke an und konnte dann zwischen zehn Reparaturmöglichkeiten auswählen, was man haben möchte. 

Allerdings glaube ich, dass wir noch nicht am Ziel angekommen sind. 

Unser neues Produkt ist das Fünf- bis Zehnfache des alten. - Constantin Klause

Johanna: Wo und wann können wir denn das neue Tool ansehen?

Constantin: Eigentlich hatten wir uns vorgenommen, im Jahr 2021 live zu gehen, das wird aber leider noch nichts, weil wir jetzt intern merken, dass wir noch Ressourcen wie einen Product Owner auf Fachbereichsseite entwickeln müssen. 

Also Kolleg:innen, die beispielsweise verstehen wie ein Wording aussehen muss. Wir können nicht einfach x-beliebig beschreiben, wie die Fragen sind oder wie die Markenbäume funktionieren. Außerdem müssen wir dafür sorgen, dass die Markenbäume verschiedener Marken ungefähr der gleichen Logik folgen. Es ist eine Herausforderung, jemanden im Fachbereich zu haben, der weiß, dass die Logik des Fossil-Baumes der des Armani-Baumes ähnelt, obwohl wir die Reparaturen auf unterschiedliche Werkstätten aufgeteilt haben. 

Michael: Ein Change-Prozess durch eine neue Software….

Constantin: Ja, wir merken gerade, dass dem Tool viele interne Prozesse folgen und wir durch das Projekt die Organisation in unserem Reparaturkontext verändern. Also gilt es, mit einem „Product Owner“ eine neue Stelle zu kreieren, die das Thema selbstständig vorantreibt. Diese Rolle haben mein Kollege Arne und ich in der Vergangenheit übernommen, wir merken jedoch, dass wir eine dedizierte Ressource benötigen, die näher an den Werkstätten dran ist. Und deswegen ist das Tool leider noch nicht online. 

Wir sind weiterhin dran, versuchen aber auch, das Ganze richtig zu machen. Dadurch, dass es das vorher so noch nicht gab und wir nicht den Druck haben etwas technisch Veraltetes abzulösen, möchten wir es erst online stellen, wenn wir auch zufrieden sind.  

Learnings und Fazit zur Zusammenarbeit

Johanna: Wart ihr denn zufrieden mit der Zusammenarbeit mit brandpfeil?

Constantin: Ja, klar – das drückt auch unser Wille aus, an dieser Case Study mitzuwirken.

Ich schätze es wert, dass wir von Anfang an mit offenen Karten spielen und sagen konnten: Bitte baut die Reparaturannahme so, dass wir euch am Ende nicht mehr brauchen. Immerhin haben brandpfeil und Michael damit dafür gesorgt, sich selbst überflüssig zu machen.

Ich fand es total super, dass es trotzdem keine Irritation gab: Weder „Wir brauchen noch einmal fünf Sprints mehr“ oder „Das Tool funktioniert nur halb“ oder „Wir erklären Euch nicht, was im Quellcode steht“. Das ganze Projekt war total auf Augenhöhe, total nett und total gut.

Was wir auch gemerkt haben ist, dass das Thema so speziell ist, dass man nicht einfach sagen kann, dass man am nächsten Tag eine andere Agentur nimmt, um etwas nachzufragen.

Johanna: Könntet ihr euch denn vorstellen in Zukunft nochmal für dieses oder ein anderes Projekt mit uns zusammenzuarbeiten?

Constantin: Wir merken schon jetzt, dass das ganze Thema bei uns sehr schnell eine Betriebsblindheit bekommt, sodass es Sinn ergibt, wieder externe Leute hinzuzunehmen. Und wenn wir den nächsten Iterations-Schritt haben, dann werden wir wieder fragen wo die Buttons hinmüssen und wie einzelne Dinge funktionieren können. Das sehe ich im Reparaturkontext als wichtigen Punkt.

Auch generell hat brandpfeil bei CHRIST einen sehr guten Eindruck hinterlassen und ich würde eine weitere Zusammenarbeit auf jeden Fall befürworten.

brandpfeil hat dafür gesorgt, sich selbst überflüssig zu machen. Trotzdem gab es keine Irritationen. - Constantin Klause

Michael: Für uns war das Projekt so spannend und außergewöhnlich, weil wir vom ersten Miro-Board bis zum fertigen Produkt eine große Bandbreite unserer Fähigkeiten einbringen konnten, egal ob Research, Technologie, agile Projektführung, Konzeption, UX, Design und schließlich Web Development. 

Johanna: Michael, sind denn auch Erfahrungen von anderen Projekten mit in der CHRIST-Projekt eingeflossen oder war das etwas komplett Neues? 

Michael: Klar haben wir Erfahrungen mit einbringen können. Das CHRIST-Spezifische haben wir ganz sicher neu gelernt, aber wir konnten Erkenntnisse aus Individual-Entwicklungen für andere Kunden einbringen, mit oder ohne agile Projektführung. 

Solche Konstellationen erfordern stets ein starkes Vertrauensverhältnis zwischen Auftraggeber und Auftragnehmer. Aber dieses haben wir zwischen CHRIST und brandpfeil vorgefunden. 

Wir haben Erfahrungen einbringen können aus anderen Projekten, in denen wir Webseiten gebaut haben, die sich wie Apps verhalten. Dabei half uns unser Erfahrungsschatz mit JavaScript-Frameworks wie React oder vueJS. Von Vornherein hatten wir „Progressive Web Apps“ im Sinn, als wir begannen, die technische Umsetzung für CHRIST zu planen. 

Johanna: Gab es denn jenseit der kundenspezifischen Dinge auch neue Erkenntnisse für uns, die wir für zukünftige Kundenprojekte mitnehmen können?

Michael: In unserer normalen Welt der Open-Source-Systeme – wie WordPress, TYPO3 oder Shopware – bauen wir selten ein komplett eigenes Backend auf. Das haben wir für CHRIST getan. Allerdings haben wir von vornherein das Backend als Bedienoberfläche für CHRIST-User begriffen, daher wurde dieses nach UX-Gesichtspunkten gestaltet. Das wird uns auch für andere Projekte von Nutzen sein. 

Bestätigt hat uns dieses Projekt in unserer Bereitschaft, Kunden genau zuzuhören. Wenn wir ein Verständnis für die Kundenwünsche und die Wünsche von deren Kunden aufbringen, wenn wir uns auf verschiedene Denkweise einlassen, funktionieren wir am besten. – Dann können wir Entscheidungen im Sinne des Kunden treffen, was nicht nur in Projektphasen mit hoher Auslastung die Treffgenauigkeit und die Umsetzungsgeschwindigkeit erhöht. 

Wir investieren zwar alle im Workshop eine Menge Zeit, aber bei der Umsetzung wissen wir, was die Anforderungen der Stakeholder sind – und dann kann man als Product Owner gute Entscheidungen treffen. Insofern hat mich das Projekt in unserer Arbeitsweise bestärkt. 

Wir "funktionieren" am besten, wenn wir ein Verständnis für die Wünsche unserer Kunden aufbringen, uns auf verschiedene Denkweise einlassen. - Michael Friedrich

Constantin: Was ich gern betonen möchte: Die Zusammenarbeit zwischen den Entwicklern von brandpfeil und von CHRIST war wirklich gut. Von unserer Seite hatte keiner das Gefühl, dass brandpfeil ein externer Dienstleister ist, sondern es stand immer das Ergebnis im Vordergrund. 

Am Projektende haben wir ganz offen besprochen, welche Dinge nicht mehr übernommen werden können, weil sie den Rahmen gesprengt hätten. Jeder auf CHRIST-Seite war darüber im Bilde. brandpfeil hat insofern keine „Paketübergabe“ vorgenommen, sondern wir haben die ganze Zeit dafür gesorgt, dass es ein fließender Übergang wird. Das fand ich echt gut und es ist auch super, dass sich die Kolleg:innen von brandpfeil darauf eingelassen haben. 

Es gab sogar Situationen, in denen ein brandpfeil Entwickler einem CHRIST Entwickler (wie einem Kollegen) gesagt hat, was er tun soll. Das hatte ich so auch noch nicht erlebt. Wir hatten uns aber bewusst dafür entschieden, in der finalen Übergabephase von brandpfeil zur CHRIST IT auf einen dedizierten Projektleiter zu verzichten und darauf vertraut, dass die Mitarbeiter unter sich gut klarkommen und niemand Befindlichkeiten hat. Das hat hervorragend funktioniert, und das möchte ich noch einmal hervorheben. Die Chemie hat einfach gestimmt. 

Michael: Du sprichst die dritte Phase des Projektes an, die wir bisher nur gestreift hatten: Nach der Erstellung des MVPs gab es als letztes Teilprojekt die Übergabe an die CHRIST IT. 

In dem Zuge wurde auch der Tech Stack komplett an die Landschaft von CHRIST angepasst. Glücklicherweise mussten wir die vueJS-Frontends nicht anfassen, jedoch gemeinsam mit der CHRIST IT das Backend und die APIs aus unserer PHP/Laravel-Logik in die .net-Architektur überführen. 

Das besondere daran war, dass sich die Entwickler komplett selbst organisiert haben, trotzdem (oder gerade deshalb?) hat der Aufwand mit unserer Schätzung übereingestimmt. Spätestens an der Stelle waren dann auch die Kaufleute zufrieden. 

Johanna: Das ist doch ein schöner Abschluss für unser Interview. Vielen Dank, dass ihr mitgemacht habt!

Das war der letzte Teil unserer Interview-Reihe „Die CHRIST-Story“. Hier noch  einmal der Überblick über die bisherigen Teile: 

Vielen Dank fürs Dranbleiben. Wenn du Anmerkungen hast, schreib uns gern auf LinkedIn


Teilen via: