SlideShare ist ein Scribd-Unternehmen logo

Einfangen eines technisch kaputten projektes

•
•
Johann-Peter Hartmann
Johann-Peter Hartmann

Keiner glaubt mehr an die Versprechen aus der IT, weder Druck, Motivation noch ein grösseres Team bringen auch nur etwas Performance. Es gibt viele Fehler in der Software und die Fluktuation geht nach oben. Wie fängt man so ein Projekt ein? Eine Geschichte von den offensichtlichen und nicht so offensichtlichen Dingen, die man dabei berücksichtigen muss - aus dem echten Leben erzählt.

1 von 32
Downloaden Sie, um offline zu lesen
Einfangen eines technisch kaputten Projektes Johann: Hallo! Erfolg kann jeder, und wenn man Konferenzen trauen darf, dann besteht unser Leben praktisch nur aus welchen. Aber man lernt mehr aus Katastrophen.
Wer war schon einmal in einem Katastrophen- Projekt? Johann: Frage an das Publikum: Wer von Euch war schon einmal in einem Katastrophenprojekt? Projekte, in denen Dinge langsam werden, Interessen unklar sind und man sich gerne und viel streitet? Die Zielstellungen unklar sind?
Wir auch. Uns geht das nicht besser. Wir, das sind : Andreas Goschler - Chief Product Manager bei myDriver und verantwortlich für die Produktentwicklung unserer Chauffeurservice-Vermittlungsplattform Johann-Peter Hartmann - CTO, Chief Tailwind Officer bei Mayflower und gerne da mit dabei wo es brennt.
Wie man mit lauter richtigen Schritten zur einer kaputten Plattform kommt. Andreas: Katastrophen passieren nie mit Absicht und nur selten aus Dummheit. Und auch in unserem Fall war jeder einzelne Schritt sinnvoll, auch wenn die Summe aller Schritte zu einer schwer wartbaren Software geführt hat.
Andreas: myDriver ist der jüngste Mobilitätsdienst aus dem Hause Sixt.
2012. Andreas: Wie haben wir begonnen? Mit einem klassischen Businesscase ca. 10 Wochen vor Jahresende wollten wir uns mal anschauen, ob man in dem gerade neu entstehenden Markt der Taxivermittlung etwas machen kann.
0 12500 25000 37500 50000 Fahrzeuge Taxi Chauffeurservices ? Andreas: Während es bei den Taxis bereits eine ganze Reihe von Startups gab die erfolgreich in der Vermittlung tätig waren, gab es bei den Chauffeurservices in Deutschland noch gar nichts - obwohl diese zahlenmäßig mit 2/3 der Anzahl Taxis nur unwesentlich weniger stark vertreten waren
Andreas: Der Businesscase war währenddessen im Ausland quasi validiert - der Erfolg von Uber in den USA und Addison Lee in London hat uns bestärkt auch in diesen Markt zu einzusteigen.
7 Wochen. Andreas: Innerhalb von 7 Wochen wurde die Applikation mobil und als Website entwickelt und im Januar 2013 in Deutschland gelauncht.
Johann: Wie kann man so eine Software schnell liefern? Die Frage können die Vorredner von Rocket und Project A am besten beantworten - indem ich einen fertigen Baukasten verwende - in diesem Fall den von Sixt, bei dem die meisten Funktionalitäten von Payment über Billing und Reservierung schon existieren.
Januar April Juli Oktober Januar Fahrten Andreas: Sofort nach Launch ging es mithilfe von Marketingmassnahmen steil bergauf. Unser Service stieß sowohl auf Kunden wie auch auf Fahrerseite auf reges Interesse und die Anfangseuphorie war bei allen riesig.
Januar April Juli Oktober Januar Fahrten Panik! Andreas: Die ersten Monate waren wir natürlich vollkommen damit beschäftigt unser Serviceversprechen einzulösen. Allerdings war schnell klar, dass die Kunden - die wir über Marketing akquirierten - die kamen nicht wieder von sich aus zurück und dass das finanziell nicht so lange Sinn macht - erschließt sich von selbst. Genau das ist der Moment, in dem die eigene Roadmap nicht mehr von einem selbst kommt, sondern vom Kunden bzw. Allen die meinen zu wissen was man braucht. Es ist zwar klar, dass es zu wenig Wiederkehrer gibt, aber warum sie nicht wiederkommen ist unklar.
Januar April Juli Oktober Januar Fahrten Feature A? Feature B? Feature C? Andreas: Was macht man in dem Moment? Man bewirft die Software mit Features. Features von denen man meint, dass der Kunde sie unbedingt braucht. Faktisch weiß man noch nicht, welche funktionieren werden.
Mitte-Ende 2013: 
 Development wird langsam Andreas: nachdem man die Software eine Weile mit Features beworfen hat kommen die Features immer langsamer, und es passieren immer mehr Bugs.
