Squad 10 | Sobre uma jornada

Artigo feito por Matheus Palinkas, Adriana Penha e Gusthavo Rodrigues, Desenvolvedores do Squad 10 no Programa de Formação

Entre os dias 21 de maio e 16 de julho, participamos da última etapa do Programa de Formação do Grupo FCamara. Foi uma experiência incrível de muito crescimento e aprendizagem, portanto resolvemos contar um pouco dessa nossa jornada.

O início

A última etapa do Programa de Formação foi adaptada em função da pandemia, sendo a distância para atender nesse momento de crise. Então foi criado um canal no “Discord”, uma plataforma de comunicação online, onde foram inseridos os participantes dessa edição. Após uma reunião, fomos divididos em “Squads” com o objetivo de desenvolver uma melhor organização, além de nós apresentarem o problema para o qual deveríamos desenvolver uma solução. A seguir, o case que nos foi apresentado:

“Atualmente, só ouvimos falar sobre o trabalho remoto, suas vantagens, buscas por novos profissionais e até mesmo novos clientes. Mas existe o outro lado da moeda: algumas áreas profissionais possuem uma maior dificuldade para se adaptar a esse novo estilo de vida, o que resulta em pessoas perdendo seus empregos, empresas perdendo lucro pela quebra de contrato etc. Qual a solução você daria para amenizar ou até melhorar essa situação?”

Partindo deste case, realizamos um “brainstorming” (“chuva de ideias” em tradução livre) com toda a equipe e, juntamente com nossas ideias prévias, realizamos uma pesquisa. A partir do resultado desta, concluímos que um dos ramos mais afetados pela COVID-19 foram os pequenos negócios, portanto propusemos um foco especial nesse público a fim de proporcionar uma solução; nasce, portanto, nosso projeto, este que visa ajudar os microempreendedores e autônomos, buscando ser um intermediário entre cliente e vendedor.

---

Hora de codar!

Fomos orientados a dividir as tarefas em “sprints” com a duração de uma semana, onde definiríamos as tarefas (backlog) no início da semana, e elas eram entregues na semana seguinte. Além dessa organização, nossa Squad também optou por realizar três encontros semanais com a equipe para sanar eventuais dúvidas e observar o andamento da sprint. Mesmo com todas as dificuldades encontradas durante o desenvolvimento, ter todas as divisões em sprints com tarefas ajudou a entregar o backlog no início da semana, além de criar uma proximidade entre os integrantes da equipe.

Tal proximidade foi essencial para enfrentar futuras adversidades, como por exemplo a perda de membros da Squad (um dev e uma ux). A partir da perda desses membros, foi necessária uma redistribuição de tarefas e uma readaptação por parte dos programadores em diferentes partes do desenvolvimento, tirando a equipe da zona de conforto e agregando conhecimento.

Conversando com usuários e ex-usuários de serviços semelhantes, como ifood, uber eats e happi, procuramos entender o porquê de potenciais usuários não utilizarem esses serviços e, os que utilizam, o que poderia ser melhorado para os microempreendedores e autônomos no atual momento de crise, e a partir de todas as informações coletadas buscarmos uma solução.

As reclamações mais recorrentes foram sobre os seguintes itens:

• Acessibilidade, os serviços se apresentavam pouco acessíveis para pessoas de idade avançada e/ou não adeptas à tecnologia;
• Taxas abusivas, como por pedido e por mensalidade, além de que apresentar demora no recebimento;
• Necessário possuir CNPJ para se cadastrar nesses serviços;
• Falta gerenciamento de estoque, falta de um módulo para gerenciar quantidade de produtos;
• Falta de suporte aos anunciantes, sendo comum o caso de pedidos falsos onde quem fica com prejuízo é o anunciante na maioria das vezes.

Com base nas reclamações, foram pensadas as seguintes funcionalidades visando resolução do problema:

