Wie du Kosten bei der Entwicklung sparen kannst

Im Artikel Was kostet eine App? bin ich bereits darauf eingegangen was denn die größten Kostenfaktoren in einem App-Projekt sind und warum die Frage was eine App generell kostet einfach nicht vorweg beantwortbar ist. Es gab einiges an Denkfutter für dich um überlegen zu können was du überhaupt wirklich brauchst. Somit hast du eine Baseline. An dieser Stelle steht fest was denn alles gebaut werden muss. Jetzt kannst du aber beeinflussen wie viel Aufwand verursacht wird um diese Funktionen zu bauen. Und Aufwände verursachen Kosten. In diesem Artikel gehe ich auf diesen variablen Anteil ein: Welchen Aufwand kannst du potentiell übernehmen um Kosten mit eigenem Einsatz zu sparen?

Die Herausforderung: nicht an der falschen Ecke sparen

Die offensichtliche Lösung wäre natürlich dafür zu sorgen, dass man sich einen günstigen Entwickler holt. Entsteht mehr Aufwand? Kein Problem, so teuer ist der Aufwand ja sowieso nicht.

Dieser Denkansatz hat allerdings mehrere Löcher und ich möchte zuerst darauf eingehen warum dieser Weg nur oberflächlich gut aussieht.

Ja, es gibt gute Entwickler, die auch günstig sind. Aber nicht viele. Ein guter Entwickler kennt in der Regel seinen Wert. Ja, das Kostet. Und gibt es aus gutem Grund das Sprichwort:

Wer denkt, dass es teuer ist mit einem Profi zu arbeiten, der hat noch nie mit einem Amateur gearbeitet.

In anderen Worten: kurzfristige Kosten können dir langfristige Kosten sparen. Kurzfristig gedachte Entscheidungen können dir bereits wenige Monate später Probleme bereiten, wenn Abkürzungen genommen wurden, die viele Folgen mit sich bringen. Ein Merkmal eines guten Entwicklers ist dich genau in solchen Fragen zu beraten und dich vor die Wahl mit den Vor- und Nachteilen zu stellen. Je besser der Entwickler umso besser kann er mit Weitsicht denken und flexible Lösungen bauen.

Steht ein IT-Projekt nicht auf solider technischen Basis, so wird jedes neue Feature schwieriger und schwieriger zum Einbauen. Ein neues Feature wird potentiell alte Features kaputt machen, diese müssen repariert werden und jeder Bugfix kann potentiell wieder neue Bugs erzeugen, vor allem bei schlecht entwickelter Software. (Ja, das ist wirklich so!) Ich selber durfte bereits in mehreren Projekten Feuerwehr spielen um diese zu retten. Ein Unterfangen, dass für die Kunden alles andere als günstig war!

Aber das ist auch nur der oberflächliche Grund. Viel schlimmer ist es was der Gedanke „extra Aufwand ist ja nicht teuer“ mit dir anstellt. Es fängt nämlich mit Kleinigkeiten an. Während der Entwicklung hast du eine Idee, dass man eine „Kleinigkeit“ doch noch anders und ganz viel besser machen kann. Dann änderst du den Plan was entwickelt werden soll. Es ist ja nur eine Kleinigkeit. Und der extra verursachte Aufwand eine bereits gebaute Sache umzubauen… ach. Du hast trotzdem ein gutes Gefühl. So viel teurer wurde es ja jetzt dadurch nicht. Und du hast ein Glücksgefühl, weil die neue coole Idee umgesetzt ist.

Feature creep

Also wirst du es wieder machen. Und wieder. Und jedes Mal werden deine Ideen ein klein wenig größer und oder spontaner. Diese „Kleinigkeiten“ werden sich langsam aufsummieren und plötzlich mehr Kosten verursachen als das gesamte Projekt ursprünglich gekostet hätte. Ja. Das passiert!

Oft!

Ich habe es bereits miterlebt. Das Phänomen tritt so häufig auf, dass es sogar einen Namen hat: feature creep oder scope creep. Also das Einschleichen von Features oder Funktionsumfang.

