Apaixonado por tecnologia. Mas ciente de que, ela não vale pra nada.

Eu sempre fui apaixonado por criar coisas também sempre fui muito curioso.

Acredito que a combinação dessas duas características explique boa parte da minha paixão por tecnologia, consigo perder horas facilmente diante do meu simples notebook.

Posso estar estudando uma arquitetura nova, tentando entender um conceito ou apenas evoluindo algo que aprendi há algum tempo.

Para mim, estudar é um hobby. Existe algo muito foda na possibilidade de começar apenas com uma ideia e, algumas horas depois, ter alguma coisa funcionando diante de você. Talvez seja por isso que, durante muito tempo, eu tenha acreditado que saber programar me permitiria resolver qualquer problema.

Se alguém apresentasse uma dificuldade, eu poderia construir um sistema, se o processo estivesse lento, eu poderia automatizá-lo, se as informações estivessem espalhadas, eu poderia criar um dashboard , o código seria o caminho entre o problema e a solução.

Parecia lógico, mas faltava uma parte importante nessa equação:

Entender o problema.

Tecnologia não cria valor sozinha, foi participando de alguns programas de inovação que comecei a enxergar tecnologia de outra forma. Até então, minha atenção estava quase sempre na solução.

Qual arquitetura usar?

Qual linguagem escolher?

Como integrar os sistemas?

Quanto tempo levaria para desenvolver?

Essas perguntas são importantes, mas todas elas partem de uma suposição perigosa: a de que já entendemos o que precisa ser resolvido.

Muitas vezes, não entendemos. Uma solução pode ser tecnicamente brilhante, utilizar as ferramentas mais modernas e ter uma interface impecável.

Ainda assim, pode não gerar valor algum, porque tecnologia não corrige um problema mal compreendido, ela apenas constrói alguma coisa em cima da interpretação que fizemos dele.

Se a interpretação estiver errada, podemos passar meses construindo com excelência na direção errada.

O cliente quer pular a janela!

Quem já passou algum tempo comigo provavelmente ouviu esta analogia.

Imagine que você está em uma sala com um cliente, tentando entender o que ele precisa.

Durante a conversa, ele diz:

“Eu quero pular a janela.”

A primeira reação de alguém apaixonado por soluções pode ser começar a pensar em como ajudá-lo.

Qual é a altura da janela?

Precisaremos construir uma escada?

Existe alguma forma mais segura de fazer o salto?

Quanto peso a estrutura deve suportar?

Podemos automatizar a abertura da janela?

Talvez seja possível criar um sistema com inteligência artificial para identificar o melhor momento para pular.

Tudo parece muito eficiente.

Só existe um problema:

Talvez ele não queira pular a janela. Talvez ele apenas queira sair da sala.

Pular a janela é a única solução que ele conhece, se aceitarmos o pedido sem entender o que existe por trás dele, podemos construir a melhor escada, instalar sensores e criar o salto mais seguro possível.

Enquanto isso, existe uma porta do outro lado da sala, o pedido não é o problema

Isso acontece o tempo inteiro no desenvolvimento de software.

O cliente pede um aplicativo. Uma área solicita um dashboard.

Alguém diz que precisa de inteligência artificial. A equipe quer automatizar determinado processo.

Esses pedidos chegam com o formato de solução. E é tentador começar a construir imediatamente.

Afinal, desenvolver é o que sabemos e amamos fazer.

O problema é que o aplicativo, o dashboard, a IA ou a automação podem ser apenas a janela, antes de escolher a tecnologia, precisamos entender o que a pessoa realmente está tentando fazer.

Ela quer tomar uma decisão mais rápido?

Reduzir erros?

Evitar retrabalho?

Atender melhor o cliente?

Ter mais previsibilidade?

Sair da sala?

A resposta muda completamente o que devemos construir.

E, em alguns casos, mostra que não precisamos construir nada.

Nem todo problema precisa de software

Essa talvez seja uma conclusão estranha para alguém que trabalha construindo software. Mas nem todo problema precisa de tecnologia.

