Au début de l'année, nous avons eu un cas intéressant. En deux semaines, nous avons créé une application de messagerie de base avec des mises à jour fonctionnelles sans avoir besoin de télécharger la version dans le magasin.
Le projet s'est avéré être un MVP classique, le modèle d'implémentation convient aux petits projets b2c et à presque tous les projets b2b. Si vous avez besoin d'une application fonctionnant sur un calendrier serré, je vous conseille de faire attention à cette approche. Le texte intéressera les chefs de projet et, très probablement, il ne contiendra rien auparavant inconnu des programmeurs.
Un peu d'histoire
VkusVill a commencé à expérimenter la livraison en ligne l'année dernière. Pour cela, une stratégie commerciale logique a été choisie et approuvée: le développement de deux applications différentes, pour le client et le collecteur / coursier.
C'était pratique, il y avait peu de clients, la charge applicative était faible: environ 100 commandes par jour, en cours de développement - jusqu'à 1000.
Puis une pandémie a commencé, le commerce de détail a commencé à se réorganiser pour livrer partout. Le flux client a augmenté de manière significative, il y avait un minimum de temps pour les changements et les approbations - tout le monde s'est rendu compte que l'implémentation existante était mauvaise et devait être modifiée de toute urgence.
Problèmes de notre mise en œuvre
- Les applications étaient uniquement Android. Mais la pandémie a secoué toutes les sphères, et les coursiers avec iOS ont commencé à venir aux services de livraison.
- La mise à jour de l'application a pris beaucoup de temps, par exemple, une fois que nous avons obtenu un examen de sept jours de la part de Google. Il était impossible d'optimiser le produit dans ces conditions.
L'ensemble du réseau dépendait du service de livraison pendant la période d'isolement, de sorte que la principale question à laquelle l'équipe était confrontée était: "Que faire des courriers?" Ensuite, nous avons décidé de créer un robot de télégramme. Parce que nous sommes bons en bots .
L'augmentation du nombre de commandes a confirmé le succès du modèle économique choisi. Mais ensuite, nous avons commencé à nous heurter aux limites du bot en tant que plate-forme. En particulier, le développement avait plusieurs tâches:
- Voir l'itinéraire et toutes les commandes sur une carte pratique
- Être lié à plusieurs points de vente à la fois
- Recevez des informations à jour sur l'état des commandes
- , . , , , .
- . telegram : 8 .
- “” - , .
Nous avons été couverts de flashbacks sur les problèmes liés à l'examen. De plus, avec une approche standard du développement, nous devions passer par toutes les étapes de conception, de conception, d'analyse par l'éditeur UX, de mise en page et d'assemblage. Nous estimons que cela prendrait un à trois mois et consommerait les ressources de l'application principale.
Un fait intéressant: dans FullStack, quatre héros sont impliqués dans le front de VkusVilla: 2 pour iOS et 2 pour Android. Si vous voulez leur tenir compagnie, écrivez-moi - kafa@automacon.ru.
Début du développement
À ce moment-là, nous avons eu de la chance: nous avons trouvé les gars qui nous ont parlé de la plate-forme sans code Bubble.io. Selon eux, l'application sur nos demandes pourrait y être faite en une semaine. De plus, ils ont montré exactement comment cela pouvait fonctionner et ont même réussi le test pour voir si cela pouvait fonctionner avec notre backend plutôt délicat.
Pour être honnête, Bubble m'a semblé être une technologie assez rudimentaire, en termes d'interface utilisateur, c'est un système un peu étrange et peu réactif.
Mais en apprenant à le connaître, une idée est venue: utiliser le principe de la plateforme pour créer rapidement sa propre application. Parce que si Bubble peut faire face à cette tâche, alors pourquoi SPA, par exemple?
Nous avons décidé d'écrire une interface utilisateur dans ReactJS en utilisant le framework Capacitor . Le projet est assemblé dans un ensemble optimisé et compressé de fichiers qui sont téléchargés sur un serveur distant. Capacitor a accès aux fonctions natives, l'application est lancée via une WebView, où l'URL avec le projet assemblé dans ReactJS est spécifiée. Selon cette logique, le projet devait s'ouvrir comme un site régulier avec la possibilité d'appeler des fonctions natives. Étonnamment, Apple n'a aucun problème à laisser une technologie comme celle-ci dans son App Store.
Nous l'avons écrit, que nous avons transmis aux gars avec la compétence Bubble et à l'un de nos programmeurs React. Cela avait l'air plutôt primitif: nous prenons un guide de conception, réfléchissons à une interface utilisateur simple et mettons en place une façade qui exécutera toutes les fonctionnalités du bot.
Chaque équipe (si nous comptons notre programmeur comme une équipe) avait 2 semaines pour terminer la tâche: en fonction de la directive, créer indépendamment l'application la plus simple et la plus pratique. Les développeurs ont dû consulter directement le chef de projet du côté commercial.
Permettez-moi de souligner que nous avons délibérément abandonné la conception, la conception et l'implication d'un analyste.
Pourquoi y avait-il deux équipes?
Dans ce cas, le fait que nous travaillions avec VkusVill a joué un rôle. Dans leur culture, la méthode de duplication des fournisseurs est activement utilisée. J'étais curieux de voir comment l'équipe tierce de Bubble travaillerait sur le projet. Peut-être aurions-nous pu en adopter quelques astuces, techniques de gestion et fonctionnalités de communication.
En même temps, je n'avais pas une foi inconditionnelle dans le succès de l'application basée sur le constructeur, donc je ne voulais pas passer 2 semaines à créer une solution.
Qu'est-il arrivé
Tout d'abord, l'idée de paralléliser les commandes s'est avérée très logique: la solution d'interface sans code n'a pas fonctionné tout de suite.
Puisque la tâche de faire selon les directives était à la fois, la mise en œuvre m'a en quelque sorte démotivé un peu. Du point de vue de la réponse, Bubble a un problème évident: tout est pressé maladroitement, souvent deux fois. Dans le processus, une autre danse avec des tambourins a été découverte: il a fallu plus de 2 jours à l'équipe pour remplacer les cartes Google "natives" de Bubble par Yandex. Un autre jour - pour rendre la fonctionnalité d'ouverture de routage via 2Gis. Dans le même temps, la solution s'est avérée être une béquille: si 2Gis n'était pas installé sur l'appareil, il était toujours proposé. En termes de coûts de main-d'œuvre, l'équipe sans code a eu un peu plus de 80 heures (à l'origine, c'était la limite) alors que l'application s'est avérée brute. C'était la fin de la coopération avec eux.
La solution dans ReactJS s'est avérée beaucoup plus optimale: d'une part, la fonctionnalité complète a été achevée en 67 heures, et d'autre part, du point de vue des lignes directrices et de la logique, tout s'est avéré assez fonctionnel: la
publication sur iOS a réussi : il n'y avait pas de questions pour l'examen, le lendemain, l'application était en magasin. Nous n'avons pas téléchargé Android sur le Play Market, nous avons simplement placé le .apk dans le stockage cloud.
Après le lancement, tous les avantages d'un tel assemblage sont devenus tangibles. L'application n'était pas prête pour des tests complets, et les mises à jour et améliorations sont plus pratiques à faire sans la nécessité de la publication.
Maintenant que l'application fonctionne depuis plusieurs mois, nous avons ajouté pas mal de fonctionnalités, fait un bon Kazdev avec des courriers. Tout le monde est content.
Peu de conclusions
Étonnamment, le développement sur bubble.io a pris plus de temps et le produit final était plus brut. La contrainte constructeur a ici joué un rôle important.
Au tout début, lors de la définition de la mission technique, j'ai attiré l'attention des équipes sur l'importance d'utiliser le guide avec des éléments visuels prêts à l'emploi: polices, icônes, style général, etc. Malgré cela, les gars de Bubble ont une interface extrêmement primitive. Il est peu probable que le banal "n'ait pas eu le temps" puisse jouer un rôle décisif, mais le fait est que la plateforme est mal personnalisable. Si quelqu'un peut expliquer la raison, écrivez dans les commentaires.
Cela peut en surprendre beaucoup que nous ne connaissions pas une telle méthodologie et qu'elle soit déjà largement utilisée. Néanmoins, ce fut une révélation pour moi et je pense que c'est une très bonne solution pour les applications d'entreprise avec un petit nombre d'utilisateurs. L'application s'avère plusieurs fois plus pratique et diffère fondamentalement de la version adaptative des sites, le temps de mise en œuvre est plus court que lorsque vous travaillez avec ReactNative ou Flutter, la différence n'est pas perceptible visuellement.
Pour résumer: le projet a semblé être un bon défi pour l'équipe, et pour moi personnellement, le gérer était un excellent moyen de rompre avec la routine de conception longue, minutieuse et très réfléchie de «grandes» tâches.