Apps sind anders als Webseiten. Zum Beispiel werden nur noch in seltenen Fällen Designer für eine Webseite beauftragt. Oft wird aus einer großen Menge aus Themes ein Design ausgewählt das gefällt und der Entwickler darf dann Anpassungen machen. Der Kunde pflegt den Inhalt ein und fertig ist die Webseite.
Nun gibt es keine Themes für Apps. Ebenso soll es ja in der Regel nicht um die reine Anzeige von Inhalten gehen, sondern der Benutzer soll irgendwas mit de App tun oder mit ihr interagieren. Da kommt zuerst die Frage auf: was genau und zwar ganz genau soll der Benutzer Mit der App tun?
Konzeption der App
Was sich nach einer langweiligen und recht offensichtlichen Phase anhört wird sie nach meiner Erfahrung doch ganz gerne übergangen oder nur oberflächlich behandelt. Nur weil eine einzige Person die Idee zu verstehen meint, heißt das nicht, dass die Person auch die Idee so klar einem Entwickler erklären kann, dass er sie danach umsetzen kann.
Der Entwickler wird die jede Funktion der App einzeln bauen, in Logik gießen und mit der UI, der Benutzeroberfläche, überziehen. Das kann er nur, wenn er wirklich versteht was gebaut wird, wie die Teile der App verzahnt sind und auch warum das für dich, den Kunden, so wichtig ist, dass die Dinge genau so sind und nicht anders.
Das erfordert Arbeit. Im Gegenzug wird es dir lange Gespräche während der Entwicklung sparen, weil früher oder später müssen diese Fragen auf den Tisch. Ebenso wird es dafür sorgen, dass irgendwann nicht böse Überraschungen auftreten weil der Entwickler potentiell Lücken im Produkt nach seiner Auffassungsgabe füllt anstatt mit deiner. Auch sorgt es dafür, dass nicht mitten in der Entwicklung Richtungswechsel passieren und Features doch plötzlich anders gebaut werden sollen, weil die Idee vorher noch nicht ausgereift genug war. In solchen Fällen muss zurück gebaut werden, Zeit wird verschwendet, Aufwand entsteht, unnötige Kosten fallen an und irgendjemand wird unglücklich aus der Situation gehen. In solchen Fällen liegt der Grund letztendlich immer darin, dass das Konzept bei Start der Entwicklung auf wackeligen Beinen stand. Ich kann nicht genug betonen wie wichtig diese Phase ist.
Bonus: ein guter Entwickler wird es erkennen, wenn du vorbereitet bist. Ein guter Entwickler sucht sich Projekte bei denen er das Gefühl hat, dass ernste Absichten dahinter stecken und eine gute Vorbereitung ist ein Zeichen dafür. Kein Entwickler will seine Zeit vermeintlich kostenlos in die Ausarbeitung des Konzeptes mit dem Kunden stecken es sei denn der potentielle Auftrag ist wirklich groß genug um das zu kompensieren. Ansonsten wird er wahrscheinlich ablehnen, weil er einfachere Projekte haben kann.
Erste Planung
Es gibt verschiedene Wege eine Software zu planen. Entwickler verwenden hier gerne Begriffe wie „Wasserfall“, „iterativ“ oder „agil“.
In den frühen Jahren der IT hat man versucht Softwareprojekte von Anfang bis Ende zu planen und in Phasen einzuteilen:
- Anforderungen sammeln und definieren
- Entwurf des technischen Konzeptes
- Implementierung (Entwicklung)
- Überprüfung
- Wartung, beheben von Fehlern, Instandhaltung
Nach einiger Zeit und immer mehr gescheiterten Großprojekten musste sich die Branche eingestehen, dass Software auf diese Weise nicht geplant werden kann.
Keine komplexe Software kann am Anfang fertig definiert werden, nicht alle Schwierigkeiten können im Voraus erkannt werden, genau so wie ein Navigationsgerät nicht vorhersehen kann bei welcher Ampel am Ankunftsort eine Rotphase haben wird und wo genau ein Parkplatz am Zielort frei sein wird. Es wird immer Unsicherheiten geben und diese multiplizieren sich mit der Zeit. Ein Schneeballsystem entsteht, Deadlines werden verschoben und wieder verschoben, unerwartete Kosten entstehen obwohl „ja alles geplant wurde“.
Der alternative Ansatz bezeichnet sich als iterativ oder agil. Das Konzept des Endproduktes muss nach wie vor stehen, aber man entscheidet sich erst einen kleinen Teil zu bauen, einen MVP, die kleinste sinnvolle Einheit.
Das bedeutet: man probiert erstmal einen kleinen Teil des Endproduktes umzusetzen und zu planen. Unsicherheiten werden dadurch schneller auffallen und können schneller angesprochen und behoben werden. Ist der MVP fertig gebaut so kann man sich den nächsten Satz an Funktionen vorknüpfen und auf die selbe Arbeitsweise dazubauen. Ein iterativer Ansatz. Klein starten und nach und nach Funktionen hinzufügen.
Dies funktioniert in der Regel auch im Kleinen. Oft planen Entwickler in sogenannten „Sprints“, z.B. Abschnitte von jeweils 2 Wochen. So weiß der Kunde was in den nächsten 2 Wochen passiert, hat im Idealfall auch alle 2 Wochen eine neue Version mit den Ergebnissen der letzten Wochen und Probleme und Fragen werden nie lange vorne weg geschoben.
Hier musst du mit dem Entwickler eine Balance finden aus fester Absprache der Aufwände Monate im Voraus und Akzeptanz, dass nicht alles geplant werden kann. Agile Softwareentwicklung ist der Versuch diese Situation fair zu gestalten. Fest geplant sind Sprints und man versucht nach x Sprints ein gewisses Ziel (einen fertigen MVP oder Version 2 etc) fertig zu haben. Der Entwickler garantiert sein bestes zu geben und sich früh bei Problemen, Rückfragen oder unerwarteten Situationen zu melden. Im Gegenzug kann der Kunde regelmäßig den Fortschritt prüfen und den Entwickler nach Absprache für diesen Fortschritt bezahlen. Ebenso kann dieser Ansatz dazu führen, dass du als Kunde frühzeitig den Entwickler wechseln kannst falls du merkst, dass die Zusammenarbeit nicht stimmt.
Auch wird hier das Zusammenspiel mit jeder Entwickler-Kunden Beziehung anders sein. Das selbe gilt wenn es mehrere Entwickler geben sollte. Jedes Team ist anders und jedes Projekt auch. Hier ist offene Kommunikation der wichtigste Punkt.
Dies ist übrigens ebenso ein wichtiges Merkmal für einen guten Entwickler, wenn er in der Lage ist ein gutes Gespräch auf Augenhöhe mit dir zu führen. Wichtig ist, dass du mit dem Entwickler einen gemeinsamen Nenner zwischen Planungszwang und Planlosigkeit findest.
Design
Design und Planung der ersten Version sollten in etwa gleichzeitig unternommen werden, sind aber zwei paar Schuhe. Der Entwickler ist für die Entwicklung und die Umsetzung zuständig. Der Entwickler ist in den seltensten Fällen auch ein Designer. Auch gibt es keine „Themes“ oder „Templates“ wie bei Webseiten, sondern wahrscheinlich hast du als Kunde ein gewisses Bild im Kopf wie es aussehen soll. Hier macht es auch Sinn in Kombination mit der Planung abzuschätzen was denn alles im ersten Schritt ein Layout braucht und was nicht. Was kann in einer späteren Version kommen und muss daher jetzt auch nicht für einen Designer bezahlt werden?
Erst mit einem Konzept und einem UI-Layout wird sich ein erfahrener Entwickler trauen eine echte Aussage über die Aufwände und damit verbundenen Entwicklungskosten zu machen. Selbst vermeintliche Kleinigkeiten können plötzlich mehrere Tage Arbeitszeit kosten. Wieder einmal: Kommunikation ist wichtig.
Entwicklung
Erst jetzt geht es in die Entwicklung. Am Anfang kann es sein, dass sich der Fortschritt sehr langsam anfühlt, das ist allerdings normal. Ein guter Entwickler wird sich erstmal Zeit nehmen einige technische Entscheidungen zu fällen, die nach außen wenig sichtbar sind aber auf lange Sicht viele Probleme vermeiden können.
Hier macht es auch Sinn mit dem Entwickler eine Vereinbarung zu treffen wie oft du eine neue Testversion bekommst. Bei kleineren Projekten kann es durchaus legitim sein, wenn er dir nach jedem Arbeitstag eine neue Version baut. Bei größeren Projekte jedoch empfehle ich den Entwickler seine Arbeit machen zu lassen und immer nach Sprintende (also z.B. 2 Wochen) eine Abnahme der erledigten Arbeit zu machen und im Anschluss die kommenden Wochen zu planen.
Je öfter eine Version gebaut wird umso öfter bekommt der Entwickler Feedback. Dieses Feedback einzupflegen kann ihn wieder davon abhalten die Aufgaben zu erledigen zu denen ihr euch ursprünglich geeinigt habt. Die kritische Frage ist ob das Feedback jetzt in diesem Moment unglaublich dringend ist, oder ob es wichtiger ist zuerst die geplanten Aufgaben zu erledigen und dann die gefragten neuen Änderungen vorzunehmen. Fokus ist während der Entwicklung das A und O. Änderungen können später immer nachgezogen werden.
Release
Kurz vor der Veröffentlichung ist nochmal eine heiße Phase. Jetzt geht es darum alles ein letztes Mal durchzuchecken. Findet man Bugs oder Fehler? Sind diese entscheidend oder sollen die Reparaturen nach hinten verschoben werden? Passt das Design überall? Sind alle Texte richtig?
Sind die grünen Häkchen gesetzt, so kann die Version zu Apple bzw. Google eingereicht werden.
Wichtig, vorallem bei iOS und iPadOS Apps:
Apple hat einen App-Review Prozess durch den eine App gehen muss bevor sie veröffentlicht werden kann. Dieser Prozess dauert nach Upload 1 oder 2, manchmal auch 3 Tage. Die App landet nicht sofort im AppStore und man braucht etwas Geduld. Das gilt übrigens auch für alle Updates die man herausbringt.
Ebenso ein Hinweise für die Weihnachtszeit: die Veraltungswebseite für den AppStore ist über die Weihnachts- und Neujahreszeit geschlossen! Jedes Jahr habe ich einen Kunden, der noch vor Weihnachten unbedingt die erste Version oder zumindest ein Update kurz vor knapp raushauen will. Lieber nicht! Im schlimmsten Fall wird die App am 21.12. von Apple freigegeben und am 22.12. machen die Schotten dicht. Hat die App einen noch unentdeckten Bug, so kann er erst am Anfang des neuen Jahres beseitigt werden. Mindestens eine Person wird wirklich, wirklich, kein gutes Weihnachten haben. Wenn ein Release nicht bis Anfang Dezember gelingt, dann lieber die Zeit nehmen um die App noch etwas zu polieren und dann im nächsten Jahr ohne Risiko live gehen.
Wartung
Keine App ist von Anfang an beliebt. Eine App muss weiterentwickelt werden, es werden Fehler gefunden und diese müssen Fehler behoben werden. Das braucht Zeit und man braucht Geduld. Es ist nicht unüblich sondern die Regel, dass eine Software deutlich, wirklich deutlich länger in der Wartungsphase ist als in der Entwicklung. Jetzt wird es interessant und es kommen Faktoren in‘s Spiel, die man vielleicht bei der Entwicklung vernachlässigt hat.
Ein guter Entwickler nimmt sich die Zeit um Software so zu bauen, dass die möglichst leicht wartbar ist. Das heißt, dass möglichst leicht Veränderungen vorgenommen und Bugs behoben werden können.
Wer während der initialen Entwicklung hier und da bei der soliden Basis sparen wollte um „schnell releasen zu können“ wird hier relativ früh in hohe Kosten laufen. Schnelle Lösungen am Anfang des Projektes können dafür sorgen, dass später viel oder komplett umgebaut werden muss um neue Features unterbringen zu können. An dieser Stelle rechnet sich ein guter Entwickler, der früh im Projekt gegen Abkürzungen geraten hat. Ich selber habe z.B. bereits Projekte von anderen Entwicklern übernommen, die nicht mehr zu retten waren. In diesen Fällen mussten wir die Version 2 der App von Grund auf neu bauen. Offensichtlich hat das nur anfänglich Kosten gespart.
Für das Thema Kurzzeit- vs Langzeit-Kosten wird es einen weiteren Artikel geben, da dieses Thema zu komplex und wichtig ist um es so kurz zu behandeln.
Zusammenfassung
Ich hoffe dieser Artikel gibt dir eine gute Übersicht über den groben Verlauf der Entwicklung einer Software, egal ob App oder nicht.
Sieh so ein Projekt an wie ein Puzzle bei dem nur du die Teile sehen kannst aber nur der Entwickler die Teile bewegen darf. Es erfordert viel Kommunikation und Klärung von Fragen. Je besser du dich mit dem Entwickler verstehst umso zügiger und besser geht es voran.
Artikel zum Anhören
Diesen Blogpost gibt es auch als Podcast zum hören:
