Das wichtigste Not-To-Do bei der App-Entwicklung

Wäre es nicht super, wenn du die größte Falle in deinem App-Projekt vermeiden könntest? Dafür habe ich dir diesen Artikel verfasst, mit der wichtigsten Lektion meiner Erfahrung als Entwickler. Es gibt viele Beiträge im Internet zu dem Thema „typische Fehler bei Software-Projekten“ (definitiv eine Google-Suche für dich wert), ich habe jedoch diesen Post absichtlich schlank gefasst, um den Kern der Sache zu treffen. Hast du diesen Punkt im Griff, dann werden dir einige Folgeprobleme nämlich auch nicht über den Weg laufen.

Es fängt nicht im Projekt an, sondern vorher. Sogar vor der Planung mit dem Entwickler. Es ist der erste Moment in dem du dafür sorgen kannst, dass die Wahrscheinlichkeit der folgenden Schwierigkeiten minimiert wird.

Plane erstmal keinen Releasezeitpunkt

Bevor du dir denkst „ja wann dann?“, erst die Gegenfrage: Weißt du wie aufwändig deine App zu entwickeln ist und wie viel Zeit da reinfließen muss? Also kannst du vorweg entscheiden wann die App fertig sein kann? Nein. Klingt doch einleuchtend, was? Interessanterweise ist es für Entwickler nicht ungewöhnlich Projektanfragen zu bekommen in denen nichts wirklich klar ist… außer das Releasedatum.

Ja moment.

Das ist wie zum Architekten zu gehen, um sich ein Haus bauen zu lassen. Man hat noch kein Grundstück gekauft, aber das Einzugsdatum ist schon fix, der Mietvertrag der alten Wohnung gekündigt, Nachmieter organisiert und neue Möbel sind bestellt.

Manchmal gibt es äußere Einflüsse, die ein gewisses Datum rechtfertigen, ja. Meiner Erfahrung nach ist dieses Datum meist selbst gesetzt. „Das Marketing ist schon angelaufen“ heißt es gerne. In der Regel ist dieses Datum auch eher zeitnah und mir müsste erst noch ein Projekt über den Weg laufen, wo ein Releasedatum mit genügend Puffer geplant ist.

Ein Releasedatum ist immer, wirklich immer, ein Kompromiss zwischen „wie viel Zeit nehmen wir uns?“ und „welche Features werden wir entwickeln?“. Es beinhaltet immer beides und wenn eines fertig bestimmt ist, dann befindet sich der gesamte Handlungsspielraum im anderen. Gibt es also Gründe für ein gewisses Datum, dann solltest du darauf vorbereitet sein bei der Planung zu realisieren, dass möglicherweise nicht alles im geplanten Zeitraum machbar ist. Das heißt, wir sind bei der Frage angelangt wie wichtig die einzelnen Teile der App sind und ob eine Teilmenge der Funktionen für den Release genügen.

Das selbe kann natürlich auch während des Projektes passieren.

Verändere nicht einfach den Planungsumfang

Ein Plan ist kein Plan, wenn er andauernd verändert wird. In einem vorherigen Artikel bin ich bereits auf „Feature creeping“ eingegangen und was es verursacht. Feature creeping ist, wenn sich neue Features als Funktionalität in den aktuellen Planungsumfang einschleichen. Meistens passiert das getarnt als tolle neue Idee oder als „kannst du nicht mal kurz/schnell…“. Ein Softwareprojekt lebt. Es werden Fehler gefunden oder der Entwickler findet raus, dass eine Sache doch schwerer zu erledigen ist als gedacht. Der Plan muss flexibel genug sein, um darauf eingehen zu können. Das ist normal und ein guter Entwickler wird dafür sorgen, dass das in der Planung berücksichtigt wird. Ich rede jedoch davon, dass es oft passiert, dass der Umfang verändert und das gesetzte Datum als undiskutabel fix behandelt wird.

Und jetzt zur Frage warum ich die Zeitplanung zuerst genannt habe: weil ein zu straffer Zeitplan dafür sorgt, dass die nächsten beiden Fehler gemacht werden:

  1. Qualitätssicherung überspringen
  2. Benutzertests überspringen

Überspringe weder die Qualitätssicherung als auch Nutzertests

Zuerst sollte ich an dieser Stelle darauf eingehen, was ich damit meine. Qualitätssicherung ist nicht, wenn du dir die App zum Testen installierst und ein paar Mal durchtappst. Qualitätssicherung ist der Versuch als Benutzer die App absichtlich kaputtzumachen. Das heißt: Fehlerfälle testen, unterschiedliche Geräte mit unterschiedlichen Bildschirmgrößen testen, Quatsch in Eingabefelder eingeben, unlogische Benutzungsreihenfolgen ausprobieren, App bei schlechtem oder nicht vorhandener Internetverbindung testen… In größeren Projekten stellt man sogar explizit Leute dafür an den ganzen Tag nichts anderes zu tun.

Genau so mit Nutzertests. Vor allem, wenn die App auch Daten von einem Server beziehen muss: Woher weißt du, dass alles glattgehen wird? Woher weißt du, dass der Server nicht in die Knie geht, wenn zum erfolgreichen Launch gleich ein paar Hundert Leute probieren die App zu benutzen? Ohne Belastungstest springen dir vielleicht Kunden ab, weil sie auf ein unzuverlässiges System gelassen werden, weil die Tests wegen Zeitnot übersprungen wurden.

Ja, dein Projekt mag nicht riesig sein, aber getestet werden muss es trotzdem. Auch Entwickler machen Fehler und diese sollten gefunden werden, bevor der Kunde darauf stößt. Oder vielleicht sind es keine Fehler, sondern die App ist an entscheidenden Stellen zu langsam oder zu kompliziert. Genau so wie ein Autor einen Lektor braucht, so braucht ein Entwickler einen Tester. Genau so wie der Autor seine eigenen Sätze so oft gelesen hat, dass die Tippfehler oder Unklarheiten nicht auffallen, so kann es sein, dass dir und Entwickler Sachen durch die Lappen gehen.

Ist jetzt im Projekt der Zeitplan besonders eng, dann ist es leicht hier ein Auge zu zu drücken und zu tun als ob alles schon gut gehen wird. Ja, du kannst Zeit sparen und in dem Fall solltest du dir bewusst sein, dass du mit dem Feuer spielst.

Dieser Artikel als Podcast-Folge

Meine Artikel kannst du auch einfach als Podcast hören. Direkt diese Folge im Web-Player oder in jeder Podcast-App:

Apple Podcasts: https://podcasts.apple.com/de/podcast/applify/id1489203144
Overcast: https://overcast.fm/itunes1489203144/applify-app-entwicklung-mit-jan-brinker
Spotify: https://open.spotify.com/show/6tVmQfMCZ7VgHU9iZD2VIU
Google Podcasts: https://podcasts.google.com/?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xMDkwMTQ4Yy9wb2RjYXN0L3Jzcw%3D%3D

Hausinterne Apps als Digitalisierungswerkzeug nutzen

Firmeninterne Apps? Ja, das gibt es. Und ja, sie können sehr viel Sinn machen. Genau so wie Firmen ein internes IT-Netz und vielleicht auch eine Art Intranet haben, so können auch Apps rein für firmeninterne Nutzung entwickelt werden.

Hausinterne Apps werden oft im Rahmen der Möglichkeiten übersehen, wenn es darum geht Prozesse zu verbessern. Warum aber? Vor allem, wenn man bedenkt, dass fast jeder Mitarbeiter einen Computer in der Hosentasche herumschleppt und potenziell noch zusätzlich ein rein geschäftliches Smartphone obendrein hat. Warum wird dieses geschäftliche Smartphone wie so oft auf die Erreichbarkeit per Email beschränkt? Warum werden diese technischen Möglichkeiten nicht ausgeschöpft?

Zum Beispiel war ich mal an einer App beschäftigt um die Außendienstler einer Firma zu unterstützen. Die App half bei der Planung des Tages, welche Ziele anzufahren sind und bei der Datenerfassung vor Ort. Wenn man das so liest, ja natürlich macht das eine Menge Sinn als App. Das Handy ist sowieso dabei. Das Handy wird sowieso auch für die Navigation benutzt. Das Handy hat Internet und die zu erfassenden Daten müssen spätestens Abends von handschriftlichen Notizen am Computer eingepflegt werden, also warum nicht direkt per Formular in der App? Macht Sinn, oder?

Oder bei Produktion und Versand in einer Firma. Hier haben wir mal eine Software entwickelt um dafür zu sorgen, dass die Mitarbeiter immer alle wichtigen Informationen zum aktuellen Auftrag auf einem Tablet sehen. Schritt für Schritt aufgeteilt für alle zu fertigenden Produkte, sodass keines vergessen werden kann. Inklusive automatisiertem Ausdruck des Versandetiketts. Kein hin und her mehr zum Schreibtisch und zurück um Details nachzuschauen. Das Tablet ist immer dabei. Keine vergessene Teile mehr. Kein falsches Versandetikett mehr.

Ebenso, macht sehr viel Sinn.

Daher die Frage: was könnte in deinem Unternehmen gleich viel Sinn machen, wenn man es mal gemacht hätte? Was macht man aktuell so, einfach weil man es bisher so gemacht hat? Ist es Zeit darüber nachzudenken, ob es vielleicht bessere Wege gibt?

  • Was sind denn Aufgaben, die besonders viel Zeit kosten? Gibt es Teile davon, die automatisierbar sein könnten?
  • Was sind denn Aufgaben, die besonders oft zu erledigen sind?
  • Was sind denn Aufgaben, die immer exakt dem gleichen Schema folgen?
  • Wie kann man ähnliche Aufgaben besser strukturieren und planen?
  • Gibt es undankbare Aufgaben, die bei der Arbeit so lang von Person zu Person geschoben werden bis sich ein unglücklicher erbarmen muss?

Digitalisierung bedeutet nicht Computer am Arbeitsplatz einzuführen und Emails zu schicken anstatt Briefpost. Es ist herausfinden was denn aktuell verbesserungswürdig ist und wie du die aktuelle Technik nutzen kannst um das zu tun. Und dann, wenn dies passiert ist, die Frage zu wiederholen und zu schauen, ob die neu entwickelte Technik neue Hebel bietet, die du nutzen kannst.

Artikel als Podcast-Folge

Diesen Artikel kannst du auch einfach hören als zu lesen. Hier im Web-Player oder auf allen Podcast-Plattformen:

Apple Podcasts: https://podcasts.apple.com/de/podcast/applify/id1489203144
Overcast: https://overcast.fm/itunes1489203144/applify-app-entwicklung-mit-jan-brinker
Spotify: https://open.spotify.com/show/6tVmQfMCZ7VgHU9iZD2VIU
Google Podcasts: https://podcasts.google.com/?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xMDkwMTQ4Yy9wb2RjYXN0L3Jzcw%3D%3D

Ist deine App eine gute Idee?

Jetzt mal ehrlich. Ist deine App-Idee gut? Ja? Nein? Woher weißt du das? Oder wie findest du es raus?

Es gibt zwei Gründe eine App zu launchen. Zum Beispiel als Hobby. Dann ist es (sagen wir mal) egal, ob die Idee gut ist oder nicht. Es ist dein Hobby und du hast Spaß an der Sache mit der App. Fertig. Vorausgesetzt du kannst den Aufwand oder die Kosten vertreten deine Hobby App in’s Leben zu rufen.

Oder du betrachtest deine App als Business. Als Geschäft. In diesem Artikel werde ich davon ausgehen, dass du damit auch Geld verdienen willst und und wir das Hobby ausschließen können. In dem Fall sind es eigentlich drei Fragen, die hier entscheidend sind:

  1. Ist die Idee als Geschäftsidee an sich gut? Trägt sich die Idee selber? Löst sie ein Problem? Macht sie das Leben bestimmter Leute besser, einfacher, effizienter, schmerzfreier oder einfach schöner?
  2. Ist es eine gute Wahl deine Geschäftsidee als App zu realisieren, oder ist ein anderer Weg doch besser?
  3. Wird die App so umgesetzt, dass am meisten Potenzial der Idee transportiert wird?

Wir reden jetzt über ein Geschäft. Das heißt es muss Geld rein kommen. Geld bekommt man von den Kunden. Kunden zahlen nur, wenn sie das Gefühl haben, dass ihnen das Geld Wert ist.

Ist die Geschäftsidee gut und ist eine App dafür sinnvoll?

Da sich dieser Blog primär um die Umsetzung dreht, gebe ich dir hier einfach nur Anhaltspunkte und Referenzen zu Ressourcen. Zum Thema Validierung von Geschäftsideen ist im Internet mehr als genug Information vorhanden.

  • Fülle ein Business Model Canvas aus: https://www.startplatz.de/startup-wiki/business-model-canvas/
  • Mache eine Konkurrenzanalyse. Wer löst denn sonst dieses Problem? Nicht unbedingt auf die gleiche Art wie du es lösen willst. Sondern wer ist generell an der Lösung von dem Problem beteiligt? Gibt es keine Konkurrenz: gibt es einen Grund dafür? Mangelnde Konkurrenz ist tendenziell ein schlechtes Zeichen!
  • Mache Umfragen
  • Gibt es alternative Wege um das Problem zu lösen ohne eine App zu haben? Vorteile? Nachteile?

Aufwand? Ja. Langweilig? Mag sein, wenn du es oberflächlich angehst. 😉

Hole das meiste Potenzial aus der Idee

Hast du die obigen Schritte gemacht und bist zum Entschluss gekommen, dass eine App wirklich für deine Rahmenbedingungen die beste Wahl ist? Gut. Jetzt wollen wir die bestmögliche Umsetzung erreichen. Nur wie?

Em Ende kommt es auf vier Faktoren an:

  • Die App macht eine Sache und diese wirklich gut
  • Die App macht diese Sache für deine spezifische Zielgruppe besonders gut
  • Die App ist zuverlässig und hat keine Bugs
  • Bonus: Details. Animationen, Mikrointeraktionen, Sounds

Auf die Zuverlässigkeit werde ich nicht eingehen. Eine App hat so zu funktionieren wie erwartet. Bugs sollten gefunden und behoben werden bevor die App an den Kunden geht oder zumindest so schnell wie möglich adressiert werden. Crashes sind ein komplettes no-go. Benutzer haben einen sehr kurzen Geduldsfaden mit Apps und auf die Gnade einer zweiten Chance solltest du dich nicht verlassen.

Mache eine Sache und diese richtig gut

Mehr ist nicht besser. Mehr ist einfach nur mehr. Du hast mehr Features in deiner App? Dann macht sie das nicht unbedingt besser, sondern erstmal voller, überladener und komplizierter zu bedienen. Potenziell mehr Funktionen in der App anzubieten heißt nicht, dass diese Features gut untergebracht sind und Benutzer sie verstehen. Oder vielleicht halten sie Benutzer sogar vom Kern der Sache ab.

Nehme doch mal dein Smartphone in die Hand und schaue die Apps an, die du selber öfter benutzt. Was machst du mit diesen Apps? Was ist das Grundprinzip und was ist letztendlich einfach nur „Zeug drum rum“? Wie schaffen diese Apps den Prozess klar zu halten und den Benutzer zu führen, ihnen zusätzliche Optionen zu geben, ohne vom Kern abzulenken?

Die Verlockung ist groß erstmal so viel wie möglich in die App reinzupacken, weil sich mehr nach besser anfühlt. Das kann aber auch sehr kontraproduktiv sein. Du steckst neue Features in die App bevor du überhaupt weißt wie deine Benutzer die App überhaupt benutzen. Ob sie mit dem Design so klar kommen oder nicht. Ob die Benutzer gut geführt werden, sodass immer klar ist was die nächste wichtige Sache ist. Gibt es mehr Funktionen, so gibt es mehr Ablenkungen auf diesem Weg. Sprich das Problem wird für die Benutzer potentiell schlechter gelöst.

Natürlich können all diese Sachen später noch eingebaut werden, aber viele Apps funktionieren nicht, weil sie den Fokus verloren haben, der nötig wäre um erstmal am Ball zu bleiben. Um die ersten Kunden so richtig zu überzeugen. Um Erfahrungswerte zu sammeln. Um zu sehen was die nächsten wirklich wichtigen Funktionen wären und wie diese wohl am Besten platziert werden.

Anstatt die App zu überladen könntest du zum Beispiel noch daran denken wie die App sich verhalten soll wenn was schief geht. Was passiert z.B., wenn zwischendrin die Internetverbindung abreißt? Es gibt nicht nur den sogenannten „happy path“, wo alles genau so funktioniert wie gedacht. Was kann sonst noch alles dazwischenkommen und wie kannst du dafür sorgen, dass auch in diesen Fällen der Benutzer ein rundes Erlebnis hat?

Mache eine Sache gut. So gut wie möglich. Dann gehe an den Markt. Und dann schaue, wie du mehr Funktion anbieten kannst, indem du Kunden beobachtest und mit ihnen redest.

Deine Zielgruppe und -situation

Das heißt auch, dass du deine Kunden kennen solltest. Also wer genau ist dein Kunde? In welchem Kontext wird denn deine App gebraucht? Daheim auf der Couch? In der Bahn beim Pendeln? Draußen, wenn man zu Fuß unterwegs ist? Auf dem Weg zur Arbeit? Bei der Arbeit? Ist das am Schreibtisch? Oder in einer Werkstatt? Oder sogar im OP-Saal vom Krankenhaus? Auf dem Weg zwischen Terminen? Oder wird die App auf dem Heimweg benutzt? Beim Joggen? In einem Laden? Im Wartezimmer beim Arzt?

Und ist die App wirklich so gebaut, dass sie den Benutzer in dem Kontext auch wirklich abholt und begleitet? Warum ist der Benutzer gerade in der Situation? Warum will er die Sache erledigen, die deine App kann? Wie kann deine App in dieser Situation am Besten helfen? Sind die z.B. Buttons groß genug um in dieser Situation gut getroffen werden zu können? Sind die „Arbeitsschritte“ in der App so wie der Benutzer es wirklich braucht?

Je besser du es verstehst umso besser kannst du auch die Details so zuschneiden, dass sich die Benutzer verstanden fühlen. Beziehungsweise weißt du dann auch wo du am Besten kleine Gimmicks einbauen kannst um den größten Wow-Effekt zu erzielen. Seien es Mikrointeraktionen, schöne Animationen oder Sounds, richtig eingesetzt sorgen sie dafür, dass sich deine Kunden verstanden fühlen.

Bonus. Ja, es ist ein Bonus, nicht essenziell

Also. Animationen sind cool. Schöne Übergänge zwischen den Ansichten sind cool. Mikrointeraktionen machen echt was her. Kleine Bestätigungssounds geben dem Benutzer Feedback und ein gutes Gefühl. Und du kannst in diese Sachen Geld versenken ohne Ende.

Es sind schwarze Löcher für Entwicklungsaufwand. Man kann immer noch was hübscher machen. Aber auch hier heißt hübscher nicht unbedingt besser. Es muss dir als auch den Benutzern klar sein, dass das ein Bonus ist. Erst wenn alles andere solide ist, dann lohnt es sich hier Aufwand reinzustecken. Vorher ist es nichts anderes als der Versuch die fehlende Basis zu kompensieren. Die Benutzer werden es merken und sich fragen warum du den Aufwand denn nicht lieber in die wichtigen Sachen steckst. Begeistern kannst du erst, wenn du nicht nur heiße Luft bietest.

Trotzdem solltest du Aufwand hier rein stecken. Deine App wird sich fluffiger anfühlen. Ich sage jetzt mal, dass die App dadurch lebendiger wird. Dein Job ist dafür zu sorgen, dass eine Balance da ist. Du solltest hier investieren und gleichzeitig die wirklich wichtigen Sachen im Auge behalten.

Zusammenfassung

Die Vorarbeit zu dieser Frage dreht sich also am meisten um generelle Business-Fragen: gibt es überhaupt einen Markt für deine Idee? Und macht es rein logisch überhaupt sinn eine App dafür zu machen, oder gibt es bessere Wege? Erst dann solltest du dir Gedanken machen wie du das dann am Besten als App umsetzt. Hier werden dir auch Entwickler und Designer mit ihren Erfahrungen helfen. Das wichtigste Asset für dich ist jedoch das Verständnis wie der Kunde tickt und wie du ihn glücklich machen kannst.

Höre den Artikel als Podcast-Folge

Diesen Artikel kannst du auch einfach hören als zu lesen. Hier im Web-Player oder auf allen Podcast-Plattformen:

Apple Podcasts: https://podcasts.apple.com/de/podcast/applify/id1489203144
Overcast: https://overcast.fm/itunes1489203144/applify-app-entwicklung-mit-jan-brinker
Spotify: https://open.spotify.com/show/6tVmQfMCZ7VgHU9iZD2VIU
Google Podcasts: https://podcasts.google.com/?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xMDkwMTQ4Yy9wb2RjYXN0L3Jzcw%3D%3D

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:

Apps mit Benutzern testen

Im Artikel „Warum du keine Angst vor dem App Review haben musst“ bin ich ja eingegangen wie du eine App überhaupt an den Kunden bringst. Du lädst die fertig gebaute App auf eine Verwaltungsplattform von Google für den PlayStore und auf AppStoreConnect für den Apple AppStore hoch, trägst die Beschreibungstexte und -bilder ein und gibst die App durch den Review für den Go-Live.

Jetzt willst du die App aber nicht immer direkt an die Kunden raus geben, sondern möchtest sie auch mal an ausgewählten Kunden testen. Und zwar bevor die App öffentlich erhältlich ist.

Aber wie können die Kunden die App installieren? Wie bekommen sie die App zum Testen? Beziehungsweise auch: wie bekommst du selber denn die App zum testen, damit du siehst was der Entwickler so schafft?

Mal wieder: auf Android ist alles einfacher

Mit Android hat man einige Freiheiten. Sowohl bei den Funktionen, die eine App ausführen darf als auch bei der Verteilung und Installation von Apps. Wie im Artikel „Warum du keine Angst vor dem App Review haben musst“ angerissen legt Apple auch einen starken Fokus darauf, dass Benutzer möglichst nur über den AppStore Apps beziehen können. Es darf keine anderen App Store Apps geben. Auf Android ist das anders und dementsprechend könnte man hier Apps einfach per E-Mail an die Tester schicken.

Warum das bei Apple schwieriger ist hat mit einem sehr technisch komplexen Thema zu tun, das auch für Nutzersicherheit relevant ist. Um eine App auf einem iOS-Gerät installieren zu können muss es auf eine bestimmte Art digital signiert sein. D.h. das Handy will bei der Installation sicher gehen, dass die App von einer vertrauenswürdigen Quelle kommt und fälschungssicher „unterschrieben“ wurde. Das sorgt auch dafür, dass es unter iOS z.B. keine gefakten Apps gibt. Trotzdem verursacht es einige Schwierigkeiten, sodass viele Entwickler sich auch nicht gerne mit dem Thema auseinandersetzen und es daher auch nicht verstehen. Die technischen Details würden den Rahmen dieses Artikels sprengen, ich kann jedoch erklären welche Wege es gibt um auch iOS-Apps zu testen.

Testen im kleinsten Kreis

Sind alle Tester bekannt und idealerweise eng an’s Entwicklerteam angeschlossen, so lohnt es sich diese Variante zu nutzen. Der Entwickler braucht hierfür die sogenannten UDIDs („Unique Device Identifier“, also eindeutige Geräte-IDs) aller Geräte mit denen die App getestet werden soll. Das heißt, dass alle Tester die nervige Aufgabe haben ein Mal diese ID herauszufinden und dem Entwickler zukommen zu lassen. Diese UDIDs müssen danach in Apples Entwicklerportal eingetragen werden, damit die App in der digitalen Signatur miteinbezieht welche Geräte die App überhaupt installieren dürfen. Wird man so eine App auf einem anderen und nicht vermerkten Gerät installieren wollen, so wird es einfach eine Fehlermeldung ausspucken. Die Liste mit UDIDs ist auch auf maximal 100 Einträge beschränkt, weswegen wir mit diesem Vorgehen größere Testerkreise direkt ausschließen können. Der Vorteil ist, dass eine App sofort installiert werden kann. Der Nachteil wie gesagt, dass man jeden einzelnen Tester nach seiner Geräte-ID fragen muss.

Die Apps können dann über Beta-Test-Plattformen wie AppCenter von Microsoft oder Firebase von Google verteilt werden. Wird eine neue Version hochgeladen, so bekommen die angemeldeten Tester eine E-Mail und können sich dann die Version herunterladen. So können übrigens auch Android-Apps an deine Tester verteilt werden, ohne, dass du alles manuell per E-Mails machen musst.

Testen im größeren Kreis

Kommt die erste Variante nicht infrage, weil du die Kunden nicht mit technischen Details wie die UDID nerven und ihnen das einfachste Erlebnis bieten willst, so kommt kein Weg um TestFlight vorbei. TestFlight ist ein Tool von Apple mit dem du die App an Tester verteilen kannst. Der Haken ist, dass du nur Apps testen lassen kannst, wenn sie den App Review von Apple bestanden haben. Das heißt eine App kann nicht sofort an deine Tester geschickt werden, sondern du musst wieder mit 1-2 Tagen rechnen bis die App durch den Review ist. Haben deine Tester die App „TestFlight“ installiert, so bekommen sie dann sogar Push-Nachrichten, wenn eine neue Version deiner App zum Testen verfügbar ist. Das heißt: der Nachteil dieser Variante ist, dass die App durch den Review muss und somit 1-2 Tage Wartezeit verbunden sind. Der Vorteil ist, dass deine Tester nur die TestFlight App installieren und auf einen Link von dir klicken müssen. Kein manuelles herausfinden der UDID, weniger Schwierigkeiten mit Zertifikaten und Codesignierung usw. Ebenso können deine Tester direkt via TestFlight Feedback an dich senden.

Zusammenfassung

Unter’m Strich kann man also wieder sagen: Testen ist auf Android leichter zu lösen als auf iOS. Du musst dich entscheiden, on du im kleinen Kreis testen willst und ob deine Tester technisch versiert genug sind um dir die Informationen (Geräte UDIDs) zuschicken zu können, die du brauchst. Ein guter Entwickler wird dich an dieser Stelle auch beraten was für den aktuellen Zeitpunkt die bessere Wahl ist. Ändern kann man das Vorgehen natürlich zu jeder späteren Zeit immernoch.

Podcast Folge zum hören

Diesen Artikel kannst du auch über meinen Podcast anhören. Falls dir mein Podcast gefällt kannst du ihn natürlich auf jeder Podcast-App finden und abonnieren, damit du nie eine Folge verpasst.