Erstellen von MVPs für Startups im Vergleich zu Unternehmenssoftware (Unsere Erfahrung)

Im vergangenen Jahr hatte ich das Glück, zwei mobile Apps für zwei unterschiedliche Kunden in unserem Unternehmen zu entwickeln.

Obwohl die Herausforderungen und die Herangehensweise ähnlicher Natur sind, haben sie sich stark voneinander unterschieden. Ich wollte meine Lernerfahrungen mit Ihnen teilen und einige der Macken und Unterschiede zwischen dem Aufbau eines MVP für ein Startup und einem großen FinTech-Unternehmen herausfinden.

Das Startup

StartUp - Die Herausforderung

Unsere erste Herausforderung für mich und meine Kollegen bestand darin, ein ziemlich kompliziertes MVP für einen der größten Flughäfen in LATAM zu erstellen, das viele bewegliche Elemente enthält, darunter das Abrufen von Flugdaten in Echtzeit, Kartenvisualisierungen von Kaufhäusern und eine personalisierte Empfehlungsengine unter vielen anderen.

Ziel war es, ein echtes, vollständig digitales Erlebnis zu bieten und Passagiere über eine einzige mobile App zu binden, sodass der Benutzer nicht mehr mehrere Apps herunterladen und das Streuengagement der Marke verringern muss.

Großes Unternehmen

ISV - Die Herausforderung

Die zweite Herausforderung, die uns gestellt wurde - und das meine ich bestmöglich -, war für ein großes FinTech-Unternehmen. Es ist eine Finanz-App, bei der mit vielen Funktionen um das Geld der Menschen gearbeitet wird. Es war auch etwas, das mehrere Banken nutzen wollten, also war, wie Sie sich vorstellen können, immer alles sehr ernst und komplex.

Heute möchte ich einen Moment Zeit nehmen, um Ihnen unsere Erfahrungen mitzuteilen, aber hauptsächlich den Unterschied zwischen dem Erstellen eines MVP für ein Startup und dem Erstellen von Enterprise Software ™.

Wir werden es in verschiedene Kategorien aufteilen:

Die Technologien dahinter

Tech Stack

Zweifellos war das Startup in dieser Hinsicht flexibler, es war offen für Vorschläge und wollte unbedingt die neuesten Technologien ausprobieren, auch wenn das Risiko bestand, Produkte in der BETA-Version für die Produktion zu verwenden . Zum Beispiel wollten sie Cloud Firestore verwenden, obwohl es zu dieser Zeit als BETA markiert war.

Die Fintech-Firma war verständlicherweise geschlossener über den Tech-Stack, den wir verwenden würden. Sogar die Pakete, die wir installieren mussten, mussten einen gründlichen Überprüfungsprozess durchlaufen, sowohl von ihrem technischen Team als auch von ihrem Sicherheitsteam. Ganz zu schweigen davon, dass alles, was sie nicht zu 100% besitzen konnten, nicht in Frage kam.

Zusammenspiel

Teamgröße

Ich bin mir immer noch nicht sicher, ob dies von der Art des Produkts abhängt. Ich bin der Meinung, dass dies eher auf den Umfang zurückzuführen ist, aber für das MVP hatten wir ein Team aus 1 Projektmanager, 2 Entwicklern und 1 QS. Es waren keine UX-Mitarbeiter im Team, da der Kunde bereits seine Entwürfe hatte.

Das Team für das Enterprise-Projekt war viel größer, wir hatten 1 Projektmanager, 6 Entwickler, 2 QS- und 2 UX-Experten.

Wie gesagt, es geht eher um den Umfang, das MVP war ein zweimonatiges Projekt, die Enterprise-Software war ein einjähriges Engagement.

Geschwindigkeit

Entwicklungsgeschwindigkeit

Dies ist ein Aspekt, bei dem wir einen großen Unterschied festgestellt haben. Das Startup musste so schnell wie möglich auf den Markt gebracht werden. Daher konzentrierten wir uns jede Woche auf die Bereitstellung neuer Funktionen.

Bei Enterprise Software ™ sieht es anders aus. Wir hatten einen mehrteiligen Prozess zum Freigeben von Code:

  • Wir begannen mit einer Roadmapping-Sitzung, in der wir das gesamte Projekt analysierten und die Funktionen für die einzelnen Releases definierten.
  • Wir haben eine monatliche Veröffentlichung mit 2 Sprints in jeder Veröffentlichung eingerichtet.
  • Nach jedem Sprint gingen die Features an unser QA-Team.
  • Nach der QA-Zertifizierung haben wir einen Installer für das QA-Team des Kunden generiert.
  • Nach der Kunden-QS-Zertifizierung wurden die Funktionen genehmigt und in das Projekt integriert. Oder sie wurden zur Behebung zurückgeschickt.
QA

Qualitätsanalysten

Ich habe im vorigen Punkt ein wenig darüber gesprochen, aber es gab auch einige Unterschiede in der Qualitätssicherung. Für das Startup-Projekt hatte unsere QS beispielsweise mehr Einfluss darauf, wie die Dinge funktionierten und was sie als erfüllte Erwartung ansah.

Für den Enterprise-Kunden hat unser QA-Team die Funktionen zertifiziert. Danach musste das eigene QA-Team die Funktionen zertifizieren, bevor es in die Master-Branche des Projekts integriert werden konnte.

Design

UX / UI

Dies ist ein weiterer Teil, in dem der Prozess VIEL anders verlief. Der Startup-Kunde übergab uns die Entwürfe, um sie umzusetzen, und es war ein weniger strenger Prozess.

Bei unserem Unternehmenskunden war das Design ebenfalls ein mehrstufiger Prozess:

  • Unser UX-Team hat die Designs für das Feature für den nächsten Sprint erstellt.
  • Die Konstruktionsabteilung des Kunden genehmigte die Entwürfe.
  • Der Kunde schickte die genehmigten Entwürfe zum Testen durch den Benutzer.
  • Der Kunde schickte die Entwürfe zurück, um Änderungen basierend auf Benutzertests durchzuführen.
  • Unser UX-Team hat die Änderungen / Korrekturen vorgenommen und die Designs dann an den Kunden zurückgesendet.
Einsatz

Einsatz

Ich denke, das muss mehr mit der Art des Kunden als mit der Art des Projekts zu tun haben, aber es ist erwähnenswert, da die Dinge sehr unterschiedlich waren.

Für unseren Startclient richten wir eine Bereitstellung mit Firebase und Wordpress ein (für den Inhaltsteil der App).

Der Enterprise-Client hatte unterschiedliche Anforderungen, alles wurde mit internen Tools / Plattformen erledigt, wir hatten den Quellcode in unserem VSTS-Konto, aber nur, während wir „in der Entwicklung“ waren.

Sobald wir eine vom Kunden genehmigte Version hatten, haben wir den Quellcode in ihre eigenen Repositorys verschoben, wo sie alles abwickelten.

Das Geldgespräch

Kosten

Wie Sie sich vorstellen können, war das Geldgespräch für beide Kunden sehr unterschiedlich.

Der Startup-Kunde hatte ein Team, das ungefähr 1/3 der Größe des Enterprise-Kunden hatte, was sich stark auf die Kosten auswirkte. Außerdem waren Prozesse und Umfang unterschiedlich.

gewonnene Erkenntnisse

Ich denke, als Unternehmen haben wir aus beiden Projekten die größte Lektion gelernt, wie unterschiedlich unser Ansatz je nach Art des Kunden sein sollte. Tools, Kommunikation, Methodik usw.

Ich persönlich habe gelernt, eine konstantere und flüssigere Kommunikation mit den Kunden aufrechtzuerhalten. Es gab viele Momente, in denen gemeinsame Gespräche uns dabei halfen, große Hindernisse zu überwinden.

Was denkst du, bist du ein Startup, das schnell auf den Markt kommen will? Oder ein etabliertes Unternehmen auf der Suche nach einem technischen Partner?

Zögern Sie nicht, uns zu kontaktieren. Wir würden gerne darüber sprechen, wie wir Ihnen helfen können, auf den Markt zu kommen und dieses Projekt zu verwirklichen.

Wenden Sie sich an mich oder an Yuxi Global - [email protected] -, wenn Sie ähnliche Herausforderungen in Ihrem Unternehmen haben und Hilfe beim Aufbau Ihres nächsten MVP oder digitalen Produkts suchen. Wir lieben eine gute Herausforderung und sind immer auf der Suche nach Wegen, um gemeinsam mit Ihnen Innovationen zu entwickeln.