„Die Developer müssen schneller liefern! Andreas: Was passiert also? Die Developer werden aufgefordert mehr zu liefern, jetzt kommt es nämlich darauf an.
Abhängigkeiten + 
 Technische Schulden =
 Kein Fortschritt. Sorry …<3 Die Entwickler können das aber nicht - sie sind nicht wirklich flexibel in Ihrer Bewegung, und sie können nur im Rahmen dessen navigieren was die Legobausteine der alten Systeme erlauben. Dazu kommen technische Schulden - immer wenn es eilig wird geht die Qualität verloren. Technical Debt macht die ganze Entwicklung nicht nur langsamer, sondern erzeugt auch mehr Bugs in der Arbeit - die dann wiederum selbst noch für eine Verlangsamung sorgen.
Druck! Andreas: Das Entwicklung bringt also nicht die Performance die es braucht - erster Lösungsansatz ist mehr Druck. Das funktioniert auch kurzzeitig, versagt aber auf der mittleren Strecke. Und zwar meist schon nach sehr kurzer Zeit.
Resultat: Die Performance sinkt nach einem initialen Anstieg weiter. Johann: Druck auf Softwaredeveloper hilft nur begrenzt weiter - am Anfang steigt die Lieferfähigkeit, und auch Überstunden resultieren in mehr Features. Das geht etwa 4 Wochen gut, dann flaut die Mehrleistung nicht nur ab, sondern man landet sogar unterhalb dem Torniveau - denn die technische Qualität ist einmal mehr deutlich gesunken.
Mehr Leute!Andreas: Die zweite Strategie ist in der IT auch nicht eben unüblich - wenn ich mehr Features über Zeit will, erhöhe ich die Zahl der beteiligten Leute.
Brooks Law: „Adding manpower to a late software project makes it later" (Un)bekannt seit 1975. Johann: Eigentlich ist Brooks Law schon von 1975, doch seltsamerweise hat es sich noch lange nicht in deutsche Managementetagen herumgesprochen. Ich kann den Featurefluss nicht schnell erhöhen indem ich neue Leute in das Projekt nehme. Ganz im Gegenteil - es wird langsamer, und diese Verlangsamung kann durch für ein halbes Jahr gelten, bevor das Projekt durch die neuen Kollegen an Fahrt gewinnt, manchmal geschieht dies auch nie.
Resultat: Die Performance sinkt weiter, jetzt aber teurer. Johann: Fazit daraus - die Performance sinkt immer noch, die Kosten sind allerdings gestiegen.
Featuredruck Lieferfähigkeit Viel Aktion, wenig Resultat. Johann: Und am Ende befindet man sich in einer Situation, in der der Featuredruck immer mehr steigt, die Lieferfähigkeit immer kleiner wird. Die übliche Antwort darauf: Aktionismus - es werden mehr Dinge probiert, andere Leute, andere Techniken. Solche Projekte werden auch Deathmarch, also Todesmarschprojekte genannt - da gibt es sogar ein Buch mit genau diesem Titel zu.
Chaos Johann: Als Management denkt man: Liebes Development, jetzt wird es gerade wirklich wichtig, und Ihr performed überhaupt nicht. Was soll ich denn bitte noch tun?
Chance Johann: Und wenn Du lange genug im Chaos steckst und nichts nachhaltig den gewünschten Erfolg bringt - dann tut sich faktisch eine Chance auf.
Featuredruck Lieferfähigkeit Johann: Wenn ich einen Schritt zurücktrete ist die Lösung doch eigentlich ganz offensichtlich: Ich muss die Lieferfähigkeit nach oben bringen und den Bedarf reduzieren. Das sagt sich jetzt leicht. Wie erreiche ich das?
Hosen runter & 
 Shareholdersupport Andreas: In unserem Fall haben wir den gesamten, angehäuften Bedarf schonungslos auf den Tisch gelegt und damit ein Bewusstsein geschaffen dass wir hier auf ganz viele lose Enden blicken. Konkret waren da Features für B2C Kunden, Features für B2B Kunden, ellenlange Wunschlisten der angeschlossenen Fahrer, aus dem BI, dem Marketing, dem Accounting, der Operations etc. etc. Ab diesem Moment wussten wir unseren Shareholder hinter uns - und das gibt einem erst den Freiraum, um wieder aus dem Sumpf herauszukommen.