Abgesehen davon, dass an dieser Stelle regelmäßig Knatsch zwischen Entwickler und Kunde entsteht („Wird das jetzt überhaupt bezahlt?“, „Das ist aber teuer jetzt!“, „Das war ja nicht abgemacht, dass es so teuer wird!“, usw.), ist es ja auch nicht zielführend. Kleinigkeiten können viel ausmachen und Detailarbeit ist wichtig, ja. Aber ohne Priorisierung, ohne „was ist jetzt wirklich für den Endkunden am wichtigsten?“, läufst du in eine Sackgasse. Am Ende hast du eine Ansammlung an vielen Kleinigkeiten, die (vielleicht) super toll sind, aber der Anwendungsfall für den Kunden ist noch nicht fertig abgebildet. Wofür? Ist das sinnvoll? Hat jemand was davon?

Jetzt magst du meinen, dass du ja jetzt davon weißt und somit das einfach nicht machst. Wäre es so einfach das immer im Kopf zu behalten wären viele IT-Projekte nicht gescheitert. Wir sind alle Menschen und in der Situation fühlen sich neue kleine Ideen einfach viel zu verlockend an um sie hinten anzustellen. Es fällt uns Menschen einfach schwer.

Auch hier wieder: ein erfahrener Entwickler kann helfen dich zu bremsen. Er wird es zumindest probieren. Wir Entwickler sind nunmal ein Volk, das sich gerne an Pläne hält und haben uns alle schonmal an feature creep die Finger verbrannt und wollen das gerne für die Zukunft vermeiden.

Plane gut und bereite vor

Das Thema können wir jetzt noch weiterdenken. Wenn du regelmäßig neue Ideen für Details bekommst, dann ist das gut. Dann weißt du wie du in Zukunft die App ausbauen und verbessern kannst. Auch ist es gut, wenn dir neue große Features einfallen. Ein schlechtes Zeichen ist es allerdings, wenn dir immer wieder neue Arten und Weisen einfallen wie du das Kernproblem für deinen Endkunden lösen kannst und zwischen den Ansätzen hinterherjagst anstatt dich für eine Variante zu entscheiden.

Wenn du dich in so einer Situation wiederfindest, dann ist es ein Zeichen dafür, dass du schlecht geplant hast. Dann hast du dich schlecht vorbereitet. Du hast das Problem nicht gut genug verstanden, du hast deine Kunden nicht genug befragt und deine Lösungsansätze zu wenig analog auf Papier und „low tech“ ausprobiert. Du hast keine Prototypen gebaut und getestet.

Ich weiß, das hört sich nach langweiligem Standard-Ratschlag an. Und weil es langweilig ist und man es überall hört macht es kaum jemand richtig.

Also. Wie machst du es richtig? Du nimmst dir Zeit und redest mit deinen Kunden. Du holst sie an Bord. Du probierst deine Lösungsideen aus bevor du sie „in Technik gießt“. Probiere unterschiedliche Ansätze aus. Fixiere nicht auf deine Wunschidee, sondern schaue was am besten bei den Kunden ankommt. Hast du das ausführlich gemacht, dann verursachst du zumindest schonmal keine extra Kosten mehr.

Wie kannst du jetzt noch Kosten sparen? Du kannst dir überlegen und definieren was die genauen Hintergründe und Regeln sind anhand deren die Anwendungsfälle zu behandeln sind. Also z.B. kann es sein, dass es eine Leiste mit Buttons in deiner App gibt und bei jedem dieser Buttons soll eine Ansicht geöffnet werden, die exakt gleich aussieht und funktioniert, nur eben andere Inhalte anzeigt. Eine News-App ist ein gutes Beispiel hierfür. Egal ob man jetzt die Sektion Wirtschaft, Politik oder generell „das Neuste“ auswählt: die resultierende Ansicht ist immer gleich aufgebaut. Nur eben was genau angezeigt wird ist anders. Kannst du Orte in der App finden, die immer nach dem gleichen Schema funktionieren? Dann definiere es explizit. Und beschreibe wie dieses Schema genau funktioniert. Wenn es auch nur einen einzigen Ausnahmefall gibt, dann kannst du dir z.B. überlegen, ob du diesen Button doch lieber wo anders platzierst.

