“É assim que a Google faz as páginas de destino. É o padrão da indústria.”
“Não conseguimos entregar antes de agosto. Somámos as nossas estimativas e obtivemos seis meses.”
“Espere apenas duas semanas por essa correção urgente. Não podemos interromper o ciclo de trabalho, caso contrário deixaremos de ser Ágeis.”
Todas estas afirmações são mentiras que a sua equipa de tecnologia lhe conta — e conta a si própria. Estes equívocos muito comuns resultam de um erro fundamental, endémico entre os engenheiros: a crença no “melhor”.
O melhor não é melhor (para todos)
Dentro de um computador, é a terra dos uns e dos zeros. Não há dúvida ou incerteza na aritmética e nas portas lógicas e, salvo um ocasional raio cósmico, a máquina é inteiramente determinista, seguindo o mesmo caminho repetidamente sempre que fornece as mesmas entradas.
Até a aleatoriedade aparente nos jogos ou nas simulações é, na verdade, uma ilusão. Se fornecer uma “semente pseudoaleatória” especificada ao Minecraft, por exemplo, obterá exatamente o mesmo comportamento em todas as partidas. É útil recordar que todos os membros da sua equipa de TI escolheram uma profissão que envolve este nível de certeza e previsibilidade; é literalmente impossível desempenharem as suas funções sem raciocinarem rigorosamente a partir dos primeiros princípios.
Mas fora do domínio computacional, deparamo-nos com seres humanos imprevisíveis e todas as apostas ficam sem efeito. Nenhuma equipa de vendas sequer consideraria aplicar a mesma apresentação ou abordagem a todos os potenciais clientes, e cada chamada para o serviço de apoio ao cliente é diferente e surpreendente. Os guiões e a formação ajudam os seus colaboradores a alcançar consistência, claro, mas é crucial variar a abordagem para corresponder a cada situação, como tantas organizações descobriram quando tentaram adotar a holocracia ou os métodos de produção enxuta para imitar o sucesso da Zappos e da Toyota e acabaram por fracassar redondamente.
Isto é tão verdade na criação de software como nas operações, nas finanças ou na estratégia: não existe uma única forma correta de conceber um ecrã de início de sessão, criar um relatório ou descobrir por que funcionalidades os clientes estarão dispostos a pagar. É por isso que os engenheiros conceberam uma variedade tão desconcertante de metodologias de software, como Scrum, Kanban, ShapeUp, o modelo Spotify, SAfE e centenas de outras, todas bem-sucedidas em alguns casos e desastrosas noutros.
Agora já consegue perceber por que razão nós, especialistas em tecnologia, somos vítimas da armadilha do melhorismo. Qualquer um de nós acharia apelativo acreditar que existe algures uma tábua de pedra com a resposta aos nossos problemas gravada nela, mas a certeza é perigosamente sedutora quando trabalhamos todos os dias com ferramentas e máquinas cujo próprio funcionamento depende de uma consistência absoluta. Mas como quebrar o hábito do pensamento binário?
Primeiro, questione sem cessar
Para tantos de nós, a tecnologia é apenas magia negra. Os engenheiros murmuram encantamentos estranhos sobre Kubernetes, zettabytes e, do vazio, fazem surgir sites, e-mails e pagamentos com cartão de crédito. Por isso, quando os feiticeiros nos dizem com autoridade que estão a seguir as “melhores práticas”, quem somos nós para duvidar deles?
A resposta é: VOCÊ! Tal como qualquer outro membro da equipa, os programadores de software precisam de feedback sobre se os seus planos e entregas estão alinhados com a estratégia da empresa. Não precisa de usar linguagem técnica para transmitir as suas reações e orientações; é responsabilidade deles aprender o suficiente sobre o seu mercado e os seus objetivos para poderem prestar-lhe contas de forma eficaz, usando português corrente. Não tenha receio de fazer todas e quaisquer perguntas sobre o que estão a priorizar, as razões para escolherem esta ou aquela tecnologia e, sobretudo, sobre a forma como esperam que o resto da empresa beneficie.
Acredito tanto no valor de fazer perguntas que mandei imprimir certificados sofisticados com folhas de ouro, concedendo autorização oficial para questionar os engenheiros sobre qualquer assunto, e distribuo-os sempre que posso. Apresento abaixo um exemplo. Se quiser um para a sua parede, envie-me um e-mail e eu enviar-lhe-ei um (gratuitamente!)
A seguir, jogue ao jogo do porquê
Depois de vencer o medo de fazer perguntas e aprender mais sobre a abordagem da sua equipa de tecnologia, está na altura de jogar ao jogo do “porquê”. As regras são simples e familiares a qualquer criança de cinco anos: primeiro pergunta o que um programador está a fazer e depois pergunta “porquê” repetidamente.
“Estou a substituir a nossa página de pagamentos.”
“Porquê?”
"Porque é ineficiente.”
“Porque é que é ineficiente?”
“Fazemos verificações desnecessárias que tornam os nossos tempos de resposta mais lentos.”
“Porque é que a velocidade é importante?”
"Porque os utilizadores desistem quando têm de esperar demasiado tempo para pagar.”
O sinal para parar é quando se chega ao dinheiro. Assim que ouvir “porque vai aumentar as conversões”, “porque mais clientes vão fazer uma atualização” ou “porque vamos reduzir drasticamente os custos de investigação”, ganhou. Se nunca chegar aí e terminar com “Não sei” ou “porque a Jane disse,”, foi você (não o engenheiro) que perdeu o jogo do “porquê”. Procure formas de aproximar muito mais a sua equipa técnica dos resultados do negócio, para que todos sejam vencedores da próxima vez que jogarem.
Depois de algumas rondas de “porquês”, começará a identificar padrões e lacunas. Por exemplo, trabalhei com uma equipa que estava totalmente focada em aumentar a sua taxa de conversão, mas ignorava completamente os custos. Não é de admirar que tenha ultrapassado largamente o orçamento com estratégias de anúncios nas redes sociais hiperotimizadas e demasiado complicadas para uma simples campanha de Natal.
É certo que os seus algoritmos complexos eram “melhores” a obter uma pequena vantagem de preço para determinadas palavras-chave, mas a fatura do Facebook foi um rude despertar quando chegou (incluindo custos por terem efetivamente feito cair alguns facebook.com servidores de anúncios com demasiados pedidos!). Quando identificar pontos cegos como estes, corrija as prioridades, cancele o que é desnecessário e reforce a mensagem de que a tecnologia tem de estar estreitamente alinhada com os seus objetivos de negócio.
Por fim, garanta a responsabilização
Agora que encontrou e eliminou as soluções tecnológicas “melhores” que, na realidade, não estão a funcionar para si, disponibilize formas simples para que os engenheiros lhe mostrem que continuam alinhados e no caminho certo. Repare que não falei em “responsabilizar a equipa técnica”, uma abordagem de apontar o dedo que me dá sempre vontade de me esconder debaixo da secretária mais próxima. Em vez disso, permita que os seus programadores prestem contas perante si. Por exemplo,
- Agende uma demonstração semanal das melhorias de TI, com os líderes das equipas a descreverem os benefícios para o negócio e a recolherem comentários seus e de outras pessoas.
- Crie um painel que apresente métricas importantes, como o tempo de atividade do sistema ou o número de chamadas atendidas, e peça frequentemente aos programadores que expliquem de que forma as suas ações melhoram os resultados.
- Crie uma trajetória para acompanhar o progresso dos projetos essenciais e recuperar rapidamente quando elementos fundamentais sofrem atrasos.
Uma estratégia clara para obter comentários frequentes e um foco nos benefícios empresariais reais e tangíveis garantirão que o seu investimento em TI não seja desperdiçado em projetos “melhores” inteligentes, mas inúteis. E se, tal como a maioria das empresas com que trabalho, está a investir milhões em tecnologia com resultados pouco claros, na melhor das hipóteses, não valerá a pena medir o retorno desse enorme investimento?
Subscreva o boletim informativo do The CTO Club para obter mais conselhos da nossa comunidade.