Störungen reduzieren Andreas: Wie haben wir es gemacht? Natürliche Verknappung auf der Maintenance-Seite, und die klügsten Leute mit Domainwissen so freigeschaufelt. Wir haben Business und Technik räumlich getrennt - das soll man eigentlich nicht machen, war in dieser Situation aber notwendig.
Fokus 20 % 80 % Kano-Modell Andreas: Und während man den Featuredruck nicht reduzieren kann, kann man ihn wenigstens fokussieren. Es gilt die Pareto-Regel: mit 20% des Aufwands kann man 80% des Nutzens erreichen. Wir haben das im konkreten Fall mit dem Kano-Modell gemacht, und den Rewrite über die Internationalisierung als Lean Startup gemacht - also ein MVP, ein kleinstmögliches Produkt in einem anderen Land aufgebaut und dann nach und nach die übrigen Features ergänzt.
Sequentiell > Parallel Time to Market:
 3 Monate im Mittel Fokus: unklar Time to Market:
 2 Monate im Mittel Fokus: klar Johann: In Deathmarchprojekten sind oft sehr viele Dinge parallel in Arbeit - man hofft die Time to Market zu verbessern, indem man früh beginnt. Faktisch ist es aber offensichtlich, dass die Time to Market bei sequentieller Bearbeitung deutlich besser ist, denn abgeschlossene Tätigkeiten werden früher geliefert. Und nicht nur das - durch den besseren Fokus liefert die Entwicklung schneller.
Immer QA statt QA-Phasen Deploy in 5 Minuten Cloud statt Server Infrastructure as Code DEV
 SPEED Johann: Nächster Schritt war Development auf Speed bringen. Da gehört nicht nur Fokus dazu, auch das Environment muss stimmen. Dafür haben wir DevOps- Methoden benutzt - gleich in die Cloud, automatisiertes Deployment, automatisierte Tests. Es gibt keine QA-Phasen, weil kontinuierlich - automatisch und manuell - getestet wird. Die komplette Plattform kann in 45 Minuten neu aufgebaut werden, wenn es einen Ausfall gäbe. Die gibt es jetzt natürlich nicht mehr.
Kontrollverlust Andreas: Das Management muss zulassen, dass die Entwicklung sich neu sortiert und darauf vertrauen, dass sie in absehbarer Zeit wieder lieferfähig wird. Wenn ich da in einen Modus des Micromanagement und der Planung übergehe - was in so einer Situation ein nachvollziehbarer Reflex ist - dann ersticke ich jedes noch so kleine Quäntchen auf Erfolg. Statt dessen ist meine Aufgabe das Alignment von Development und Businessanforderungen. Jeder muss verstehen, worum es wirklich geht. In unserem Fall war ich derjenige der zwar das Domainwissen besaß aber die Lösung genauso wenig kann wie alle anderen. Ich kann nur empfehlen sich mitten in diesen Prozess hinein zu begeben, darauf zu vertrauen dass die Entwicklung die Lieferfähigkeit sehr bald wieder herstellen wird und die eigene Energie dafür einsetzen den Weg von jeglichen Blockaden zu befreien.
Fragen! Andreas: Wir haben erst vor wenigen Wochen erfolgreich unsere neue Platform gelauncht, bereits 4 weitere europäische Ländern eröffnet und keine Sekunde Downtime gehabt ;-)

