Im Artikel Was kostet eine App? habe ich die größten Kostenfaktoren erklärt. Du hast jetzt eine Baseline: du weißt, was gebaut werden muss. Jetzt geht es darum zu beeinflussen, wie viel Aufwand dabei entsteht. Und Aufwände verursachen Kosten.
Nicht an der falschen Ecke sparen
Die offensichtliche Lösung wäre, sich einen günstigen Entwickler zu holen. Entsteht mehr Aufwand? Nicht so schlimm, wenn der Stundensatz niedrig ist.
Dieser Denkansatz hat mehrere Löcher.
Ja, es gibt gute Entwickler, die auch günstig sind. Aber nicht viele. Ein guter Entwickler kennt seinen Wert. Und es gibt aus gutem Grund das Sprichwort:
Wer denkt, dass es teuer ist mit einem Profi zu arbeiten, der hat noch nie mit einem Amateur gearbeitet.
Kurzfristige Kosteneinsparungen können langfristige Probleme verursachen. Steht ein Projekt nicht auf solider technischer Basis, wird jedes neue Feature schwieriger. Ein neues Feature macht vielleicht ein altes kaputt, der Bugfix erzeugt neue Bugs. (Ja, das ist wirklich so!) Ich habe bereits in mehreren Projekten Feuerwehr gespielt um diese zu retten. Alles andere als günstig für die betroffenen Kunden.
Aber das ist noch nicht mal das Schlimmste. Viel schlimmer ist, was der Gedanke „extra Aufwand ist ja nicht teuer” mit dir anstellt.
Feature Creep
Es fängt klein an. Du hast mitten in der Entwicklung eine Idee, eine „Kleinigkeit” könnte noch anders und viel besser gemacht werden. Der Entwickler baut es um. So teuer war es ja nicht.
Also machst du es wieder. Und wieder. Die Ideen werden größer, spontaner. Diese Kleinigkeiten summieren sich und kosten plötzlich mehr als das gesamte ursprüngliche Projekt. Ja. Das passiert!
Oft!
Das Phänomen hat sogar einen Namen: feature creep oder scope creep. Das Einschleichen von Features in den Planungsumfang. Abgesehen davon, dass es regelmäßig zu Konflikten zwischen Entwickler und Kunde führt, ist es auch schlicht nicht zielführend. Am Ende hat man viele Kleinigkeiten, die (vielleicht) super sind, aber der eigentliche Anwendungsfall für den Kunden ist noch gar nicht fertig abgebildet.
Ein erfahrener Entwickler wird versuchen dich zu bremsen. Wir haben uns alle schon mal an feature creep die Finger verbrannt.
Plane gut und bereite vor
Wenn dir während der Entwicklung ständig neue Wege einfallen, wie du das Kernproblem lösen könntest, und du zwischen Ansätzen hin- und herjagst, anstatt dich für einen zu entscheiden: das ist ein Zeichen für schlechte Vorbereitung. Du hast das Problem nicht gut genug verstanden, deine Kunden nicht genug befragt, deine Lösungsansätze zu wenig „low tech” auf Papier ausprobiert.
Ich weiß, das klingt nach langweiligem Standard-Ratschlag. Und genau weil es langweilig klingt macht es kaum jemand richtig.
So macht man es richtig: Nimm dir Zeit, rede mit deinen Kunden, probiere verschiedene Ansätze aus, bevor du sie in Technik gießt. Fixiere dich nicht auf deine Lieblingsidee, schau was bei den Kunden wirklich ankommt.
Zusätzlich hilft es, wenn du dem Entwickler nicht nur sagst was gebaut werden soll, sondern warum, und wie deine Prozesse wirklich funktionieren. Du bist der Experte in deiner Problemdomäne. Der Entwickler kennt deine Kunden, dein Geschäft, die Regeln dahinter nicht. Das musst du klar vermitteln. Je besser du vorarbeitest, desto weniger Wartezeit und desto weniger Risiko, dass Teile der App später umgebaut werden müssen.
Habe ich bereits in vorherigen Folgen gesagt, dass Kommunikation alles ist?
Klein anfangen
Eine weitere Stellschraube: Was ist das kleinstmögliche sinnvolle Paket, mit dem du starten kannst?
Willst du die App sowohl für iOS als auch für Android — genügt für den Anfang auch erstmal nur eine Plattform? Das sind Abstriche für die erste Zeit. Aber wenn du erst für eine Plattform baust und danach die zweite nachziehst, sparst du dir einigen Aufwand. Bei paralleler Entwicklung beider Plattformen tauchen die gleichen Fragen und Probleme gleichzeitig auf, bei beiden Versionen gleichzeitig. Baust du die zweite Plattform nach, hast du den Weg bereits geebnet. Die zweite Version wird deutlich schneller und günstiger.
Das gilt auch für Features generell. Starte mit einem MVP. Was ist die kleinste sinnvolle App, die du an Kunden rausgeben kannst? Alles andere kann später kommen. Du bekommst früh Feedback, kannst nachsteuern, und falls die Idee nicht zieht, hast du nicht gleich alles verbrannt.
Eine Lektion von Astronauten: Sei eine Null, keine +1
Vor einiger Zeit las ich das Buch „Anleitung zur Schwerelosigkeit” vom kanadischen Astronauten Chris Hadfield. Er beschreibt darin das Konzept, lieber eine „0” zu sein als eine „+1”.
Wir wollen gerne helfen, im guten Licht dastehen. Und dabei blockieren wir manchmal genau die Leute, die eigentlich den Job haben. Das Resultat: wir sind keine Hilfe, sondern eine Bürde.
Sei dir klar, dass du nichts beweisen musst, weder dir noch dem Entwickler. Vor allem nicht, wenn du noch nie in einem Softwareprojekt mitgemacht hast. Frage den Entwickler, was er genau braucht um weiterzumachen. Wenn er das hat, dann lass ihn machen. So wie du einem Handwerker in deiner Wohnung nicht dauernd dazwischenfunkst, muss auch ein Entwickler nicht ständig unterbrochen werden.
Gute neue Mitarbeiter schauen erst zu, beobachten, fragen wo sie wie helfen können, und packen dann mit an, wenn es wirklich hilfreich ist. Das ist die richtige Haltung.
Zusammenfassung
- Günstige Entwickler können dir mehr Kosten verursachen als du sparst.
- Vermeide feature und scope creep konsequent.
- Bereite dich gut vor: rede mit Kunden, teste analog, bevor du in Technik investierst.
- Definiere klare Regeln für deine Prozesse. Regeln sind nur Regeln, wenn sie immer gelten.
- Starte mit einem MVP, beobachte Benutzer, baue dann aus.
- Baue zuerst für eine Plattform und ziehe die zweite nach.
- Sei eine Null: hilf, aber stehe nicht im Weg.