Die sieben größten Kostentreiber in der Softwareentwicklung.

Softwareentwicklung und die Entwicklung digitaler Produkte können und sollten als Investment betrachtet werden. Ein Investment, welches sich am Ende des Tages auszahlen muss. Und dabei spielt es keine Rolle, ob das Produkt für einen internen „Kunden“, also eine andere Fachabteilung gebaut wird oder für einen echten Kunden außerhalb des Unternehmens. Software-Produkte haben immer den Sinn, Kosten zu reduzieren, Umsätze zu generieren oder Risiken zu vermeiden. Damit das Return on Investment also letzten Endes auch stimmt und sich die Entwicklung lohnt, hängt stark von den Kosten ab, die in die Entwicklung gesteckt werden. Die Hauptkosten in der Softwareentwicklung stecken zum Großteil in Personalkosten. Softwareentwicklung ist ein kreativer Prozess, der durch ein Team aus Menschen ausgeführt wird und nur zum Teil automatisiert werden kann. Daher ist Softwareentwicklung auch immer mit viel Kommunikationsarbeit verbunden.

Die folgenden Punkte bilden die größten Kostentreiber für Softwareentwicklungsprojekte ab und können somit als Anitpattern in der Entwicklung digitaler Produkte gesehen werden.

  1. Plangetriebene Softwareentwicklung
  2. Agiles Theater
  3. Output-denken – Features statt Nutzen
  4. Fehlender Fokus
  5. Kein Produktmanagement
  6. Keine Insights für den Product-Market-Fit
  7. Zu wenig Investment in Qualität und Testen

Beschreibung des Kostentreibers:

In den 80er 90er und teilweise auch in den 0er-Jahren waren plangetriebene Umsetzungsprozesse ala Wasserfall und V-Modell hoch im Kurs bei Softwareprojekten. In den 0er-Jahren kamen dann jedoch das agile Manifest und Methoden wie Kanban, XP und Scrum auf. Dennoch nutzen sehr viele Unternehmen und leider auch noch sehr viele Softwareprojektmanager plangetriebene Methoden, um digitale Produkte zu entwickeln. Plangetrebene Methoden gehen davon aus, dass zu Beginn des Projektes bereits die Grundlage vorhanden ist, um alle wichtigen Entscheidungen und Planungen durchführen zu können. Dabei werden viele Annahmen zu Beginn gemacht, Pläne erstellt und dann dem Team zum Abarbeiten gegeben.

Warum ist das schlecht?

Eine derartige Vorgehensweise führt dazu, dass Risiken gar nicht oder erst sehr spät im Projekt erkannt werden. Fehler oder falsche Annahmen, die zu Beginn gemacht wurden, werden erst sehr spät entdeckt und führen zu Massiven kosten. Des Weiteren wird Feedback erst sehr spät gegen Ende der Umsetzung von Kunden eingeholt. Die Rule of 101 besagt2 jedoch, dass die Kosten der Fehlerbehebung massiv ansteigen, je später der Fehler gefunden wird.

Verbesserung:

Durch die richtige Verwendung von agilen Methoden können Risiken gleich zu Beginn des Projekts adressiert werden und Annahmen und Hypothesen nach jedem Sprint-Release direkt mit Kunden getestet werden.

Beschreibung des Kostentreibers:

Neben der offenen plangetriebenen Softwareentwicklung lässt sich aber auch oft ein anderes Phänomen erkennen – das agile Theater. Beim agilen Theater wird agil gespielt aber plangetrieben vorgegangen. Das Umsetzungsteam arbeitet zwar mit „Scrum“ im Sprint, bekommt aber strikte Vorgaben und muss sprintweise Ziele erreichen und Deliveries abliefern. Das Ganze passiert nach einem Plan, der schrittweise abgearbeitet wird.

Warum ist das schlecht?

Durch die strikten Vorgaben des Managers, der sich gegebenenfalls fälschlicherweise als Scrum-Master oder Product-Owner bezeichnet, ist das Team immer „auf Zug“ gehalten und muss oft Kompromisse hinsichtlich der Qualität machen.

Feedback von Kunden oder Keystakeholdern wird nicht am Sprintende eingeholt und Risiken nicht oder nur teilweise systematisch minimiert. Im Hintergrund folgt der Manager einem Gantchart, den er gegebenenfalls als Roadmap oder Backlog bezeichnet. Durch dieses verdeckte plangetriebene Vorgehen kauft sich das Team nicht nur die Kosten durch die plangetriebene Vorgehensweise, sondern auch die Kosten für die falsche agile Vorgehensweise ein. Scrum hat relativ viele Meetings, die wenn sie richtig gemacht werden, sinnvoll, notwendig und effizient sind. Wird jedoch plangetrieben vorgegangen und nur agiles Theater gespielt, so ist das Team nicht effektiv und auch nicht effizient.

Verbesserungen:

Das agile Theater muss aufgedeckt werden und bewusst in eine echte agile Vorgehensweise geändert werden. Durch Feedback und Systematisches ausschalten von Risiken kann das Team auch wirklich ein digitales Produkt entwickeln, welches am Ende ein gutes Return on Investment hat.

Beschreibung des Kostentreibers:

Einer der größten Kostentreiber, die es in der digitalen Produktentwicklung und in der Softwareentwicklung gibt, ist es, die falschen Features zu implementieren. Immer wieder hört entwickeln Unternehmen Produkte oder Produktfeatures, die dann von den Usern nicht verwendet werden. Dahinter steckt oft ein falsches Denken der beteiligten und eine falsche Vorgehensmethode. Wir befinden uns leider viel zu oft viel zu lange im Lösungsraum anstatt über die Probleme, die wir lösen wollen nachzudenken. Dabei werden Annahmen zum Produkt und zu der Software gemacht und Feature um Feature entwickelt.

Warum ist das schlecht?

Setzt das Team das Produkt Feature um Feature um und wird zu sehr auf den Output geachtet, so wird der Blick von dem weggenommen, was letzten Endes wichtig ist und für Umsatz und Gewinne sorgt – nämlich glückliche User und Kunden, die bereit sind, für die Software zu zahlen. Der Fokus sollte daher nicht auf Output, sondern auf Outcome3 liegen. Nicht das Produkt ist das wichtige, sondern die Lösung der Probleme und der Fokus darauf, was diese Probleme sind. Somit müssen nicht viele Features umgesetzt werden, sondern nur die richtigen. Doch wie werden die richtigen Features gefunden? Ansonsten ist das ständige Hetzen nach neuen Features, die letztlich niemand verwendet, ein reiner Kostentreiber.

Verbesserungen:

Das Team muss sich auf den Problembereich fokussieren und die Essenz herausfinden, was die User wirklich brauchen, um ihre Probleme zu lösen.

„People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!“—Theodore Levitt

Statt sich auf den Output zu konzentrieren, muss sich das Team auf den Outcome fokussieren4.

Feedback muss nach jedem Release gesammelt werden und ins Produkt und die Softwareentwicklung zurückfließen.

Beschreibung des Kostentreibers:

Oft setzten Scrum-Teams sehr viele verschiedene Tickets in einem Sprint um. Es werden keine Sprintziele formuliert und generell lässt sich auch keine Strategie oder Fokus in der Umsetzung erkennen. Sie gehen eher in die Breite als in die Tiefe und versuchen möglichst viele Features ins Produkt zu bekommen.

Warum ist das schlecht?

Fehlt der Fokus und werden zu viele Themen gleichzeitig bearbeitet, kann es passieren, dass zwar die Dinge parallel umgesetzt werden, aber alle Features nicht in die tiefe funktionieren. Es wird versucht, Stakeholder und Kunden viele Features anzubieten. Diese werden aber bei genauerer Betrachtung nicht zufriedenstellend sein. Wenn das Team außerdem aufgeteilt wird und jedes Teammitglied an seinen eigenen Themen arbeitet, so entsteht Multitasking und Einzelkämpfertum und Zusammenarbeit wird verhindert. Werden die Kräfte des Teams nicht gebündelt, so geht viel Zeit für das switchen zwischen der Aufgaben drauf. Die Effizienz des Teams leidet und dies führt zu höheren Produktionskosten. Des Weiteren werden Themen nur halb fertig und beinhalten dann meist noch einige Fehler, die wiederum zu hohen Fehlerbehebungskosten führen. Fehlender Fokus führt also zu doppelten Kosten – Features, die nicht fertig sind und lange in der Umsetzung brauchen und Fehlerkosten, die bei der Behebung dieser Fehler auftreten.

Verbesserungen:

Es ist besser, wenige Features im Produkt zu haben, die alle hundertprozentig funktionieren und die Kunden begeistern, als viele halb fertige Features zu haben, die die User frustrieren. Es kann sein, dass die gewisse Strategie fehlt, eine Produktentwicklungsstragie basierend auf den Bedürfnissen der Zielgruppen ist notwendig. Da Ressourcen immer eingeschränkt sind, müssen die Kräfte gebündelt werden. Das gesamte Team sollte an einem Strang ziehen und Sprintziele umsetzen. Zu viele verschiedene Themen sollten nicht gleichzeitig umgesetzt werden, weil das der Effizienz schadet und letzten Endes zu hohen Kosten führt. Das Team sollte interdisziplinär am Sprintziel arbeiten und vor allem auf die Qualität und den Outcome der umzusetzenden Features achten. Denn die größten Kosten sind die, die entstehen wenn ein Feature gar nicht benutzt werden kann.

