| path | title | subtitle | date | tags | banner | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
/analisando-trade-offs |
Analisando trade-offs |
E como a tomada de decisões baseada em dados e analise de impactos positivos e negativos pode ajudar a longo prazo |
2020-08-05 |
|
|
Fazer decisões é comum. Quando você trabalha em um time que lida com produtos não é diferente e durante o crescimento desse produto você precisará fazer escolhas (ou pelo menos demonstrar sua opinião em algum momento).
Nem sempre ou quase nunca a escolha agradará a todos e isso também é comum. Geralmente existem diversas pessoas envolvidas nesses produtos e cada uma delas tem o papel de prezar por um pedaço específico de cada "entregável", sejam as pessoas que o desenvolvem, as que cuidam do alinhamento com o produto e a empresa como um total, a liderança ou qualquer outra pessoa que seja responsável e/ou interessada no crescimento desse produto (os tão falados stakeholders).
No entanto, medir alguns pontos e analisar os melhores e piores cenários de cada escolha pode ajudar e a ideia de hoje é comentar um pouco sobre o que eu, particularmente, levo em consideração quando estou participando dessas decisões.
Se traduzirmos trade-off veremos, muito provavelmente, que significa "troca". É um termo comumente utilizado para indicar uma decisão em um cenário onde uma escolha é feita em detrimento de outra.
Algo muito comum nesses cenários que comentei, onde precisamos realizar entregas para pessoas usuárias de um produto mas, ainda assim, manter uma qualidade técnica desses entregáveis.
Dito isso, podemos começar a analisar algumas coisas que podem nos ajudar em um cenário de decisão.
Antes de qualquer discussão é importante ter certeza que você entendeu o problema e todas as peças que estão envolvidas no jogo.
A maioria das vezes as decisões não vão depender somente do time que você faz parte e pode ser que você não tenha todo o contexto necessário dos outros times e/ou sistemas relacionados.
Vale a pena "fazer a lição de casa" e tentar entender o cenário completo pra que, quando uma reunião ou discussão realmente aparecer.
Isso serve não apenas para embasar suas opiniões, mas também para você se sinta mais confortável para palpitar e opinar sobre o que acha ou não válido (e trazer, de fato, argumentos relevantes).
É mais fácil avaliar o jogo quando todas as cartas estão na mesa.
Analise a situação de fora por alguns instantes e tente ver quais opções são viáveis (e até mesmo quais são inviáveis). A ideia nesse primeiro momento é tentar trazer à mesa qualquer ideia que possa resolver esse problema, antes de se prender aos detalhes técnicos ou funcionais.
Tenha certeza de esmiuçar tudo o que acha válido para resolver um problema para que, aí sim, a parte da tomada de decisão e análise das opiniões comece a entrar em cena.
Mesmo a ideia mais perfeita terá algum ponto negativo.
Geralmente, zelar pelo aspecto técnico indica um tempo maior gasto refinando um produto antes de uma entrega. Assim como não se preocupar com o código que você desenvolve também indica um produto com uma qualidade inferior e/ou com dívidas que você precisará pagar no futuro.
É importante levar em consideração as diversas "caras" que um produto tem ao tomar uma decisão. Se coloque no lugar das pessoas envolvidas com o seu negócio: as que vão utilizar essa nova funcionalidade, as que de fato desenvolvem esse produto, as que alinham expectativas dos responsáveis com as entregas, a liderança e até mesmo as pessoas que só querem ver o produto prosperar.
As decisões nunca vão agradar a todos, mas tendem a ser escolhidas por sanar maior quantidade de dores dos responsáveis envolvidos. Ou seja, tente cobrir em suas decisões o maior número possível dessas "caras" que comentamos.
Com certeza isso trará uma força em sua argumentação e mostrará o valor de uma opinião perto de outras. Afinal, se seu produto e/ou negócio existe é por que ele resolve o problema de alguém.
Confirme que ideias foram entendidas e tenha certeza que todas as pessoas estão cientes de todas as perdas e ganhos de cada decisão.
Isso facilmente evita retrabalhos futuros e garante que todo mundo está ciente do rumo que uma decisão pode tomar e quais mudanças nas demandas ou cenários imprevistos podem ocorrer.
Essas perdas (em alguma parte do produto) causadas por uma escolha podem e devem ser resolvidas no futuro.
Gerar refinamentos, dívidas técnicas ou qualquer insumo que seja resolvido e priorizado no futuro do seu backlog é essencial e vai fazer parte do seu dia-a-dia quando essas decisões são tomadas (do ponto de vista técnico, são as tão faladas dívidas técnicas ou tech debts).
É essa disciplina de olhar para detalhes não priorizados de uma decisão e trazê-los de volta como uma demanda futura que faz com que o alinhamento entre o produto e as pessoas relacionadas seja mantido. É comum que, ao ignorar esses detalhes, produtos e funcionalidades acabem virando um "frankenstein" com diversas pontas soltas ao longo do tempo.
Nem sempre teremos a melhor entrega no ponto de vista técnico, mas com certeza precisamos conciliar decisões de negócio com as tarefas e funcionalidades que nosso software precisa. Tudo isso sem deixar de pensar e construir um sistema que seja fácil de trabalhar e crescer a longo prazo.
Essas decisões costumam acontecer de forma mais corriqueira do que percebemos, às vezes uma pequena discussão via texto ou em uma pequena reunião já é o suficiente para trazer algumas decisões ao jogo.
Espero que com tudo isso você possa se sentir mais confortável em debater opiniões e apresentar seus pontos de vista quando precisar!