O cérebro também precisa aprender a mudança
Há alguns dias, estudando sobre memória e aprendizagem, encontrei uma ideia que não me saiu da cabeça.
Os estudos de Eric Kandel, que lhe renderam o Prêmio Nobel de Fisiologia ou Medicina em 2000, ajudaram a mostrar algo fascinante: aprender não é apenas receber informação.
Existe uma diferença entre uma alteração momentânea no funcionamento de uma célula e uma mudança que realmente se consolida.
Kandel estudou mecanismos de aprendizagem utilizando a Aplysia californica, uma lesma-do-mar com um sistema nervoso muito mais simples que o nosso.
A simplicidade do organismo permitiu observar com bastante clareza como determinados estímulos produzem mudanças nas conexões entre neurônios.
Em termos bastante simplificados, estímulos passageiros podem produzir alterações químicas temporárias. Já estímulos suficientemente relevantes, repetidos ou intensos podem iniciar processos que envolvem expressão gênica, síntese de proteínas e alterações estruturais nas conexões neurais.
Ou seja:
Para uma mudança se tornar duradoura, não basta que a informação passe pelo sistema.
Ela precisa encontrar condições para se incorporar a ele.
E foi aí que comecei a enxergar isso no nosso dia a dia: na forma como empresas operam..
Talvez processos também tenham memória
Uma empresa não possui um cérebro único, obviamente.
Mas seus processos acumulam algo parecido com uma memória.
Durante meses ou anos, pessoas aprendem como determinada operação funciona. Criam atalhos. Aprendem exceções. Desenvolvem referências. Criam vocabulário. Descobrem quais informações realmente importam.
Algumas dessas coisas estão documentadas.
Muitas não estão.
Elas simplesmente estão na cabeça das pessoas.
É assim que surge o que podemos chamar de modelo mental da operação.
O usuário não enxerga apenas uma tela, uma planilha ou um formulário.
Ele enxerga um conjunto de conceitos relacionados:
"Cliente."
"Pedido."
"Problema."
"Responsável."
"Prazo."
"Quando isso acontecer, faço aquilo."
Aos poucos, essa estrutura deixa de ser apenas um procedimento e passa a fazer parte da forma como aquela pessoa compreende o próprio trabalho.
É por isso que uma solução melhor pode ser rejeitada
Imagine uma empresa que controla determinado processo utilizando uma planilha.
A planilha é lenta, possui informações duplicadas, depende de preenchimento manual e provavelmente não é a melhor ferramenta para aquilo.
Você entra nessa empresa e percebe imediatamente que existe uma oportunidade de construir um sistema muito melhor.
Então cria uma solução moderna:
Banco estruturado.
Interface bonita.
Fluxo automatizado.
Validações.
Integrações.
Indicadores.
Tecnicamente, tudo melhor.
Mas, quando o usuário abre a aplicação, ele pergunta:
"Mas onde eu coloco aquilo que antes ficava aqui?"
E talvez esse seja o problema.
Você não apenas substituiu a planilha.
Você substituiu o modelo mental que existia ao redor dela.
O usuário não conhece a sua arquitetura
Existe uma diferença importante entre a arquitetura que construímos e a realidade que precisamos representar.
Nós podemos pensar em:
Entidades → Eventos → Estados → Workflows → Regras → Integrações
Enquanto o usuário pensa em:
Cliente → Solicitação → Problema → Solução → Prazo
Nenhum dos dois está necessariamente errado.
São apenas abstrações diferentes da mesma realidade.
A arquitetura precisa ser sofisticada quando necessário.
Mas isso não significa que o usuário precise carregar essa sofisticação na cabeça para executar seu trabalho.
Podemos construir complexidade por baixo e simplicidade por cima.
Podemos fazer com que o sistema seja muito diferente internamente e ainda assim pareça familiar para quem o utiliza.
E isso não é falta de inovação.
É engenharia de mudança.
Automatizar não é apenas eliminar cliques
Quando falamos em automação, frequentemente pensamos em eficiência:
menos cliques, menos digitação, menos planilhas, menos trabalho manual.
Tudo isso é importante.
Mas existe uma pergunta anterior:
"O que exatamente essa pessoa acredita que está fazendo?"
Essa pergunta muda bastante o projeto.
Porque processos reais possuem contexto.
Existem exceções que nunca foram documentadas.
Existem decisões que parecem pequenas, mas carregam conhecimento.
Existem informações que o sistema atual nem registra, mas que o usuário considera fundamentais.
Se ignorarmos tudo isso e simplesmente automatizarmos os passos visíveis, podemos construir uma solução que reproduz a mecânica do processo sem reproduzir o entendimento necessário para executá-lo.
Primeiro entender. Depois mudar.
Talvez uma boa ordem para projetos de transformação seja diferente daquela que normalmente imaginamos.
Em vez de:
Problema → Nova solução
poderíamos pensar:
Modelo atual → Compreensão → Automação → Aprendizado → Transformação
Primeiro precisamos entender como o trabalho acontece.
Não apenas como deveria acontecer segundo um procedimento.
Precisamos descobrir como ele realmente acontece.
Quais conceitos existem?
Quais decisões são tomadas?
Quais exceções existem?
O que o usuário considera importante?
O que ele consulta antes de tomar uma decisão?
Só depois disso começamos a desenhar a automação.
A primeira versão não precisa ser a versão final
Isso traz uma consequência interessante.
Talvez a primeira solução não precise transformar completamente o processo.
Ela precisa criar uma ponte.
Se uma pessoa está acostumada a registrar:
Cliente → Projeto → Problema → Solução → Prazo
talvez a primeira versão do sistema deva respeitar exatamente essa sequência.
Por trás dela, podemos automatizar consultas, cálculos, integrações, validações, notificações e tudo aquilo que não precisa mais ser manual.
Para o usuário, porém, existe uma sensação importante:
"Eu sei onde estou."
Essa familiaridade reduz o custo da mudança.
E, depois que a pessoa já confia na solução, podemos começar a questionar o próprio processo.
É aqui que a transformação realmente começa
Depois da primeira automação, algo interessante acontece.
Agora temos dados.
Temos observações reais.
Temos usuários utilizando o sistema.
Começamos a enxergar padrões que antes estavam escondidos.
Talvez uma etapa inteira exista apenas porque dois sistemas não conversam.
Talvez determinada informação seja preenchida manualmente, mas pudesse ser obtida automaticamente.
Talvez duas áreas utilizem conceitos diferentes para falar da mesma coisa.
Talvez determinado relatório exista apenas porque ninguém confiava nos dados disponíveis.
Agora podemos começar a melhorar.
Não estamos mais propondo uma mudança baseada apenas em uma ideia abstrata de como a empresa deveria funcionar.
Estamos propondo uma mudança baseada naquilo que aprendemos sobre a operação.
Da automação para a transformação
Existe uma diferença entre impor um novo processo e construir um novo processo.
No primeiro caso, alguém chega com uma solução pronta e espera que as pessoas se adaptem.
No segundo, começamos pela realidade existente.
Capturamos o conhecimento.
Organizamos.
Automatizamos.
Observamos.
E então transformamos.
É uma evolução gradual.
Algo parecido acontece na aprendizagem: uma mudança precisa deixar de ser apenas um estímulo passageiro para realmente se incorporar ao sistema.
Em uma empresa, talvez uma transformação também precise deixar de ser apenas uma nova ferramenta para se tornar parte da maneira como as pessoas trabalham e pensam.
Respeitar não significa preservar
Existe uma distinção importante aqui.
Respeitar o modelo mental do usuário não significa preservar todas as limitações existentes.
Não significa manter uma planilha ruim porque as pessoas estão acostumadas com ela.
Não significa evitar mudanças.
Significa entender que existe um custo cognitivo para qualquer transformação.
Quando mudamos uma ferramenta, podemos estar mudando também conceitos, hábitos, responsabilidades e decisões que foram construídos ao longo do tempo.
Uma boa solução considera esse custo.
Ela não trata o usuário como alguém que precisa simplesmente "se adaptar".
Ela trata o usuário como parte do sistema que está sendo transformado.
Uma ponte entre dois mundos
Talvez essa seja uma das responsabilidades mais interessantes de quem trabalha com tecnologia.
Estamos constantemente entre dois mundos.
De um lado, existe a realidade do negócio:
"É assim que fazemos."
Do outro, existe a possibilidade tecnológica:
"Poderíamos fazer assim."
Nosso trabalho não deveria ser simplesmente escolher um dos lados.
Deveria ser construir a ponte entre eles.
Traduzir o modelo mental existente para uma estrutura mais organizada.
Automatizar aquilo que não precisa mais ser manual.
Preservar aquilo que ajuda as pessoas a compreender o processo.
E, gradualmente, mostrar que existe uma forma melhor de fazer.
A primeira entrega deve reduzir a fricção da mudança
Talvez essa reflexão possa ser resumida em uma regra simples:
A primeira entrega deve reduzir a fricção da mudança; as próximas podem ampliar a mudança.
Uma primeira solução familiar pode parecer menos revolucionária.
Mas ela pode ser justamente aquilo que permite que uma transformação maior aconteça depois.
Porque a primeira entrega cria confiança.
A confiança cria abertura.
A abertura permite questionar o processo.
E o questionamento permite transformar.
Talvez seja assim que uma empresa aprende
Volto então àquela primeira reflexão sobre memória.
O cérebro não trata toda informação da mesma maneira.
Algumas mudanças são passageiras.
Outras se consolidam.
Algumas informações desaparecem.
Outras passam a fazer parte da estrutura que usamos para interpretar o mundo.
Talvez uma organização funcione de maneira parecida.
Podemos instalar uma ferramenta e, ainda assim, nada mudar de verdade.
Podemos criar um procedimento e ninguém incorporá-lo.
Podemos produzir documentação e ela continuar distante da operação.
Ou podemos construir soluções que, pouco a pouco, alteram a maneira como as pessoas trabalham.
Nesse caso, a tecnologia deixa de ser apenas uma ferramenta.
Ela começa a fazer parte da memória operacional da empresa.
Não é sobre preservar o passado
Respeitar o modelo mental não significa ter medo de mudança.
Significa reconhecer que transformação não acontece apenas quando construímos algo novo.
Ela acontece quando aquilo que construímos consegue ser incorporado à realidade de quem precisa utilizá-lo.
Podemos mudar profundamente uma operação sem exigir que tudo seja esquecido no primeiro dia.
Podemos começar pelo que o usuário conhece e terminar em algo que ele nunca imaginou.
A diferença está no caminho.
Talvez o papel da tecnologia não seja simplesmente levar uma empresa para um lugar melhor.
Talvez seja construir uma ponte suficientemente boa para que as pessoas consigam chegar lá.
O princípio
No fim, a ideia que ficou para mim é simples:
Antes de transformar um processo, entenda o modelo mental de quem o executa.
Primeiro, capture.
Depois, organize.
Então, automatize.
Observe o que acontece.
E só depois transforme aquilo que realmente precisa ser transformado.
Não porque o modelo atual seja necessariamente bom.
Mas porque é muito mais fácil construir uma mudança duradoura quando começamos entendendo onde as pessoas estão.
Entrar pelo problema que o cliente conhece. Permanecer pela melhoria que ele ainda não imaginava.
Talvez uma boa solução não seja aquela que simplesmente cria um processo melhor.
Talvez seja aquela que consegue fazer com que um processo melhor passe a fazer sentido para quem vive aquele processo todos os dias.