Beschreibung des Kostentreibers:

In vielen Softwareentwicklungsprojekten gibt es keinen Produktmanager oder Product-Owner oder es wird kurzerhand jemand aus der Fachabteilung zum Produktmanager/Product-Owner ernannt. Ohne viel über die Entwicklung von Produkten zu wissen, oftmals nur mit einem 2-3 Tages Workshop für Scrum – Product-Owner gewappnet, werden diese Mitarbeiter auf die Produktentwicklung losgelassen und ins kalte Wasser gestoßen. Durch den reinen Fokus auf das Backlog und ohne theoretischen Background über Produktmanagement werden wichtige Themen, die es für die Entwicklung guter Produkte braucht, einfach vergessen oder ausgelassen. Product-Onwer und Produktmanager müssen alber viel mehr sein und machen. Das Team und die Entwicklung braucht keinen reinen Product-Backlog- Pfleger, sondern Strategen und Experten, die eine Vielzahl an Methoden einsetzen, um den richtigen Fokus zu setzen und ein Produkt zum Erfolg zu führen.

Warum ist das schlecht?

Wird das Thema Produktmanagement in einem Softwareprojekt nicht bedacht, so ist dies meist im fehlenden Fokus zu spüren. Produktmanager kümmern sich darum die User-Experience und Qualität des Produkts hoch und das Team effektiv zu halten. Kennt das Umsetzungsteam die Zielgruppe, die Kundensegmente und deren Bedürfnisse nicht, und kann es nicht effizient und effektiv die Probleme der Kunden durch das Produkt lösen, so wird sich das Produkt nicht verkaufen und das sind die größten Kosten, die in einem Softwareentwicklungsprojekt entstehen können. Features, die falsch umgesetzt werden und eine schlechte User-Experience aufweisen, zerstören die Wahrnehmung der Kunden über das Produkt. Sprechen die erst einmal schlecht über das Produkt oder sind enttäuscht, kann dies schnell sehr schädlich für das Produkt und das Unternehmen werden.

Verbesserungen:

Damit die Softwareentwicklung in die richtige Richtung geht, müssen Grundlagen des Produktmanagements beachtet werden und gewisse Methoden, die mittlerweile als Basis eingestuft werden, angewandt werden. Es müssen Informationen über die Zielgruppe gesammelt werden und diese am besten in Personas5 konzentriert werden. Durch die Entwicklung einer Produktstrategie und das richtige Gestalten einer Roadmap können Vision und Ziele in Einklang gebracht werden. Value-Proposition Canvas6 und Busines-Model Canvas bilden die Grundlage für eine erfolgreiche Produktstrategie. User-Experience und Usability7 sowie UI-Design müssen ebenfalls gestaltet und modelliert werden. Das alles bedeutet zwar Aufwand und Kosten, es verhindert jedoch auch gleichzeitig, dass die falschen Dinge umgesetzt werden und somit Kosten zu vermeiden. Das Setzen und Einhalten des Fokus ist eine der wichtigsten Aufgaben des Produktmanagers und deswegen müssen Produktmanager Nein sagen können8. Kurzum, beim Produktmanager sollte nicht gespart werden, hier können am meisten Kosten verhindert werden.

Beschreibung des Kostentreibers:

Wird ein Produkt entwickelt, so werden zu Beginn viele Annahmen über den Markt, die Kunden und deren Bedürfnisse und somit auch über die Features, die diese Bedürfnisse befriedigen sollen, gemacht. Die Aufgabe des Produktmanagements ist es gemeinsam mit dem Umsetzungsteam diese Annahmen durch Experimente9 zu bestätigen oder zu entkräften. Oftmals werden diese Experimente aber selbst zum Kostentreiber. Werden sie nicht gewissenhaft gemacht oder werden zu wenige Experimente gemacht und ist das Feedback zu schlecht, leidet die Qualität der Entscheidungen, die das Produktmanagement macht. Es werden falsche Features umgesetzt oder Features nur teilweise umgesetzt, wie es die Kunden brauchen. Das sind Fehler, die im Nachhinein viel Kosten verursachen.

Warum ist das schlecht?

Nur wenn ein guter Product-Market-Fit gefunden wird, kann das Produkt seinen Absatzmarkt finden und Kunden begeistern. Werden zu wenige Experimente gemacht oder das Feedback aus diesen Experimenten nicht richtig erhoben, führt dies zu Fehlentscheidungen, die teuer werden. Feedback zu sammeln an sich ist aber auch kostspielig und zeitaufwendig.