Der Grund? Naja, Programmieren ist das erstellen von Regeln. Also: Wenn x passiert, dann mache y. Und es ist eben einfacher und schneller zu programmieren, wenn man eine generelle Regel hat „wenn x passiert, dann mache y“ als „wenn x passiert und y zutrifft, dann mache z“. Natürlich kann man das bauen. Aber jede Regel, die einen Sonderfall enthält verursacht extra Aufwand und somit Kosten. Wenn es dir wichtig ist, dass diese Sonderregel genau an dieser Stelle so eingebaut ist: gut! Wenn nicht: wie kannst du es anders lösen? Definiere.

Zusätzlich: wenn du dem Entwickler direkt erklären kannst was die Hintergründe sind und wie die Prozesse funktionieren, dann kann der Entwickler direkt überlegen wie das umzusetzen ist. Du sparst den Aufwand der entsteht, wenn sich der Entwickler erstmal darum kümmern muss von dir aktiv zu erfragen wie denn die Prozesse funktionieren. Es geht nicht darum, dass du dem Entwickler sagen sollst was er technisch zu tun hat. Aber du bist der Experte in der Problemdomäne, also kennst du (und nicht der Entwickler) wie deine Kunden ticken, was sie wollen oder auch was die Kniffe oder sogar Legalitäten hinter deinem Geschäft sind. Das musst du dem Entwickler möglichst klar vermitteln, wenn du Aufwand sparen willst.

Ja, das erfordert Arbeit und ja das ist schwer. Dir muss nur klar sein, dass du den Aufwand sowieso haben wirst. Spätestens wenn der Entwickler eine Funktion umsetzen will. Die Frage ist, ob du den Entwickler vorweg mit Informationen versorgst oder nur auf Abruf Informationen lieferst und somit viel Wartezeit erzeugst. Beziehungsweise riskierst du auch, dass der Entwickler Teile deiner App ohne genug Weitsicht entwickelt. Das wiederum kann Kosten zu einem späteren Zeitpunkt erzeugen, wenn diese Teile umgebaut werden müssen.

Habe ich bereits in vorherigen Folgen gesagt, dass Kommunikation alles ist?

Nicht verkünsteln. Klein anfangen. In kleinen Schritten weiterdenken.

Eine Sache, die auch hilft die Kommunikation klar und fokussiert zu halten ist, wenn du dir mit deinem Entwickler klare Ziele steckst.

Was soll bis wann fertig sein?
Was ist erstmal wichtig für den Kunden?
Was kann aufgeschoben werden?
Was ist das kleinste sinnvolle Arbeitspaket?
Wie kann man möglichst früh erste Testversionen haben?

Das Ziel hinter diesen Fragen ist letztendlich mit einem MVP zu starten. Mit der kleinsten sinnvoll nutzbaren App. Das fokussiert euch auf die wichtigen Themen. Alles andere kann später kommen. Aber dein Kunde hat dann was in der Hand. Bonus: du bekommst erstes Feedback von deinen Kunden und kannst früh nachsteuern, wenn die Kunden Änderungswünsche haben.

Zusätzlich, offensichtlich, hast du dann noch nicht so viel Aufwand erzeugt. Sondern nur so viel wie gerade nötig um eine erste Version zu haben. Stellst du hier fest, dass deine App-Idee einfach nicht zieht, dann kannst du froh sein, dass du nicht gleich viel zu weit gedacht hast. Dann hast du dir Aufwand und Kosten gespart.

Wenn dir das noch nicht genug ist, dann kannst du dir zusätzlich die Frage stellen:

Kannst du noch kleiner denken?

Zum Beispiel: ja, vielleicht willst du sowohl die App für Android und iOS haben, aber genügt für die erste Zeit auch erstmal nur eine Plattform? Ja, das sind Abstriche für die erste Zeit. Aber wenn du gewollt bist erst für eine Plattform zu entwickeln und danach für die andere, dann wirst du dir einigen Aufwand sparen können.

Egal wie sehr du dich vorbereitest, am Ende wird es einige Punkte geben, die während der Entwicklung auffallen und anders gemacht werden müssen. Das ist vollkommen normal. Baust du jedoch die iOS und Android Apps parallel, dann kommt man bei beiden Versionen gleichzeitig auf die gleichen Fragen und muss gleichzeitig warten, gleichzeitig Sachen umbauen usw. Entscheidet man sich erstmal für eine einzelne Plattform, so kann man damit für die zweite den Weg ebnen und dann nachziehen. Die zweite Version wird deutlich schneller und somit günstiger entwickelt.

Der geebnete Weg spart dir Kosten

Genau wie bei dem Beispiel zuerst nur eine Plattform zu bauen und die zweite nachzuziehen, kommt es in allen vorherigen Punkten auf den gleichen Kern raus: wie kannst du den Weg ebnen? Kannst du durch Weitsicht Hindernisse erkennen und diese frühzeitig vom Weg entfernen?

Somit kommen wir auch zum letzten Punkt dieses Artikels. Wenn du Hindernisse entfernen willst, dann begibst du dich selber auf und somit auch in den Weg.

Eine Lektion von Astronauten: Probiere eine 0 zu sein, keine +1

Vor einiger Zeit las ich das Buch „Anleitung zur Schwerelosigkeit“ vom kanadischen Astronauten Chris Hadfield und bin über diese Aussage gestolpert.

Wir Menschen wollen doch gerne in einem guten Licht da stehen. Dabei werden wir auch gerne vom Eifer erfasst und probieren eine „+1“ zu sein. Eine Person, die mit ihrem Handeln Gewinn bringt. Leider passiert es oft, dass wir damit die Leute blockieren, die eigentlich den Job haben, das zu tun, was wir erleichtern wollen. Das Resultat: wir sind keine Hilfe sondern eine Bürde, eine „-1“.

Was dann? Sei dir im Klaren, dass du nichts beweisen musst, weder dir selber noch dem Entwickler. Gerade in neuen Situationen für dich. Wenn du noch nie in einem Softwareprojekt beteiligt warst, dann ist das doch vollkommen ok. Mache dich erstmal mit der Situation vertraut und halte dich an deinen Experten (deinen Entwickler) und frage ihn was er genau braucht um weitermachen zu können. Wenn er das dann hat, dann kannst du ihn getrost machen lassen. Fordere ihn dazu auf sich bei dir zu melden, wenn er findet, dass du bei etwas helfen könntest um Aufwand zu sparen. Ansonsten: lass ihn machen.

Genau so wie du einen Handwerker in deinem Haus dazwischenfunkst brauchst du auch nicht deinem Entwickler ein Hindernis sein. Halte dir mal zum Beispiel vor Augen wie sich gute neue Angestellte bei deiner Arbeit verhalten. Sind sie voller Tatendrang und probieren erstmal krampfhaft überall mitzumischen und sind der Meinung zu allem eine bessere Lösung zu haben? Oder schauen sie zu, beobachten, fragen wo sie wie helfen können und packen dann mit an, wenn es überhaupt hilfreich ist? Die erste Verhaltensweise wird recht schnell auf den Keks gehen, weil diese Person im Übereifer erstmal übersieht, dass bestehende und noch unbekannte Prozesse einen Sinn haben. Es folgen unnötige Diskussionen, Erklärungen, sich gegenseitig im Weg stehen und Frustration.

Die Alternative ist niemandem etwas beweisen zu müssen und zu helfen, wenn es sinnvoll ist.

Zusammenfassung

Um alles nochmal auf einen Punkt zu bringen habe ich nochmal alle Aspekte für dich zusammengefasst:

Unerfahrene Entwickler können dir mehr Kosten verursachen als du sparst.
Kurzfristig gedachte Kosteneinsparungen können wir auf lange Sicht Kosten verursachen.
Vermeide Feature und Scope Creeping
Plane gut und bereite vor
Probiere Regeln zu definieren wie deine Prozesse zu funktionieren haben. Merke: Regeln sind nur Regeln, wenn sie immer gelten!
Starte klein, MVP zuerst. Dann Benutzer beobachten. Dann ausbauen.
Baue die App zuerst für nur eine Plattform und ziehe die andere nach. Z.B. erst iOS und dann Android.
Überlege dir wie du den Weg für die Entwicklung ebnen kannst. Halte Rücksprache dazu mit den involvierten Personen.
Mantra von Chris Hadfield: Sei eine Null. Du musst zu Beginn nichts beweisen. Hilf, aber stehe nicht im Weg.

Artikel als Podcastfolge

Diesen Artikel gibt es auch vertont als Podcast-Folge auf allen großen Podcast-Plattformen und direkt hier im Web-Player: