Meta descrição: O diagnóstico em campo é o primeiro passo dos nossos projetos. Explicamos como fazemos, com quem falamos e o que anotamos para não falhar.
O Problema de Começar no Escritório
O diagnóstico em campo falha quando começa no escritório. Quando olhamos para dados de indicadores económicos e achamos que percebemos o problema. O problema está nos detalhes que os números não contam.
Na primeira vez, ainda no início da Digital Native, desenhámos um projecto para uma autarquia baseado num relatório de desemprego. Quando chegámos ao terreno, percebemos que o desemprego não era o problema. Era a falta de transporte para chegar ao emprego. Perdemos três meses. Hoje, não abrimos um ficheiro Excel antes de sentarmos na casa de alguém.
Passo 1: Diagnóstico em Campo
Falamos com quem carrega o problema
O diagnóstico em campo começa pela identificação de quem vive o problema diariamente. Não falamos com o presidente da câmara primeiro. Falamos com a técnica do gabinete que atende as pessoas. Falamos com a presidente da associação que abre porta todos os dias. Falamos com dois ou três moradores que têm o problema e não têm cargo.
Num município de 20 mil habitantes, o diagnóstico demora 4 a 5 dias. Três dias de conversas informais. Um dia de observação participante. Um dia de revisão de notas. Não usamos questionários. Usamos conversas que duram 45 minutos. Anotamos tudo num caderno. Não gravamos. Gravações assustam. Cadernos tranquilizam.
Perguntamos três coisas apenas
No diagnóstico em campo, fazemos três perguntas. “O que é que lhe custa mais no dia a dia?” “O que já tentou fazer para resolver?” “Se tivesse 1000 euros, qual seria a primeira coisa que mudava?” Estas três perguntas dão mais informação que um inquérito de 30 perguntas.
A primeira pergunta mostra o problema real. A segunda mostra o conhecimento local. A terceira mostra as prioridades. Nunca perguntamos “o que precisa”. As pessoas não sabem o que precisam. Sabem o que lhes custa. É diferente.
Anotamos as respostas à mão. Depois passamos para uma tabela simples. Uma coluna para quem falámos. Outra para o que disse. Outra para o que observámos. Não codificamos nada. Não usamos software de análise de dados qualitativos. Usamos olho nu e bom senso.
Quando as pessoas não sabem o que precisam
O diagnóstico em campo falha quando as pessoas não conseguem articular o problema. Não forçamos. Mostramos. Levamos um mapa. Pedimos que desenhem o seu dia. Pedimos que nos mostrem onde trava. A linguagem corporal diz mais que as palavras.
Numa junta de freguesia, ninguém sabia dizer porque o processo de atribui de bolsas demorava 3 meses. Observámos. Vimos que o formulário tinha 15 campos, mas só 3 eram usados. Vimos que faltava um carimbo que só uma pessoa tinha. O problema não era digital. Era o carimbo.
O diagnóstico em campo é um processo de tradução. Traduzimos o que as pessoas vivem para o que a equipa técnica consegue resolver. E traduzimos o que a equipa técnica propõe para o que as pessoas conseguem usar.
Passo 2: Prototipagem Rápida
O que prototipamos: apenas o que não sabemos
Nos projetos da Digital Native, prototipamos apenas o que não sabemos se funciona. Se sabemos que funciona, implementamos directo. Se não sabemos, fazemos uma versão mínima. Não prototipamos para mostrar. Prototipamos para testar.
Num projecto de mapeamento de recursos comunitários, não sabíamos se as pessoas sabiam descrever os seus próprios recursos. Prototipámos um formulário em papel. Fizemos 5 pessoas preencherem. Percebemos que não. O problema não era o formulário. Era a linguagem. Mudámos a pergunta. Testámos outras 5. Funcionou. Aí sim, passámos para digital.
Esta regra poupa-nos meses. A tentação é prototipar tudo. O resultado é perder tempo em coisas que já sabíamos que funcionavam. Hoje, perguntamo-nos sempre: “qual é a hipótese que estamos a testar?” Se não conseguimos responder, não prototipamos.
Com que materiais: papel, caneta e telemóvel
A prototipagem rápida começa com papel. Sempre. Desenhamos interfaces em folhas A4. Recortamos botões. Simulamos cliques. Pedimos às pessoas que fingem usar. O feedback é imediato.
Depois usamos ferramentas low-code: Typeform, Google Forms, Airtable. Não investimos código antes de validar a lógica. Um formulário Typeform testa o fluxo de dados. Se funciona, depois se constrói base de dados dedicada. Se não funciona, mudamos em 10 minutos.
Num projeto de acompanhamento de famílias vulneráveis, o protótipo foi uma pasta Google Drive com 10 fichas. Funcionou durante 2 meses. Só depois construímos um sistema CiviCRM. A pasta era feia. Mas era usada. E isso é o que importa.
Quanto tempo demora: 3 dias máximo
A regra da Digital Native é: protótipo não demora mais que 3 dias. Se demorar mais, é porque estamos a perfeccionar. E perfeccionar um protótipo é perder tempo. O protótipo deve ser feio. Deve ter falhas. Deve ser suficiente para testar uma hipótese e nada mais.
Passados 3 dias, entregamos. Não pedimos feedback formal. Pedimos que usem. Observamos o que fazem. Anotamos os pontos de fricção. E decidimos: avançamos, ajustamos ou desistimos. Desistir é uma opção válida. É melhor desistir ao fim de 3 dias que ao fim de 3 meses.
Esta rapidez assusta clientes habituados a planos de 50 páginas. Explicamos: o plano está no protótipo. Quando vêem o resultado, percebem. Mas exige confiança. E confiança constrói-se mostrando trabalho, não planos.
Como testamos com 5 pessoas
Testamos com 5 pessoas. Não com 50. Cinco pessoas identificam 85% dos problemas de usabilidade. É um dado que aprendemos e confirmamos. O truque é escolher as 5 pessoas certas.
Escolhemos 2 que vão usar a ferramenta diariamente. 2 que vão usar ocasionalmente. E 1 que vai ter de treinar os outros. Esta mistura dá-nos perspectiva completa. Não precisamos de mais.
O teste é simples: damos a tarefa e calamo-nos. Não explicamos. Não ajudamos. Observamos onde tentam carregar. Onde hesitam. Onde erram. Anotamos. No fim, perguntamos “o que esperava que acontecesse?” e “o que aconteceu?”. Estas duas pergunta revelam tudo.
Passo 3: Implementação Iterativa
Tamanho dos ciclos: 2 semanas, nunca mais
A implementação iterativa na Digital Native funciona em ciclos de 2 semanas. Cada ciclo entrega algo que funciona. Não entrega partes. Entrega funcionalidades completas, ainda que pequenas.
Num projeto de gestão de voluntariado, o primeiro ciclo entregava só o registo de voluntários. Nada mais. Mas funcionava. O segundo ciclo entregava a atribuição de tarefas. O terceiro, o relatório. O cliente podia usar dês do primeiro dia. E isso muda tudo.
Ciclos longos criam risco. Três meses sem entrega geram ansiedade. E ansiedade leva a más decisões. Duas semanas é o suficiente para fazer algo útil e o curto o suficiente para corrigir rápido.
Critérios para avançar ou retratar
Em cada fim de ciclo, fazemos uma reunião de 30 minutos. Mostramos o que foi feito. Perguntamos: “é isto que precisavam?” Se sim, avançamos. Se não, perguntamos: “o que falta?” E ajustamos.
Há uma regra dura: se duas pessoas que vão usar o sistema dizem “não percebo”, paramos. Não avançamos até perceberem. Não importa se o plano dizia outra coisa. O plano é uma hipótese. O feedback é a realidade.
Retratar é aceitar que o protótipo falhou. Num projecto de mapeamento de competências, o segundo ciclo mostrou que a lógica estava errada. Demos dois passos atrás. Refizemos o protótipo. Perdemos 2 semanas. Mas salvámos o projecto. Retratar é sinal de maturidade, não de fracasso.
Como lidamos com pressa do cliente
O cliente tem sempre pressa. “Preciso disto para ontem.” Nós dizemos: “entregamos em 2 semanas uma versão que resolve metade. Ou demora 2 meses e resolve tudo mal.”
A pressa é um problema real. Mas não é um problema técnico. É um problema de confiança. O cliente teme que não entregamos. Nós mostramos entregas a cada 2 semanas. A pressa desaparece.
Quando a pressa é política e inegociável, fazemos uma versão de emergência. Uma planilha. Um formulário. Qualquer coisa que funcione. E explicamos: “isto é para ontem. O projecto real começa depois.” Gerimos expectativas. É parte do trabalho.
Passo 4: Entrega e Autonomia Local
Documentação que criamos: um vídeo de 10 minutos
A documentação que deixamos não é um manual. É um vídeo de 10 minutos gravado em Loom. Mostramos o ecrã. Clicamos. Explicamos o que fazemos e porquê. Guardamos no Google Drive da organização.
Um manual escrito ninguém lê. Um vídeo que dura 10 minutos pode ser visto quando surge uma dúvida. Pode ser partilhado. Pode ser pausado. É documentação viva, não documentação morta.
No vídeo, explicamos não só como se faz, mas o que fazer quando dá erro. Mostramos os erros mais comuns. E como voltar atrás. Esta parte é essencial. É o que dá autonomia.
Treino que damos: 2 horas, mãos na massa
O treino dura 2 horas. Não mais. É mão na massa. Cada pessoa traz o seu portátil. Fazem as tarefas que vão fazer no dia a dia. Nós corrigimos. Respondemos. Rimos dos erros.
Numa formação para uma câmara municipal, a técnica tinha medo de carregar no botão errado. Durante 30 minutos, o único exercício foi carregar em tudo. Sem medo. Com um botão “voltar atrás” sempre visível. O medo desaparece quando se pratica sem consequências.
O treino não é modular. É prático. Não tem slides. Tem o sistema aberto e um caso real. Resolve-se o caso. Aprende-se o sistema. É assim que funciona.
Ferramentas que deixamos: low-cost e open source
Deixamos ferramentas que não custam. Nextcloud para partilha de ficheiros. Taiga para gestão de tarefas. O CiviCRM para relações com comunidade. Tudo open source. Tudo com documentação em português. Tudo que funciona num servidor de 5 euros por mês.
Numa entrega recente, o cliente perguntou: “e as licenças?” Respondemos: “não há licenças. É vosso.” O alívio foi visível. A autonomia começa aí. Quando percebem que não precisam de pedir orçamento para renovar licenças, o projeto ganha vida própria.
Deixamos também um contacto. Não para manutenção. Para emergências. “Se não funcionar, liguem. Mas tente primeiro resolver com o vídeo.” É um contacto de segurança, não de dependência.
Passo 5: Acompanhamento sem Burocracia
Métricas claras e acessíveis: usamos o Excel do cliente
Monitorizar impacto não é usar Power BI. É usar o Excel que a equipa já usa. Criamos uma folha com 4 colunas: o que medimos, como contámos, o que aconteceu, o que vamos fazer. Atualizam-nos por email a cada 2 semanas.
Não é perfeito. Mas é usado. E é usado porque não exige mudar de ferramenta. O acompanhamento só funciona se for mais fácil que não acompanhar.
Num projeto de integração de migrantes, a métrica era “quantas pessoas conseguiram marcar consulta por telefone”. Não era “nível de inclusão”. Era concreto. Era mensurável. Era relevante. E a equipa conseguia contar.
Frequência de check-ins: um email, não uma reunião
O check-in é um email que demora 2 minutos a responder. “O que correu bem? O que correu mal? O que precisam?” Enviado por nós às segundas-feiras. Respondido por eles quando podem. Não marcamos reuniões de acompanhamento. As reuniões consomem tempo. O email consome 2 minutos.
Se o email não é respondido em 2 semanas, ligamos. Não para cobrar. Para saber se precisam de ajuda. A falta de resposta é um sinal. Pode ser sobrecarga. Pode ser desmotivação. Pode ser que o sistema caiu e não sabem como dizer.
Como corrigimos em tempo útil: mudamos logo, não esperamos
Quando algo não funciona, corrigimos no próprio dia. Não esperamos pelo fim do mês. Não esperamos pela reunião de balanço. A correção é um processo vivo.
Num projeto de acompanhamento de idosos, a equipa deixou de usar o sistema porque um campo obrigatório não fazia sentido. Nós mudámos o campo em 30 minutos. Enviamos um email com “já está”. Isso mostra que estamos atentos. Que a opinião deles importa. Que a tecnologia serve.
A correção rápida é mais importante que a correção perfeita. Uma correção imperfeita que sai no mesmo dia permite o trabalho continuar. Uma correção perfeita que sai na próxima semana para o projecto. Preferimos imperfeita e útil.
O Que Aprendemos a Fazer Diferente
Aprendemos que planos são hipóteses. Que documentação sem vídeo não é usada. Que treino sem medo não é aprendizado. E que a autonomia do cliente é o único indicador de sucesso que importa.
Hoje, começamos tudo com o fim em mente. Desde o primeiro dia, perguntamos: “o que é que vocês precisam saber para isto correr sem nós?” E planificamos para isso. O resto é detalhe.
A pergunta que deixamos aos clientes é: “daqui a seis meses, sem nós, como sabem que isto funciona?” Se conseguirem responder, fizemos o nosso trabalho. Se não, voltamos atrás. E é por isso que fazemos diagnóstico em campo. Porque só quem pergunta no terreno consegue entregar algo que dura.