Was kostet eine App? Teil 2: Kostenoptimierung & Einflussfaktoren

Übersicht über App-Entwicklungsphasen

Ein kompletter App-Entwicklungsprozess umfasst mehr als nur Design und dessen Umsetzung in Code. Er umfasst verschiedene Phasen und Iterationen, die sich jeweils untereinander beeinflussen. In unserer Betrachtung konzentrieren wir uns auf die Entwicklungsphase selbst als Einflussfaktor auf das Gesamtbudget (siehe Markierung im Bild). Eine klare Übersicht über diesen Teilbereich erlaubt es, die Mittel für jede Phase besser zuzuordnen.

Entwicklungsphasen und ihr Einfluss auf das App-Budget. Beispielprojekt aus Teil 1: Was kostet eine Appentwicklung

Unsere App-Kostenbeispiele aus Teil I verdeutlichen, dass der Preis selbst bei gleichbleibenden Stundensätzen von Projekt zu Projekt sehr unterschiedlich ausfallen kann. Gerade in der ersten Phase des Projektentwicklungszyklus machen die Arbeitsstunden den Hauptteil des Gesamtpreises aus. Die tatsächlich verbrauchte Stundenanzahl der Entwickler:innen wird multipliziert mit einem vorab vereinbarten Stundensatz. Hinzu kommen etwa Maintenance-Kosten, externe Dienste wie Datenspeicherung, Hosting und Wartung.

Hourly-Rate-Rechnung

Ist nun der Stundensatz der beteiligten Vendors (z.B. Projektmanagement, UX/UI Design und IT) das entscheidende Stellrädchen? Ja und nein: Ließe man ein und dieselbe App unter ansonsten gleichen Bedingungen einmal durch einen Konzern mit Sitz im Silicon Valley und einmal mit einen lokalen Mittelständler in Schwaben umsetzen, so ließe sich durchaus einen Preisunterschied feststellen. Doch der Stundensatz ist nicht alles. Die folgenden Variablen nehmen ebenso Einfluss darauf, wie agil und produktiv ein Entwicklungsteam in der Zusammenarbeit sein wird:

