Von der Idee zur fertigen Software

‍

Viele Menschen fragen sich wie der Prozess, bis eine fertige App im App-Store oder im Web-Browser landet, aussieht und welche Fähigkeiten und Kenntnisse von Nöten sind.
In diesem Artikel beschreiben wir den Entstehungsprozess einer Software und gehen auf die nötigen Kenntnisse ein, die im Entwicklungsteam benötigt werden.

In diesem Artikel:

1. Die Idee
2. Das MVP
3. Das Team
4. Die Entwicklung
5. Die Übergabe
6. Die Betreuung

‍

Die Idee

Jede Innovation beginnt mit einer Idee, einem Problem oder einem optimierbaren Prozess.
Vor dem Beginn eines Softwareprojektes ist es unabdingbar, diese Idee in Worte zu fassen oder das Problem / den Prozess so zu beschreiben, dass eine Branchenferne Person diese sofort verstehen kann.

Ohne ein klares Verständnis der Idee kann kein externes und zumeist auch kein internes Team verstehen, wie die Idee umzusetzen oder das Problem zu lösen ist.
Eine klare Definition ist daher unfassbar wichtig.

Ein hilfreiches Tool für die präzise Formulierung lässt sich aus dem Startup Bereich ableiten: der Elevator Pitch.
Kurz: Das Ziel ist es die Idee / das Problem innerhalb einer Aufzugfahrt jemandem zu erklären, der noch nie einen Berührungspunkt mit dieser gehabt hat. Dabei lohnt es, sich an folgendem Faden entlangzuhangeln:

Bei einer Idee:

• Worum geht es?
• Was ist das Problem?
• Wie kann das Problem gelöst werden?
• Wie hoch ist der Nutzen, wenn das Problem gelöst ist?

Bei einem Problem:

• Worum geht es?
• Was ist das Problem?
• Was sind die Auswirkungen des Problems?
• Wie hoch ist der Nutzen, wenn das Problem gelöst ist?

Das generelle Ziel der Ideenphase eines Projektes muss es sein, am Ende eine gut formulierte und für alle Stakeholder in dem möglichen Projekt verständliche Beschreibung des Problems und dessen Lösung zu haben.
Nur wenn alle Parteien abgeholt sind und den Grund bzw. den Sinn des Projektes verstehen, werden sie sich mit vollem Herzblut der Umsetzung widmen. Der Mensch sucht immer nach einem Sinn, auch bei Softwareprojekten. Und grade in den späteren Phasen eines Projektes ist dies ein Punkt, der die Motivation des Teams beflügeln kann und so eine menge Geld spart.

‍

Das MVP

Nachdem der erste Schritt getan und eine Idee mit Problemidentifizierung und Lösungsansatz ausformuliert ist, geht es daran, diesen Lösungsansatz zu testen und zu validieren. Hier gibt es viele Möglichkeiten. Da wir uns auf die Softwareentwicklungs beziehen, fokussieren wir uns auf die Validierung durch ein Screendesign und dessen inkrementelle Überarbeitung.

Im ersten Schritt erstellt ein UI/UX Designer ein Screendesign, welches die Nutzeroberfläche der zu entwickelnden Lösung wiederspiegelt. Das Screendesign kann für eine mobile App oder eine Weboberfläche erstellt werden und dient als Vorzeigeobjekt. Es handelt sich dabei um eine statische Darstellung der Software und wird im ersten Schritt dafür verwendet, um Feedback potentieller Nutzer einzuholen und die Lösung zu validieren. Bei diesem Schritt ist es wichtig das Feedback der Nutzer zu sammeln und inkrementell in die Ausarbeitung des Prototypen einfliessen zu lassen.

Nach mehreren Verbesserungsschleifen soll dann ein finaler Prototyp stehen, welcher in Kombination mit den User Storys dem Entwicklungsteam zur Verfügung gestellt wird und umgesetzt wird.

‍

Das Team

In den ersten beiden Phasen der Realisierung einer neuen Software besteht das Team im Regelfall aus einer kleinen Gruppe von Pionieren. Für die Erstellung des Screendesigns / des MVPs wird ein UI/UX Designer in das Team mit aufgenommen. Bereits im ersten Schritt macht es Sinn, den späteren Projektmanager in die Ausarbeitung der Idee und des Screeendesigns zu integrieren, um das Wissen dieser beiden Personen mit in die Entwicklungsphase zu nehmen.

In der Teamfindungsphase wird nun das Team für die Umsetzung der Idee und des Screendesign zusammengestellt. Da hier die Zusammensetung des Team je nach Projektart unterschiedlich ist, werden wir uns auf ein Projekt fokussieren, in welchem eine App für das Aufzeichnen von Fahrtwegen und Aufgaben von Feldarbeitern in der Landwirtschaft programiert wird.

Dafür schauen wir uns die Anforderungen an diese App an:

1. Arbeiter sieht eine Karte mit Geopositionen für seine Arbeiten
2. Der Fahrtweg des Arbeiters wird aufgezeichnet
3. Der Büromitarbeiter kann Aufgaben erstellen und diese verschiedenen Mitarbeitern zuweisen
4. Der Büromitarbeiter kann sehen, wann welche Aufgaben erledigt wurden

