Wünsche/Features ≠ Qualität

Es kann nun sein, dass zwar alle geforderten Features umgesetzt wurden und die Software, genau wie zu Begin ausgemacht, funktioniert und trotzdem kein zufriedenstellendes Ergebnis vorliegt. Woran kann das liegen?

Meistens sind es die versteckten, kleinen Details, die über den Erfolg entscheiden. Sehen wir uns dazu ein paar Beispiel-Situationen an.

1. Man entwickelt eine Software, um die Prozesse in einem Betrieb zu digitalisieren. Die Entwickler sind sehr zufrieden mit dem Ergebnis und stolz darauf. Vom Kunden kommt aber das Feedback, dass er die Software so nicht nutzen kann, selbst wenn alle Anforderungen erfüllt wurden.
2. Der Webshop des Kunden mit seinem großen Produktsortiment ist fertig. Er ist überglücklich mit den Funktionen, die er mit ein paar Testdaten probiert und freut sich über das hübsche Design. Am Eröffnungstag geht der Shop Live und der Kunde ist plötzlich nicht mehr so zufrieden, da er die Seite zwischendurch oft nicht aufrufen kann.
3. Ein Start-Up engagiert dich, damit du ihre Idee ordentlich umsetzt und sie danach selbst an der Software weiterentwickeln können. Sie erhalten das Endergebnis, sind auch damit zufrieden, aber ab dem Zeitpunkt an dem sie selbst weiter entwickeln, beginnen sie sich zu beschweren, über die unzureichende Arbeit und dass sie das Software-Projekt von Grund auf neu starten wollen - aber mit einem anderen Unternehmen.
4. Ein Unternehmen möchte, dass du eine Software zum Verwalten ihrer Klienten schreibst. Die Software wird blitzschnell umgesetzt und der Kunde ist sehr zufrieden. Nachdem sie aber kurze Zeit im Einsatz war, kontaktiert dich der Kunde wieder und fragt verärgert nach, warum du das Administratoren-Passwort geändert hast, weil er sich nicht mehr einloggen kann.

In all diesen Geschichten stecken oft auch nur kleine Details, die man berücksichtigen muss, um solch unangenehme Situationen zu vermeiden. Allgemein lassen sich alle diese Geschichten in 4 Kategorien einteilen, an denen der Erfolg scheitert, wenn man sie übersieht.

Usability

Im Bezug auf Beispiel 1, beschwert sich der Kunde, dass er die Software nicht gebrauchen kann. Hierbei liegt es daran, dass der bisherige Workflow im Betrieb anders gestaltet sein könnte, als der Workflow der neuen Software. Die Software kann exakt die Funktionen bieten, die benötigt werden, aber trotzdem erfüllt sie ihren Nutzen nicht, wenn der Workflow damit umständlicher wird oder vielleicht gar nicht mehr exakt so abgebildet werden kann.

Fehler in der Usability sollten/müssen bereits ganz früh im Projektverlauf erkannt und behoben werden. Dabei geht es oft um grundlegende Bedienung und Funktionalität der Software und Änderungen dabei führen im späteren Projektverlauf sehr schnell zu enorm hohem Zusatz-Aufwand.

Zu Beginn ist es oftmals schwierig jeden Prozess exakt zu definieren, auch auf Kundenseite gibt es oft mehrere zukünftige Nutzer-Gruppen, die alle einzubeziehen sind. Wie schafft man nun gute Software-Qualität durch gute Usability?Dazu gibt es diverse Workshop-Methoden für größere Nutzer-Gruppen, aber auch einfache Möglichkeiten, wie in diesem Beitrag  beschrieben wird.

Performance

In der zweiten Beispiel-Situation wird beschrieben, dass der Kunde zwischenzeitlich keine Verbindung mehr zu seinem Webshop bekommt. Hier könnte man starke Performance-Probleme vermuten. Der Webshop wurde davor nur mit Testdaten ausprobiert und vielleicht auch nur vom Kunden selbst getestet, ohne weiteren gleichzeitigen Testern. Mit der großen Produkt-Menge die im Produktiv-Betrieb bereitgestellt ist und den vielen Zugriffen am Eröffnungstag, kann es leicht sein, dass der Server oder die Software überlastet ist. Vor allem wenn bei der Programmierung nicht darauf geachtet wurde, ressourcenschonend und effizient Daten abzurufen und zu verarbeiten.

Auch das versteckte Detail der geforderten Performance, sollte frühzeitig im Projekt abgeklärt werden, um für den Produktiv-Betrieb gewappnet zu sein. Im Nachhinein kann es sich oft als mühsam erweisen, derartige Performance-Probleme in der Software selbst ausfindig zu machen, wenn diese schon aus vielen, vielen Zeilen Code besteht.

Die notwendige Performance der Software kann ganz einfach bestimmt werden. Man braucht lediglich die Fragen zu stellen, für wie viele Nutzer die Software ausgelegt sein soll, ob der Server eine bestimmte Reaktionszeit gewährleisten soll und/oder auf welchem Server die Software schlussendlich gehostet wird. Es kann auch der Fall sein, dass die Software im Test-Betrieb schon mit Produktiv-Daten arbeitet und dort trotzdem viel schneller läuft als am Produktiv-Server, falls der Server für den Test-Betrieb einfach viel mehr Power hat.

Code-Quality

In Beispiel 3 geht es um ein Start-Up, dass die fertige Software zwar weiterentwickeln möchte - aber nicht kann. Hier könnte es eine mangelhafte Code-Qualität geben. Das bedeutet, dass die Software zwar gut funktioniert, aber im Hintergrund nicht so programmiert wurde, dass eine einfache Weiterentwicklung gegeben ist. Ein paar Stichwörter hierzu wären Dokumentation wie Prozess-Skizzen, Interfaces und Beschreibungen oder auch Clean-Code (also dass der Code so sauber formuliert wurde, dass dieser so selbsterklärend ist, damit keine weiteren Kommentare im Code notwendig sind).

Um eine Software gut und effizient erweitern zu können, sollte sie modular aufgebaut sein. Das heißt, alle Teile der Software sollten so wenig Abhängigkeit wie nur möglich zueinander haben, damit man einfach neue Module dazwischen einfügen kann, ohne den Rest "zu zerstören". Ein gewisses Maß an Code-Qualität sollte zumindest für jedes Projekt, an dem mehrere Personen beteiligt sind, gegeben sein. Darüber hinaus ist es eines der wichtigsten Details, falls die Software in Zukunft von einem anderen Unternehmen oder anderen Entwicklern übernommen werden soll. Ist das der Fall und von Anfang an bekannt, sollte darauf großes Augenmerk gelegt werden.

Wie kann man das am einfachsten erreichen? Es ist immer von Vorteil, wenn mindestens zwei Personen an dem Projekt arbeiten und gegenseitig Code-Reviews durchführen. Das bedeutet, dass eine Person, die programmierten Funktionen des anderen reviewed und Feedback einbringt und umgekehrt. So kann man einen gewissen Standard an Code-Qualität von Anfang an geben. Auch automatisierte Tests beeinflussen die Code-Qualität sehr positiv. Weitere Maßnahmen wie Dokumentation oder Ablauf-Diagramme können auch noch nachträglich zur Übernahme erstellt werden.

Security

Was könnte in Beispiel 4 passiert sein? Hier ist es plötzlich nicht mehr möglich, sich als Admin einzuloggen, da anscheinend das Passwort geändert wurde. Ein wahrscheinliches Szenario ist, dass die Security der Software Lücken aufweist, die es einem Hacker in kurzer Zeit ermöglicht haben, das Passwort des Administrators zu ändern. Bei einer Software, mit der vertrauliche Kundendaten verarbeitet werden, darf das natürlich keineswegs so einfach geschehen können.

Bezüglich Security gibt es viele Risiken die man beachten kann und kaum ein System das nicht gehackt werden könnte. Je wichtiger die Daten sind, die durch den Login geschützt sein sollen, desto mehr Aufwand sollte man auch in Überlegungen zu Security und deren Umsetzung stecken. Je ausgeklügelter das System, desto sicherer ist es grundsätzlich. Im Zweifelsfall sollte man sich hier auch an Experten wenden, die bei der Umsetzung oder Konzipierung des Systems mithelfen sollen.

Kommt man erst im Laufe des Projekts darauf, wie wichtig die Security ist und wie stark die Daten geschützt werden müssen, ist das in dieser Qualitäts-Kategorie nicht so tragisch, wie beispielsweise wenn die Usability komplett überdacht werden müsste. Alle Schnittstellen die abgesichert werden müssen, alle Logins und so weiter, können theoretisch jederzeit auch im Nachhinein noch einfach und besser abgesichert werden.

Wieviel Software-Qualität brauche ich?

Grundsätzlich geht es immer darum, die Software zum Erfolg zu machen. Dabei gilt es, nicht nur die Anforderungen, die der Kunde nennt, zu erfüllen, sondern auch die versteckten Details aufzudecken und den Fokus darauf zu legen. Mit ein bisschen Hirnschmalz findet man in jedem Projekt sehr schnell heraus, was in welchem Maße notwendig ist, um eine sehr gute Software-Qualität zu erreichen, die garantiert zum Erfolg führt.

Wird die Software beispielsweise in Zukunft nie wieder weiter entwickelt (Beispielsweise wird sie nur für ein bestimmtes, einmaliges Event entwickelt), dann bringt es auch wenig, viel Wert auf Code-Qualität zu legen. Andererseits sind aber vielleicht dafür gerade die Performance sehr wichtig, falls es ein Event mit vielen Besuchern ist, die alle gleichzeitig darauf zugreifen wollen.

Als Hilfestellung kann man sich auch gerne einen Prozess definieren, den man zu Beginn eines Projekts abarbeitet. Wir bei Deckweiss starten beispielsweise immer damit, die Anforderungen des Kunden kennen zu lernen und die Idee, sowie die vorgeschlagene Lösung ganz im Detail zu verstehen. Das geschieht meistens in einem Meeting, oder bei größeren Anliegen auch in einem gemeinsamen Workshop. Mehr Details über unser Erfolgsgeheimnis findest du hier. Have fun!

‍