Às vezes, o processo está mal definido, as pessoas não sabem quem pode tomar determinada decisão , duas áreas trabalham com objetivos conflitantes.

A informação existe, mas ninguém confia nela, ou a empresa está tentando automatizar uma atividade que nem deveria continuar existindo.

Colocar tecnologia nesse cenário pode aumentar a velocidade.

Só que velocidade na direção errada não é progresso.

É apenas uma forma mais rápida de se afastar do resultado.

A inteligência artificial torna essa reflexão ainda mais importante.

Hoje conseguimos criar protótipos, sistemas e automações em uma velocidade absurda.

Isso é incrível, mas a redução do custo de construir não reduz o custo de construir a coisa errada.

Na verdade, pode aumentar o risco, como ficou mais fácil produzir, começamos antes de entender.

Apaixonado, não iludido

Continuo apaixonado por tecnologia.

Continuo gastando horas estudando, testando e criando coisas no meu notebook, não quero deixar de fazer isso, mas hoje tento separar paixão de deslumbramento.

Ser apaixonado por tecnologia não significa acreditar que ela seja a resposta para tudo, significa também conhecer seus limites.

Uma ferramenta não entende sozinha o contexto de uma empresa, não decide qual problema merece ser resolvido.

Não cria alinhamento entre pessoas, não transforma uma estratégia ruim em uma boa estratégia.

Tecnologia amplifica, pode amplificar uma operação bem desenhada.

Pode aumentar a capacidade de um time, pode reduzir custos, criar experiências e abrir modelos de negócio que antes pareciam impossíveis.

Mas também pode amplificar desperdícios, decisões ruins e processos que nunca deveriam ter sido automatizados.

Sozinha, ela não sabe a diferença, a engenharia começa antes do código

Hoje acredito que o trabalho de quem constrói tecnologia começa muito antes de abrir o editor.

Começa na conversa, na observação.

Nas perguntas que parecem simples, mas que evitam meses de desenvolvimento desnecessário.

Por que isso precisa existir?

Quem vive esse problema?

O que acontece hoje quando ele aparece?

Qual resultado realmente queremos produzir?

Como saberemos se o problema foi resolvido?

A parte difícil nem sempre é escrever o código.

Muitas vezes, é resistir à vontade de escrever código antes de entender a realidade.

Essa visão também mudou a forma como trabalhamos na Origami Lab.

Nosso papel não é apenas receber uma lista de funcionalidades e transformá-la em software.

Precisamos entender o negócio, questionar o pedido e descobrir o que está por trás da solução que chegou pronta.

Às vezes, a resposta será um produto digital complexo.

Em outras, uma integração mais simples.

E haverá situações em que a melhor recomendação será não construir.

Isso pode significar vender menos código no curto prazo.

Mas também significa criar soluções que tenham motivo para existir.

A porta

Se o cliente pede para pular a janela, nosso trabalho não é simplesmente construir uma escada.

Também não é responder imediatamente que a ideia está errada, precisamos entender por que ele quer sair, o que existe fora da sala e quais caminhos estão disponíveis.

Talvez a janela realmente seja a melhor saída, talvez não exista uma porta, talvez exista uma emergência que justifique o salto.

Mas só conseguiremos saber depois de compreender o problema.

A tecnologia entra depois.

Como ferramenta.

Como alavanca.

Como meio para transformar uma intenção em resultado.

Nunca como substituta da compreensão.

Eu continuo acreditando que tecnologia pode resolver problemas enormes, só deixei de acreditar que saber programar é suficiente para descobrir quais problemas deveriam ser resolvidos.

Porque uma tecnologia incrível aplicada ao problema errado continua sem valer muita coisa, mesmo que a escada fique perfeita.

E hoje com o advento da IA, tem uma frase bem interessante que é:
”Inteligência artificial é igual a um microfone, ela vai amplificar, se você não souber cantar meu amigo, você só cantará mais alto e com uma péssima qualidade”

E essa foi mais uma dobra de: entender por que alguém quer sair da sala antes de construir a escada para a janela.

Nos vemos na próxima quinta, às 10:10