Für dieses Projekt müssen wir eine App für den Feldmitarbeiter entwickeln und eine Oberfläche im Browser, über die der Büromitarbeiter die Aufgaben verwalten kann. Dafür brauchen wir einen Entwickler, der sich um die Datenverarbeitung und die Datenbank kümmert. Für die Nutzeroberflächen brauchen wir jeweils mindestens einen Mitarbeiter, der die Oberfläche der App entwickelt (App und Web).
Da wir uns in diesen Projekt dafür entscheiden, die Oberfläche für den Feldarbeiter als mobile App anzubieten, müssen wir einen Entwickler für die iOS-Entwicklung und einen Mitarbeiter für die Android-Entwicklung einstellen.

Das Team für dieses Projekt besteht also aus:

• 1 Projektmanager
• 1 UI/UX Designer
• 1 BackEnd Entwickler
• 1 Web Entwickler
• 1 iOS Entwickler
• 1 Android Entwickler

Je nach Zeitdruck im Projekt sollte zu Beginn bedacht werden, ob für die Entwicklerrollen jeweeils ein zweiter Entewickler eingestellt werden soll. Wenn möglich sollte dies nicht mitten im Projekt entschieden werden, da an diesem Zeitpunkt mit Verzögerungen durch das Anlernen und Einbinden der neuen Entwickler in den Entwicklungsprozess Zeit kosten.

‍

Die Entwicklung

Während der Teamfindung bereitet der Projektmanager mit dem fertigen Screendesign den Projektablauf vor.
Dabei erstellt dieser für alle Funktionen der Nutzeroberfläche sogenannte User Storys. Diese sind im Normalfall folgendermaßen aufgebaut:

Zunächst wird beschrieben, was das Ziel der auszuführenden Funktionalität für den Nutzer ist:
Als "Nutzerrolle" will ich "Ergebnis der Ausführung der Funktionalität".

Dann wird im Detail beschrieben, was der Nutzer machen muss um dieses Ziel zu erreichen:
Der "Nutzerrolle" kann "Beschreibung der Aktion".

Beispiel:

Als Büromitarbeiter will ich eine neue Aufgabe für einen Feldarbeiter anlegen.

• Der Büromitarbeiter kann eine Tabelle mit allen im System angelegten Aufgaben sehen.
• Der Büromitarbeiter kann auf den Button: "Aufgabe anlegen" klicken.
• Der Büromitarbeiter sieht eine Eingabemaske mit folgenden Eingabemöglichkeiten: Name, Mitarbeiter, Geoposition
• Der Büromitarbeiter kann durch klick auf den Button: "Speichern" die Aufgabe final anlegen
• Der Büromitarbeiter wird auf die Tabelle zurückgeleitet und sieht die neue Aufgabe an erster Stelle in der Tabelle

Nachdem der Projektmanager alle User Storys geschrieben hat werden diese in Epics gruppiert. Die Entwickler schätzen jede der User Storys und legen fest, wie viele Stunden sie für die Umsetzung dieser brauchen.
Der Projektmanager kann nun die gruppierten User Storys (Epics) in eine Zeitliche Reihenfolge bringen und dabei die Abhängigkeiten zwischen BackEnd und FrontEnd so abstimmen, dass es keine Wartezeiten in der Entwicklung gibt.

Nachdem dieser Schritt abgeschlossen ist, können die Entwickler mit der Arbeit beginnen. Da wir die User Storys zuvor gruppiert haben, können abgeschlossene Funktionalitäten bereits während der Entwicklungsphase von allen Stakeholdern getestet werden und mögliche Bugs oder Änderungswünsche in den Entwicklungsprozess einfließen.

Hinweis: Es ist wichtig genügend Puffer für Änderungswünsche und Bugs einzuplanen, sobald erste Teile der Software durch die Stakeholder getestet werden.

‍

Die Übergabe

Am Ende des Projektes steht die Übergabe. Hier ist es wichtig für die Agentur, sowie für den Kunden schon während der Entwicklungsphase einen transparenten Überblick zu schaffen, welche Funktionalitäten im Projektumfang mit inbegriffen sind. Dies lässt sich gut anhand der User Storys festlegen, da diese die App in Gänze beschreiben müssen und Rückblickend gut als eine Art Lastenheft dienen können. Alternativ kann es aber genauso Sinn machen, zu Beginn des Projektes ein separates Lastenheft zu führen. Hierbei ist zu beachten, dass Änderungen am Funktionsumfang auch hier dokumentiert und von beiden Seiten abgesegnet werden.

Im Übergabeprozess sollte zunächst durch den Projektmanager die gesamte Software anhand der User Storys / des Lastenheftes getestet werden. Sind diese Fehlerfrei umgesetzt, wiederholt der Kunde diesen Prozess.

Hinweis: Es empfiehlt sich die "Übergabe" schon nach jeder abgeschlossenen Funktionalität im Entwicklungsprozess zu machen, da hierdurch lästige Diskussionen über Bugs und Änderungen schneller gelöst werden können.

‍

Die Betreuung

Nach der Übergabe sollte ein Rahmenvertrag über die Betreuung und Weiterentwicklung der Software abgeschlossen werden. Die Plattformen, auf denen eine Software entwickelt wurde ändern sich stetig und diese Änderungen müssen in der Software kontinuierlich mitgezogen werden. Des Weiteren ist es ganz normal, dass bei der Abnahme nicht alle Bugs in der Software gefunden werden. Daher eignet sich ein Rahmenvertrag hervorragend, um die durch die Nutzer aufgedeckten Bugs schnell und effizient zu beheben.