Transkript
Jörg: Hallo und herzlich willkommen zu einer neuen Episode des Podcasts CTO Need to Know. In diesem Podcast sprechen wir mit Entscheiderinnen und Entscheidern über ausgewählte Themen, um ihre Sicht auf die Herausforderungen, die Fragestellungen und die gemachten Erfahrungen aufzugreifen, die wir mit euch in diesem Podcast teilen wollen. Mein Name ist Jörg Müller. Ich bin Principal Consultant bei INNOQ und seit circa 25 Jahren in verschiedensten Rollen in der IT unterwegs.
Jörg: In den vergangenen Episoden haben wir uns oft mit größeren Unternehmen unterhalten und sind dabei auf deren Herausforderungen eingegangen, zum Beispiel Legacy-Modernisierung. Heute sprechen wir mit Movacar, einem Start-up, und deren Herausforderung, ein Projekt in einem sehr engen Zeitplan umzusetzen, also mal ein etwas anderer Blickwinkel auf die Dinge. Dazu haben wir Eustach und Karl eingeladen. Möchtet ihr euch gerne kurz vorstellen?
Eustach: Ja, gerne. Grüß dich, Jörg. Vielen Dank, dass wir heute dabei sein dürfen. Also ich bin Eustach, bin einer der Gründer von Movacar. Ich habe meine gesamte berufliche Laufbahn in der Mobilität verbracht. Ich bin seit fast 30 Jahren in Sachen Mobilität unterwegs und habe über 20 Jahre erst mal für einen großen Autovermieter das Vermietgeschäft von Grund auf in Deutschland aufgebaut als General Manager, teilweise mit Karl zusammen. Und dann haben wir uns 2018, nachdem wir beide das Unternehmen verlassen hatten, da haben wir Movacar gegründet und befassen uns mit Fahrzeuglogistik.
Karl: Genau, ja, ich bin Karl, ich bin der andere Gründer von Movacar. Ich habe eher einen kaufmännischen Background, habe verschiedene Positionen bei diesen großen Autovermietungen genommen und bin über die Welt gereist und am Ende in Berlin gelandet mit Eustach zusammen und ja.
Jörg: Okay, Movacar ist ja nun ein recht junges Unternehmen, wahrscheinlich kennt das noch nicht jeder, der Hörer. Wollt ihr vielleicht mal ganz kurz vorstellen, was Movacar macht?
Eustach: Ja gerne. Also, im Prinzip sorgen wir dafür, dass Fahrzeuge überführt werden. Das ist ja ein großer Bestandteil der Operations für eigentlich jeden, der einen Fuhrpark betreibt oder eine Flotte. Und für uns als Autovermieter war das auch immer ein Riesenthema und vor allem auch ein großer Kostenblock. Und da haben wir uns Gedanken gemacht, wie wir den Bereich effizienter gestalten können und auch kostengünstiger und haben da eine Idee aufgegriffen, die schon länger in der Branche kursierte, nämlich Privatreisende zu rekrutieren, um die Fahrzeuge zu überführen. Das hat natürlich den Riesenvorteil, dass in der Kalkulation keine Personalkosten anfallen. Wir vermarkten diese Überführungsfahrten als Einwegmiete für einen Euro. Das heißt also unsere Nutzer haben den großen Vorteil, dass sie im Prinzip umsonst von A nach B kommen und damit gleichzeitig eben eine Dienstleistung erbringen, die wir dann gegenüber dem Flottenbetreiber oder dem Vermieter dann abrechnen können.
Jörg: Mhm. Mhm.
Eustach: Daneben haben wir noch ein zweites Standbein, denn nicht für jede Fahrt kann man einen Privatreisenden einsetzen und das ist der Einsatz von gewerblichen Fahrern. Das betrifft dann auch das Thema, was wir heute besprechen, nämlich die entsprechende Plattform dazu.
Jörg: Ah ja, super, genau. Ja, letztes Jahr seid ihr ungefähr um die Zeit, also für die Hörer, wir haben jetzt gerade 2024 im Juli, seid ihr ungefähr um diese Zeit auf uns zugekommen und habt gesagt, hey, ihr habt da ein neues Projekt mit dem Wunsch, dass wir bei der Entwicklung helfen. Und du hast ja gerade schon das Thema gewerbliche Fahrer angesprochen. Also erzähl mal ganz kurz, worum ging es in dem Projekt und warum war das eigentlich so dringend?
Eustach: Also, wie erwähnt, haben wir den Bereich eigentlich immer schon mit abgewickelt. Wir hatten dafür vorher eine externe Lösung, mit der wir dann aus verschiedenen Gründen nicht mehr zufrieden waren und beschlossen haben, dann unsere eigene Plattform für die Rekrutierung von gewerblichen Fahrern aufzusetzen. Wir hatten dabei eben sehr engen Zeitrahmen auch, weil unsere alte Lösung eben ein Sunset-Datum hatte, die lief also aus und wir mussten also zu diesem Datum eine funktionierende Plattform an den Start schieben, mit der wir in der Lage sind, dann eben gewerbliche Fahrer zu rekrutieren und entsprechend die Fahraufträge zu platzieren.
Jörg: Ja spannend war ja für mich dabei zum Beispiel, dass es so wahnsinnig viele Leute gibt, die tatsächlich solche Überführungen auch gewerblich machen. Also kannst du da mal so ein paar Rahmendaten nennen, wie viele Leute das sind.
Eustach: Also es ist so, dass das ist ein Thema, was so ein bisschen unter der Oberfläche passiert, weil das sieht natürlich nicht jeder. Für jemanden, der aus der Branche kommt, der weiß, dass jedes Jahr Millionen von Fahrzeugen überführt werden, insbesondere auf Eigenachse, aber teilweise auch auf Fremdachse, also auf LKWs. Und wir schätzen also, dass das Volumen in Deutschland da, wie gesagt, mehrere Millionen Transfers sind im Jahr. In Europa sind es ungefähr dreimal so viel. Also es ist eine beträchtliche Anzahl von Transaktionen, die da stattfindet. Und das Thema ist eben, dass gerade mit der Transformation der Mobilität von Eigentum hin zu Nutzung, also Pay-Per-Use, das hat vielleicht jeder schon mal gehört, es gibt zunehmend mehr Auto-Abos und Angebote, wie man eben Mobilität einkauft. Also die Art und Weise, wie Mobilität konsumiert wird, verändert sich und damit steigt auch ständig der Bedarf an Fahrzeugüberführung. Und dieser Bedarf wächst halt schneller als der Pool von Fahrern. Und das ist ein Thema, dem wir uns angenommen haben und was wir adressieren, um da einfach zusätzliche Kapazitäten zu schaffen und skalierbare Ressourcen für Fahrzeugüberführung zu bieten für dieses wachsende Publikum an Mobilitätsanbietern.
Karl: Dazu kamen auch ein paar externe Themen wie die Krieg in der Ukraine oder Brexit, das hat dazu geführt, dass die Anzahl von Fahrern sich deutlich reduziert hat auch.
Jörg: Und das Spannende ist ja, was ich so am Anfang gelernt habe, die meisten haben quasi kaum IT im Einsatz gehabt, um sich da irgendwie zu koordinieren. Das meiste lief eigentlich eher über WhatsApp-Gruppen und Excel-Sheets und ähnliche Dinge. Da sind also teilweise Unternehmen mit 20, 30, 40 Fahrern unterwegs gewesen. Das fand ich tatsächlich sehr, sehr spannend. Der Zeitrahmen, ich werfe es mal kurz rein, waren drei Monate. Also wir mussten von der Idee und von dem Zeitpunkt, wo ihr eigentlich auf uns zugekommen seid und das Ganze umgesetzt werden soll, das Ganze in drei Monaten umsetzen und idealerweise mit einer Web-Oberfläche, mit App, die da entwickelt werden sollte und ganz vielen Ideen, die auch am Anfang reingekommen sind mit KI, Touren-Vorschlägen und all solchen Dingen. Ich muss gestehen, die meisten meiner Kollegen, die da jetzt auch involviert waren, die wären natürlich erstmal etwas schockiert und haben gedacht, um Gottes Willen, wie wollen wir das in drei Monaten umsetzen? Im schlimmsten Fall brauchen wir ja zwei, drei Wochen alleine, um eine App in den App Store zu bekommen und ähnliche Dinge. Insofern, das fand ich tatsächlich eine sehr spannende Herausforderung. Aber vielleicht ein Spoiler an der Stelle. Wir haben es tatsächlich geschafft. Nicht in der perfekten Variante, aber wir waren dann tatsächlich am 1. Oktober mit einer Lösung live. Aber die Frage ist ja, wie hat das funktioniert, vor allem auch aus eurer Sicht? Was waren aus eurer Sicht die Dinge, die dazu geführt haben, die wir tun mussten, damit das Ganze tatsächlich geklappt hat?
Karl: Ja, also ich glaube, effektiv war das eher zweieinhalb Monate und dazu kam natürlich, dass alle in Urlaube sind. Und wir hatten, ich glaube, das Schlüssel war, ganz am Anfang haben wir diese Workshop gemacht und diese Workshop brachte alle Stakeholders zusammen, also wir als Entscheidungsträger und auch das Entwicklungsteam und auch der Product und auch teilweise unser Marketing-Abteilung war dabei. Und alle am gleichen Tisch haben wir die verschiedenen Features und Bedürfnisse besprochen und durchgegangen. Und dann haben wir das natürlich prioritisiert. Wir haben nicht alles ausgerollt am 1.10. Es war ein Prozess und viele Features kamen danach. Aber ganz am Anfang, die Workshop und die Kommunikation, das war der Schlüssel, finde ich.
Eustach: Ich glaube, ich wollte das eben nur zufügen. Ich glaube, paradoxerweise hat der Zeitdruck tatsächlich auch dafür gesorgt, dass wir uns schneller bewegt haben. Denn dieser enge Zeitrahmen hat natürlich auch diktiert, dass wir also nicht uns in Perfektion versteigen konnten, sondern wir mussten einfach schnelle pragmatische Entscheidungen darüber treffen, was die Kernfunktionalitäten sind, die wir also unbedingt brauchten. Und das hat aus meiner Sicht auch geholfen, das Ganze zu beschleunigen.
Jörg: Ja, ich kann mich noch sehr gut an den Workshop erinnern. Das Interessante war, dass wir am Anfang, glaube ich, mit einer völlig anderen Idee reingegangen sind, was da eigentlich umgesetzt werden soll, als das, was nach zwei Tagen dann am Ende rausgekommen ist. Das waren, glaube ich, ganz unterschiedliche Dinge an der Stelle. Ich glaube, was auch nicht ganz unwichtig war, ich werfe das mal von unserer Seite rein, dass eben nicht nur die Stakeholder waren, die drin waren und irgendwie ein paar Businessanalysten, sondern dass tatsächlich letzten Endes auch jeder Entwickler, der später an dem Projekt beteiligt war, also bis auf einen, der war leider im Urlaub, aber alle anderen tatsächlich mit in dem Workshop gesessen haben und dadurch verstanden haben, was eigentlich wirklich gefordert wird und was wichtig ist für den Kunden, was dann letztendlich natürlich hinterher auch irgendwie spannende Effekte ausgelöst hat.
Karl: Absolut. Und das hat auch dazu geführt, dass wir ein bisschen enger zusammengekommen sind und dadurch diese Kommunikation innerhalb des 2,5 Monate deutlich besser war. Wir hatten unsere Dailies, das war ganz klar, aber zwischendurch gab es Fragen, dann konnten wir ganz schnell in einen Huddle gehen oder was auch immer und haben das schnell gelöst.
Jörg: Ja, Dailys, spannendes Thema. Viele Leute finden ja immer die Scrum-Zeremonien relativ lästig oder unnötig. Aber ich glaube, an der Stelle war das wirklich sehr, sehr gut, sich da sehr regelmäßig mit den richtigen Leuten zusammenzusetzen. Und es war natürlich auch traumhaft, mit welcher Geschwindigkeit ihr teilweise reagiert habt. Wir waren ja dann gemeinsam mit einem Slack-Channel drin. Und manchmal gab es Fragen, um ein Problem zu lösen. Und fünf Minuten später hattest du, Karl, da schon einen Lösungsvorschlag drin.
Karl: Ja, ich glaube, das war ein Key, dass ich schnell entscheiden konnte. Also als Founder von Movacar mit Eustach, wir hatten natürlich die A, das Bedürfnis, bis zu dem 1.10. alles fertig zu haben, deshalb mussten wir schnell reagieren.
Jörg: Willst du ein bisschen was zu den Technologien kurz erzählen, Karl, was da eingesetzt wurde?
Karl: Ja, klar. Zu ganz am Anfang, also was klar war, war, dass die Disponenten an sich die Web-Oberfläche hauptsächlich nutzen würden, weil die eine größere Übersicht haben müssen von Fahrten und was auch immer und der Touren, was wir gemacht haben. Aber natürlich für die Fahrer selber war das Bedürfnis, eine App zu haben. Wir haben ganz am Anfang entschieden, das mit dem Ionic Framework zu machen. Das war eher eine langfristige Entscheidung, dass wir eine Sprache haben, die auch für Apps genutzt werden kann. Ich bin kein Techie, aber das spart auf jeden Fall eine doppelte Entwicklung in der Sache. Natürlich hatten wir auf unser Backend verschiedene Technologien, die wir auch integrieren mussten, wie unsere Admin-Oberfläche, dort nutzen wir Salesforce. Das ist auch nötig, um die ganze Kommunikation zu machen, und auch die Mischung zwischen unserem klassischen Ein-Euro-Produkt und den Pro-Fahrten, wie wir das nennen, das war ziemlich kompliziert teilweise.
Jörg: Ja, ich glaube, die Entscheidung für so ein, ich sag mal, technologieneutrales Framework wie Ionic, oder ist vielleicht jetzt der falsche Begriff, aber es geht ja darum, Apps und Web-Oberflächen zu erzeugen. Und letztendlich hatten wir in dem Zeitraum auch gar keine andere Chance, weil wenn wir versucht hätten, parallel Native Apps zu entwickeln und noch eine Web-Oberfläche zu entwickeln, das wäre, glaube ich, selbst wenn wir ganz viel Geld und Ressourcen da reingeworfen hätten, kaum möglich gewesen.
Karl: Genau.
Jörg: Hat natürlich auch so ein bisschen Nachteile, aber da kommen wir nachher nochmal drauf. So ein paar Dinge haben sich dann im Nachgang auch als schwieriger herausgestellt als das, was wir da an der Stelle hatten. Genau. Was hat denn die Zusammenarbeit da effektiver gestaltet oder was haben wir daraus gelernt?
Eustach: Ich würde sagen, eine Sache, die auch geholfen hat, Karl, das hattest du auch immer wieder gesagt, war die Erstellung der UI zusammen mit INNOQ. Denn da haben wir nicht so einen klassischen Design-Prozess durchlaufen, sondern die UI wurde gebaut und dann haben wir das gleich geprüft. Und dann konnte das Team gleich sozusagen alles dahinter bauen. Verzeih mir die nicht technischen Ausdrücke dabei.
Jörg: Ja, stimmt, das war eine interessante Entscheidung im Team. Unser UX-Designer wollte ursprünglich ganz klassisch vorgehen mit dem Figma-Design und dann haben wir eine Weile darüber diskutiert und er kommt halt auch aus dem Entwickler-Hintergrund. Und dann sind wir zu der Entscheidung gekommen, er baut einfach in Ionic die Oberfläche und diskutiert die dann mit euch und hat die dann teilweise sogar direkt im Prozess dann noch mit euch angepasst. Dadurch war dann die Oberfläche mehr oder weniger schon fertig und der Rest des Teams konnte darauf aufsetzend dann das Backend bzw. die Logik dahinter bauen. Das war tatsächlich so ein ganz interessanter parallel laufender Prozess, wo die Dinge parallel entwickelt worden sind, was es wahrscheinlich auch um einiges schneller gemacht hat.
Karl: Ja, ich glaube, ich war jeden Tag mit ihm beschäftigt damit. Also mit Screenshares und “Was hältst du davon? Was hältst du davon?” Das war ein schneller Prozess, weil er hat das direkt entwickelt und dann hat er die Frontend grundsätzlich fertig gemacht, das weitergegeben an das Entwicklungsteam und dann haben die das Backend eingebunden. Das hat auf jeden Fall dazu geführt, dass dieser Entscheidungsprozess sehr schnell war, diese UX-UI-Review sehr schnell war und das hat auf jeden Fall geholfen.
Jörg: Und er konnte sogar noch Urlaub nehmen, das war interessant. Also bei so einem Projekt drin, er hat dann sogar irgendwie das in dem ersten Monat fertig gemacht und war dann erstmal für ein paar Wochen weg und ist dann später erst wieder dazu gestoßen. Das hat sogar erstaunlicherweise noch funktioniert. Da hatten wir alle relativ große Zweifel dran. Ja, ist interessant. Zeitdruck erzeugt manchmal auch positive Effekte, nämlich Mut und Pragmatismus, bestimmte Dinge anders umzusetzen, als man sie eigentlich denkt an der Stelle.
Eustach: Stimmt, also wir haben von der ursprünglichen Idee da die große Liste, die wir gemacht hatten, um auch Mehrwert Richtung Fahrdienstleister zu bieten auf der Plattform. Das war ja eine unserer Hauptziele. Da haben wir dann doch einiges runterrasiert. Das war natürlich einerseits schmerzlich, aber andererseits eben, wie du sagst, geprägt einfach durch die pragmatische Überlegung, dass wenn wir jetzt uns verzetteln in der Auswahl, welche Sachen jetzt am besten doch drin sein müssen, dann werden wir nicht fertig. Und wenn wir nicht fertig werden, dann heißt das, dass ein wesentlicher Umsatztreiber für uns einfach nicht funktioniert. Und das war natürlich dann ein Umstand, der motiviert hat, da dann teilweise auch harte Entscheidungen zu treffen, Funktionalitäten wegzulassen, die wir doch gerne zum Start drin gehabt hätten.
Karl: Ja, ein gutes Beispiel ist die Entfernung von unserem 1-Euro-Produkt. Wir haben ursprünglich gedacht, wir könnten gleichzeitig unser 1-Euro-Produkt als Verbindungsfahrt für die Fahrer darstellen. Aber das gesamte Konzept von Movacar Pro war, das effiziente Tour-Management vom Disponenten darzustellen. Und dadurch ist es ein Ziel, dass wenn ein Mitarbeiter in Berlin wohnt, als Beispiel, dass er eine Kette baut von Fahrten. Und unser Gedanke da war, wir verbinden bezahlte Fahrten mit unseren 1-Euro-Fahrten, um das so effizient wie möglich zu machen für die Fahrer, dadurch Bahnkosten oder was auch immer zu sparen. Und das mussten wir am Ende rauslassen, weil wir andere Sachen auf den Tisch bekommen haben, die wichtiger waren für den Start. Beispielsweise eine Anbindung an einen großen Autovermieter für die professionelle Fahrten als Beispiel.
Jörg: Wie seid ihr eigentlich umgegangen mit dem Test oder der Einbeziehung potenzieller Endnutzer? Was habt ihr da an der Stelle gemacht?
Eustach: Wir haben ja im Rahmen des Workshops ein Interview geführt mit einem Disponenten, also wir haben praktisch einen kleinen Clickdummy gebaut und haben den also laufend auch befragt, um das Input zu haben der Endnutzer. Das ist ja letztendlich der ausschlaggebende Punkt, dass das, was wir da bauen, auch wirklich nutzbar und nützlich ist für diejenigen, die es dann nutzen sollen.
Jörg: Gut, jetzt ist das Ganze zum 1.10. live gegangen. Wie hat das denn da funktioniert? Bisschen geruckelt hat es ja trotzdem, oder?
Karl: Ja, ein bisschen. Wir haben bei dem Launch, ich glaube, der Launch war tatsächlich am 4. Oktober wegen Wochenende und allem. Es war interessant, also viele Bugs natürlich am Anfang, das hatten wir auch erwartet, teilweise. Im Nachhinein habe ich gesehen, wir hätten mehr Testing machen können, aber diese fehlende Zeit, das konnte man nicht ausgleichen. Und es waren ein paar harte Monate, weil viele Sachen mussten wir manuell anfassen. Weil es gibt Fragen dazu oder Probleme oder technische Issues. Natürlich die Verbindung mit den native Apps, das hat auch viele Probleme verursacht, weil das hat nicht so kommuniziert, wie wir das geplant und getestet haben. Wenn man in die reale Welt kommt, sieht es ein bisschen anders aus. Deutschland ist natürlich nicht das beste Land, mit einem 5G-Netz zu fahren. Und teilweise sind die Carports, wo Fahrzeuge abgegeben werden, die haben überhaupt kein Netzwerk, kein WLAN, nichts. Und deshalb war dieses Offline-Thema als Beispiel ganz oben auf unserer Priorität in den ersten Monaten.
Eustach: Man muss dazusagen, wir hatten natürlich auch nicht den Luxus, einen Soft-Launch machen zu können, sondern wir sind gleich praktisch mit Volllast gestartet. Wir waren ja innerhalb von vier oder fünf Wochen auf sechsstelligen Umsätzen auch über die Plattform. Und das ist natürlich eine Riesenherausforderung für das ganze Team, wenn du dabei auch noch das System sozusagen auf die Bugs und die Dinge überprüfen und fixen musst, die noch nicht so richtig funktionieren. Also es war eine heiße Phase für uns.
Karl: Ja, und das Onboarding an sich. Also wir haben zu spät angefangen, die ganzen Fahrer onboarden. Wir hatten ganz beim Launch sehr viele Fahrten zu machen und ganz am Anfang hatten wir nur 50 Fahrer auf der Plattform in den ersten paar Tagen. Und das hat dazu geführt, dass wir sehr viel telefonieren mussten und diesen Onboarding-Prozess schnell implementieren. Das heißt Beschleunigung mit Identitätsprüfungen, mit Führungszeugnisprüfungen, alles drum und dran, das hat sich in die Länge gezogen auf jeden Fall.
Jörg: Ja, das mit der Offline-Fähigkeit ist spannend, was du vorhin angesprochen hast. Wir hatten das ja bewusst ausgeschlossen. Wir hatten ja gesagt, das werden wir nicht schaffen, in der Zeit zu implementieren. Geahnt haben wir das schon. Tiefgaragen gibt es in Deutschland auch, die auch kein Netz haben. Da muss man ein bisschen dran arbeiten. Aber ich glaube, das gehört auch tatsächlich dazu. Also wenn man das in der Geschwindigkeit umsetzen will und schließlich, sagen wir mal, ökonomisch erfolgreich starten will, muss man dann auch damit rechnen, dass das eine oder andere dahinter ruckelt. Deswegen hatten wir ja ursprünglich auch gleich eingeplant, dass wir die erste Zeit da noch eine ganze Zeit mit dabei sind und euch unterstützen, sagen wir mal, das relativ schnell dann auch zu beheben in den ersten Wochen.
Karl: Ja, das hat gut geklappt. Also wir hatten eineinhalb Mitarbeiter für ein guter zwei Monate danach. Und jeder Bug, der aufgepoppt ist, konnten wir innerhalb ein paar Tage klären und lösen. Also es war ein ständiger Verbesserungsprozess. Nichtsdestotrotz, es waren harte Monate. Ich glaube, meine Frau hat mich überhaupt nicht gesehen in den Monaten.
Jörg: Ja, okay. Gut, das ist, also klar, um halt das auch nochmal ganz offen und deutlich zu sagen, wenn man solche Zeitpläne hat, muss man damit rechnen, dass das so ruckelt. Also, dass das dann hinterher ganz sauber durchläuft. Das wäre, wenn, dann wahrscheinlich nur ein sehr großer Zufall gewesen. Und vermutlich nicht zu machen. Ja, war auf jeden Fall sehr, sehr spannend. Zu Ionic wollten wir ja auch nochmal ein paar Worte gerade sagen, von der Entscheidung her. Genau, wahrscheinlich ist es immer noch die richtige Entscheidung, aber was sind trotzdem auch die Nachteile, wenn man so ein Framework einsetzt, Karl? Was habt ihr daraus gelernt?
Karl: Ja, also die Nutzung der Kameras, wie die native Apps mit dem Background agiert, Dokumente speichern, Sendung von Bildern, Dinge wie das. Das ist, ja, knifflige Arbeit, lass uns sagen. Ja, und dann haben wir ein paar andere Dinge gesehen, wie die Nutzung des Webs, dass wir das ausschließen, dass sie Bilder machen können, zum Beispiel, weil wir hatten sehr viele Fahrer, die einfach Bilder gemacht, gespeichert und dann später die Dokumentation gemacht haben. Das ist natürlich nicht der Sinn der Sache. Der Sinn der Sache war, vor Ort Dokumentation zu machen. Aber durch diese fehlende Offline-Funktionalität, das hat dazu geführt, dass die Fahrer keine andere Option hatten. Und das sind Beispiele, Dinge, die wir danach verbessert haben. Aber im Großen und Ganzen bin ich ein totaler Fan von dem Ionic Framework, das erleichtert den Entwicklungsprozess, das reduziert die Bedürfnisse an Anzahl von unterschiedlichen Entwicklern. Dann kann man sich mehr auf die Funktionalität konzentrieren, statt das mit Web, dann mit iOS, dann mit Android, das spart sehr viele Ressourcen.
Jörg: Es ist auch immer wieder faszinierend, wie erfinderisch Nutzer sind, wenn sie mit einem System umgehen. Wenn man eine hinreichend große Anzahl von Nutzern hat, kommen interessante Dinge zum Vorschein, mit denen man vorher auf gar keinen Fall gerechnet hat. Würdet ihr so ein schnelles Projekt wieder durchziehen oder wollt ihr das beim nächsten Mal dann doch anders machen?
Karl: Anders. Natürlich dadurch haben wir sehr viel gelernt. Also das war echt, dieses Projekt war in der Not. Also man muss überlegen, wir haben den ersten Kontakt, ich glaube, das war im Mai mit euch gehabt, über das Projekt an sich. Und dann haben wir den Workshop Anfang Juli gemacht. Und wir haben angefangen zu programmieren Mitte Juli. Und das Ding war im Oktober fertig. Das war sehr anstrengend für alle Parteien. Und natürlich, wenn man ein bisschen mehr Zeit hat, kann man mehr Testings machen, dass das erfolgreicher wird auf dem Markt. Und die Dinge, die wir weggelassen haben, vielleicht nochmal überlegen, bringen wir das doch rein für den Launch oder nicht. Also man redet immer über einen MVP, also ein Skateboard zu bauen, bevor man ein ganzes Auto baut, das ist absolut richtig. Wir haben das immer so gemacht in der Vergangenheit. Aber vielleicht braucht man einen Tick mehr als ein Skateboard, vielleicht ein Go-Kart oder sowas am Anfang. Und es gibt ein paar Funktionalitäten, die wir weggelassen haben, die man grundsätzlich für den Launch braucht.
Jörg: Okay, gut. Trotzdem war es ein sehr spannendes Projekt und ich danke euch sehr für die Zeit und für das Gespräch.
Karl: Danke Jörg. Ich muss euch bedanken für die ganze Arbeit. Danke.
Jörg: Ja, kein Problem. Ja, danke auch an unsere Zuhörerinnen und Zuhörer. Ich hoffe, dass das für euch auch mal ein etwas anderer Blickwinkel wieder war und die eine oder andere Erkenntnis oder das eine oder andere Learning dabei ist. Ja, und damit macht’s gut und bis zum nächsten Mal.
Eustach: Vielen Dank, lieber Jörg.