Verbesserungen:

Feedback wird in zwei Bereiche gegliedert. Qualitatives und quantitatives Feedback. Während qualitatives durch Interviews Einblicke in die Funktionalität des Produkts gibt, kann quantitatives durch Analytics und Insights extrem wertvoll sein. Gute Projekte brauchen sowohl regelmäßiges Feedback von Keystakeholdern und Key-Usern als auch gutes Monitoring und Insights der Funktionen. Daraus können Schlüsse gezogen werden, an welchen Ecken und Kanten das Produkt noch verbessert werden muss und wo es Probleme gibt.

Beschreibung des Kostentreibers:

Der letzte große Kostentreiber ist ein Engineering Thema. Es ist notwendig, immer laufend in die Qualität einer Software10 zu investieren. Passiert dies nicht, so können extrem hohe Kosten entstehen. Im schlimmsten Fall wird die Software nach einiger Zeit durch Bugs und Seiteneffekte so instabil, dass ein großes Redesign oder eine Neuimplementierung notwendig ist. Kosten, die jede Wirtschaftlichkeit eines Produkts zerstören können und ganze Investitionen vernichten können.

Warum ist das schlecht?

Das zu wenig investierte Zeit des Teams in Qualität unweigerlich zu einer schlechten Software-Qualität und somit auch einer schlechten Produktqualität führt, leuchtet jedem ein. Oftmals sind es aber nicht einmal die Manager, die das Team daran hinder, in Qualität zu investieren. In vielen agilen Teams, aber vor allem in plangetriebenen Umsetzungen entsteht im Team der Druck, Funktionalität zu liefern. In Scrum ist es eigentlich Best-Practice, dass keine Kompromisse hinsichtlich der Qualität gemacht werden sollen.

Dennoch passiert dies immer wieder. Es wird oftmals nicht so viel wert auf Testabdeckung und Unit-Tests gelegt, weil das Umsetzen von neuen Features einfach interessanter ist. Oder es gibt einen Product-Owern der das Developmentteam unter Druck setzt. Fehler, die aber jetzt nicht gefunden werden, kosten durch die Rule of 10 im Nachhinein, aber um ein Vielfaches mehr. Legt das Team keinen wert auf Architektur und Design, so könne später nur mehr sehr schwer Verbesserungen gemacht werden. Im Laufe der Zeit wird es für das Team immer schwerer, neue Features einzubauen, ohne dabei andere Teile des Systems zu destabilisieren.

Verbesserungen:

Aus diesen Gründen ist es notwendig immer und sofort in Qualität, Architektur und Design von Software-Produkten zu stecken. Wer hier spart wird später bestraft und spart an der falschen Stelle.

Fazit:

Die sieben Kostentreiber, die hier aufgezeigt wurden, sind nur jene, die sehr häufig in Softwareentwicklungsprojekten auftauchen. Es gibt noch zahlreiche weitere Punkte und Anitpattern, die die Kosten für Individualsoftwareprojekte und digitale Produkte in die Höhe schnellen lassen.

Wichtig ist in jeden Fall auch, dass die beteiligten Personen professionell agieren und das nötige Know-how haben, die Software möglichst effizient und kostengünstig umzusetzen und vor allem auch professionell und eigenständig agieren können/dürfen und selbstorganisiert arbeiten, nur dann wird das Produkt zum Erfolg und das Return on Investment stimmt am Ende des Tages.

1https://www.standishgroup.com/sample_research_files/RuleTen.pdf

2https://www.olev.de/0/10er-regl.htm

3https://digitalisierungscoach.com/2018/11/02/outputorientierte-vs-outcomeorientierte-scrum-teams/

4https://digitalisierungscoach.com/2018/11/02/outputorientierte-vs-outcomeorientierte-scrum-teams/

5https://digitalisierungscoach.com/2020/07/03/personas-verwenden-fuer-die-digitalisierung/

6https://digitalisierungscoach.com/2020/06/25/das-value-proposition-canvas-als-ausgangslage-fuer-die-entwicklung-digitaler-produkte/

7https://digitalisierungscoach.com/2020/03/21/agiles-produktmanagement-und-user-experience-ux/

8https://digitalisierungscoach.com/2018/11/06/product-owner-muessen-gut-nein-sagen-koennen-und-klare-aussagen-treffen/

9https://digitalisierungscoach.com/2020/08/13/was-ist-product-market-fit/

10https://digitalisierungscoach.com/2020/06/20/softwarequalitaet-testen-und-unittesting/

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

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: