No início do ano, recebemos um caso interessante. Em duas semanas, fizemos um aplicativo de correio básico com atualizações funcionais sem a necessidade de fazer o upload do build para a loja.
O projeto acabou por ser um MVP clássico, o modelo de implementação é adequado para pequenos projetos b2c e quase todos os projetos b2b. Se você precisa de um aplicativo funcionando em um cronograma apertado, aconselho que preste atenção a esta abordagem. O texto será do interesse dos gerentes de projeto e, provavelmente, não conterá nada anteriormente desconhecido para os programadores.
Um pouco de historia
VkusVill começou a experimentar a entrega online no ano passado. Para tal, foi seleccionada e aprovada uma estratégia de negócio lógica: o desenvolvimento de duas aplicações distintas, para o cliente e para o cobrador / estafeta.
Era conveniente, havia poucos clientes, a carga de aplicativos era pequena: cerca de 100 pedidos por dia, em processo de desenvolvimento - até 1000.
Então começou uma pandemia, o varejo começou a se reorganizar para entrega em todos os lugares. O fluxo de clientes aumentou significativamente, havia um tempo mínimo para mudanças e aprovações - todos perceberam que a implementação existente era ruim e precisava ser mudada com urgência.
Problemas de nossa implementação
- Os aplicativos eram apenas para Android. Mas a pandemia abalou todas as esferas, e correios com iOS começaram a chegar aos serviços de entrega.
- O aplicativo demorou muito para atualizar, por exemplo, depois que recebemos uma análise de sete dias do Google. Era impossível otimizar o produto nessas condições.
Toda a rede dependia do serviço de entrega durante o período de isolamento, então a principal dúvida da equipe era: "O que fazer com os entregadores?" Então decidimos fazer um bot de telegrama. Porque somos bons em bots .
O aumento no número de pedidos confirmou o sucesso do modelo de negócio escolhido. Mas então começamos a nos deparar com as limitações do bot como plataforma. Em particular, o desenvolvimento teve várias tarefas:
- Veja a rota e todos os pedidos em um mapa conveniente
- Esteja vinculado a vários pontos de venda ao mesmo tempo
- Receba informações atualizadas sobre o status dos pedidos
- , . , , , .
- . telegram : 8 .
- “” - , .
Fomos cobertos de flashbacks sobre os problemas com a revisão. Além disso, com uma abordagem padrão para o desenvolvimento, teríamos que passar por todos os estágios de design, design, análise pelo editor de UX, layout e montagem. Estimamos que isso levaria de um a três meses e consumiria recursos do aplicativo principal.
Um fato interessante: em FullStack, quatro heróis estão envolvidos na frente do VkusVilla: 2 para iOS e 2 para Android. Se você quiser fazer companhia a eles, escreva para mim - kafa@automacon.ru.
Início do desenvolvimento
Naquele momento tivemos sorte: encontramos os caras que nos falaram sobre a plataforma sem código Bubble.io. Segundo eles, o aplicativo sobre nossos pedidos poderia ser feito lá em uma semana. Além disso, eles mostraram exatamente como ele poderia funcionar e até passaram no teste para ver se funcionava com nosso back-end complicado.
Para ser honesto, Bubble parecia uma tecnologia bastante rudimentar para mim, em termos de interface de usuário é um sistema um tanto estranho e não responsivo.
Mas, ao conhecê-lo, surgiu uma ideia: usar o princípio da plataforma para criar rapidamente sua própria aplicação. Porque se Bubble pode dar conta dessa tarefa, por que o SPA não pode, por exemplo?
Decidimos escrever uma interface de usuário em ReactJS usando o framework Capacitor . O projeto é montado em um conjunto otimizado e compactado de arquivos que são carregados em um servidor remoto. O capacitor tem acesso às funções nativas, a aplicação é iniciada através de um WebView, onde é especificada a URL com o projeto montado no ReactJS. Seguindo essa lógica, o projeto deveria ser aberto como um site regular com a capacidade de chamar funções nativas. Surpreendentemente, a Apple não tem problema em permitir que uma tecnologia como essa entre em sua app store.
Nós o escrevemos, que passamos para os caras com a competência Bubble e um de nossos programadores React. Parecia bastante primitivo: pegamos um guia de design, pensamos em uma interface de usuário simples e montamos uma frente que realizará todas as funcionalidades do bot.
Cada equipe (se contarmos nosso programador como uma equipe) teve 2 semanas para concluir a tarefa: com base na diretriz, criar de forma independente o aplicativo mais simples e conveniente. Os desenvolvedores tiveram que consultar diretamente o líder do projeto do lado comercial.
Deixe-me enfatizar que abandonamos deliberadamente o design, design e envolvimento de um analista.
Por que havia duas equipes?
Neste caso, o fato de trabalharmos com a VkusVill desempenhou um papel importante. Em sua cultura, o método de duplicação de fornecedores é usado ativamente. Eu estava curioso para ver como a equipe de terceiros do Bubble trabalharia no projeto. Talvez pudéssemos ter adotado alguns truques, técnicas de gestão e recursos de comunicação.
Ao mesmo tempo, não tinha fé incondicional no sucesso do aplicativo com base no construtor, então não queria gastar 2 semanas criando uma solução.
O que aconteceu
Em primeiro lugar, a ideia de paralelizar os comandos acabou sendo muito lógica: a solução de interface sem código de alguma forma não funcionou imediatamente.
Como a tarefa de fazer de acordo com as diretrizes era imediata, a implementação de alguma forma me desmotivou um pouco. Do ponto de vista da resposta, Bubble tem um problema óbvio: tudo é pressionado desajeitadamente, muitas vezes duas vezes. No processo, mais uma dança com pandeiros foi descoberta: a equipe levou mais de 2 dias para substituir os mapas "nativos" do Google por Bubble por Yandex. Mais 1 dia - para fazer a funcionalidade de abertura de roteamento via 2Gis. Ao mesmo tempo, a solução acabou sendo uma muleta: se o 2Gis não estava instalado no aparelho, ainda era oferecido. Em termos de custos de mão de obra, a equipe sem código ganhava um pouco mais de 80 horas (originalmente esse era o limite) enquanto o aplicativo se revelava bruto. Foi o fim da cooperação com eles.
A solução no ReactJS revelou-se muito mais ideal: em primeiro lugar, toda a funcionalidade foi concluída em 67 horas e, em segundo lugar, do ponto de vista das diretrizes e da lógica, tudo funcionou bem: a
publicação no iOS foi um sucesso : não houve perguntas para a revisão, no dia seguinte, o aplicativo estava na loja. Não carregamos o Android para o Play Market, apenas colocamos o .apk no armazenamento em nuvem.
Após o lançamento, todas as vantagens de tal montagem se tornaram tangíveis. O aplicativo não estava pronto para testes completos, e atualizações e melhorias são mais convenientes de fazer sem a necessidade de publicação.
Agora, o aplicativo está funcionando há vários meses, adicionamos muitas funcionalidades, fizemos um bom Kazdev com mensageiros. Todo mundo está feliz.
Poucas conclusões
Surpreendentemente, o desenvolvimento em bubble.io demorou mais e o produto final era mais bruto. A restrição do construtor desempenhou um papel significativo aqui.
No início, ao definir o trabalho técnico, chamei a atenção das equipes para a importância de usar a diretriz com elementos visuais prontos: fontes, ícones, estilo geral, etc. Apesar disso, os caras do Bubble têm uma interface extremamente primitiva. É improvável que o banal "não tive tempo" pudesse ter um papel decisivo, mas o fato é que a plataforma é pouco personalizável. Se alguém puder explicar o motivo, escreva nos comentários.
Pode surpreender a muitos que não conhecíamos essa metodologia e já é amplamente utilizada. Mesmo assim, foi uma revelação para mim e acho que é uma solução muito boa para aplicações corporativas com um número pequeno de usuários. O aplicativo acaba sendo muitas vezes mais conveniente e fundamentalmente diferente da versão adaptativa dos sites, o tempo de implementação é menor do que quando se trabalha com ReactNative ou Flutter, a diferença não é perceptível visualmente.
Para resumir: o projeto parecia um bom desafio para a equipe, e para mim pessoalmente, gerenciá-lo foi uma ótima maneira de quebrar a rotina de design longo, cuidadoso e muito atencioso de "grandes" tarefas.