Anfang des Jahres haben wir einen interessanten Fall bekommen. In zwei Wochen haben wir eine grundlegende Kurieranwendung mit funktionalen Updates erstellt, ohne dass der Build in den Store hochgeladen werden muss.
Das Projekt stellte sich als klassisches MVP heraus. Das Implementierungsmodell eignet sich für kleine B2C- und fast alle B2B-Projekte. Wenn Sie eine funktionierende Anwendung mit einem engen Zeitplan benötigen, empfehle ich Ihnen, diesen Ansatz zu beachten. Der Text wird für Projektmanager von Interesse sein und höchstwahrscheinlich nichts enthalten, was Programmierern bisher unbekannt war.
Ein bisschen Geschichte
VkusVill begann im vergangenen Jahr mit der Online-Lieferung zu experimentieren. Hierzu wurde eine logische Geschäftsstrategie ausgewählt und genehmigt: die Entwicklung von zwei verschiedenen Anwendungen für den Kunden und den Sammler / Kurier.
Es war praktisch, es gab nur wenige Kunden, die Anwendungslast war gering: etwa 100 Bestellungen pro Tag im Entwicklungsprozess - bis zu 1000.
Dann begann eine Pandemie, der Einzelhandel begann sich in Richtung Lieferung überall neu zu organisieren. Der Kundenfluss nahm erheblich zu, es gab ein Minimum an Zeit für Änderungen und Genehmigungen - jeder erkannte, dass die vorhandene Implementierung schlecht war und dringend geändert werden musste.
Probleme unserer Implementierung
- Die Apps waren nur Android. Aber die Pandemie erschütterte alle Bereiche und Kuriere mit iOS kamen zu Lieferservices.
- Die Aktualisierung der Anwendung hat sehr lange gedauert, nachdem wir beispielsweise eine siebentägige Überprüfung durch Google erhalten hatten. Unter diesen Bedingungen war es unmöglich, das Produkt zu optimieren.
Das gesamte Netzwerk war während der Isolationsphase vom Lieferservice abhängig. Die Hauptfrage des Teams lautete daher: "Was tun mit den Kurieren?" Dann haben wir beschlossen, einen Telegramm-Bot zu machen. Weil wir gut in Bots sind .
Die Zunahme der Auftragsbestätigung bestätigte den Erfolg des gewählten Geschäftsmodells. Aber dann stießen wir auf die Grenzen des Bots als Plattform. Insbesondere hatte die Entwicklung mehrere Aufgaben:
- Sehen Sie die Route und alle Bestellungen auf einer praktischen Karte
- An mehrere Verkaufsstellen gleichzeitig gebunden sein
- Erhalten Sie aktuelle Informationen zum Status von Bestellungen
- , . , , , .
- . telegram : 8 .
- “” - , .
Wir wurden mit Rückblenden über die Probleme mit der Überprüfung abgedeckt. Außerdem müssten wir mit einem Standardansatz für die Entwicklung alle Phasen des Entwurfs, des Entwurfs, der Analyse durch den UX-Editor, des Layouts und der Montage durchlaufen. Wir schätzen, dass dies ein bis drei Monate dauern und Ressourcen aus der Hauptanwendung verbrauchen würde.
Eine interessante Tatsache: In FullStack sind vier Helden an der VkusVilla-Front beteiligt: 2 für iOS und 2 für Android. Wenn Sie ihnen Gesellschaft leisten möchten, schreiben Sie mir - kafa@automacon.ru.
Entwicklungsstart
In diesem Moment hatten wir Glück: Wir fanden die Leute, die uns von der No-Code-Plattform Bubble.io erzählten. Demnach könnte der Antrag auf unsere Anfragen dort in einer Woche gestellt werden. Außerdem zeigten sie genau, wie es funktionieren könnte und bestanden sogar den Test, um zu sehen, ob es mit unserem ziemlich kniffligen Backend funktionieren könnte.
Um ehrlich zu sein, schien mir Bubble eine ziemlich grobe Technologie zu sein, in Bezug auf die Benutzeroberfläche ist es ein etwas seltsames und nicht ansprechendes System.
Beim Kennenlernen kam jedoch die Idee auf, das Prinzip der Plattform zu nutzen, um schnell eine eigene Anwendung zu erstellen. Denn wenn Bubble diese Aufgabe bewältigen kann, warum kann SPA dann zum Beispiel nicht?
Wir haben beschlossen, eine Benutzeroberfläche in ReactJS unter Verwendung des Capacitor- Frameworks zu schreiben . Das Projekt wird zu einem optimierten und komprimierten Satz von Dateien zusammengestellt, die auf einen Remote-Server hochgeladen werden. Der Kondensator hat Zugriff auf native Funktionen. Die Anwendung wird über eine WebView gestartet, in der die URL mit dem in ReactJS zusammengestellten Projekt angegeben wird. Nach dieser Logik musste das Projekt als reguläre Site mit der Fähigkeit geöffnet werden, native Funktionen aufzurufen. Überraschenderweise hat Apple kein Problem damit, solche Technologien in seinen App Store zu lassen.
Wir haben es geschrieben, das wir an die Jungs mit der Bubble-Kompetenz und einen unserer React-Programmierer weitergegeben haben. Es sah ziemlich primitiv aus: Wir nehmen einen Designleitfaden, überlegen uns eine einfache Benutzeroberfläche und stellen eine Front zusammen, die alle Funktionen des Bots erfüllt.
Jedes Team (wenn wir unseren Programmierer als Team zählen) hatte 2 Wochen Zeit, um die Aufgabe zu erledigen: Erstellen Sie anhand der Richtlinie unabhängig die einfachste und bequemste Anwendung. Die Entwickler mussten sich direkt mit dem Projektleiter von der Geschäftsseite beraten.
Lassen Sie mich betonen, dass wir das Design, das Design und die Einbeziehung eines Analysten bewusst aufgegeben haben.
Warum gab es zwei Teams?
In diesem Fall spielte die Tatsache, dass wir mit VkusVill arbeiten, eine Rolle. In ihrer Kultur wird die Methode der Vervielfältigung von Lieferanten aktiv angewendet. Ich war gespannt, wie das Bubble-Team von Drittanbietern an dem Projekt arbeiten würde. Vielleicht hätten wir einige Tricks, Managementtechniken und Kommunikationsfunktionen von ihnen übernehmen können.
Gleichzeitig hatte ich kein bedingungsloses Vertrauen in den Erfolg der auf dem Konstruktor basierenden Anwendung, sodass ich nicht zwei Wochen damit verbringen wollte, eine Lösung zu erstellen.
Was ist passiert
Zunächst stellte sich die Idee der Parallelisierung der Befehle als sehr logisch heraus: Die No-Code-Schnittstellenlösung funktionierte irgendwie nicht sofort.
Da die Aufgabe, nach den Richtlinien zu handeln, sofort bestand, hat mich die Implementierung ein wenig demotiviert. Unter dem Gesichtspunkt der Reaktion hat Bubble ein offensichtliches Problem: Alles wird ungeschickt gedrückt, oft zweimal. Dabei wurde ein weiterer Tanz mit Tamburinen entdeckt: Das Team brauchte mehr als 2 Tage, um die "nativen" Google Maps für Bubble durch Yandex zu ersetzen. Noch 1 Tag - um die Funktionalität zum Öffnen des Routings über 2Gis zu nutzen. Gleichzeitig stellte sich heraus, dass es sich bei der Lösung um eine Krücke handelte: Wenn 2Gis nicht auf dem Gerät installiert war, wurde es dennoch angeboten. In Bezug auf die Arbeitskosten erhielt das No-Code-Team etwas mehr als 80 Stunden (ursprünglich war dies das Limit), während sich die Anwendung als roh herausstellte. Dies war das Ende der Zusammenarbeit mit ihnen.
Die Lösung in ReactJS erwies sich als viel optimaler: Erstens war die volle Funktionalität in 67 Stunden abgeschlossen, und zweitens funktionierte aus Sicht der Richtlinien und der Logik alles recht gut: Die
Veröffentlichung auf iOS war erfolgreich : Es gab keine Fragen zur Überprüfung, am nächsten Tag war die Anwendung auf Lager. Wir haben Android nicht in den Play Market hochgeladen, sondern nur die .apk-Datei in den Cloud-Speicher gestellt.
Nach dem Start wurden alle Vorteile einer solchen Baugruppe greifbar. Die Anwendung war nicht für vollständige Tests bereit, und Aktualisierungen und Verbesserungen sind bequemer, ohne dass eine Veröffentlichung erforderlich ist.
Jetzt funktioniert die Anwendung seit mehreren Monaten, wir haben eine Menge Funktionen hinzugefügt und mit Kurieren einen guten Kazdev gemacht. Alle sind glücklich.
Nur wenige Schlussfolgerungen
Überraschenderweise dauerte die Entwicklung auf buble.io länger und das Endprodukt war roher. Die Konstruktorbeschränkung spielte hier eine bedeutende Rolle.
Ganz am Anfang, als ich die technische Aufgabe festlegte, machte ich die Teams darauf aufmerksam, wie wichtig es ist, die Richtlinie mit vorgefertigten visuellen Elementen zu verwenden: Schriftarten, Symbole, allgemeiner Stil usw. Trotzdem haben die Jungs von Bubble eine extrem primitive Oberfläche bekommen. Es ist unwahrscheinlich, dass das Banale "keine Zeit hatte" eine entscheidende Rolle spielen könnte, vielmehr ist die Tatsache, dass die Plattform schlecht anpassbar ist. Wenn jemand den Grund erklären kann, schreiben Sie in die Kommentare.
Es mag viele überraschen, dass wir über eine solche Methodik nichts wussten und bereits weit verbreitet sind. Trotzdem war es eine Offenbarung für mich und ich denke, es ist eine sehr gute Lösung für Unternehmensanwendungen mit einer kleinen Anzahl von Benutzern. Die Anwendung erweist sich als um ein Vielfaches praktischer und unterscheidet sich grundlegend von der adaptiven Version von Sites. Die Implementierungszeit ist kürzer als bei der Arbeit mit ReactNative oder Flutter. Der Unterschied ist visuell nicht erkennbar.
Zusammenfassend: Das Projekt schien eine gute Herausforderung für das Team zu sein, und für mich persönlich war die Verwaltung eine großartige Möglichkeit, eine Pause von der Routine der langen, sorgfältigen und sehr durchdachten Gestaltung "großer" Aufgaben einzulegen.