Direkt zum Hauptbereich

Hilfe für “insolvente” Softwareprojekte


You can read an english version of this idea in the july issue of the PragPub Magazine.


Bei den privaten Fernsehsendern sind Formate, bei denen ein erfahrener Koch, Restaurants oder der ehrenamtliche Schuldenberater aus Berlin, Familien vor dem Untergang rettet der Hit. Ich denke, dass viele Softwareprojekte auch so einen “Schuldenberater” gebrauchen könnten.

Nun haben Softwareprojekte nicht direkt was mit Schulden zu tun aber schon Anfang der 90er hat Ward Cunningham einen Bezug zwischen techn. Komplexität und Schulden hergestellt. Der Begriff technische Schulden wird heute, auch immer wieder im Zusammenhang mit Refactorings benutzt.

Setzen wir doch nun mal die Features welche in dem Projekt umgesetzt werden mit den Dingen gleich, welche für Geld zu kaufen sind. Und sehen als Preis für ein Feature die Zeit an, die benötigt wird um ein Feature umzusetzen. Wie kommen wir dann zu den Schulden?



Die Personen im TV haben oft in jungen Jahren über Ihre Verhältnisse gelebt und konnten den tollen Angeboten “Heute kaufen, morgen zahlen” schlecht widerstehen. Meist ging das gut, bis ein “Unglück” geschah oder sie anders die Kontrolle verloren haben.

Und bei Softwareprojekten, ist es da anders? – Na schauen wir mal: Am Anfang steht das tolle Projekt vor der Tür und die CodeBasis ist = null. Also wird ein Team zusammengewürfelt aus mehr oder weniger erfahrenen Entwicklern. (Die unerfahrenen sind meist günstiger also auch oft in der Mehrheit.) Mit guten Vorsätzen und Anfangsanforderungen, Architektur und Design wird losgelegt. An der ein oder anderen Stelle wird nun bewusst eine Abkürzungen genommen, das Design vereinfacht oder eine Infrastrukturbetrachtung vertragt um ein Feature schneller zu bekommen. Das sind die ersten technischen Schulden. Zeit ist Geld und in Festpreisprojekten sowieso.

Die Schulden sind in beiden Fällen erst mal nichts schlimmes. Problematisch wird es erst, wenn man den Überblick verliert und zu viele Schulden aufnimmt. Irgendwann übersteigen die Ausgaben für das tägliche Leben und die Rückzahlungen der Schulden die Einnahmen. Bei Softwareprojekten heißt dies, es dauert immer länger ein neues Feature umzusetzen, bis dies unmöglich wird.

Ist es erst mal so weit gekommen, werden oft die Augen verschlossen und es wird nur noch schlimmer.

Bei den finanziellen Schulden gibt es die (Privat-)Insolvenz als letzten Ausweg um aus dem Teufelskreis raus zu kommen.

In den TV Folgen, kommt der Profi meist kurz vor der Insolvenz zu den Leuten, um ihnen dabei zu helfen, die Insolvenz zu vermeiden und ihre Schulden und anderen Probleme in den Griff zu bekommen. Denn oft sind die Schulden nur ein Teil des Problems.

Er beginnt immer damit, sich einen Überblick zu verschaffen. Dabei müssen die relevanten Dokumente oft aus allen Ecken zusammengesucht oder anders wieder besorgt werden. Denn die “Kunden” haben längst den Überblick verloren. Um die Schulden in den Griff zu bekommen, hilft der Schuldenberater ihnen nicht nur dabei einen Überblick über ihre Finanzen zu bekommen sondern auch ihr Leben neu zu regeln und die allgemeinen Probleme in den Griff zu bekommen. Selbst wenn er die Insolvenz nicht vermeiden kann ist dies essentiell, denn was bringt es die Schulden auf 0 zu setzen wenn der Kreislauf danach von vorn beginnt?

Warum gibt es so jemanden nicht für Softwareprojekte? Hier gibt es ja auch so was wie die Insolvenz: “Wir fangen von Vorne an und entwickeln für die nächste Version alles neu.”

Dieser “Schuldenberater für Softwareprojekte” verschafft sich einen Überblick über das Projekt, macht eine Aufstellung, welche Probleme am dringendsten behoben werden müssen und prüft ob das Projekt mit vertretbaren Aufwand gerettet werden.

