a B42 Edtech, nosso propósito de “Fazer a educação ser POP” já permeava entre nossas mentes, mesmo antes de oficializá-lo. Sempre fomos entusiastas e adeptos de empregar a tecnologia para revolucionar a aprendizagem. Hoje, quero convidar você aos bastidores da criação do EducaBox, um aplicativo que reflete nossa paixão e compromisso com a educação. Além disso, vou detalhar como expandimos essa visão para criar uma skill interativa para Alexa, proporcionando uma experiência de aprendizado ainda mais integrada.
Na jornada da criação de um app, há muitos desafios, coisas que ninguém te ensina, coisas que você descobre na hora. Três perguntinhas nos nortearam em busca dos nossos objetivos. Foram elas: O quê? Por quê? E Como?
Mas além disso, outros desafios surgiram no meio do caminho. Embarque comigo nesta jornada e eu te mostro como foi.
O quê queremos?
R.: um app para ajudar professores a se conectarem com ideias, teorias, conceitos e referências de forma rápida e fácil. Enviando um push diariamente, ele lembrará o docente que novo conteúdo foi disponibilizado no app.
Por quê?
R.: no meio de uma pandemia, o lockdown e o aprendizado forçado à distância foram fatores desnorteantes para as pessoas, inclusive para muitos docentes. Nos sensibilizamos com esta situação e como trabalhamos diretamente com EaD, sabemos o quanto é importante possuir um embasamento teórico e prático para lecionar neste meio.
Como?
R.: senta que lá vem história! Aqui começa minha jornada!
Quando se fala de software, precisamos nos comunicar. É necessário conversar muito, se expressar bem e assegurar a clareza da comunicação entre todos. Precisamos entender o que as partes interessadas (stakeholders) do projeto gostariam ou propor ideias e aspectos que sentimos que o stakeholder precisa, mas às vezes ele ainda não sabe disso. Por mais que criar software seja criar códigos de programação e “conversar” com a máquina (digamos assim), primeiro há tarefas extremamente humanas e com toques de sensibilidade que requerem tato, feeling e habilidades na comunicação. Nós, analistas de sistemas, precisamos ter este driver instalado, digo, esta softskill desenvolvida. Perdoe meu tecniquês, às vezes sai sem querer.
A Ideia:
A ideia, normalmente, vem de uma necessidade, um anseio, um vislumbre de algo que poderíamos fazer; muitas vezes, surge ligada à alguma necessidade, vindo para solucioná-la. “E se eu tivesse um app que pudesse entregar conteúdos diários e relevantes para o aperfeiçoamento das principais competências docentes?” E assim, naturalmente, vamos conversando e alimentando essa ideia. Uma vez entendido que é uma boa ideia, podemos seguir para a próxima fase.
Levantamento de requisitos:
Primeiro, precisamos levantar requisitos, de modo que utilizar ferramentas de brainstorming nesta fase é muito bem-vindo. Papel, caneta, planilha, documento de texto, tudo vale! Tire da cabeça e coloque no papel, deixe sua imaginação fluir dentro da ideia inicial que foi previamente pensada. A partir disso, conseguimos entender o que está sendo solicitado; em seguida, na próxima fase do escopo, podemos fazer algumas aparas e propor um limite imaginário sobre o que é viável e o que não é.
O Escopo:
Definir o escopo é um processo fundamental para termos um início, meio e fim do projeto. Na verdade, o escopo por si só poderia ser infinito se não houvesse outras duas restrições: o tempo e o custo.
Perceba que estes três pilares estão intrinsecamente ligados, são, na verdade, um triângulo, chamado de Triângulo de tríplice restrição. Em bom português, significa que você não pode aumentar o escopo sem aumentar o custo ou a qualidade. Um projeto que seja rápido e com extrema qualidade custará caro. Um projeto que seja barato e rápido, provavelmente, terá baixa qualidade. Um projeto com alta qualidade e barato, provavelmente, vai demorar para ser finalizado.
Portanto, na fase de definição do escopo, é muito importante definir “o quê o app não vai fazer”. Pode soar estranho, mas vou te dar um exemplo: imagine um aplicativo que conecta o motorista de um carro a serviços de guincho. Este app vai mostrar, em um mapa, os guinchos mais próximos e dará uma forma de chamar e pagar por este guincho. Mas este mesmo app não vai aproveitar que você está pedindo um guincho em uma determinada localização e te dar opções de delivery de comida para que o cara do guincho traga uma pizza para você. Este foi um exemplo bem caricato com o propósito de ilustrar este conceito do que não fazer, mas é importante que, neste documento do escopo, sejam escritas algumas restrições, garantindo que não fique nada subentendido sobre as funcionalidades do aplicativo.
Limitar propositalmente as possibilidades é benéfico, porque quando entramos no campo da programação, se não houver limites, iremos a todo momento mudar de ideia, criar novas funcionalidades e o projeto nunca acaba. Em um app, praticamente, a maioria das idealizações podem ser desenvolvidas, mas nem tudo é viável. Pelo menos em um primeiro momento. Eu defendo que atualizações devam existir, mas que sejam tratadas como um novo pacote de funcionalidades ou uma nova fase do projeto e não um projeto sem fim.
Para criar o escopo, criamos um documento com as especificações do produto, com linguagem informal, sem muita regra, desde que seja legível. Eu prefiro listas numeradas. Saímos, aqui, com um esboço do documento de requisitos. Este esboço ainda pode mudar, mas, primeiramente, com bastante alinhamento com os stakeholders, chegamos a um escopo que satisfaça um MVP (minimum valuable product), um produto funcional, mais ou menos como uma versão de testes do seu projeto, a fim de reduzir o tempo e o custo. Sendo assim, podemos avançar para a próxima etapa de prototipação.
O protótipo:
Dividido em duas partes, o protótipo de baixa fidelidade e alta fidelidade é um importante artefato para validação dos requisitos (Francisco, 2021).
No protótipo de baixa fidelidade, esboçamos telas, esquemas e diagramas, no intuito simples e puro de dizer: “é isso que estamos idealizando? Estamos na mesma página?” Por favor, não espere telas cheias de recursos gráficos nesta fase. Sabendo que tudo pode mudar, a caneta e o papel são seus melhores aliados. Caneta não, use lápis e borracha, assim, você pode apagar e refazer, ou alguma aplicação de desenhar wireframes, mas eu prefiro o papel.
Após termos o desenho das telas, nos reunimos com os stakeholders e mostramos como está sendo idealizado, buscando aprovações ou pontos de melhoria. E assim voltamos para ajuste do protótipo e novamente conversamos com o stakeholder. Ficamos neste círculo de desenho do protótipo e validação até que todas as expectativas estejam alinhadas e o protótipo seja aprovado por completo.
A partir deste momento, podemos entrar com o protótipo de alta fidelidade, que vai levar toda a UX e UI do projeto.
Um dia, um professor da faculdade me disse: “um bom sistema é aquele que não obriga o usuário a pensar demais ou a recordar informações. Ele acessa o sistema e já consegue entender o que precisa ser feito, tudo flui”.
A palavra UX vem de user experience, ou seja, precisamos desenvolver como será o comportamento esperado do usuário do aplicativo, avaliando diversos quesitos do público-alvo, como: idade, grau de instrução, familiaridade com a tecnologia etc. UI vem de user interface, é a tela propriamente dita, com todo seu design, estilo de cores, formatos de botões e componentes, tipografia e espaçamentos.
Nesta fase é a hora que o designer que participou desde o começo do projeto, ou teve um briefing muito bom sobre ele, tome seu café, ouça sua música preferida e deixe a mente fluir buscando criar uma experiência única e agradável no app, desenhando as telas exatamente como elas devem ser no produto final. Este profissional tem grandes responsabilidades. Basicamente, dependendo do que é feito, o usuário final vai dizer: “este app é maravilhoso” ou “este app é péssimo”.
Em seguida é apresentado ao stakeholder novamente e vamos validando se o design e o produto final está alinhado com as expectativas dele. Perceba que é um trabalho em conjunto de cocriação! Um mal analista que não entende o que o stakeholder quer, um mal designer que não consegue pensar em uma tela funcional ou um stakeholder ausente que não participa da criação resulta em prováveis desastres. E ainda nem começamos a programar!
P.O. Gerente de projetos e programadores:
Feito isto, podemos criar as histórias de usuário, que são descrições das funcionalidades separadas em pequenas partes para que os programadores possam atuar. Nestas histórias de usuário, há especificações que seguem o que foi escrito no documento de requisitos, restrições, casos de testes e critérios de aceitação. Então, o Gerente de projetos utiliza um framework para executar estas histórias, o SCRUM, o qual o time atribui pontos para cada história, funcionando como uma espécie de valor simbólico de dificuldade de execução destas histórias.
Em seguida, definimos a Sprint, um pacote de trabalho com duração de uma ou duas semanas, em que o time se comprometerá com uma quantidade de pontos a serem entregues. Ao final da Sprint, temos entregáveis reais, partes do sistema prontos para uso. Esta entrega incremental possibilita obter validação constante do stakeholder, de modo que pequenas correções de curso sejam realizadas nesta jornada, evitando que o produto final fique muito diferente do que foi idealizado, seja por falta de especificação, seja por falhas de comunicação. Lembrando que possuir um time de programadores empenhados, comunicativos e questionadores faz toda a diferença. Às vezes, projetamos algo que, no momento da criação, é inviável ou problemático, nesta hora, o senso crítico do programador precisa agir, se for preciso.
Escolhendo a linguagem de programação
Este é um desafio que cabe aos programadores mais experientes ou tech leads, que conheçam bem as capacidades e limitações das linguagens e escolher algo que faça mais sentido dentro do escopo do projeto, seja pela dificuldade ou facilidade técnica, seja pelo custo ou curva de aprendizado.
No caso do EducaBox, prezamos por ter um app que seja distribuído nas duas principais plataformas móveis: Android e iOS. Seria possível criar dois apps nativos totalmente desacoplados e como vantagem termos muita velocidade, menos chances de bugs e incompatibilidades, e um perfeito acoplamento do app com o sistema operacional do dispositivo móvel. Mas como desvantagem, teríamos uma curva de aprendizado dupla e um assincronismo de versões, pois seriam dois aplicativos independentes. Ainda, o fato de realizar uma grande alteração, adicionando mais funcionalidades em um app iOS, implicaria em realizar a mesma carga de trabalho no app Android.
Escolhemos Flutter, mas por quê?
Com base na decisão de termos somente um código para manter, ficamos com dois principais frameworks: React Native e Flutter. No nosso caso, a melhor escolha foi o Flutter, oferecendo mais performance. Aqui, vai um pouco de detalhes técnicos: a escolha do Flutter foi por conta da sua linguagem de programação (Dart) que, apesar de ser menos conhecidas pelos desenvolvedores, é otimizada para desenvolvimento de UI com desempenho eficiente, por conta dos seus Widgets altamente personalizáveis, assim, era possível criar qualquer tela, como, por exemplo do EducaBox, que se assemelhava a um quadro negro com papéis, fitas e etiquetas coladas. Contudo, principalmente pelo seu método de compilação Ahead of Time (AoT), gerando uma biblioteca nativa de código em instruções ARM64, que são lidas pelos processadores dos dispositivos móveis.
Já o React Native encapsula Javascript e faz utilização de uma arquitetura chamada Bridge, que faz, literalmente, uma ponte de comunicação entre o aplicativo e os módulos nativos do sistema operacional dos dispositivos móveis, o qual, se for medido minuciosamente, oferece menor desempenho, mas continuaria sendo uma boa escolha para outros fins. O fato é que queríamos usar Flutter também, como forma de aprendizado.
As constantes reprovações nas stores de aplicativos
Este foi o maior pesadelo, mas também permitiu que uma grande experiência fosse adquirida.
Quando você submete um aplicativo para o Google Play (Google) ou App Store (Apple), pessoas do outro lado analisam se seu app está seguindo as normas de cada loja, se possui conteúdo adequado, se está apresentável e, principalmente, se não está fazendo nada ilícito.
Nossos desafios foram que as primeiras versões, diversas vezes, foram reprovadas, principalmente pela Apple, porque, vez ou outra, o app não funcionava e outras vezes o app mostrava os drops do EducaBox com algum link específico nas dicas, que levava para algum site externo, normalmente ferramentas de produtividade, como Miro, Canva etc., e estas ferramentas tinham opção de comprar planos. O avaliador da Apple entendia que estávamos querendo vender coisas por fora do app e nos reprovava! Até que aprendemos a seguir os termos corretamente, cuidar para que os drops não possuíssem estes links e, a partir daí, foi possível ter o aplicativo nas lojas!
O Futuro do EducaBox
Atualmente, o EducaBox está chegando na casa dos 10 mil downloads se somarmos iOS e Android, temos recebido muitos depoimentos sobre o quanto o EducaBox tem sido útil na microformação docente. Em outro momento, quero falar sobre a Skill da Alexa que desenvolvemos para o EducaBox. Sabemos que nossa jornada não acaba aqui, este foi só o começo! Procuro levar a B42 e seus produtos como um grande laboratório, aprendendo novas tecnologias. Temos um mar de infinitas possibilidades para explorar, I.A., realidade aumentada, realidade virtual, quem sabe hologramas e coisas que nem sabemos ainda que virão a existir!
O fato é: procuramos sempre unir a vontade de aprender algo novo com um real propósito de uso, sempre norteados em fazer a educação ser POP!
Por fim, estamos entusiasmados em anunciar uma atualização recente do EducaBox. Esta nova versão traz um design mais moderno e envolvente, pensado para refletir a atmosfera e materiais do dia a dia da sala de aula, tornando a experiência mais imersiva e intuitiva. Estamos dedicados a melhorar continuamente o EducaBox, sempre buscando maneiras de enriquecer e facilitar a jornada de aprendizado dos educadores. Explore essa nova face do app e junte-se a nós no link: https://educabox.app.br/
REFERÊNCIAS
ASANA. Em que consiste o triângulo de gestão de projetos, e como ele pode ajudar a sua equipe? Asana, 2022. Disponível em: https://asana.com/pt/resources/project-management-triangle. Acesso em: 11 jan. 2024.
FRANCISCO, T. Protótipos: baixa, média ou alta fidelidade? Meduim, 2021. Disponível em: https://medium.com/ladies-that-ux-br/prot%C3%B3tipos-baixa-m%C3%A9dia-ou-alta-fidelidade-71d897559135. Acesso em: 11 jan. 2024.
