Die Moral eines Fehlschlages //2066

Aus verlässlicher Quelle habe ich die folgende Angelegenheit erfahren, die ich aus gewissen, nicht näher erläuterbaren Gründen im Blog festhalten möchte.

Ein größeres Unternehmen (bei dem mein Informant angestellt ist) muss regelmäßig gesetzlichen Prüf- und Dokumentationsaufgaben nachkommen. Ein (geübter) Mensch würde dafür mindestens einen Tag brauchen. Also liegt die Idee an eine Software nah, die die Routineanteile dieser Pflichten übernimmt. Dann könnte der Aufwand auf ein bis zwei Stunden reduziert werden.
In der Tat existiert dazu bereits seit zwanzig Jahren oder so eine derartige Software. Die wurde allerdings nie richtig angenommen, weil sie nicht wirklich funktioniert. Keine intuitive Eingabe, fehlerträchtig, häufige Abstürze, und dann sind alle bisher erhobenen Daten weg, etc.. Das GUI ist auch längst nicht mehr zeitgemäß. Die gesetzlichen Auflagen wurden seither erweitert, aber das Programm ist mittlerweile nicht mehr wartbar, da der wichtigste Entwickler inzwischen in Rente ist und seine Sourcen weder dokumentiert noch versioniert hat.

Also entschlossen sich die Verantwortlichen nach einigem Hin und Her vor ein paar Jahren, einer kleinen Softwarefirma als Subunternehmen den Auftrag zu geben, ein Programm dafür neu aufzusetzen. (Ich war damals auch im Gespräch, aber lehnte ab – zu verworrene Anforderungen und auch eine Nummer zu groß für einen Einzelkämpfer, zumal es mit meinem sonstigen Fachgebiet überhaupt keine Berührungspunkte gab.)
Das Projekt verzögerte sich noch, aber inzwischen hätte es eigentlich abgeschlossen sein sollen.
Nun wurde ein Prototyp vorgelegt, bei dem jetzt schon absehbar ist, dass er nicht funktionieren wird. Wichtige Konfigurationsmöglichkeiten fehlen.
Das Budget ist längst erschöpft. Momentan ist es offen, wie es weitergeht.

Mein Informant (der ein wichtiger Anwender ist, und auch andere Anwender einlernt und instruiert), ist verärgert, weil er überhaupt nicht in den Entwicklungsprozess eingebunden worden ist. Er hatte nie Einladungen zu Projekttreffen erhalten, und befürchtet jetzt, für das Scheitern mitverantwortlich gemacht zu werden.

Die alte Software funktioniert nicht richtig und ist nicht mehr auf dem aktuellen Stand.
Die neue Software funktioniert erst recht nicht.
Geld für eine Neuentwicklung ist nicht mehr vorgesehen.
So kann man ein wichtiges Projekt in den Sand setzen. Immerhin ein Beispiel, aus dem man lernen kann, wie man es nicht machen soll.

Wer beabsichtigt, ein Projekt outzusourcen, sollte wenigstens einen Festpreis vereinbaren, um zumindest einige Risiken zu vermeiden. Wer als Auftragnehmer zuversichtlich ist, das Projekt innerhalb eines vernünftigen Zeitrahmens erledigen zu können, sollte doch eigentlich kein Problem haben, dafür einen Festpreis zu veranschlagen.

Werbeanzeigen

Über Anne Nühm (breakpoint)

Die Programmierschlampe.
Dieser Beitrag wurde unter Uncategorized abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

11 Antworten zu Die Moral eines Fehlschlages //2066

  1. Plietsche Jung schreibt:

    Dafür gibt es ja Werkverträge, die, untermauert mit einem exakten Briefing, auch funktionieren. Ein schlechtes Briefing oder andauernde Änderungen machen einem Projekt das Leben schwer. Zum Schluss ist es nicht mehr durchführbar.
    Der Fehler wird schon am Anfang gemacht.

    So wurden aus 77 Mio€ für die Elbphilharmonie auch 800 (!) Mio€.

    Liken

  2. Athropos schreibt:

    Festpreis funktioniert aber nur mit abgenommenem Lasten- und Pflichtenheft – erfahrungsgemäß ändern sich die Anforderungen ja im Laufe des Projekts signifikant (das nennt man dann agile ;))

    Liken

    • Das stimmt. Trotzdem sollte man nach Spezifikation arbeiten.
      Wenn sich Anforderungen im Nachhinein ändern, lässt sich der zusätzliche Aufwand natürlich separat in Rechnung stellen. Das ist dann eine Frage der Vereinbarung zwischen den Vertragspartnern.
      Aber von vornherein einen Blankoscheck auszustellen, halte ich für verfehlt.

      Liken

  3. ednong schreibt:

    Für einen Festpreis muß man ja erstmal als AG wissen, was man will. Und was nicht. Und meist hapert es ja schon genau an dieser Stelle – wie soll man da als AN einen Festpreis machen?

    FP habe ich anfangs auch mal gemacht, inzwischen nur noch nach Zeitaufwand, weil doch immer wieder Änderungen einfließen sollen (was ja auch soweit möglich ok ist). Aber das lass ich mir halt auch bezahlen.

    Hättest du denn einen Festpreis gemacht, wärest du genommen worden? Und wie hättest du das kalkuliert?

    Liken

    • Als ich noch Entwicklungsaufträge angenommen habe, habe ich mit dem potentiellen Auftraggeber vorher recht detailliert abgesprochen, was die Software genau machen soll.
      Darauf basierend eine Aufwandabschätzung, die in einem Angebot mit Festpreis und Liefertermin mündete (angemessener Zeitpuffer eingeschlossen).
      Dann habe ich die Spec geschrieben, in dem ich die Einzelheiten noch mal genau aufgedröselt habe. Sobald der Kunde sein OK dafür gab, habe ich mit der Implementierung begonnen (de facto eigentlich schon früher, aber auf eigenes Risiko).

      Dieses Vorgehen hat im Prinzip immer funktioniert. Es besteht aber halt die Gefahr, dass irgendetwas unvorhergesehenes dazwischen kommt, das den Zeitplan durcheinanderbringt. Gerade als Einzelkämpfer hat man null Redundanz. Wenn man z.B. krank wird, lässt sich das nur schwer abfangen. Ein Quäntchen Glück gehört schon dazu.

      Liken

  4. idgie13 schreibt:

    Die Erfahrung zeigt, dass es hilft
    a) vorher gut zu spezifizieren, auch wenn das manchmal mühsam ist
    b) den Kunden in die Entwicklung mit einzubinden, dass es Betatester für Vorabversionen gibt

    Wir geben meist einen Fixpreis mit einem Puffer von +- 20% an und kommunizieren frühzeitig, wenn der Aufwand aus dem Ruder läuft.

    Ärgerlich ist es ja für alle Seiten, wenn das Geld weg und trotzdem keine Lösung da ist.

    Gefällt 1 Person

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.