Aber was viel wichtiger ist, dieser Schuldenberater hilft dabei Ordnung in das Chaos zu bringen. Er hilft dabei einen sauberen Prozess aufzusetzen und aus den Entwicklern ein Team mit Verantwortung für das Projekt zu formen. Er zeigt ihnen wie man mit Legacy Code umgeht, ein Sicherheitsnetz aus Tests baut und man aus den schlechten Gewohnheiten des zusammenhackens von Code raus kommt. Er begeistert die Leute für qualitative Arbeit.

Kurz: Er sorgt dafür, dass das nächste Projekt (oder das aktuell gerettete) nicht wieder vor der “Insolvenz” steht.

Ich übertreibe? Nun wenn man solche Sätze als Normal ansieht: “Alle drei Jahre eine Neuimplementierung ist normal” oder “Der Kunde denkt auch dass eine Neuentwicklung mal wieder angebracht ist und bezahlt diese auch”.  Und 10 Milliarden Euro Verlust im Jahr durch schlechte Software (nach einer aktuellen Studie) für wenig hält, dann übertreibe ich.

Und wenn ich nicht übertreibe, wo findet man nun so einen Schuldenberater für sein Softwareprojekt? Nun ich kenne noch keinen, der sich das auf die Fahne geschrieben hat, aber Hilfe bekommt man bestimmt von einem Software Craftsman – und den findet man in der Softwerkskammer.

Kommentare

Beliebte Posts aus diesem Blog

Eine Retro im Kreis

Für die letzte Retro habe ich die Tische und Stühle alle beseite gestellt um dann mit Klebeband (Malercrep) drei unterschiedlich große Kreise um einen Mittelpunkt zu kleben. Der innerste Ring war groß genug, dass das gesamte Team da drin Platz finden konnte. Für die erste Phase der Retro habe ich Kärtchen mit den Zahlen 50, 40, 30, 20 in den Ringen ve rteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

Mit dem Rücken am Tellerrand

Es ist gut auch mal über den Tellerrand zu schauen. Manchmal sind wir so in "unserer Welt" gefangen, dass wir den Rest gar nicht mehr wahr nehmen. Zum Beispiel muss ich mich immer wieder daran erinnern, dass nicht alle Menschen mindestens ein Smartphone haben. Oder das agile noch lange nicht Mainstream ist. Nur weil wir uns in einem Umfeld bewegen, in dem die Dinge so scheinen wie sie sind, heißt das noch lange nicht, dass dem auch so ist. Ein Typisches Beispiel für den Unterschied von Realität und Wahrnehmung der Realität. Aber auch um neuen Ideen eine Chance zu geben, welche scheinbar nicht funktionieren können, weil sie nicht in unsere Gedankenwelt passen ist es sinnvoll ab und an über den Tellerrand zu schauen. Heute habe ich noch einen Tweet, welcher darauf hinweist gesehen: Wenn uns das einmal bewusst geworden ist, dann neigen wir (oder zumindest geht es mir so) dazu möglichst oft über diesen Tellerrand zu schauen. Dabei kann es aber passieren, dass wir so

Der Wasserfall ist immer noch vorherrschend in der Softwareentwicklung

In den letzten Jahren sind viele "neue" Bewegungen auf der Bildfläche des Mainstream-Bewusstseins der Softwareentwicklung erschienen. Und viele aktuelle Studien berichten, dass die Agilität den Wasserfall abgelöst hat. In allen Softwareunternehmen und viele der Entwickler die ich treffe reden zumindest viel über Agilität. Wenn aber mal einen Schritt zurück macht sieht das (ideal) Bild eher so aus: Die neue Lösung wird mit Design Thinking gefunden und definiert. In der Entwicklung ist dann eher die Rede von agile (meist Scrum) und selten SoftwareCraftsmanship. Von der Betriebsseite heißt es nun DevOps. Aber dazwischen gibt es immer noch Brüche und es existiert keine Ganzheitlichkeit. Jahrzehnte lang haben wir in der Softwareentwicklung geglaubt und es so auch allen Kunden beigebracht, dass die "Cost of Change Curve" gilt und daher der Wasserfall als Vorgehen perfekt ist. (Was nun was bedingt, lass ich mal dahingestellt) Dadurch haben sich natürlich auch di