Du hast mehrere Möglichkeiten, um in deinem Softwareprojekt viel Geld zu sparen. Die meisten bieten sich dir während der Designphase. Anhand der 1:10:100-Regel erkläre ich dir, warum und wie wichtig es ist, deine Hypothesen früh zu verifizieren. Mit der soliden Datengrundlage behältst du den Kostenrahmen deines Softwareprojekts im Griff und kannst wegweisende Entscheidungen treffen und damit Fehlinvestitionen und Kopfzerbrechen vermeiden.
- Autor
- Daniel Öttl
- Datum
- 29. Mai 2024
- Lesedauer
- 3 Minuten
Was besagt die 1:10:100-Regel?
Die Faustregel wurde 1992 von George Labovitz und Yu Sang Chang definiert. Sie haben darin die Entwicklung der Kosten beschrieben, die mit einem Dateneingabefehler einhergehen. Die 1:10:100-Regel besagt, dass die Kosten pro Stufe um den Faktor 10 steigen:
- Prävention ($1): wenn der Eingabefehler sofort behoben wird
- Korrektur ($10): wenn der Fehler im Nachhinein behoben wird
- Misserfolg ($100): wenn der Fehler nie behoben wird, was zu Mehrarbeit, verpassten Chancen und Fehlkommunikation führt
Grundsätzlich gilt, je später ein Fehler entdeckt wird, desto mehr kostet es, diesen zu beheben, weil weitere Datenpunkte darauf aufbauen.
Die 1:10:100-Regel wurde anschließend in weitere Bereiche übernommen, um Fehlinvestitionen oder Änderungen in verschiedenen Projektphasen zu verdeutlichen. Für ein Softwareprojekt kann die 1:10:100-Regel auf folgende Phasen umgelegt werden:
- Im UX Designprozess
- Während der Entwicklung
- Nach dem Launch
Faktor 1: im UX Designprozess
Im UX Designprozess beschäftigen wir uns mit der Aufgabenstellung und entwickeln unterschiedliche Lösungsansätze. Durch User Research, Workflows, Wireframes, Design-Prototypen und Usability Tests evaluieren wir diese und können so rasch konkreter werden. Das Angenehme daran ist, dass sich der zeitliche Aufwand in dieser Phase noch auf wenige Personen beschränkt und Änderungen sehr schnell möglich sind. Insgesamt sind die Kosten somit gering.
Natürlich gilt die 1:10:100-Regel auch in den einzelnen Phasen des Designprozesses. Es geht viel schneller, einen Workflow anzupassen, als das Design für die dazugehörenden Screens zu adaptieren. Insgesamt ist es im Vergleich zu Änderungen im Code aber vernachlässigbar.
Faktor 10: während der Entwicklung
Mit dem Entwicklungsbeginn kommen weitere Personen zum Projekt dazu. Bei Fusonic umfassen die Entwicklungsteams 4 bis 10 Personen, um die geplante Lösung technisch umzusetzen. Alleine anhand der Personenanzahl ist es leicht zu erkennen, dass der Aufwand und damit die Kosten einer Änderung höher sind als im UX Designprozess. Die Änderungen werden in der Entwicklung durch ihre technischen Abhängigkeiten zudem weitaus komplexer, was wiederum zu Mehraufwand führt.
Um trotzdem sicherzugehen, dass die konzipierte und umgesetzte Lösung für die Nutzer:innen passt, empfehlen wir, Usability Tests durchzuführen. Durch diese Tests werden sowohl die Nutzbarkeit als auch die Effektivität der Lösung validiert und es können weitere Kosten vermieden werden.
Faktor 100: nach dem Launch
Manche Fehler schaffen es trotz aller Vorsichtsmaßnahmen in das Produktivsystem. Unser Ziel ist es, die Anzahl möglichst gering zu halten und die Auswirkungen auf ein Minimum zu begrenzen. Denn nach dem Launch können zusätzlich zu den oben erwähnten weitere Kosten entstehen. Zum Beispiel durch Anpassungen der Infrastruktur, Migration der bestehenden Daten, Umschulungen und zusätzlichem Supportaufwand.
Fazit
Die 1:10:100-Regel verdeutlicht in Softwareprojekten, wie wichtig es ist, die eigenen Lösungsansätze von Anfang an in realen Situationen zu testen und damit zu validieren. Die Designphase bietet sich an, um noch vor der Entwicklung verschiedene Wege auszuprobieren und zu experimentieren. Denn Änderungen können in dieser Stufe noch schnell und kostengünstig umgesetzt werden und gleichzeitig wächst das Verständnis für die Anforderungen und Bedürfnisse der Zielgruppe bei allen Projektbeteiligten mit.
