Fünf Dinge, die bei der Entwicklung eines MVP mit knappem Budget zu beachten sind

Ein Mann steht und präsentiert drei sitzenden Kollegen in einem modernen Büro mit Glaswänden und Grünpflanzen Informationen auf einem Bildschirm. An der Wand hinter ihnen ist das Wort „smartive“ zu sehen.

Ein funktionsreiches, gut aussehendes MVP. Ein knappes Budget; nicht unbedingt in Bezug auf Geld, aber ein enger Zeitrahmen. Ein Kunde, mit dem Sie noch nie gearbeitet haben. Eine harte Deadline. Klingt wie ein Projekt aus der Hölle, nicht wahr?

Das dachten wir uns auch, als wir uns kürzlich mit einem potenziellen Kunden unterhielten, der uns seine Gründungsidee vorstellte. Sie hatten eine tolle Geschäftsidee und ein tolles Konzept, aber es fehlte ihnen an technischem Know-how, um es durchzusetzen, also baten sie uns um eine Partnerschaft. Der Haken an der Sache: In vier Wochen hatten sie ihren ersten Pitch mit einem ihrer potenziellen Kunden. Uns gefiel ihre Idee und wir beschlossen, unser Bestes zu tun, um ihnen zu helfen. Im Folgenden erfahren Sie, was in dieser Konstellation gut funktioniert hat und was wir beim nächsten Mal anders machen würden.

Prolog: Der Liefergegenstand

Um diese Geschichte richtig zu stellen, müssen wir beurteilen, was wir eigentlich tun sollten. Wir haben die Backend-Arbeiten komplett weggelassen, da unsere Partner eine arbeiten Frontend-App, die sie ihren potenziellen Kunden präsentieren können. Die App sollte den kompletten Arbeitsablauf ermöglichen, um das endgültige Feature-Set zu präsentieren. Das bedeutete, dass wir eine Menge Data Mocking machten, aber wir mussten nicht auch noch das Backend schreiben, was uns etwas Zeit gab. Wir entschieden uns für React als Stack, konfiguriert von React-App erstellen. Das Ergebnis ist ein einigermaßen intelligenter Prototyp, der zwei Onboarding-Prozesse für Kunden zeigt, die aus etwa 20 Seiten und hochdynamischen Formularen bestehen.

1. Viel und viel Kommunikation

Ein Kunde mit einer Startup-Idee betrachtet Ihr Ergebnis mit anderen Augen als Ihr Firmenkunde seine Unternehmensanwendung. Sie arbeiten an ihrer BabyEs ist ihre Idee, und sie wollen, dass es perfekt ist und genau so, wie sie es sich vorgestellt haben. Mit einem kleinen Budget und wenig Zeit ist die Kommunikation zwischen Ihrem Kunden und Ihrem Team entscheidend. Wir richteten ein einfaches Trello-Board ein, das unsere laufenden Arbeiten und unsere Arbeitsliste anzeigte. Durch tägliche Anrufe hatte unser Kunde volle Transparenz über unsere Arbeitslast und unseren Fortschritt. Dies half ihm, den Aufwand für bestimmte Funktionen zu verstehen und machte es einfacher, Prioritäten zu setzen.

2. Kontinuierliche Lieferung

Bei smartive arbeiten wir intensiv mit GitLab und GitLab CI, so dass wir mit Continuous Integration und Delivery vertraut sind. Das bedeutete, dass wir immer eine funktionierende Anwendung für unsere Kunden hatten, die sie ansehen, testen und ausprobieren konnten. Wir erhielten sofortiges Feedback von ihnen und wussten, für welche Teile der Anwendung wir mehr oder weniger Zeit aufwenden mussten. Die Organisation und Priorisierung ihres Feedbacks in unserer Arbeitswarteschlange war natürlich nicht immer einfach und könnte in anderen Fällen sogar ein Risiko darstellen, aber das ist ein ganz anderes Thema.

Die kontinuierliche Bereitstellung von Software ermöglichte es uns, so schnell zu iterieren, ohne zu viel Zeit für unnötige Funktionen zu verschwenden.

3. Testen nicht vernachlässigen

Sie haben nur vier Wochen Zeit und wollen loslegen und nicht unnötig Zeit mit der Einrichtung eines Test-Frameworks zu verbringen. Unser Team iterierte schnell und mit hoher Geschwindigkeit, was bedeutete, dass Komponenten und Codeeinheiten ständig erweitert, umgeschrieben und entfernt wurden. Das Fehlen von Tests bedeutete, dass wir Fehler und Irrtümer zu spät erkannten - einmal sogar in unserer (für den Kunden öffentlichen) Testumgebung.

Ich bin ein großer Fan von Scherz weil ich glaube, dass sein Slogan "Delightful JavaScript Testing" perfekt passt. Die Einrichtung von Jest hätte uns anfangs fünf Minuten gekostet, und der Zeitaufwand für das Hinzufügen einfacher Snapshot-Tests zu unseren React-Komponenten wäre vernachlässigbar gewesen. Teile unserer App, die durch Code-Änderungen kaputt gehen, wären offensichtlich gewesen, ohne uns viel Zeit zu kosten.

Das Positive daran ist, dass wir daran erinnert wurden, wie wichtig automatisierte Tests sind, seien es Unit-, Integrations- oder sogar Snapshot-Tests.

4. Bleiben Sie bei dem, was Sie wissen

Wir haben die statische Typisierung in JavaScript sehr lieb gewonnen. Unser gesamter Node-Code ist in TypeScript geschrieben (mit express-verbessernden Bibliotheken wie giuseppe) und Flow ist regelmäßig Teil unseres React-Setups.

In letzter Zeit bin ich jedoch ziemlich genervt von Flow's Server, hauptsächlich wegen dieses Thema. Da wir gute Erfahrungen mit TypeScript gemacht haben und der TypeScript + React-Stack offenbar recht stabil geworden ist, haben wir uns für diese Kombination entschieden. Leider ist es nicht so gut gelaufen, wie wir es uns erhofft hatten.

Wir starteten unser Projekt mit create-react-app-typescript denn wir haben recht gute Erfahrungen gemacht mit React-App erstellen (und Anpassungen) in der Vergangenheit. Unsere größten Probleme mit diesem Stack waren (und sind):

  • Das Mischen von TypeScript mit anderen Technologien aus dem Webpack-Ökosystem funktioniert nicht so gut, wie es könnte. CSS-Module müssen z.B. mit verlangen() statt importieren Anweisungen, da das Modulsystem von TypeScript anders funktioniert.
  • Typisierungen durch Dritte sind oft falsch oder veraltet.
  • PropTypes als Typen oder Schnittstellen kommen beim TypeScript-Compiler nicht immer gut an. Der Compiler gibt oft Fehlermeldungen über IntrinsicAttributes & IntrinsicClassAttributes die einen nicht wirklich weiterbringen. Wir haben viel mehr (Verbindung als beliebig)() als ich bereit bin zuzugeben.
  • Fehler von ts-lint und dem TypeScript-Compiler haben uns mehr Zeit gekostet als die Typsicherheit gewonnen hat.

Dies sollte jedoch nicht als TypeScript-Rant interpretiert werden. Wir lieben TypeScript nach wie vor und werden es auch weiterhin täglich verwenden, aber wir würden es uns zweimal überlegen, mit diesem speziellen Stack zu arbeiten.

5. Schnell, nicht schmutzig

Ein knapper Zeitrahmen und die Ausrede, an einem MVP zu arbeiten, könnten Sie dazu verleiten, von Zeit zu Zeit eine Abkürzung zu nehmen. Tun Sie das nicht. Wenn wir gehackt Wenn wir etwas falsch gemacht haben, haben wir den Code in der Regel innerhalb von ein paar Tagen richtig umgeschrieben. Es ist in Ordnung, rechthaberischen Code zu schreiben, man kann ihn aber auch weniger rechthaberisch gestalten, wenn es einen Anwendungsfall gibt, in dem er wiederverwendet werden kann (DRY zählt in einem MVP immer noch). Stellen Sie sicher, dass der Code entkoppelt und kohärent ist und dass Sie wie üblich gute Programmierpraktiken anwenden. Dies wird nicht nur Ihre Probleme in der Anfangsphase des Projekts verringern, sondern Ihnen auch eine solide Grundlage für zukünftige Entwicklungen bieten.

Epilog

Mit einem MVP, das sowohl uns als auch unsere Kunden glücklich macht, würden wir so etwas auf jeden Fall wieder machen. Wir haben gelernt, was es braucht, um in einer Hochgeschwindigkeitsumgebung mit ständigen Änderungsanfragen und Feedbackzyklen voranzukommen. Ein eher formaler Prozess wie schnelle Anwendungsentwicklung (RAD) könnte beim nächsten Mal in Betracht gezogen werden, um Risiken und Ablenkungen noch weiter zu reduzieren. Unserem Team wurde wieder einmal gezeigt, dass hohe Anforderungen an die Codequalität wie Tests und sauberer Code die Zeit und den Aufwand wert sind, unabhängig von der Größe des Projekts.

Geschrieben von
Robert Vogt

Technology|Januar 2017

Weitere Artikel