• Teamzusammensetzung und -Dynamik (Teamgröße, Aufstellung Inhouse-Entwicklungsteam, Freelancer, IT-Dienstleister...)
• Erfahrung der beteiligten Stakeholder:innen, Designer:innen und Entwickler:innen
• Bestehende agile Workflows im Team (Vertrautheit mit SCRUM-Methoden, Rollenaufteilung, gute Besetzung des:r Product-Owner:in, Stakeholder-Integration)
• Bestehende Entwicklungsumgebung und -Stand (z.B. muss eine bestehende (Backend-)Infrastruktur integriert oder angepasst werden? Wie ausgereift ist das bestehende Testing-Environment? Wie viel Code muss gerefactored werden?)
• Bestehendes UX/UI (wie konkret ist das Konzept? Gibt es Wireframes oder fertige UI-Designentwürfe? Soll das Design maßgefertigt sein oder können Templates verwendet werden?
• Geplanter Funktionsumfang und Featurereichtum
• Plattformanforderungen (iOS, Android) und Benutzeroberflächen (speziell im Bereich IoT), vereinbarte Anforderungen wie Geräte-, Browser-, Accessibilityvorgaben

Diese Variablen beeinflussen die Produktivität bisweilen enorm. Daher ist es sinnvoll, an erster Stelle diese Faktoren unter die Lupe zu nehmen, sie kritisch zu prüfen und immer wieder zu optimieren – vor und während der Entwicklungsphase.

Wie kann man die Entwicklung nun erleichtern und beschleunigen? Wie erreicht man es, schnell in der Lage zu sein, ein nutzungsorientiertes Produkt zu bauen? An dieser Stelle gibt das agile Dreieck einen guten Überblick. Es ist wertvolles Planungsinstrument und visualisiert die Zielvorgaben bei Softwareprojekten.

Das Modell des agilen Dreiecks zeigt die drei Parameter auf, die ein Softwareprojekt und dessen Erfolg bestimmen. Das Projekt wird aufgespannt in ein "Dreieck" zwischen den drei Polen Budget, Terminierung und Featurereichtum/Solidität. Alle drei Größen sind im Softwareprojekt von Interesse. Sie stehen miteinander in einem Zusammenhang und beeinflussen sich durch gegenseitige Trade-Offs. In der agilen Softwareentwicklung werden meist die ersten beiden Pole vorab festgelegt, der variablere Faktor ist die Komponente Featurereichtum/Solidität. Beispiel: Der Kostenrahmen für die Entwicklung eines neuen Prototypen ist gedeckelt und auch das Datum des Go-Lives wird auf ein bestimmtes Datum fixiert. Sind Budget und Zeitrahmen begrenzt, bleibt nur noch eine Ecke aus dem magischen Dreieck übrig – der Featureumfang, der variabel angepasst werden kann. Diese Anpassungsfähigkeit macht ja gerade ein wichtiges Prinzip agiler Arbeit aus: Stimmen alle Voraussetzungen, bleiben Entwicklungsteams und Stakeholder reaktionsfähig, können sich auf Veränderungen einstellen und umso größeren Mehrwert für ihre Nutzer:innen schaffen.

Features, die in der Entwicklung oft aufwändiger sind

Unter Punkt 1 haben wir Abhängigkeitsfaktoren bestimmt, die die Produktivität ganz allgemein beeinflussen: Entwicklungsressourcen, Komplexität der App, Plattform-Constraints etc. Nun nehmen wir speziell den Featureumfang in den Blick. Denn in jeder Aufwandsschätzung können konkrete Features ausgemacht werden, die aus Entwicklungssicht zeitintensiv und daher tendentiell aufwändiger sind. Diese Requirements gehen oftmals mit höherem Aufwand einher:

• Vielschichtige Nutzersysteme und Rollen
• Browserkompatibilität (sollen z.B. noch ältere Safari-Versionen unterstützt werden?)
• Stark individualisierte UI
• Native Entwicklung für jede Plattform
• Internationalisierung/Lokalisierungsvorgaben
• Verpflichtende Integration von unfertigen/legacy APIs (oder solchen, die schlecht dokumentiert sind)

Disclaimer: Diese Liste dient als erste Orientierung. Für jedes der genannten Features gibt es, je nach Anforderung, eine große Bandbreite an Implementierungsmöglichkeiten. Vielleicht sind Ihnen hier auch einige Faktoren aufgefallen, die nicht aufgezählt wurden: Ist es teurer, gerätespezifische Features wie GPS-Tracking mit einzubeziehen? Wie aufwändig sind Details wie Animationen? Wie sieht es mit Performance-Optimierungen aus? Ist eine App, die auf mehreren Plattformen läuft, automatisch mit mehr Kosten verbunden?

In vielen Fällen können Spezifikationen auch überraschend schnell implementiert werden. Für spezialisierte IT-Dienstleister beginnt an dieser Stelle die eigentliche Challenge. Für sie steht immer die Frage im Vordergrund: Wie könnte eine nachhaltige, gut skalierbare Architektur aussehen, die zugleich schnelle Ergebnisse liefert? Wenn Sie wissen möchten, was in Ihrer besonderen Situation am meisten Sinn ergibt, fragen Sie uns gerne unverbindlich nach einer Expert:inneneinschätzung.

Workshops während der Kick-Off-Phase dienen nicht nur der Klärung offener Fragen. Sie können die Implementierung beschleunigen

Jedes Projekt ist einzigartig. Und jedes Setup ist unterschiedlich. Wir würden Ihrem Vorhaben nicht gerecht, wenn wir an dieser Stelle pauschale Ratschläge geben würden. Dennoch gibt es Vorgehensweisen, die sich als gewinnbringend etabliert haben. In unseren Projekten haben sich z.B. während der Kick-Off-Phase MVP-Workshops (Minimum Viable Product) oder Design Sprints bewährt. Beide Ansätze dienen dazu, den Satz Kernfeatures zu definieren, die einen maximalen Mehrwert für Nutzer:innen schaffen. Damit können Softwareprojekte auf gute Beine gestellt und nachhaltig auf Erfolg programmiert werden. Ein Beispiel? Haben Sie ein IT-Beratungsunternehmen zum Partner, werden Sie zusammen in der Kick-Off-Phase u.a. folgende Aspekte gemeinsam auf Herz und Nieren prüfen:

• Zielvorgaben und Deliverables zum Release: Was muss unbedingt in die Version 1.0? Minimum Viable Product zu Testzwecken oder erweiterte Marktreife?
• Teamzusammenstellung und Workflows im agilen Projekt: Wie funktioniert die Zusammenarbeit ganz konkret? Wie "hands-on" können und müssen die beteiligten Stakeholder:innen sein? Gibt es Klärungsbedarf beim Rollenverständnis? Welche Stellen sollten besetzt werden?
• Bestehendes UX/UI: Wie konkret sind User Flows und Wireframes? Wie handfest die User Interface Designs? Soll das Design möglichst maßgefertigt sein oder können Design Libraries verwendet werden?
• Bestehende Entwicklungsumgebung und -Stand: muss eine bestehende (Backend-)Infrastruktur integriert oder angepasst werden? Wie ausgereift ist das Testing-Environment?
• Plattformanforderungen und Benutzeroberflächen (speziell im Bereich IoT), Nebenbedingungen und Constraints: Geräte-, Browser-, Accessibilityvorgaben, Datenschutz etc.
• Stacks, Services und Frameworks: Was wäre ein nachhaltiges, gut skalierbares Ökosystem?
• Einsparmöglichkeiten: Was muss wirklich custom umgesetzt werden, an welcher Stelle können wir ohne Qualitätsabtriche Abkürzungen nehmen?
• Laufende Kosten, Hosting, Services und Lizenzen: Was kostet uns der reine Betrieb im Jahr?
• Zeitplan: Was ist eine realistische Entwicklungszeit? Wie viele Entwickler:innen sind dafür nötig?
• Perspektive für nach der Version 1.0: Wer entwickelt weiter? Wie werden von Anfang an Inhouse-Entwickler:innen mit einbezogen und befähigt?

Ein solider Kick-Off mit Anforderungsworkshops nach Maß holt Stakeholder- und Umsetzer:innen in ein Boot, ermöglicht das Ausloten von Abkürzungen und schafft Tatsachen für gemeinsamen Fokus sowie produktive Kommunikation im Team.

Im Teil II unserer Serie "Was kostet eine App" haben wir versucht zu klären, welche Stellschrauben den Preis für eine App entscheidend beeinflussen. Mit dem Bild des magischen Dreiecks aus dem Bereich des Projektmanagements fiel unser Blick auf den variablen Faktor des Featurerumfangs. Oberste Prämisse für verantwortungsvolle Softwareentwicklung ist die konsequente Ausrichtung auf diejenigen, die auf der anderen Seite des Screens sitzen. So ist nicht zuletzt der für Stakeholder:innen, Entwicklungsteam und Nutzer:innen stimmige Satz an Features oberste Voraussetzung für eine App mit echtem Mehrwert. Mit den richtigen Partnern lassen sich nicht nur die individuellen Kosten quantifizieren. Ist erst der beste Satz an Mindestspezifikationen für Ihre App gefunden, haben Sie die beste Voraussetzung für die schnelle Umsetzung geschaffen.

Lesen Sie weiter: in Teil III verraten die fünf häufigsten Kostentreiber bei der Appentwicklung und wie sie sich vermeiden lassen.