2015 Jul 23
Warum neigen wir Softwareentwickler immer zu unnötig komplexen Lösungen, wenn es eigentlich darum geht eine Idee auszuprobieren? Warum müssen wir das vollständige Produkt bauen, bevor wir wissen ob der Ansatz das Problem wirklich löst? Warum bauen wir Prototypen, wenn wir das Konzept auch mit einem Mock-up ausprobieren können? Und wann würde sogar die sprichwörtliche Serviette ausreichen?
Bei der Gründung eines Startups gibt es schon genug Aufgaben zu erledigen, da muss kein unnötiger Aufwand an der falschen Stelle erzeugt werden. Wenn es noch darum geht die Relevanz des Problems herauszufinden, braucht man üblicherweise keine Software. Und solange unklar ist ob die Lösung vom Kunden akzeptiert werden würde, reicht für die ersten Tests oft ein Papier-Prototyp oder ein einfaches Mock-up.
Für jedes Problem gibt es ein angemessenes Werkzeug, das ist bei der Softwareentwicklung im Startup nicht anders. Wann reicht eine Serviette, wann ein Mock-up, wann ein Prototyp und wann die minimale Version des geplanten Produktes?
Du hast herausgefunden dass deine späteren Kunden tatsächlich das erwartete Problem haben und möchtest jetzt anfangen über deine Lösungsidee zu reden? Oft reicht dafür eine einfache Skizze auf dem Papier. Für die Erklärung von Ideen gibt das Buch „Auf der Serviette erklärt“ viele Anregungen, aber auch das User-Interface der nächsten Webanwendung lässt sich ganz einfach mit einem Bleistift und ein paar Zetteln darstellen.
Papier-Prototypen haben ein paar wirklich unschlagbare Vorteile:
Die Idee ist verstanden, der Papier-Prototyp erklärt und die Fragen rund um das Interface werden konkreter? An dieser Stelle lassen sich viele offene Fragen mit einem Mock-up lösen. Um Mock-ups zu erstellen gibt es viele kostenlose, günstige und ein paar sündhaft teure Tools. Manchmal reicht aber auch einfach eine simple HTML-Seite.
Mit einem Mock-up lässt sich der Seitenaufbau gut testen und es können bereits grundlegende Details ausgearbeitet werden. Je nach Komplexität des Tools, lassen sich auch schon Prozesse und Abläufe darstellen, so dass erste rudimentäre Tests der User-Experience möglich sind.
Für erste Mock-ups nutze ich gerne pencil. Das Tool ist kostenlos und für viele Plattformen verfügbar. Für komplexere Mock-ups bei größeren Projekten habe ich gelegentlich myBalsamiq genutzt. Die Webanwendung ist nicht kostenlos, hat aber einige wirklich gute Features und die Mock-ups sehen echt gut aus.
Wenn anhand von Mock-ups das grundlegende Konzept geklärt ist, kann im nächsten Schritt „endlich“ echte Software entstehen. Ob jetzt ein Prototyp die richtige Wahl ist oder ob schon eine erste Version des eigentlichen Produktes gebaut wird, hängt von der Komplexität und der verbliebenen Rest-Unsicherheit ab.
Prototypen können unterschiedliche Ziele verfolgen. Ist eine Technologie noch neu und unerprobt? Ist das Bedienkonzept so neu, dass hier ein erster Test mit den realen Nutzern sinnvoll wäre? Für diese Fälle wäre ein Prototyp sinnvoll, der relativ schnell und ohne besonders hohe Qualitätsanforderungen entwickelt werden kann.
Ein „minimum viable product (MVP)“ ist die kleinste Version des Produktes, die einen echten Kundennutzen erbringen kann. Ein MVP wird üblicherweise mit den hohen Qualitätsansprüchen gebaut, die später auch das finale Produkt gestellt werden. Da im ersten Schritt nur die kleinstmögliche Menge an Funktionen implementiert wird, kann auch hier sehr schnell ein Feedback der späteren Anwender erreicht werden.
Was sind Deine Erfahrungen mit „zu viel“ Software? Hast Du auch schon Code geschrieben, der am Ende gar nicht das Problem gelöst hat? Berichte in den Kommentaren davon!