[CASE] Sistema para gestão de Escolas técnicas (ERP)
Este é um case de [re]criação de um ERP, em um cenário onde não existir a cultura de produto e Roadmap era um ser estranho… Então o descritivo a seguir tanto é um relato de experiência de projeto de design, quanto uma evolução de cultura enquanto o projeto estava em andamento.
O desafio apresentado
Reprojetar/redesenhar um ERP para gestão de escolas técnicas.
O desafio real
Identificar features necessárias para escalabilidade e otimização do trabalho para os stakeholders (professores, alunos, coordenação, direção, gestores de áreas e suporte).
O cenário
Uma empresa de cursos técnicos sem cultura de pesquisa e desenvolvimento por metodologia de design, sem PO/PM, roadmap ou histórico de documentação para as features necessárias. Somando a isso, a necessidade de entregas para o desenvolvimento enquanto o sistema legado está no ar, competindo com features do novo sistema 🤦🏽
Trabalho realizado
Para iniciar o trabalho foi necessário entender o que era prioritário, ou o que já estavam trabalhando na equipe de tecnologia (devs). Além de conhecer a dimensão do sistema e seus envolvidos/usuários.
Entendendo o problema e mapeando cenários
O primeiro passo foi identificar os stakeholders envolvidos, daí tentar projetar um plano de pesquisa com o objetivo de entender e mapear o negócio, com suas particularidades da instituição.
No mapeamento feito, encontramos entidades que estão mais distantes da operação, mas que interferem no funcionamento por conta da prestação de algum serviço ou questões normativas/legislativas.
Ok… agora que temos uma ideia do problema, vamos ao processo para solucionar.
Para isso, foi seguido um fluxo com a abstração do Double Diamond. Isso significa que passamos por uma fase de exploração do problema, definição, prototipação e validação, para depois documentar e entregar a feature.
Para ficar ilustrativo e tangível, pois o projeto é enorme, vou descrever como fizemos com 1 dos módulos e daí o mesmo processo se aplica para todos os demais. O módulo escolhido será o Portal do Aluno, pois também possuiu um entregável de app móvel, além do portal web.
Portal do Aluno
Know and learning — Exploração
Para entender qual o tamanho do problema e as features necessárias para um portal do aluno, primeiramente foram mapeadas as telas/features do portal atual e do app existente — sim, ainda tinha um app para dar conta :D
E os dados de utilização?
Bom, não tem… não havia um monitoramento para dizer quantos acessos existem em cada página dessa nem os acessos às funcionalidades do app. A partir desta descoberta, criei uma conta no Google Analytics, Tagmanger e Data Studio (Looker) para começar a coletar os dados de acesso, enquanto seguia com o discovery.
Pesquisas Quali e Quanti
Como não havia indícios sobre quais as features mais usadas, tivemos que seguir com a descoberta qualitativa e depois realizar um levantamento para ordem de grandeza e daí tomarmos as decisões com a gestão.
Etapa 1: Quali
A etapa de pesquisa com usuários foi feita a partir de uma documentação seguindo o framework DECIDE, orientando as fases e estrutura. Criado 2 roteiros semi-estruturados, um deles foi aplicado a um grupo de alunos ativos de uma unidade e outro foi usado para guiar a pesquisa com pessoas de secretaria. Assim tivemos a visão de dois lados deste problema: O que os alunos dizem que precisam vs o que o atendimento/secretaria diz.
Haviam alguns registros no Help Desk, mas referenciaram a Bugs e o processo de atendimento não era direto via essa ferramenta. O atendimento na secretaria fazia o papel de N1, então nem todos os problemas chegavam a ser registrados.
Enfim…
Montamos uma CSD com os achados da entrevista, deixando evidente os pontos agrupados por semelhança e depois identificando quais as dúvidas para validarmos quantitativamente.
Descoberta bônus: Existe uma iniciativa de atendimento via WhatsApp por Bot que emite algumas informações e 2ª via do boleto.
Obs.: Os fluxos acima foram resumidos ou suprimidos de qualidade propositalmente, pois em outra forma poderiam expor detalhes estratégicos e aqui a ideia é apenas mostrar que existiu o mapeamento.
Etapa 2: Insights e negociação
Como nesse momento fomos impedidos de realizar uma quanti, por questões de acesso a dados e ferramental, fizemos uma “acareação” com as informações passadas pela secretaria e também com os chamados abertos no Help Desk que se relacionaram com problemas do App ou Portal do Aluno.
Para entender um pouco melhor sobre o mercado, realizamos um benchmarking para trazer alguns insights durante as discussões de negociação de funcionalidades.
Com esses alinhamentos realizados, decidimos pelas funcionalidades:
- Login no portal do aluno;
- Visualizar notas e faltas;
- Acesso às disciplinas do EaD;
- Acesso ao histórico financeiro e boletos; e
- Documentos e abertura de solicitações.
Fase 3: Prototipação e testes
Esta etapa foi marcada por várias decisões de design, como:
- Usar uma biblioteca de componentes pré-existente e expandí-la;
- Adotar o minimalismo e otimização de fluxos;
- Determinar um padrão de layout para servir de base em todos os fluxos;
- Validar presencialmente, com alunos;
- Prototipar em alta, diminuindo o tempo desta etapa;
- Para o portal, a versão responsiva será a v1 do app.
Explicando cada uma delas, iniciando pela biblioteca de componentes, adotamos uma pré-existente pela necessidade de ganhar velocidade e, juntamente com a decisão de sermos minimalistas, criarmos poucos componentes novos/complexos.
A biblioteca de componentes de interface implementada no Material UI (MUI v5), já contando com a grande maioria dos componentes e comportamentos básicos necessários e com implementação em React.
O minimalismo e otimização ficou por conta de estabelecer uns layouts base, sendo a organização de arquitetura de informação inicial e que poderia ser expandida pela pessoa designer como fosse necessário.
Criamos alguns padrões de fluxo das interfaces, como templates, garantindo uma consistência na operação.
Fase 4: Testes
Após as fases de prototipação do portal do aluno, realizamos um teste com alguns alunos da unidade mais movimentada em São Paulo.
Para a realização deste teste foi criado um roteiro e os protótipos usados foram os do Desktop, importados e configurados no Useberry. Tentamos usar o Maze, mas estava dando muito problema, então encontramos esse outro concorrente que é fácil de configurar e possui a mesma dinâmica.
O teste foi em um laboratório e, por conta da dinâmica de aulas, aconteceu com vários alunos ao mesmo tempo. Ao final dos desafios, o sistema mostrava algumas perguntas e ao final responderam um SUS.
Além da nota do SUS (obtivemos 8.9), o mais valioso foi ouvir as explanações, ver as dúvidas e entender os desafios da interação dos alunos com o sistema. No geral foram muito poucas dúvidas e uma certeza: é sempre necessário fazer esse tipo de teste para adequar o sistema ao cenário e ao usuário.
Com o teste feito, volto para o protótipo e realizo os ajustes finos com base nesta fase. Passando para a documentação final de inspeção no Figma e apresentação de Handoff.
Extra: Handoff
Testamos algumas formas de realizar o repasse para os Devs. Os detalhes que funcionaram e foram replicados foram:
- Uso do Confluence como documentação textual e para consulta assíncrona;
- Acesso como visualização ao Figma, sinalizado e com os protótipos em versão final;
- Vídeo de apresentação contextual e detalhando a entrega com o embasamento do “porque” das coisas, durando até 10 min;
- Gif, acompanhando a documentação, do protótipo funcional para ilustrar os comportamentos;
- Tabelas de Regras de Negócio e Regras de Interface, junto com o print da tela na documentação. Deixando pré-escritas as job stories e o que será levado para o Jira (também consultado pela QA);
Usamos as capas para indicar como está o projeto e também quem são os responsáveis que estão trabalhando neste.
Utilizamos uma sinalização ao lado do nome da página para indicar aos visitantes seus status, assim como nos ajudar na fácil identificação do que levar em consideração e o que poderia ser descartado em breve.
Existe uma página para componentes locais, usada mais para criar conjunto de componentes (organismos) que nos ajudam a replicar algumas coisas na tela, como cards, tabelas e filtros. Não é usado para criar componentes novos, pois a ideia é que tudo venha da biblioteca central.
Para garantir um trackeamento dos eventos, formalizamos uma nomenclatura para ser aplicada como classe de CSS aos componentes como botões, listas, checkbox e links. Assim consigo identificar através do Tagmanager essas “tags” e realizar o monitoramento, enviando para o Analytics da forma como desejamos, não onerando os devs e flexibilizando a camada de monitoramento.
Acima de cada conjunto de telas/frames adicionamos esse cabeçalho identificador para informar aos devs quem é a pessoa responsável, além de seu status e correspondência no menu.
Por fim, na documentação do Confluence e nas tasks do Jira são adicionados os links que direcionam para o cabeçalho do conjunto de frames correspondente. Assim diminui a confusão e torna muito mais rápido para a pessoa PO e Dev encontrar o protótipo correspondente a documentação ou tarefa concluída.
Fiz alguns vídeos treinamento e uma apresentação para orientar todo o time sobre os padrões de trabalho com essas ferramentas.
— — —
Bom… é isso. O case é grande e este aqui só trata do módulo de Portal de Aluno. Imagine o quão grande foi a reconstrução de todos os módulos 😀
Obs.1: Algumas páginas e detalhes foram retirados pois, como forma de gratidão pelo grande trabalho e colaboração que fiz, fui notificado e ameaçado de ser processado por usar a marca da empresa.
Obs.2: Este case pode ou não ser fictício e toda a história inventada da minha cabeça :D