• Um sistema de avaliação do cliente, assim os comerciantes poderiam avaliar os mesmos e vice-versa; com base na nota, os outros comerciantes podem avaliar e decidir se vão ou não aceitar o pedido;
• CNPJ não obrigatório. Um comércio pode se cadastrar no serviço, mas, se assim desejar, é direcionado para uma página com as informações necessárias de como adquirir o CNPJ, seus benefícios e taxas;
• Módulo para gerenciar estoque de produtos, onde é possível controlar a quantidade de itens de determinada mercadoria;
• Apenas uma taxa mensal com base nas vendas para manter a aplicação.

A partir dessas informações, começamos a dar forma ao sistema e, com a orientação dos consultores da FCamara, fizemos uma aplicação e decidimos regras de negócio. Após isso, foi feito um Wireframe e um Styleguid a fim de termos um esboço.

E então começamos a fazer o que amamos: codar :).

Backend

Estruturamos o projeto em duas partes, sendo o backend uma api rest consumida por um frontend responsiva em um framework de JavaScript. Para o backend a escolha foi em cima das linguagens em comum que os desenvolvedores da Squad tiveram contato, estávamos entre Java e C#, decidimos por Java e o projeto foi desenvolvido em Spring Boot, banco de dados MongoDB e a documentação com Swagger e Insomnia.

Foi a primeira experiência com banco não relacional e, com ajuda dos desenvolvedores da FCamara, cursos e pesquisas, conseguimos trabalhar sem grandes problemas. A escolha do Mongo foi em função da facilidade de alocá-lo em nuvem, com o uso do MongoDBAtlas e o gerenciamento utilizando o MongoDB Compass.

A linguagem Java ainda é muito utilizada, estava presente nos projetos da faculdade e/ou projetos pessoais que acompanhavam os estudos. Acreditávamos ter uma boa base e, para facilitar o desenvolvimento, utilizamos Spring Boot. O projeto foi gerado pelo spring.io com as dependências necessárias para o desenvolvimento inicial.

Iniciamos com CRUD e o projeto foi crescendo, as classes separadas e organizadas de acordo com suas responsabilidades, regras iam sendo adicionadas a cada sprint até a última semana, que ficou para os ajustes e toques finais para entrega do MVP do projeto.

Frontend

Para o frontend escolhemos usar React pela familiaridade da equipe e por essa biblioteca permitir a componentização dos elementos, facilitando assim o reaproveitamento de código.

Tivemos uma experiencia bem fluida com o React, partido na separação da interface em componentes menores, como menu, cads, buttons entre outros. Após isso, partimos para criação das páginas, o que foi bem mais rápido em função de usarmos os componentes já criados, e, conforme o desenvolvimento foi acontecendo, foram surgindo novas necessidades, tal como a validação de dados de formulário. Para tal, usamos o yup, que é uma biblioteca para validação muito utilizada com React, junto ao formik uma biblioteca de react que traz componentes de formulário com os states já encapsulados.

Também foi necessário usar uma biblioteca para gerenciamento de estado e escolhemos o Redux a fim de manter um state global com os dados do login, pois ele era usado em diversos pontos da nossa interface, além ter sido usado para manter os itens em um carrinho de compras.

A integração do front com o back ocorreu na etapa final do desenvolvimento usando uma biblioteca para chamadas assíncronas denominada “axios”.

Conclusão

Com muita perseverança, trabalho em equipe e muito código conseguimos finalizar o desafio; foi um experiencia incrível de muito crescimento e aprendizagem. Com o fim do desafio, descobrimos o que é de fato ser os protagonistas de nossas histórias. Como já dizia Dory: “Continue a nadar…para achar a solução, nadar, nadar!”

Artigo: https://medium.com/@matheuspalinkas/sobre-uma-jornada-fcamara-desafios-e-c%C3%B3digos-596b55657d0d
Repositório:
https://github.com/MatheusPalinkas/Projeto-FCamara-Frontend
https://github.com/MatheusPalinkas/Projeto-FCamara-Backend

Squad 10

Matheus Palinkas – Desenvolvedor
Adriana Penha – Desenvolvedor
Gusthavo Rodrigues – Desenvolvedor