Direkt zum Hauptbereich

Keine Zeit für Helden

Da ist er wieder - Superbösewicht auch Kunde genannt und er führt nichts gutes im Schilde. Er möchte doch tatsächlich sein Projekt zu dem zugesagten Termin fertig haben. Oh und das Spiel mit den Change Request spielt er auch noch hervorragend mit seinen gezinkten Karten.
Oder war es doch die Katastrophe der stockenden Entwicklung, weil niemand mehr den Code versteht?

Ich weiß nicht mehr genau was der Auslöser war, aber er hat dafür gesorgt, dass sie aus allen Ecken geflogen kamen - Die Superhelden der Softwareentwicklung.




Auf mal waren sie da und hackten unermüdlich, noch in tiefster Nacht in der Codebasis rum. So lange bis die olle Software irgendwie tat was sie sollte und damit die Katastrophe abgewendet und der Kunde besiegt war.

In manchen Gegenden soll man sich sogar soweit an sie gewöhnt haben, dass nur noch diese Superhelden die Arbeiten erledigen konnten und sollten. Die anderen kamen in der Welt die durch die Superkärfte erschaffen wurden eh nicht mehr klar.

Was dabei oft vergessen wird, selbst wenn es in den Comicverfilmungen der Superhelden am Rande dargestellt wird ist, dass diese Helden nicht überall sein können und zum Teil auch durch ihren Eingriff an der einen Stelle  etwas negatives an der anderen bewirken. Noch dazu leidet meist das "normale" Leben der Helden da drunter, so das fast alle ihren Heldenjob zum Ende des Films an den Nagel hängen.

Und was machen wir dann? Wenn die Heldenzeit rum ist? Wir stehen vor einem Scherbenhaufen von zusammengehacktem Code und sollen den nun noch Jahrelang weiterentwickeln und Pflegen? Und den ganzen Kleinkram wie Bugs die vermehrt dazwischen Lungern? Die bleiben uns auch noch zum Aufräumen.
Aber das sieht beim Lobgesang auf die Helden keiner.

Ja ich habe auch schon in Projekten den Helden gespielt und irgendwie den Karren aus den Dreck gezogen. Und ich bin immer noch begeistert von dem Einsatz und die Energie die für das Projekt erbracht wird.
Nur heute, da ich älter bin und mehr und mehr von den "geretteten" Projekten auch nachher gesehen habe finde ich diesen Einsatz fehlplatziert.

Software lebt länger als die erste heiße Projektphase und auf lange Sicht betrachtet haben wir keine Zeit für Heldentum in der ersten Stunde! Diese Energie sollte lieber dazu verwendet werden es richtig zu machen. Auch wenn das bedeutet dem Kunden seinen Wunsch nicht erfüllen zu können.

Ich möchte ja auch kein Auto fahren bei dem in den letzten Minuten vor der Abholung, ein übermüdeter Lehrling noch schnell alle Schlauchleitungen so zusammengeschlossen hat, wie sie gerade passten, nur weil ich auf den Termin bestehe.

Eine Ausnahme gibt es natürlich: Wegwerfprodukte da dürfen sich die Helden gerne austoben.

Ach und noch was: Habt ihr jemals gesehen, dass der Held mehr als ein Danke oder gar die erfüllte  Liebe bekommt?

