Tecnologia só entra quando resolve um problema real. Sem futurismos, só ferramentas que funcionam no terreno da inovação social.
O Problema Real
A tecnologia chega aos territórios como uma promessa. Um representante de vendas explica que aquela plataforma resolve tudo. A câmara compra. A associação tenta usar. Passados seis meses, o projecto está parado e o dinheiro gasto.
Isto acontece porque a tecnologia foi escolhida antes do problema. Nós aprendemos isto da pior forma. Já gastámos tempo e dinheiro a implementar sistemas que ninguém usava. Hoje, a nossa regra é simples: tecnologia só entra depois de pelo menos três conversas no terreno onde ninguém menciona a palavra “tecnologia”.
O problema real não é falta de ferramentas. É falta de clareza sobre o que se está a tentar resolver. E é aqui que a maioria das consultoras falha. Vêm com a solução na mão. Nós viemos com perguntas. E só quando as perguntas não têm resposta manual é que pegamos no teclado.
Como Fazemos: O Diagnóstico antes do Teclado
Primeiro vamos ao terreno, não ao GitHub
Antes de abrir um browser, vamos às reuniões de bairro. Sentamo-nos nas associações. Observamos como as pessoas trabalham com papel, Excel, telefone. Anotamos os pontos onde o trabalho trava.
Numa aldeia do interior, percebemos que o problema não era partilhar ficheiros. Era saber quem tinha a versão final do documento. Não precisávamos de uma plataforma cloud complexa. Precisávamos de um sistema de nomeação de ficheiros que todos respeitassem. Custou zero euros.
Este é o trabalho que não aparece nas propostas. É lento. É conversa. É ganhar confiança. Mas é o que evita a compra de uma licença de software que resolve um problema que não existia.
O problema define a ferramenta, nunca o contrário
Quando o diagnóstico está feito, escolhemos a ferramenta. E a escolha passa por três questões: resolve o problema? Alguém no território consegue gerir sem nós? O custo de manutenção justifica o benefício?
Uma autarquia queria uma plataforma de participação cidadã. O diagnóstico mostrou que as pessoas não usavam o site da câmara. Propusemos um número de WhatsApp. Custou zero. A participação aumentou porque as pessoas já usavam a ferramenta. Não tivemos de treinar ninguém.
Isto parece óbvio, mas não é. A indústria tecnológica vive de vender complexidade. Nós vivemos de a evitar. Quando a ferramenta é mais simples que o problema, o problema resolve-se.
Testamos no papel antes de instalar
Sempre que possível, simulamos o processo tecnológico sem tecnologia. Se é um workflow, fazemos com post-its numa parede. Se é uma base de dados, usamos uma folha Excel partilhada. Se aguenta assim, aguenta com ferramenta leve.
Num caso recente, o cliente queria um sistema de gestão de voluntários. Passámos duas semanas com uma planilha. No fim, perceberam que o que precisavam era de um formulário Google, não de uma plataforma. Pouparam milhares de euros e ganharam autonomia.
Este teste em papel é o filtro que nos protege da vontade de implementar. Mostra se a lógica está sólida. Se não está, a tecnologia só esconde a confusão. Se está, a tecnologia acelera o que já funciona.
Como Fazemos: Software que Serve e Não Escraviza
Open source porque não podemos depender de licenças
Usamos software open source por uma razão prática: quando o projecto acaba, o cliente fica com tudo. Código, dados, autonomia. Não fica preso a uma licença que não pode pagar ou a um fornecedor que desaparece.
Instalamos Nextcloud para partilha de ficheiros em muitas autarquias. Não porque é grátis. Porque quando o técnico da câmara pergunta “e depois?”, podemos dizer: “depois você gere”. Damos-lhe as chaves e as instruções. E não precisamos de voltar para manutenção.
Isto muda a relação. O cliente deixa de ser consumidor e passa a ser gestor. É mais trabalho inicial. Exige formação. Mas é o que faz com que o projecto dure depois de nós sairmos. E é isto que nos diferencia de quem vende soluções fechadas.
Escolhemos ferramentas que uma câmara municipal consegue gerir sozinha
Nunca implementamos uma ferramenta que exija um sysadmin a tempo inteiro. Se há um botão “configurações avançadas”, garantimos que alguém local consegue carregar lá sem ter de ligar para nós.
Para gestão de projectos, usamos Taiga ou Wekan. Não porque são as mais poderosas. Porque a interface é intuitiva. Um trabalhador de uma associação com formação básica consegue criar um cartão, atribuir uma tarefa, mover para concluído. Não precisa de manual.
Esta escolha é política. É dar poder a quem faz o trabalho real. É recusar ferramentas que centralizam o conhecimento num especialista. O custo não é só o preço. É a dependência. E nós recusamos criar dependência.
Quando desligamos soluções caras que não justificam
Já chegámos a clientes com um sistema CRM caro e complexo que ninguém usava. Desligámos. Migramos dados para uma planilha simples e treinámos a equipa a usar filtros. O custo passou de milhares por ano para zero. A utilização passou de 10% para 100%.
Esta decisão é difícil. O cliente investiu dinheiro. Mas manter um sistema só porque se pagou por ele é o mesmo que continuar a usar uma ferramenta partida. Nós medimos uso, não custo de aquisição. Se não se usa, vai fora.
Isto posiciona-nos como quem protege o cliente dos seus próprios erros. Não somos vendedores de tecnologia. Somos gestores de utilidade. E algumas vezes a decisão mais técnica é desligar a tecnologia.
Como Fazemos: Gente que Sabe o Que Faz
Contratamos em Bangalore e Recife porque o talento é real e o custo é justo
A nossa equipa técnica está em Bangalore, Recife, Buenos Aires. Não porque é barato. Porque são bons. E porque o custo de vida deles permite que paguemos bem um valor que para nós é baixo. Isto cria uma relação justa.
Um developer sénior em Bangalore recebe da Digital Native um salário que lhe dá qualidade de vida. Para a autarquia portuguesa, custa menos que um júnior em Lisboa. E o trabalho é melhor. Isto não é outsourcing. É construção de equipa distribuída com critério.
O trabalho passa por passar requisitos claros, testar rigorosamente e manter comunicação assíncrona. Usamos Loom para gravar explicações em vídeo que eles veem quando acordam. Eles usam gravadoras para responder. O ciclo de feedback é 24h, mas ninguém fica preso a reuniões nocturnas.
O freelancer pontual é melhor que a equipa fixa para muitos casos
Temos um rol de freelancers que conhecemos. Quando surge um projecto com necessidade específica, ligamos à pessoa certa. Não mantemos uma equipa grande a tempo inteiro. O custo fixo baixa, a flexibilidade sobe.
Num projecto de mapeamento comunitário, precisámos de alguém que percebesse de QGIS. Não tínhamos. Ligámos a um freelancer no Porto que trabalha connosco há três anos. Ele fez o trabalho em duas semanas. Pagou-se pelo projecto, não pelo tempo. E o cliente teve exatamente o que precisava sem pagar um especialista a tempo inteiro.
Este modelo exige uma gestão de rede. Manter contactos, saber quem está disponível, quem gosta de quê. É mais trabalho de coordenação. Mas é o que permite dizer sim a projectos sem aumentar a estrutura.
A tradução entre quem codifica e quem usa é o trabalho real
O maior custo de uma equipa técnica internacional não é o salário. É a distância cultural e de linguagem entre quem programa e quem usa. O trabalho da Digital Native é traduzir.
Quando o developer propõe uma solução, nós perguntamos: “como é que a Maria da associação vai usar isto?” Se a resposta envolver mais de três cliques, voltamos atrás. Se exigir inglês, voltamos atrás. Se precisar de ler um manual, voltamos atrás.
Esta tradução é um trabalho técnico. É saber o suficiente de código para perceber o que é possível. E saber o suficiente do terreno para perceber o que é útil. É a ponte. E é por isso que um developer bom em Bangalore e uma associação no Alentejo conseguem trabalhar juntos.
Onde Isto Pode Dar Errado
Quando a tecnologia se torna o objectivo
Já caímos nesta armadilha. Um cliente entusiasmado queria automatizar tudo. Nós percebemos que a automação ia eliminar os momentos de conversa entre a equipa. Mas avançámos. No fim, o sistema funcionava e as pessoas estavam desconectadas. Desligámos a automação.
A lição é simples: se a tecnologia elimina relações humanas que são úteis, é má tecnologia. Mesmo que funcione. Mesmo que seja eficiente. O objectivo é sempre o impacto humano, nunca o desempenho técnico.
Quando escolhemos ferramentas demasiado complexas para o cliente
Numa fase inicial, implementámos um sistema de gestão de voluntários com workflows complexos. Funcionava. Mas quando a pessoa que o geria saiu, ninguém mais conseguia usar. Tivemos de voltar, simplificar, perder funcionalidade para ganhar autonomia.
A tendência é sempre para sobre-especificar. Para usar a capacidade técnica que temos. A disciplina é fazer o oposto: usar a capacidade técnica mínima que resolve o problema. E viver com as limitações.
Quando o trabalho remoto vira isolamento
A equipa distribuída funciona até deixar de funcionar. Já perdemos bons freelancers porque a comunicação assíncrona se tornou ausência de comunicação. Hoje, exigimos uma chamada por semana, mesmo que seja de 15 minutos. É cara. Mas mantém a ligação.
O custo de coordenação de equipas distribuídas é real. Não desaparece magicamente. Tem de ser orçamentado. Se não for, vem o choque cultural, a má compreensão dos requisitos e o retrabalho. E aí o barato sai caro.
O Que Faz a Diferença
A diferença não está nas ferramentas. Está na ordem: problema primeiro, tecnologia depois. Está na escolha: software simples e aberto. Está na equipa: distribuída, qualificada, gerida com cuidado.
Mas acima de tudo, a diferença está na honestidade sobre limites. Nós não somos uma consultora tecnológica. Somos uma consultora de inovação social que usa tecnologia. Se o problema não precisa de tecnologia, não a usamos. Se precisa, usamos a mínima possível.
O cliente percebe esta diferença quando lhe entregamos uma solução que ele consegue gerir sem nós. Quando lhe dizemos “você não precisa disto” a uma ferramenta cara. Quando o orçamento é baixo e o impacto é real.
A pergunta que fazemos sempre é: daqui a um ano, isto funciona sem a Digital Native? Se a resposta for não, estamos a fazer algo errado. E é por isso que usamos tecnologia como ferramenta. Ferramenta deixa de servir quando quem a usa acaba a obra. E nós queremos que as obras duram.