Weitere ähnliche Inhalte

Einfangen eines technisch kaputten projektes

  • 1. Einfangen eines technisch kaputten Projektes Johann: Hallo! Erfolg kann jeder, und wenn man Konferenzen trauen darf, dann besteht unser Leben praktisch nur aus welchen. Aber man lernt mehr aus Katastrophen.
  • 2. Wer war schon einmal in einem Katastrophen- Projekt? Johann: Frage an das Publikum: Wer von Euch war schon einmal in einem Katastrophenprojekt? Projekte, in denen Dinge langsam werden, Interessen unklar sind und man sich gerne und viel streitet? Die Zielstellungen unklar sind?
  • 3. Wir auch. Uns geht das nicht besser. Wir, das sind : Andreas Goschler - Chief Product Manager bei myDriver und verantwortlich für die Produktentwicklung unserer Chauffeurservice-Vermittlungsplattform Johann-Peter Hartmann - CTO, Chief Tailwind Officer bei Mayflower und gerne da mit dabei wo es brennt.
  • 4. Wie man mit lauter richtigen Schritten zur einer kaputten Plattform kommt. Andreas: Katastrophen passieren nie mit Absicht und nur selten aus Dummheit. Und auch in unserem Fall war jeder einzelne Schritt sinnvoll, auch wenn die Summe aller Schritte zu einer schwer wartbaren Software geführt hat.
  • 5. Andreas: myDriver ist der jüngste Mobilitätsdienst aus dem Hause Sixt.
  • 6. 2012. Andreas: Wie haben wir begonnen? Mit einem klassischen Businesscase ca. 10 Wochen vor Jahresende wollten wir uns mal anschauen, ob man in dem gerade neu entstehenden Markt der Taxivermittlung etwas machen kann.
  • 7. 0 12500 25000 37500 50000 Fahrzeuge Taxi Chauffeurservices ? Andreas: Während es bei den Taxis bereits eine ganze Reihe von Startups gab die erfolgreich in der Vermittlung tätig waren, gab es bei den Chauffeurservices in Deutschland noch gar nichts - obwohl diese zahlenmäßig mit 2/3 der Anzahl Taxis nur unwesentlich weniger stark vertreten waren
  • 8. Andreas: Der Businesscase war währenddessen im Ausland quasi validiert - der Erfolg von Uber in den USA und Addison Lee in London hat uns bestärkt auch in diesen Markt zu einzusteigen.
  • 9. 7 Wochen. Andreas: Innerhalb von 7 Wochen wurde die Applikation mobil und als Website entwickelt und im Januar 2013 in Deutschland gelauncht.
  • 10. Johann: Wie kann man so eine Software schnell liefern? Die Frage können die Vorredner von Rocket und Project A am besten beantworten - indem ich einen fertigen Baukasten verwende - in diesem Fall den von Sixt, bei dem die meisten Funktionalitäten von Payment über Billing und Reservierung schon existieren.
  • 11. Januar April Juli Oktober Januar Fahrten Andreas: Sofort nach Launch ging es mithilfe von Marketingmassnahmen steil bergauf. Unser Service stieß sowohl auf Kunden wie auch auf Fahrerseite auf reges Interesse und die Anfangseuphorie war bei allen riesig.
  • 12. Januar April Juli Oktober Januar Fahrten Panik! Andreas: Die ersten Monate waren wir natürlich vollkommen damit beschäftigt unser Serviceversprechen einzulösen. Allerdings war schnell klar, dass die Kunden - die wir über Marketing akquirierten - die kamen nicht wieder von sich aus zurück und dass das finanziell nicht so lange Sinn macht - erschließt sich von selbst. Genau das ist der Moment, in dem die eigene Roadmap nicht mehr von einem selbst kommt, sondern vom Kunden bzw. Allen die meinen zu wissen was man braucht. Es ist zwar klar, dass es zu wenig Wiederkehrer gibt, aber warum sie nicht wiederkommen ist unklar.
  • 13. Januar April Juli Oktober Januar Fahrten Feature A? Feature B? Feature C? Andreas: Was macht man in dem Moment? Man bewirft die Software mit Features. Features von denen man meint, dass der Kunde sie unbedingt braucht. Faktisch weiß man noch nicht, welche funktionieren werden.
  • 14. Mitte-Ende 2013: 
 Development wird langsam Andreas: nachdem man die Software eine Weile mit Features beworfen hat kommen die Features immer langsamer, und es passieren immer mehr Bugs.
  • 15. „Die Developer müssen schneller liefern! Andreas: Was passiert also? Die Developer werden aufgefordert mehr zu liefern, jetzt kommt es nämlich darauf an.
  • 16. Abhängigkeiten + 
 Technische Schulden =
 Kein Fortschritt. Sorry …<3 Die Entwickler können das aber nicht - sie sind nicht wirklich flexibel in Ihrer Bewegung, und sie können nur im Rahmen dessen navigieren was die Legobausteine der alten Systeme erlauben. Dazu kommen technische Schulden - immer wenn es eilig wird geht die Qualität verloren. Technical Debt macht die ganze Entwicklung nicht nur langsamer, sondern erzeugt auch mehr Bugs in der Arbeit - die dann wiederum selbst noch für eine Verlangsamung sorgen.
  • 17. Druck! Andreas: Das Entwicklung bringt also nicht die Performance die es braucht - erster Lösungsansatz ist mehr Druck. Das funktioniert auch kurzzeitig, versagt aber auf der mittleren Strecke. Und zwar meist schon nach sehr kurzer Zeit.
  • 18. Resultat: Die Performance sinkt nach einem initialen Anstieg weiter. Johann: Druck auf Softwaredeveloper hilft nur begrenzt weiter - am Anfang steigt die Lieferfähigkeit, und auch Überstunden resultieren in mehr Features. Das geht etwa 4 Wochen gut, dann flaut die Mehrleistung nicht nur ab, sondern man landet sogar unterhalb dem Torniveau - denn die technische Qualität ist einmal mehr deutlich gesunken.
  • 19. Mehr Leute!Andreas: Die zweite Strategie ist in der IT auch nicht eben unüblich - wenn ich mehr Features über Zeit will, erhöhe ich die Zahl der beteiligten Leute.
  • 20. Brooks Law: „Adding manpower to a late software project makes it later" (Un)bekannt seit 1975. Johann: Eigentlich ist Brooks Law schon von 1975, doch seltsamerweise hat es sich noch lange nicht in deutsche Managementetagen herumgesprochen. Ich kann den Featurefluss nicht schnell erhöhen indem ich neue Leute in das Projekt nehme. Ganz im Gegenteil - es wird langsamer, und diese Verlangsamung kann durch für ein halbes Jahr gelten, bevor das Projekt durch die neuen Kollegen an Fahrt gewinnt, manchmal geschieht dies auch nie.
  • 21. Resultat: Die Performance sinkt weiter, jetzt aber teurer. Johann: Fazit daraus - die Performance sinkt immer noch, die Kosten sind allerdings gestiegen.
  • 22. Featuredruck Lieferfähigkeit Viel Aktion, wenig Resultat. Johann: Und am Ende befindet man sich in einer Situation, in der der Featuredruck immer mehr steigt, die Lieferfähigkeit immer kleiner wird. Die übliche Antwort darauf: Aktionismus - es werden mehr Dinge probiert, andere Leute, andere Techniken. Solche Projekte werden auch Deathmarch, also Todesmarschprojekte genannt - da gibt es sogar ein Buch mit genau diesem Titel zu.
  • 23. Chaos Johann: Als Management denkt man: Liebes Development, jetzt wird es gerade wirklich wichtig, und Ihr performed überhaupt nicht. Was soll ich denn bitte noch tun?
  • 24. Chance Johann: Und wenn Du lange genug im Chaos steckst und nichts nachhaltig den gewünschten Erfolg bringt - dann tut sich faktisch eine Chance auf.
  • 25. Featuredruck Lieferfähigkeit Johann: Wenn ich einen Schritt zurücktrete ist die Lösung doch eigentlich ganz offensichtlich: Ich muss die Lieferfähigkeit nach oben bringen und den Bedarf reduzieren. Das sagt sich jetzt leicht. Wie erreiche ich das?
  • 26. Hosen runter & 
 Shareholdersupport Andreas: In unserem Fall haben wir den gesamten, angehäuften Bedarf schonungslos auf den Tisch gelegt und damit ein Bewusstsein geschaffen dass wir hier auf ganz viele lose Enden blicken. Konkret waren da Features für B2C Kunden, Features für B2B Kunden, ellenlange Wunschlisten der angeschlossenen Fahrer, aus dem BI, dem Marketing, dem Accounting, der Operations etc. etc. Ab diesem Moment wussten wir unseren Shareholder hinter uns - und das gibt einem erst den Freiraum, um wieder aus dem Sumpf herauszukommen.
  • 27. Störungen reduzieren Andreas: Wie haben wir es gemacht? Natürliche Verknappung auf der Maintenance-Seite, und die klügsten Leute mit Domainwissen so freigeschaufelt. Wir haben Business und Technik räumlich getrennt - das soll man eigentlich nicht machen, war in dieser Situation aber notwendig.
  • 28. Fokus 20 % 80 % Kano-Modell Andreas: Und während man den Featuredruck nicht reduzieren kann, kann man ihn wenigstens fokussieren. Es gilt die Pareto-Regel: mit 20% des Aufwands kann man 80% des Nutzens erreichen. Wir haben das im konkreten Fall mit dem Kano-Modell gemacht, und den Rewrite über die Internationalisierung als Lean Startup gemacht - also ein MVP, ein kleinstmögliches Produkt in einem anderen Land aufgebaut und dann nach und nach die übrigen Features ergänzt.
  • 29. Sequentiell > Parallel Time to Market:
 3 Monate im Mittel Fokus: unklar Time to Market:
 2 Monate im Mittel Fokus: klar Johann: In Deathmarchprojekten sind oft sehr viele Dinge parallel in Arbeit - man hofft die Time to Market zu verbessern, indem man früh beginnt. Faktisch ist es aber offensichtlich, dass die Time to Market bei sequentieller Bearbeitung deutlich besser ist, denn abgeschlossene Tätigkeiten werden früher geliefert. Und nicht nur das - durch den besseren Fokus liefert die Entwicklung schneller.
  • 30. Immer QA statt QA-Phasen Deploy in 5 Minuten Cloud statt Server Infrastructure as Code DEV
 SPEED Johann: Nächster Schritt war Development auf Speed bringen. Da gehört nicht nur Fokus dazu, auch das Environment muss stimmen. Dafür haben wir DevOps- Methoden benutzt - gleich in die Cloud, automatisiertes Deployment, automatisierte Tests. Es gibt keine QA-Phasen, weil kontinuierlich - automatisch und manuell - getestet wird. Die komplette Plattform kann in 45 Minuten neu aufgebaut werden, wenn es einen Ausfall gäbe. Die gibt es jetzt natürlich nicht mehr.
  • 31. Kontrollverlust Andreas: Das Management muss zulassen, dass die Entwicklung sich neu sortiert und darauf vertrauen, dass sie in absehbarer Zeit wieder lieferfähig wird. Wenn ich da in einen Modus des Micromanagement und der Planung übergehe - was in so einer Situation ein nachvollziehbarer Reflex ist - dann ersticke ich jedes noch so kleine Quäntchen auf Erfolg. Statt dessen ist meine Aufgabe das Alignment von Development und Businessanforderungen. Jeder muss verstehen, worum es wirklich geht. In unserem Fall war ich derjenige der zwar das Domainwissen besaß aber die Lösung genauso wenig kann wie alle anderen. Ich kann nur empfehlen sich mitten in diesen Prozess hinein zu begeben, darauf zu vertrauen dass die Entwicklung die Lieferfähigkeit sehr bald wieder herstellen wird und die eigene Energie dafür einsetzen den Weg von jeglichen Blockaden zu befreien.
  • 32. Fragen! Andreas: Wir haben erst vor wenigen Wochen erfolgreich unsere neue Platform gelauncht, bereits 4 weitere europäische Ländern eröffnet und keine Sekunde Downtime gehabt ;-)