Durante as primeiras semanas de Novembro de 2019, a F2Data realizou um design sprint com a equipe da Performa Mais e este artigo tem a finalidade de contar um pouco de como foi a minha experiência atuando como facilitador e na prototipação.
A Performa Mais tem como principal objetivo oferecer aos seus clientes novos patamares de produtividade e resultados a partir da implementação de processos otimizados e eficientes.
Através do programa A.L.I. (Agente Local de Inovação) do Sebrae, o Alexandre Anbar (Fundador e Diretor de Inovação da empresa) conheceu o Flávio Fukabori (Co-fundador da F2Data) e contou um pouco sobre a sua idéia: Um líder virtual para acompanhar, metrificar e gerenciar as operações em chão de fábrica usando inteligência artificial.
Quando falamos de inteligência artificial estamos abrangendo várias áreas da T.I., e por consequência é muito difícil conceber e principalmente orçar um software desta magnitude sem alguns levantamentos. Para estes casos indicamos e realizamos o design sprint com objetivo de entender a ideia do cliente e pensar em uma solução tecnológica com chances reais de se tornar um software de sucesso no mercado, diminuindo ao máximo o tempo e valor de desenvolvimento, além de reduzir retrabalho possibilitando testes de usabilidade e mudanças no projeto antes de partir pro código.
Na F2 aplicamos a metodologia sprint criada por Jake Knapp, onde o processo inicia na segunda-feira e percorre a semana, finalizando na sexta-feira. Porém pela incompatibilidade de agenda com todo os especialistas da Performa Mais, a equipe da empresa participou apenas no primeiro dia para nos introduzir ao contexto do problema, e no último dia para a etapa de testes do protótipo.
Já o Alexandre esteve conosco todos os dias do sprint no papel de decisor e como ator principal da idealização da solução, e para não afastar o decisor de suas atividades de rotina durante uma semana inteira, dividimos o sprint em 3 dias seguidos na primeira semana e os 2 restantes na semana seguinte .
Nas linhas a seguir irei descrever as etapas realizadas para a criação deste protótipo (algumas etapas e resultados serão omitidos por questões de confidencialidade):
Dia 1 – MAP
No primeiro dia era fundamental entendermos o contexto do problema e conhecer os especialistas envolvidos, para isso tínhamos na sala: eu como facilitador, Guilherme como especialista em desenvolvimento, Flávio como especialista em gestão de projetos e inteligência artificial, Alexandre como decisor e toda a equipe da Performa Mais estava presente, desde o setor de operações até comercial, era o ambiente perfeito para conhecermos todas as nuances do problema a ser solucionado.
Apresentamos o processo do Sprint e como ele seria aplicado ao decorrer da semana, foi também o momento da criação do primeiro check list, visando melhor compreensão dos envolvidos e principalmente controle dos tempos das dinâmicas.
-”O que vocês acham que pode fazer deste projeto um sucesso?”
-”Qual é a nossa vantagem neste cenário?”
-”Quem pode nos apresentar a perspectiva do cliente?”
-”Quem entende a mecânica da linha de produção e quais processos são aplicados?”
-”Quais são as soluções disponíveis hoje?”
Respondendo estas e outras perguntas os especialistas da Performa Mais contaram como é o dia-a-dia dos operadores, como são oferecidos seus serviços, como eles atuam e quais eram os pontos críticos de falha ou inconsistência.
Após alguns minutos (controlados) de conversa, foi definido como objetivo de longo prazo do sprint o “Monitoramento e comunicação em tempo real para melhoria na produtividade.”
Conhecendo o objetivo pelo qual todos deveríamos nos basear, era a hora de descobrir os riscos do projeto, mas para manter a discussão estruturada com 11 pessoas na sala meu maior desafio era evitar cair em um brainstorm infinito, para isso propus a utilização de uma variação da técnica “Como poderíamos”, onde neste caso, ao invés de escrever nos cartões as soluções que esperávamos, escrevemos o que poderia dar errado no projeto, e quais seriam os pontos de atenção.
É nessa hora que o sprint bem aplicado começa a fazer sua primeira mágica; imagine quanto tempo demoraríamos para ouvir todas as ideias das pessoas e seus respectivos pontos de vista?!
No modelo brainstorm comum provavelmente horas, mas com a técnica certa em apenas 10 minutos tínhamos uma mesa cheia de cartões com diversos pontos de atenção a serem considerados.
Depois de remover os repetidos e mais 10 minutos para que todos lessem todos os cartões restantes, realizamos uma votação usando adesivos verdes para escolher os 3 pontos mais importantes a serem evitados.
Sabendo qual era o objetivo de longo prazo e quais os riscos que deveriam ser evitados, começamos a construir o fluxograma da solução, que ao longo dos próximos dias receberia todas as ideias (divergência) e se converteria nos modelos definidos (convergência) de como o produto final deveria ser.
Depois do almoço do primeiro dia, visitamos uma das fábricas clientes da Performa Mais onde pudemos ver pessoalmente como se dava a operação em que o assistente seria aplicado, visita esta que foi crucial para melhorar o nosso entendimento do problema.
Dia 2 – SKETCH
Começamos o segundo dia bem animados; depois da visita à fábrica tínhamos o entendimento do problema e como o próprio Alexandre disse, estávamos “com a cabeça borbulhando de ideias!”
Dedicamos 30 minutos em pesquisa para saber como poderíamos diminuir os riscos levantados no dia anterior e usando a dinâmica “demonstrações relâmpago” condensamos todas as pesquisas e análises de possíveis concorrentes para o time em apenas alguns minutos.
Com os pontos de atenção parcialmente resolvidos era a hora da criação:
Por se tratar de um sistema que acompanha o operador em várias tarefas diferentes, dividimos a solução em 3 fases no fluxograma e repetimos a técnica “esboço em 4 etapas” em cada uma destas fases ao longo do dia. Ao fim do segundo dia nosso Storyboard estava completo; com todos os fluxos de interações e nenhuma ponta solta. A esta altura nós já sabíamos que o protótipo não serviria apenas para testar um “caminho feliz”, mas sim todas a possibilidades de ações dos usuários.
Dia 3 – DECIDE
Começamos o dia mais importante do sprint relativamente adiantados no cronograma proposto por Jake Knapp, porém pela decisão de prototipar todas as funcionalidades do aplicativo (não apenas um fluxo como normalmente é feito), tínhamos apenas 8 horas para decidir como seriam TODAS as telas do sistema.
Não era fácil mas neste momento todos do time já estavam acostumados com as dinâmicas e os processos fluíam muito bem. Por isso dividi o storyboard em 4 etapas e propus o “crazy 8s” para literalmente desenhar como imaginávamos cada uma das telas destas etapas.
Foi uma manhã silenciosa e ao mesmo tempo muito divertida, todos desenhamos sem parar tela a tela um sistema que todos sabíamos como iria funcionar mas não tínhamos ideia de como seria visualmente.
Descobrimos que todos já imaginávamos o sistema final de forma muito semelhante e a cada rodada de “crazy 8s“ produzimos esboços cada vez mais fiéis ao layout final.
Pouco a pouco, de forma muito criativa e organizada o sistema ia tomando forma em frente ao nossos olhos e ao sair para o almoço já tínhamos todas as telas espalhadas em um “museu de arte”.
Durante a tarde, conforme nós da F2 íamos apontando nossas intenções de voto, o Alexandre decidia e as telas passaram uma de cada vez do museu de arte para o storyboard.
No fim do dia tínhamos o sistema pronto para ser prototipado e reinava no ambiente a ansiedade de conhecer o produto final.
Em apenas três dias havíamos captado exatamente o que o Alexandre havia idealizado, e no nosso próximo encontro o protótipo seria apresentado e testado.
Dia 4 – PROTOTYPE
Fugindo um pouco do método original, neste sprint não contamos com o time para a prototipação. Todas as telas e fluxos de interação já estavam fixados no storyboard e cabia a mim transformar aqueles pequenos recortes de papel desenhados em um protótipo navegável de alta fidelidade. Mas havia um grande desafio:
-Como prototipar um sistema baseado em comandos por voz?
Apesar de vir estudando e utilizando o Adobe XD a algum tempo para este tipo de serviço, eu não conhecia nenhum recurso ou aplicação que pudesse simular um STT (Speech to text) ou TTS (text to speech) em um protótipo. Logo eu fui atrás de uma solução, que literalmente “pulou no meu colo”!
Acontece que assim que eu comecei minha pesquisa eu descobri que a Adobe acabava de implementar as interações por voz no XD:
Com a maior dúvida (como ouvir e falar com o protótipo) respondida, o trabalho se converteu no bom e velho UI design, que depois de 12 horas de: “Cria botão / escolhe cor / muda tipografia / -Será que esse ícone ficou correto?! / -Este botão leva para onde mesmo?! / -A assistente tem um sotaque estranho vou ter que pôr um acento aqui…” (entre outros pequenos questionamentos que fazem o design de interfaces ser tão divertido e compensador), eu tinha concluído o protótipo com 73 telas, usando a identidade visual da Performa Mais, e totalmente integrado com comandos de voz e cliques.
Dia 5 – TESTE
Logo pela manhã fomos ao escritório da Performa Mais encontrar toda a equipe para apresentar o protótipo.
Estávamos confiantes e ao mesmo tempo ansiosos em saber o que a equipe que havia nos encontrado apenas no primeiro dia, para apresentar o contexto do problema, acharia da solução.
Foi em um clima muito agradável que apresentamos o protótipo para cada um, e testamos sua usabilidade.
Após a primeira fase de testes, com os feedbacks da própria equipe da Performa Mais, descobrimos que uma das etapas da interação com o assistente estava muito mais complexa e repetitiva do que deveria ser, e é aí que o sprint para prototipação fez a sua segunda mágica:
Imagine quanto tempo e dinheiro teria sido desperdiçado se descobríssemos este problema depois de horas e horas de desenvolvimento?!
Ainda na fase de prototipação em apenas alguns minutos eu pude re-mapear as interações e remover as telas que confundiam o processo. Simples, rápido e barato!
Deste momento em diante o protótipo será testado com os operadores das diversas fábricas que a Performa Mais atende, a fim de melhorar o sistema para que o desenvolvimento seja 100% assertivo e sem gastos desnecessários.
Conclusão
Em apenas 5 dias nós conhecemos o problema, criamos em conjunto uma solução, desenhamos, prototipamos, e testamos aquilo que, antes do sprint, era apenas uma ideia na mente do Alexandre.
Pra mim foi uma semana desafiadora, onde tive que adaptar algumas ferramentas do método original para conceber uma solução que já havia sido idealizada, mas que me trouxe muito mais confiança ao método, que pode ser aplicado literalmente em qualquer contexto onde haja um problema e um time disposto a se entregar durante 5 dias única e exclusivamente para encontrar uma solução. Além de incluir ao meu set de skills de prototipação um novo conhecimento no Adobe XD (interação por voz) e nos trazer mais um case de sucesso.
E a opinião do cliente??
Bem… Com a palavra o próprio Alexandre Anbar:
Deixo meu agradecimento a toda a equipe da Performa Mais, em especial ao Alexandre Anbar que não só acreditou no processo como mergulhou em todas as etapas sempre muito animado e confiante!
Agradeço também a equipe da F2 que confiou em mim como facilitador e trouxe todo o conhecimento em projetos de I.A. e desenvolvimento de software que possibilitaram a concepção de um sistema tão complexo.
Por último agradeço a você que dedicou seu tempo a ler este artigo e conhecer um pouco do processo de design sprint para prototipação de software que realizamos na F2Data.
Obrigado!