Decisões Técnicas – Você está focando primeiro no problema ou na solução?

Será que é preciso focar no problema ou na solução? Veja dicas do que é preciso se atentar na hora de pensar decisões técnicas

Uma das principais tarefas de uma pessoa engenheira é selecionar soluções relevantes em meio a alternativas. Neste contexto, é fácil perceber por que as habilidades de análise e avaliação são tão exigidas destas e de outras profissionais técnicas.

 

Quando empregadas de forma criteriosa, essas habilidades se tornam indispensáveis para o tipo de decisão que com frequência se espera que essas profissionais tomem: as chamadas decisões técnicas.

 

Um destino e muitos caminhos

 

Imagine que você quer ir de um lugar para outro e há muitas estradas que podem te levar ao seu destino.

 

A princípio, pode não parecer difícil escolher qual estrada pegar — afinal, como disse anterior, todas levam ao mesmo lugar. Mas acrescente restrições como gastar o mínimo de combustível, chegar em um determinado horário e correr o menor risco, e você terá um problema interessante em mãos.

 

A tomada de decisões técnicas — ou seja, quando tentamos resolver um problema escolhendo uma tecnologia, ferramenta, estrutura, linguagem de programação, serviço, arquitetura ou padrão — não é muito diferente disso.

 

Precisamos escolher a “estrada certa” e, às vezes, só saberemos com certeza quão boa ou ruim foi a nossa escolha quando tivermos percorrido um terço do caminho elegido.

 

Não afirmo ter respostas fáceis para qual estrada escolher, mas há alguns padrões que vi se repetirem com bastante frequência nos últimos dez anos como profissional — e são eles que eu compartilho com vocês aqui. 

 

Vale salientar que é mais fácil dizer do que fazer e alguns desses erros geralmente são óbvios apenas analisando o passado.

 

Atente-se a qual problema é preciso resolver

 

O foco da tomada de decisão técnica não é sobre qual ferramenta escolher , mas sim sobre qual problema resolver. Uma vez que ele tenha sido bem definido, avaliar as possíveis soluções torna-se muito mais fácil.

 

Ter uma compreensão sólida do problema que realmente precisa ser resolvido pode ser muito mais difícil do que se pode reconhecer, especialmente quando um grande número de “soluções” está disponível.

 

É mais fácil do que nunca, na era atual, colocar a carroça na frente dos bois. Os riscos de começar com uma solução primeiro para depois encontrar um argumento convincente para, de alguma forma, adaptar o problema a essa resposta escolhida são inúmeros. Tempo de colaboradores e sprints desperdiçadas, complexidade adicional a uma “solução” que pode acabar vindo a não ser uma resposta, acúmulo de débito técnico, bem como os custos operacionais e de manutenção, são alguns deles. 

 

E, no entanto, isso é algo que acontece com mais frequência do que muitos gostariam de reconhecer. Certamente, eu já passei por esse tipo de problema mais vezes do que posso contar.

 

Saiba priorizar o que resolver

Mais desafiador do que decidir qual problema resolver é escolher o que priorizar. É comum que um problema venha acompanhado de uma lista de coisas que precisam de correção ou melhoria. A priorização torna-se fácil quando temos uma compreensão completa do impacto de cada um dos itens que estamos tentando classificar.

 

Frequentemente, as coisas que estão “visivelmente” quebradas ou abaixo do ideal podem ser uma pista falsa ou um sintoma de problemas subjacentes mais profundos. 

 

Um exemplo desse caso aconteceu comigo recentemente. Eu estava trabalhando em uma tabela que tinha colunas com dados nulos. A ferramenta me apresentou como solução retirar os nulos. Ao investigar mais a fundo, descobri que o erro estava na regra de negócio do processamento. Bastou corrigi-lo e os dados que antes eram nulos passaram a aparecer corretamente. Se o meu foco tivesse sido corrigir os nulos, eu poderia simplesmente ter removido esses dados da tabela — e a “solução”  teria atacado apenas a superfície do problema.

 

A coisa mais fácil de fazer é resolver o problema mais “visível”, quando o problema real está à espreita sob a superfície. É como um iceberg.

 

 

É importante priorizar os “problemas reais” para a solução, não apenas o que pode parecer quebrado na superfície. No entanto, é impossível adivinhar todas as possíveis questões que nosso sistema pode encontrar durante sua evolução. A tomada de decisão baseada em dados funciona melhor quando apoiada em boa intuição e instintos, principalmente ao tomar decisões enquanto perde bits de dados importantes.

 

Deixe o passado no passado

 

Quanto mais tempo trabalho na área da tecnologia, mais percebo que poucas coisas são absolutas. Na verdade, costumo dizer que “todas as afirmações absolutas estão erradas”. 

 

Quando as pessoas pensam em criar soluções, elas tendem a pensar nas maneiras como resolveram problemas no passado. Muitas vezes, a coisa mais fácil de fazer é se convencer de que uma solução que funcionou para outra organização que enfrentou problemas semelhantes é a melhor para o obstáculo em questão. Mesmo que ele seja aparentemente igual na superfície, a base está cheia de detalhes — ignorá-los pode nos levar a não perceber que uma solução que outrora funcionou não se aplica no contexto atual.

 

Todes nós já trabalhamos com aquela pessoa que — muitas vezes, irritantemente — sugere: “Na [empresa anterior], nós …”. O problema é que essas pessoas não percebem que os requisitos para o que você está tentando construir hoje devem orientar sua tomada de decisão, não apenas o que você já sabe.

 

Não caia na falácia de que tudo é útil e agradável

 

Nem todo trabalho útil será agradável, e nem todo trabalho agradável será necessariamente útil para a empresa.

 

Basicamente, essa falácia se resume a pessoas confundindo o tempo que elas deveriam estar focadas no entendimento de um problema com o tempo onde elas podem aplicar a sua tecnologia favorita e acabar apresentando uma “solução” que resolve apenas a ponta do iceberg.

 

O ideal, nesse caso, é pedir à pessoa engenheira que forneça evidências suficientes sobre como a proposta contribuirá para o problema, e que apresente um plano detalhado sobre os custos de manutenção, a maturidade das ferramentas, a facilidade de depuração, e, se possível, benchmarks. 

 

Calibre a rota em caso de erros

 

Apesar dos melhores esforços, às vezes os erros são inevitáveis. Errar, corrigir o erro e seguir em frente é importante.

 

Já vi — e fiz parte — de projetos que claramente começaram errados. O problema é que, em um deles, a equipe só percebeu isso quando o projeto já estava na metade! A única opção era seguir em frente e ir trocando o pneu com o carro andando até ver o projeto concluído, mesmo quando isso significava que ele possivelmente  apresentaria vários bugs em produção.

 

É importante que os projetos — especialmente os grandes e aqueles que irão impactar muitas equipes da organização — sejam concebidos de maneira modular, e que cada tarefa possa ter sucesso individual, de modo que, ao falhar em uma dessas tarefas, a equipe consiga mudar a rota sem afetar o projeto como um todo. O que, novamente, é mais fácil dizer do que fazer.

 

Não se deslumbre com a solução perfeita

 

Normalmente, as pessoas engenheiras pensam no ajuste técnico como a principal e talvez a única razão para fazer uma escolha sobre como construir uma solução. 

 

No entanto, muitas vezes várias opções fornecem um ajuste técnico decente, mas não  necessariamente perfeito. E tudo bem. 

 

Às vezes, até identificamos que existe uma tecnologia perfeita para construir uma solução específica, mas há variáveis a serem consideradas, que podem até inviabilizar a sua criação.  Pode ser que essa solução nunca seja construída a tempo ou que ela nunca seja usada o suficiente pelas pessoas usuárias para justificar a dedicação, o trabalho e o tempo gastos para construir essa tecnologia perfeita. 

 

Lembre-se: a perfeição é um luxo. Uma boa pessoa engenheira entenderá como lixar os cantos nessas decisões.

 

Observe a maturidade da tecnologia

 

Algumas tecnologias podem parecer perfeitas no papel ou soar perfeitas se você ouvir as mensagens de marketing. Mas é comum a tecnologia não estar madura o suficiente para fazer todas as coisas que as pessoas afirmam que ela pode fazer. 

 

Às vezes, brincamos que a versão 3 de um produto é quando ele fica bom o suficiente para ser considerado. Nem sempre é tão extremo, mas no mundo atual de Produtos Mínimos Viáveis ​​(MVPs), Previews e até mesmo betas — agora antiquados —, é importante entender onde uma tecnologia está em seu ciclo de vida. 

 

O fato de ela estar no início não significa uma coisa ruim, mas pode acabar levando sua equipe a atrasos no projeto e até a retrabalho. Ou pode ser que a sua organização seja muito experiente tecnicamente e geralmente líder no uso de novas tecnologias — nesse caso, tomar essa decisão técnica pode ser parte de sua estratégia. 

 

A importância da solução e as habilidades da organização podem significar que escolher uma tecnologia que não esteja madura seja muito mais arriscado. Leve sempre em consideração que a maturidade de qualquer produto é importante, pois pode ter um enorme impacto no sucesso da solução a ser escolhida.

 

Quais os próximos passos?

 

“Mas, espere!”, você pode me dizer. “Neste ponto, ainda nem escolhemos a tecnologia! Não sabemos o que vamos construir!”. Isso pode ser verdade, mas você terá uma visão muito melhor do que é a solução quando souber o que precisa resolver. 

 

Usando o pensamento que você colocou para entender a solução em relação às situações e dicas acima, é provável que você tome decisões muito melhores do que se você simplesmente escolhesse a tecnologia primeiro.

 

Por fim, lembro a frase de Albert Einstein: “Se eu tivesse uma hora para resolver um problema, passaria 55 minutos pensando no problema e 5 minutos pensando nas soluções”.

 

 

Este conteúdo faz parte da PrograMaria Sprint Tech Leads.

 

O que você achou deste conteúdo? Deixe sua avaliação abaixo: