A principios de año, tenemos un caso interesante. En dos semanas hicimos una aplicación de mensajería básica con actualizaciones funcionales sin la necesidad de subir la compilación a la tienda.
El proyecto resultó ser un MVP clásico, el modelo de implementación es adecuado para pequeños proyectos b2c y casi cualquier proyecto b2b. Si necesita una aplicación que funcione en un horario apretado, le aconsejo que preste atención a este enfoque. El texto será de interés para los jefes de proyecto y, muy probablemente, no habrá nada previamente desconocido para los programadores.
Un poco de historia
VkusVill comenzó a experimentar con la entrega en línea el año pasado. Para ello, se seleccionó y aprobó una lógica estrategia empresarial: el desarrollo de dos aplicaciones diferentes, para el cliente y el cobrador / mensajero.
Era conveniente, había pocos clientes, la descarga de la aplicación era pequeña: alrededor de 100 pedidos por día, en proceso de desarrollo, hasta 1000.
Luego comenzó una pandemia, el comercio minorista comenzó a reorganizarse hacia la entrega en todas partes. El flujo de clientes aumentó significativamente, hubo un mínimo de tiempo para cambios y aprobaciones; todos se dieron cuenta de que la implementación existente era mala y debía cambiarse con urgencia.
Problemas de nuestra implementación
- Las aplicaciones eran solo para Android. Pero la pandemia sacudió todas las esferas y los mensajeros de iOS comenzaron a llegar a los servicios de entrega.
- La aplicación tardó mucho en actualizarse, por ejemplo, una vez que Google la revisó durante siete días. Era imposible optimizar el producto en tales condiciones.
Toda la red dependía del servicio de entrega durante el período de aislamiento, por lo que la principal pregunta a la que se enfrentaba el equipo era: "¿Qué hacer con los mensajeros?" Entonces decidimos hacer un bot de telegramas. Porque somos buenos con los bots .
El aumento en el número de pedidos confirmó el éxito del modelo de negocio elegido. Pero luego comenzamos a encontrarnos con las limitaciones del bot como plataforma. En particular, el desarrollo tuvo varias tareas:
- Vea la ruta y todos los pedidos en un mapa conveniente
- Estar vinculado a varios puntos de venta a la vez
- Reciba información actualizada sobre el estado de los pedidos
- , . , , , .
- . telegram : 8 .
- “” - , .
Estábamos cubiertos de flashbacks sobre los problemas con la revisión. Además, con un enfoque estándar de desarrollo, tendríamos que pasar por todas las etapas de diseño, diseño, análisis por parte del editor de UX, maquetación y montaje. Estimamos que esto tomaría de uno a tres meses y consumiría recursos de la aplicación principal.
Un dato interesante: en FullStack, cuatro héroes están involucrados en el frente de VkusVilla: 2 para iOS y 2 para Android. Si quieres hacerles compañía, escríbeme: kafa@automacon.ru.
Inicio del desarrollo
En ese momento tuvimos suerte: encontramos a los chicos que nos hablaron de la plataforma sin código Bubble.io. Según ellos, la solicitud de nuestras solicitudes podría realizarse allí en una semana. Además, mostraron exactamente cómo podría funcionar e incluso pasaron la prueba de la posibilidad de trabajar con nuestro complicado backend.
Para ser honesto, Bubble me pareció una tecnología bastante tosca, en términos de interfaz de usuario es un sistema algo extraño y no responde.
Pero mientras lo conocía, surgió una idea: utilizar el principio de la plataforma para crear rápidamente su propia aplicación. Porque si Bubble puede hacer frente a esta tarea, ¿por qué no puede SPA, por ejemplo?
Decidimos escribir una interfaz de usuario en ReactJS usando el marco Capacitor . El proyecto se ensambla en un conjunto optimizado y comprimido de archivos que se cargan en un servidor remoto. Capacitor tiene acceso a funciones nativas, la aplicación se lanza a través de un WebView, donde se especifica la URL con el proyecto ensamblado en ReactJS. De acuerdo con esta lógica, el proyecto tenía que abrirse como un sitio regular con la capacidad de llamar a funciones nativas. Sorprendentemente, Apple no tiene ningún problema en permitir que una tecnología como esta entre en su tienda de aplicaciones.
Lo escribimos y se lo pasamos a los chicos con la competencia Bubble y a uno de nuestros programadores de React. Parecía bastante primitivo: tomamos una guía de diseño, pensamos en una interfaz de usuario simple y armamos un frente que llevará a cabo toda la funcionalidad del bot.
Cada equipo (si contamos a nuestro programador como un equipo) tuvo 2 semanas para completar la tarea: de acuerdo con la guía, crear de forma independiente la aplicación más simple y conveniente. Los desarrolladores tuvieron que consultar directamente con el líder del proyecto desde el lado comercial.
Permítanme enfatizar que abandonamos deliberadamente el diseño, el diseño y la participación de un analista.
¿Por qué había dos equipos?
En este caso, el hecho de que trabajemos con VkusVill jugó un papel. En su cultura, se utiliza activamente el método de duplicar proveedores. Tenía curiosidad por ver cómo trabajaría el equipo de Bubble de terceros en el proyecto. Quizás podríamos haber adoptado de ellos algunos trucos, técnicas de gestión y funciones de comunicación.
Al mismo tiempo, no tenía una fe incondicional en el éxito de la aplicación basada en el constructor, por lo que no quería pasar 2 semanas creando una solución.
Qué pasó
En primer lugar, la idea de paralelizar los comandos resultó ser muy lógica: la solución de interfaz sin código de alguna manera no funcionó de inmediato.
Dado que la tarea de hacer de acuerdo con las pautas fue de una vez, la implementación de alguna manera me desmotivó un poco. Desde el punto de vista de la respuesta, Bubble tiene un problema obvio: todo se presiona con torpeza, a menudo dos veces. En el proceso, se descubrió un baile más con panderetas: el equipo tardó más de 2 días en reemplazar los mapas "nativos" de Google para Bubble con Yandex. Otro 1 día - para hacer la funcionalidad de abrir el enrutamiento a través de 2Gis. Al mismo tiempo, la solución resultó ser una muleta: si 2Gis no estaba instalado en el dispositivo, todavía se ofrecía. En términos de costos laborales, el equipo sin código obtuvo un poco más de 80 horas (originalmente este era el límite) mientras que la aplicación resultó ser cruda. Este fue el final de la cooperación con ellos.
La solución en ReactJS resultó ser mucho más óptima: en primer lugar, la funcionalidad completa se completó en 67 horas, y en segundo lugar, desde el punto de vista de las pautas y la lógica, todo resultó bastante funcional: la
publicación en iOS fue un éxito : no hubo preguntas para la revisión, al día siguiente la aplicación estaba en la tienda. No cargamos Android en Play Market, solo colocamos el .apk en el almacenamiento en la nube.
Después del lanzamiento, todas las ventajas de dicho montaje se hicieron tangibles. La aplicación no estaba lista para pruebas completas, y las actualizaciones y mejoras son más convenientes sin la necesidad de publicación.
Ahora la aplicación ha estado funcionando durante varios meses, hemos agregado bastante funcionalidad, hicimos un buen Kazdev con mensajeros. Todos están felices.
Pocas conclusiones
Sorprendentemente, el desarrollo de bubble.io tomó más tiempo y el producto final fue más crudo. La restricción del constructor jugó un papel importante aquí.
Al principio, al establecer la asignación técnica, llamé la atención de los equipos sobre la importancia de usar la guía con elementos visuales prefabricados: fuentes, iconos, estilo general, etc. A pesar de esto, los chicos de Bubble obtuvieron una interfaz extremadamente primitiva. Es poco probable que el banal "no tuve tiempo" pudiera jugar un papel decisivo, más bien, lo cierto es que la plataforma es poco personalizable. Si alguien puede explicar el motivo, escriba los comentarios.
Puede sorprender a muchos que no conociéramos tal metodología y que ya sea ampliamente utilizada. Sin embargo, fue una revelación para mí y creo que es una muy buena solución para aplicaciones corporativas con un número reducido de Usuarios. La aplicación resulta ser muchas veces más conveniente y se diferencia fundamentalmente de la versión adaptativa de los sitios, el tiempo de implementación es más corto que cuando se trabaja con ReactNative o Flutter, la diferencia no se nota visualmente.
En resumen, el proyecto parecía un buen desafío para el equipo, y para mí, personalmente, administrarlo fue una excelente manera de tomar un descanso de la rutina del diseño largo, cuidadoso y muy meditado de tareas "grandes".