Ja gut, wir setzen einfach einen Designer dran und gut ist… oder?

Wirklich? Kann der Designer deine Gedanken lesen? Er wird erstmal viele Fragen haben, genau so wie der Entwickler. Um die Zusammenarbeit mit dem Designer etwas zu vereinfachen habe ich eine Übung für dich, die dafür sorgt, dass du mit dem Designer konkrete Vorschläge zu besprechen hast.

Setze 4 Leute an einen Tisch und erzähle ihnen von deiner Idee bis alle ihre Fragen geklärt sind und gebe ihnen folgende Aufgabe:

• Malt die App auf ein Blatt Papier schematisch auf (grob, wirklich nur mit Strichen, nicht verkünsteln).
• Wie sieht die Startseite aus?
• Was passiert wenn ich auf folgenden Button drücke?
• Wie sieht die kommende Seite aus?
• Wie kann ich als Benutzer genau die Sache machen, die ich mit der App machen will?
• Wie sehen die Ansichten auf diesem Weg aus?

Wahrscheinlich hattest du einen Entwurf schon im Kopf wie du dir das Layout vorgestellt hast. Und wahrscheinlich ist dieser Entwurf höchstens Ansatzweise verstreut mal hier und mal da in Ansätzen der gezeichneten Layouts zu erkennen.

Meine Erfahrung sagt, dass keine einzelne Ansicht zwei mal gleich gezeichnet wird. Am Ende hat doch jeder eigene Vorstellungen und Ideen wie eine Sache am Besten dargestellt werden kann und das ist gut so. Das bedeutet nämlich, dass mehr Ideen auf dem Tisch sind und du aussortieren kannst.

Jetzt kannst du die besten Aspekte aus allen Entwürfen zu einem einzigen vereinen. Idealerweise solltest du jetzt noch einen oder mehrere potentielle Benutzer fragen wie sie die App benutzen würden, wenn sie den Entwurf vorgelegt bekommen. Das Feedback kannst du wieder in den Entwurf einfließen lassen.

Kommt ein simpler Entwurf raus, so kann es bereits genug für einen guten Entwickler mit einem Auge für Design sein um zumindest eine brauchbare App zu entwickeln. Ist es komplexer, so rate ich doch den Weg zum erfahrenen Designer. In beiden Fällen hast du konkrete Vorstellungen, die dir unnötiges vor und zurück mit vielen Vorschlägen und Gegenvorschlägen erspart.

Artikel zum Anhören

Diesen Blogpost gibt es auch als Podcast zum hören:

Ein Entwickler ist z.B. kein Designer. Ja das hört sich einleuchtend an, oder?

Interessanterweise kommt es trotzdem oft vor, dass Kunden davon ausgehen, dass der Entwickler das Design macht oder sogar auch Inhalte der App für Benutzer Europaweit in mehreren Sprachen erstellt und pflegt. Für einen Festpreis natürlich.

Aber wie? Mir wurde soeben zum ersten Mal von einem gewissen Problem einer bestimmten Zielgruppe erzählt und ich soll jetzt schon in der Lage sein das alles zu machen? Mal ganz vom Festpreis abgesehen.

Auf meine Rückfrage folgt immer eine kurze Stille am Telefon.

„Achso, stimmt, aber das ist ja ziemlich viel Aufwand, den ich dann habe.“

Ja eben. Darum geht es ja. Eine App ist ein Business, genau wie jedes andere auch. Es braucht für unterschiedliche Aufgaben unterschiedliche Leute und es kostet Aufwand.

Wie soll denn eine einzelne Person alle Bereiche gut abdecken können? Der Designer übernimmt den visuellen Part. Potentiell brauchst du wie bei einem großen Blog Leute, die den Inhalt für dich schreiben. Der Entwickler übernimmt den technischen Part für dich.

Mit technischem Part meine ich, dass er dafür sorgt, dass ein Design in Software gegossen wird. Dass die Benutzeroberfläche an Programmlogik geknüpft wird und in diesem Prozess auch beratend zur Seite steht. Er sorgt dafür, dass verfasst Inhalte in die App geladen werden. Er informiert dich, wenn er widersprüchliche Anforderungen gefunden hat (das passiert nicht selten, auch bei gut geplanten Projekten) oder sich Sachen vielleicht unerwartet als unklar herausstellen. Er wird dafür sorgen, dass die Software gut gebaut ist, d.h. dass sie möglichst leicht wartbar und erweiterbar ist. Er wird dich auch beraten können zu technischen Möglichkeiten, z.B. wenn ein Feature auf mehrere Arten und Weisen gebaut werden können mit unterschiedlichen Aufwänden und Vor- und Nachteilen. Auch ist er in der Regel ein Spezialist darin zu sehen ob eine Sache z.B. auf iOS oder Android gar nicht Konvention ist und ob man bei einer Platform doch lieber einen anderen Weg geht.

In anderen Worten: eine App ist in der Regel ein Geschäft, ein Business. In jedem Business ist es das gleiche: du brauchst jemanden, der dir Inhalte schreibt/aufnimmt/filmt. Du brauchst jemanden, der sich um das Marketing kümmert. Oder um Akquise. Oder, oder. oder. Die Aufgabenverteilung muss klar und sinnvoll sein.

Wir Entwickler mögen vielleicht Sachen bauen können, was sich für andere wie Magie anfühlen mag. Aber wir sind keine Zauberer und können somit auch vieles nicht so gut wie andere. Hier ist es für dich wichtig zu sehen wem du denn solche Aufgaben besser überlässt.

Artikel zum Anhören

Diesen Blogpost gibt es auch als Podcast zum hören:

Das ist wohl die Frage schlechthin, die aktuell bei jedem App-Projekt gefragt wird.

Aber erstmal ein Schritt zurück, damit wir alle verstehen was die Begriffe überhaupt genau bedeuten.

Android und iOS sind grundlegend andere Systeme, genau so wie macOS und Windows. Es ist irgendwie einleuchtend, dass eine iOS App nicht auf einem normalen Windows-PC installiert werden kann oder umgedreht. Ähnlich unterschiedlich sind iOS und Android in ihrer Funktionsweise und wie Apps für die beiden Platformen entwickelt werden. Das heißt, dass man für eine Smartphone-App erstmal zwei Apps entwickeln muss. Einmal die iOS Variante und einmal die für Android.

Da schluckt man, ja. Eine App ist nicht ein Projekt sondern eigentlich zwei. Doppelter Aufwand, doppelte Kosten.

Cross-Platform – Die Lösung?

Es gibt jedoch Ansätze die eine Lösung versprechen. Namentlich „Cross-Platform“ (Entwicklung über mehrere Platformen hinweg) und Hybrid (eine Webseite, die als App verpackt Zugriff auf Geräte-Funktionen wie GPS, Bluetooth etc. hat). Webseiten funktionieren offensichtlich sowohl auf iOS als auch auf Android ohne Unterschied, also ist dies eine beliebte Option eine einzelne App sowohl für iOS als auch für Android tauglich zu machen. Tools für diese zwei Optionen sind zum Beispiel Xamarin und Ionic.

„Ja wunderbar“, magst du dir denken, „das ist die Lösung!“

Der Haken an der Sache

Leider ist dies nicht so einfach. Hybrid-Apps fühlen sich oft nicht so wirklich wie Apps an. Irgendwas schwingt von Webseite im Benutzererlebnis mit. Ebenso sind meine persönlichen Erfahrungen mit Ionic zutiefst getrübt von Problemen mit Inkompatibilität, Unstabilität und mangelhafter Verlässlichkeit. Ein Gefühl, das mir bereits mehrere Male von Kollegen bestätigt wurde.

Ähnlich verhält es sich mit Cross-Platform Frameworks wie Xamarin. In der Theorie eine tolle Idee, in der Praxis stößt man jedoch oft auf Gegebenheiten, die man wieder für iOS auf die eine und für Android auf die andere Weise lösen muss… und schon hat man wieder an einer Stelle den Split. Dann kommt eine weitere Stelle hinzu und dann noch eine… Schnell wächst es zu einem Ungetüm, das wieder nichtmehr ganz so schön wartbar ist und doch wieder an vielen Stellen zwei Projekte verpackt in einem sind. Gewonnen hat man wenig, außer die Abhängigkeit zu einem Framework bei dem man wenig Einfluss hat, wenn mal Sachen nicht so funktionieren wie sie sollen.

Das ist meine Ansicht, die auch von mit mir befreundeten Entwicklern geteilt wird. Natürlich gibt es auch Entwickler die das anders sehen und ja da mag auch Geschmack mit reinspielen.

Unter‘m Strich bleiben folgende Fragen:

• Was ist das Ziel der App?
• Wie lange soll sie „leben“ und weiterentwickelt werden?
• Wie schnell muss sie auf den Markt geworfen werden?
• Kann danach mehr Zeit investiert werden um aus einem Prototypen eine saubere Version 2 zu entwickeln?

Ist der kurzfristige Zeitraum das entscheidende Kriterium so kann es trotz allen Nachteilen sinn machen sich für eine Cross-Platform- oder Hybrid-Lösung zu entscheiden. Aber bitte denke daran, dass, wie so oft, das dauerhafte Festhalten an kurzfristigen Lösungen dafür sorgt, dass nie langfristig geplant wird und man irgendwann in Schwierigkeiten rennt. In der Softwareentwicklung spricht man sogar von „technical debt“, also technischen Schulden, die irgendwann beglichen werden müssen. Irgendwann können diese Schulden so groß sein, dass sich wirtschaftlich eine komplette Neuentwicklung lohnt, selbst wenn die App „nur“ ein Jahr alt ist.

Ist der langfristige Zeitraum das entscheidende Kriterium so empfehle ich dringend eine native Lösung. Auf Dauer wird sich das rechnen und man ist flexibler und freier mit der Entwicklung, da man nicht von Limitierungen der Cross-Platform-Frameworks abhängig ist.

Artikel zum Anhören

Diesen Blogpost gibt es auch als Podcast zum hören:

Ja warum überhaupt?

Das frage ich dich als App-Entwickler. Ja, ich könnte froh sein, dass mehr Kunden mehr Apps wollen und jawohl das wäre mehr Geschäft Für mich.

Aber nein. Ein Entwickler ist eine Person die dich in der Umsetzung eines Software-Projektes berät. Und ein guter Entwickler denkt nach welche Technologie für den Einsatzzweck am meisten Sinn hat. Daher ist diese Frage wichtig.

Was willst du mit der App erreichen?

Gibt es Sachen, die die App können soll, die du mit einer Webseite nicht oder wenn überhaupt nur schwer erreichen kannst? Wenn Kernfunktionen der App einen dieser folgenden Punkte benötigt ist es ein gutes Zeichen, dass der Entwicklungsaufwand einer App gegenüber einer Webseite gerechtfertigt ist:

• Offline arbeiten
• App-Internes Speichern und verwalten von Daten
• Synchronisation der gespeicherten Daten in der App zwischen mehreren Geräten (z.B. iPhone und iPad)
• Empfangen von Push-Nachrichten
• Hintergrundaktivität wie z.B. Runter- & Hochladen von Dateien oder Abspielen von Musik wenn die App geschlossen ist
• Bluetooth
• GPS und Kompass
• Interaktion mit einer der Kameras
• Steuerung des Kamera-Blitzes
• Mikrofon
• Accelerometer (Beschleunigungsmessung, z.B. Schütteln des Smartphones) oder Gyroskop (Bestimmung des Neigungswinkels wie der Benutzer das Gerät hält)
• Zugriff auf Gesundheitsdaten (auf iOS: HealthKit)
• NFC
• Interaktion mit dem Sprachassistenten wie Hey Google und Siri

Ist deine App eine Ausnahme?

Es gibt jedoch auch viele Apps bei denen eigentlich, ganz nüchtern technisch betrachtet, auch keine App nötig gewesen wäre. In diesen Fällen hat man sich bewusst entschieden, dass sich der Entwicklungsaufwand rechnet oder lohnt. Z.B. News Apps fallen in diese Kategorie. Der Benutzer hat keine extra Personalisierung durch einen Login, alle Benutzer bekommen die gleichen Nachrichten angezeigt, die einfach aus dem Internet geladen werden. Keine spektakulären Funktionen, eigentlich würde eine Webseite vollkommen reichen. Hier ist die einzige Daseinsberechtigung der App der gewonnene Komfort. Bist du bereit Geld für diesen Komfort in die Hand zu nehmen?

Ist diese Frage beantwortet, so kann es weiter gehen. Ja, es wäre natürlich möglich eine App zu bauen in der letztendlich nur eine Webseite angezeigt wird. Dann hat der Benutzer ein App-Icon auf dem Homescreen und man hat kaum extra Entwicklungskosten. Jedoch lehnt Apple solche Apps ab und lässt sie (meiner Meinung nach zurecht) nicht in den App Store. Eine App soll sich wie eine App anfühlen. Das ist zumindest der Anspruch auf iOS. Google ist da sehr viel entspannter und auf Android kann man das machen. Die Frage ist natürlich ob eine solche App auch besonders gute Bewertungen bekommt und das ein gutes Licht auf das ganze Unterfangen wirft.

Der kühle Kopf sollte entscheiden

Oft sind Kunden mit einer App-Idee schon sehr darauf fokussiert, dass es eine App werden muss ohne sich um das „ja warum eigentlich?“ gekümmert zu haben. Mein Rat an jeden Kunden ist sich wirklich im gewissen zu sein warum das Investment eine gute Idee ist. Am Ende kostet die Entwicklung Geld. Würdest du gerne extra Geld ausgeben, wenn du wüsstest, dass du es hättest sparen können?

Artikel zum Anhören

Diesen Blogpost gibt es auch als Podcast zum hören:

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: