Softwarewartungskosten: Was Niemand Einplant

Softwarewartungskosten sind die Zahl, die aus einem erfolgreichen Projekt achtzehn Monate später ein schwieriges Gespräch macht. Die Entwicklung war budgetiert, freigegeben und geliefert. Was nach dem Livegang passiert, wurde als „Support" bezeichnet und mit einem Betrag versehen, den jemand geschätzt hat, und dieser Betrag war fast immer zu klein.

Der Grund dafür ist strukturell und nicht nachlässig. Eine Entwicklung hat einen Umfang, den man bepreisen kann. Wartung hat keinen Umfang, weil sie von Dingen bestimmt wird, die noch nicht passiert sind: eine Bibliothek mit einer Schwachstelle, ein Anbieter, der eine API ändert, ein Nutzer, der auf einen Fall stößt, den niemand vorhergesehen hat.

Die Faustregel, die alle zitieren, lautet 15 bis 20 Prozent der Entwicklungskosten pro Jahr, und sie liegt nah genug an der Wahrheit, um gefährlich zu sein. Sie stimmt oft genug, um Sicherheit zu suggerieren, und sie irrt in einer vorhersehbaren Richtung: Sie unterschätzt das erste Jahr, in dem die Defekte auftauchen, und sie bricht vollständig zusammen bei Systemen mit regulatorischen Pflichten oder vielen Fremdschnittstellen, bei denen die Arbeit von äußeren Ereignissen angestoßen wird und nicht von Ihrer eigenen Codebasis.

Was Softwarewartungskosten tatsächlich abdecken

Fünf klar unterscheidbare Kategorien, und sie zu vermischen ist genau das, was die falsche Zahl erzeugt.

Korrektive Arbeit. Das Beheben von Defekten. Sie fällt am Anfang an, weil die meisten Fehler in den ersten Monaten echter Nutzung sichtbar werden, und dies ist die Kategorie, die die Prozentregel am besten trifft.

Adaptive Arbeit. Mit Dingen Schritt halten, die außerhalb Ihrer Kontrolle liegen. Eine Abhängigkeit veröffentlicht einen Sicherheitspatch. Ein Zahlungsdienstleister setzt eine API-Version ab. Ein Browser ändert sein Verhalten. Nichts davon fügt eine Funktion hinzu, und alles davon ist Pflicht.

Präventive Arbeit. Aktualisieren, bevor Sie dazu gezwungen werden. Sie zu überspringen beseitigt die Kosten nicht, es verschiebt sie und lässt sie anwachsen, und genau so wird aus einem Routine-Upgrade des Frameworks ein Projekt über drei Monate.

Betrieb. Hosting, Monitoring, Sicherungen, Zertifikate und die Personenzeit, die das im Blick behält. Häufig getrennt verbucht, was in Ordnung ist, solange es überhaupt jemand verbucht.

Kleine Änderungen. Der stetige Strom an Anpassungen, den ein Livesystem erzeugt, sobald echte Nutzer darin arbeiten. Einzeln belanglos, zusammengenommen in den meisten Jahren die größte Kategorie.

Nur die erste Kategorie ist das, was die meisten Menschen mit Wartung meinen. Die anderen vier sind der Grund, warum das Budget nicht reicht.

Warum die Prozentregel in die Irre führt

Sie verankert sich an der falschen Größe. Der Wartungsaufwand richtet sich nach der Zahl der beweglichen Teile und nach dem Tempo, in dem die Außenwelt sie verändert, nicht danach, was die Entwicklung zufällig gekostet hat.

Zwei Systeme, die für dasselbe Geld gebaut wurden, können um den Faktor drei auseinanderliegen. Eine in sich geschlossene Anwendung mit zwei Abhängigkeiten und ohne regulatorische Belastung ist günstig am Laufen zu halten. Ein System, das sechs Fremddienste einbindet, personenbezogene Daten verarbeitet und Branchenregeln unterliegt, ist es nicht, denn jede einzelne dieser Schnittstellen ist eine Quelle von Arbeit, die Sie nicht selbst einplanen.

Die Regel unterstellt außerdem einen eingeschwungenen Zustand, den es im ersten Jahr nicht gibt. Echte Nutzung findet Defekte, und die ersten sechs Monate nach dem Start liegen typischerweise deutlich über dem Jahresdurchschnitt, bevor sich das einpendelt.

Eine bessere Schätzung beginnt bei den beweglichen Teilen. Zählen Sie die Schnittstellen, die Compliance-Pflichten und die Zahl der Nutzer, die Supportkontakte erzeugen, und bepreisen Sie dann die Zeit, die das realistisch verbraucht. Unser Leitfaden zu den Kosten individueller Softwareentwicklung behandelt die Bauseite derselben Rechnung.

Die Posten, die Teams vergessen

Aktualisierung von Abhängigkeiten. Nicht optional, denn ungepatchte Bibliotheken sind der Weg, auf dem Systeme kompromittiert werden, und der Aufwand ist wirklich unvorhersehbar, weil er davon abhängt, was die Betreuer der jeweiligen Pakete tun.

Änderungen an Fremd-APIs. Ein Anbieter kündigt eine Version ab und gibt Ihnen eine Frist. Den Zeitpunkt haben Sie nicht gewählt, und ablehnen können Sie ihn nicht.

Verlängerung von Zertifikaten und Domains. Belanglos, bis eines an einem Wochenende abläuft und die Seite nicht mehr erreichbar ist.