Kommentare

  1. "Auch wenn das bedeutet dem Kunden seinen Wunsch nicht erfüllen zu können."

    Was bringt dir das, wenn aus firmenwirtschaftlicher Sicht du nicht möchtest das der Kunde abspringt? (Mal abgesehen von quärulanten Kunden die mehr Nerven als Geld bringen)

    Denn seien wir auch hier mal ehrlich. Wenn du nein sagst.. freut sich ein anderer. Denn wenn der Kunde darauf besteht es fertig zu kriegen, wird er sich jemand anderen suchen der es macht.

    Aus BWL Sicht ist ein schlechter Code lukrativer als ein guter. Natürlich nicht immer aber oft. Denn die Pflege ist zeitaufwändiger, also kostenintensiver. Dies kommt dem Dienstleister zu Gute.

    Wichtig für die den Dienstleister ist natürlich von Anfang an mit offenen Karten zu spielen. Dem Kunden sagen "Ja der Termin ist machbar aber nur unter der prämisse das wir hier schlecht wartbaren Code produzieren, der zwar funktioniert aber mangels Zeitdruck nicht vernünftig strukturiert werden kann"
    Später bei jedem Change Request des Kunden wird darauf hingewiesen. "Ja machen wird aber wegen der Codebasis dauerts länger."

    Ich bin zwar kein Profi in der Softwareentwicklung aber Profi in der IT Infrastruktur Netzwerktechnik und hier läuft genau das gleiche Lied tagtäglich im Radio.

    Zuerst bekommt der Kunde das all-inkl. Angebot das seine Anforderungen perfekt erfüllen und wenn er sagt.. nö ist zu teuer.. dann bekommt er die billig Lösung. Sobald er dann neue Wünsche hat (vor allem die, die bereits abzusehen waren) binde ich ihm jedes Mal auf die Nase, dass dies mit der Lösung nicht möglich ist oder nur eingeschränkt und dadurch Zusatzskosten entstehen und das insg. auch wieder nur gefrickel ist und z. B. bei einer hochverfügbaren Lösung uns ggf. die Hochverfügbarkeit klaut oder einschränkt.

    AntwortenLöschen
    Antworten
    1. Hallo Jan,
      danke für deinen Kommentar.
      Natürlich muss man da drauf achten, einen Kunden nicht zu verlieren, den man halten möchte. Dazu gehört aber auch, dass man wie du schon sagst mit offenen Karten spielt.
      Wenn die Software z.B. für eine Messe ist, so ist eins der wichtigsten Kriterien dass sie zur Messe fertig ist und funktioniert. Klar kann ich dann mal was zusammenhacken. Siehe meinen Verweis auf die Wegwerfprodukte. Aber das muss ich dem Kunden auch so verkaufen.
      Wenn der Kunde mit der Software aber langfristig arbeiten will, so sollte ich mir (mit dem Kunden zusammen) gut überlegen ob der Wunschtermin so wichtig ist, dass der Code von überarbeiten Entwicklern notfalls in Nachtschichten zusammengestrickt wird. Auf den ersten Blick sieht der Kunde das ja auch gar nicht. Oder ist es wichtiger dass die Software zuverlässig ist und der Kunde seine Erweiterungen bekommt? Wir verkaufen uns ja alle als Profis.

      "Aus BWL Sicht ist ein schlechter Code lukrativer als ein guter. Natürlich nicht immer aber oft. Denn die Pflege ist zeitaufwändiger, also kostenintensiver. Dies kommt dem Dienstleister zu Gute." Dass ist nicht gesagt. Oft fallen die Bugs dem Dienstleister zu und für die Changes kann auch nicht immer das berechnet werden, was aufgrund der Probleme mit der Codebasis entsteht.

      Und das ist ja mein Hauptpunkt gewesen: "Auf dauer lohnt sich das zusammenstricken am Anfang nicht" (Leider werden die Bug Behebung, oder manuelle Eingriffe in das System die dadurch nötig werden, oft "nebenbei" erledigt und gar nicht mehr den Projektkosten zugeschrieben).

      Löschen

Kommentar posten

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 verteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

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 die Struktur…

Speed Temenos auf dem AgileDay der JAX

Letzte Woche hatte ich die Gelegenheit auf dem AgileDay der JAX zu sein. Neben Vorträgen am Vormittag mit Beiträgen zu Retrospektiven agile in Konzernen sowie einer spezifischen Implementierung in einem Unternehmen stand nach der Mittagspause ein Speed Temenos mit Olaf Lewitz und Christine Neidhardt auf dem Programm. Zur Unterstützung hatten sie sich Unterstützung über die Softwerkskammer organisiert, so dass die Anwesenden von insgesamt 20 Facilitatoren betreut wurden.

Bei Temenos handelt es sich um einen "geschützten Raum" in dem Menschen Offenheit und Vertrauen erleben können. Das Speed Temenos mit seinen 3 Phasen, in welchen es um die Persönliche (Berufliche) Vergangenheit, den Ist-Zustand und die Vision für die Zukunft geht hilft über Geschichten erzählen, sich selbst zu reflektieren und Gemeinsamkeiten in der Gruppe zu entdecken. Details sind auf http://trusttemenos.de/ viel besser erklärt als ich es hier kann.

Ich hatte Temenos mit Olaf bereits auf der Play4Agile 201…