Monitoring und die Reaktion darauf. Alarme nützen nichts ohne jemanden, der reagiert, und diese Bereitschaft ist ein realer Kostenpunkt, ob nun etwas ausfällt oder nicht.

Wissenstransfer. Menschen gehen. Was es kostet, bis die nächste Person das System versteht, ist ein Wartungsposten, und er steht im Verhältnis dazu, wie wenig aufgeschrieben wurde.

Datenwachstum. Die Speicherkosten steigen, Abfragen, die schnell waren, werden langsamer, und die Arbeit daran kommt nach einem Zeitplan, den Ihr eigener Erfolg setzt. Unser Leitfaden zur Datenbank-Performance zeigt, wie das in der Praxis aussieht.

Was das im Vereinigten Königreich kostet

Grobe Jahresspannen für die Wartung eines individuellen Systems, unter der Annahme eines externen Dienstleisters statt eigener Angestellter.

Hosting und Lizenzen sind darin nicht enthalten, sie werden separat abgerechnet und schwanken enorm. Vorausgesetzt ist außerdem, dass das System in vertretbarem Zustand ist. Etwas zu warten, das niemand dokumentiert hat, ohne Tests und mit einer einzigen Person, die es versteht, kostet mehr und trägt ein Risiko, das keine Pauschale beseitigt.

Wie Sie es aufsetzen

Eine Pauschale mit definierten Stunden funktioniert, wenn das Volumen grob vorhersehbar ist. Sie kauft Verfügbarkeit, und die ist das meiste von dem, wofür Sie zahlen; nicht genutzte Stunden sind kein Verlust, denn die Alternative wäre, niemanden zu haben.

Abrechnung nach Zeit und Material passt zu Systemen mit wenig Veränderung, doch die Reaktionszeit ist genau das, was die übrigen Verpflichtungen des Dienstleisters zulassen, und das ist der Preis dafür.

Ein Supportvertrag zum Festpreis verlagert das Risiko auf den Dienstleister, der dieses Risiko in das Honorar einpreist. Sinnvoll für kritische Systeme, bei denen Planbarkeit mehr wert ist als die Marge.

Wofür Sie sich auch entscheiden: Legen Sie fest, was als Wartung gilt und was als neue Funktion, bevor Sie es brauchen. Diese Grenze ist die Ursache fast jedes Streits in Supportbeziehungen, und sie zu definieren kostet am Anfang nichts.

Mecanik wartet Systeme, die wir nicht gebaut haben, ebenso wie solche, die von uns stammen, als Teil unserer Arbeit in der Softwareentwicklung . Der erste Monat einer Übernahme besteht meist aus Dokumentation, denn sie bestimmt die Kosten jedes weiteren Monats.

Weiterführende Artikel: Festpreis oder Zeit und Material? , So schreiben Sie eine Software-Ausschreibung, die brauchbare Angebote bringt , Software-Escrow: Wer es wirklich braucht und MVP-Softwareentwicklung: Umfang, Kosten und Zeitplan .

Häufig gestellte Fragen

Wie hoch sind die Softwarewartungskosten pro Jahr? Die übliche Faustregel nennt 15 bis 20 Prozent der Entwicklungskosten pro Jahr, doch sie unterschätzt das erste Jahr, in dem die Defekte auftauchen, und versagt völlig bei Systemen mit vielen Schnittstellen oder regulatorischen Pflichten. Grobe Spannen im Vereinigten Königreich reichen von £6.000 bis £15.000 für ein kleines internes Werkzeug bis zu £60.000 oder mehr für ein reguliertes oder stark frequentiertes System, ohne Hosting.

Was umfasst Softwarewartung tatsächlich? Fünf Kategorien: korrektive Arbeit zur Behebung von Defekten, adaptive Arbeit, um mit Abhängigkeiten und Änderungen an Fremd-APIs Schritt zu halten, präventive Arbeit, also Aktualisieren, bevor man gezwungen wird, der Betrieb mit Hosting und Monitoring sowie der stetige Strom kleiner Änderungen, den ein Livesystem erzeugt. Nur die erste ist das, was die meisten mit Wartung meinen.

Warum ist die Regel vom Prozentsatz der Entwicklungskosten unzuverlässig? Sie verankert sich an der falschen Größe. Der Wartungsaufwand richtet sich nach der Zahl der beweglichen Teile und danach, wie schnell die Außenwelt sie verändert, nicht nach den Entwicklungskosten. Zwei Systeme, die dasselbe gekostet haben, können sich um den Faktor drei unterscheiden, je nach Zahl der Schnittstellen, regulatorischer Belastung und Supportaufkommen.

Welche Wartungskosten vergessen Teams einzuplanen? Aktualisierungen von Abhängigkeiten, abgekündigte Fremd-APIs mit Fristen, die Sie nicht gewählt haben, Verlängerungen von Zertifikaten und Domains, die menschliche Bereitschaft hinter den Monitoring-Alarmen, den Wissenstransfer, wenn Menschen gehen, und die Wirkung des Datenwachstums auf Speicherkosten und Abfragegeschwindigkeit.

Sollte ich eine Pauschale nehmen oder nach Bedarf zahlen? Eine Pauschale mit definierten Stunden passt zu vorhersehbarem Volumen und kauft Verfügbarkeit, und die ist das meiste von dem, wofür Sie zahlen. Zeit und Material passt zu Systemen mit wenig Veränderung, doch die Reaktionszeit hängt von den übrigen Verpflichtungen des Dienstleisters ab. Was Sie auch wählen: Definieren Sie, was als Wartung und was als neue Funktion gilt, bevor Sie es brauchen.