Uma das justificativas mais frequentes para os nossos “improvisos” do dia-a-dia, é a falta de tempo.
“Nós”, de tecnologia, argumentamos que “eles”, do negócio, criam prazos impossíveis de cumprir. Pelo menos com a qualidade que sabemos e queremos entregar.
É fato que “eles”, muitas vezes, assumem compromissos sem sentido e que agregam pouco ou nenhum valor. Mas, também é fato que, muitas vezes, há a tal “janela de oportunidade”! Ou seja, ou “eles” aproveitam uma oportunidade para “fechar” um negócio (acordo, contrato, …), ou a perdem em definitivo. Não podemos esquecer que não há negócio sem clientes. Também não podemos ignorar que o tempo em que funcionalidades ficam “represadas” aumenta o custo geral da operação.
Os acordos “deles” nos forçam a fazer as coisas de uma forma diferente da que faríamos. Implementamos soluções funcionais, entretanto que não são a mais apropriadas para um problema. Em momentos assim, nascem as dívidas técnicas.
É indicativo de senioridade saber reconhecer que, as vezes, precisamos mesmo contrair algumas dívidas técnicas para atender o negócio. Entretanto, também é indicativo de senioridade saber que temos a responsabilidade de gerenciar e pagar essas dívidas no momento certo.
“Nós” sabemos que dívidas técnicas reduzem o custo de desenvolvimento, mas aumentam o custo de manutenção. “Eles” não sabem, nem precisam saber disso. É nossa responsabilidade!
“Nós” sabemos que podemos até demorar menos tempo para implementar uma solução ruim. Entretanto, “nós” sabemos que vamos precisar de muito mais tempo e esforço para manter essa solução.
Dívidas técnicas, assim como as financeiras, geram “juros”. Precisamos de muita energia para pagar esses “juros” até que desejemos ou consigamos liquidar o “principal”. “Nós”, como profissionais, temos a responsabildade de demonstrar para “eles” que isso acontece.
Soluções técnicas geradas com dívidas, invariavelmente custam mais no longo prazo. O acúmulo de dívidas técnicas destrói valor para o cliente, para a empresa e para o desenvolvedor. É ruim para todo mundo. “Nós” precisamos explicar isso para “eles” de uma forma que entendam.
“Eles” são pouco sensíveis as dores que “nós” sentimos. Assim como “nós” somos poucos sensíveis as dores que “eles” sentem. É natural!
Depois de muitos anos de frustrações, entendi que “nós” só conseguiremos demonstrar para “eles” os impactos das dívidas técnicas usando expressões que “eles” entendem. Dívida, juro, custo, são termos muito sensíveis para “eles”, acredite. Deveríamos usar mais!
Como profissionais, “nós” temos responsabilidade de relacionar as dívidas técnicas de nossos sistemas e de montar planos de pagamento dessas dívidas. Caso contrário, seremos apenas um bocado de “chorões” que culpam “eles” pela nossa falta de capacidade para fazer o nosso trabalho.
“Nós” não podemos transferir a gestão das dívidas técnicas para “eles”. Nem podemos transferir decisão se devemos ou não pagar essas dívidas. Isso seria transferir uma responsabilidade que é nossa e intransferível. O máximo que podemos fazer é compartilhar algumas decisões, mas não todas.
O progresso, muitas vezes, implica em saber assumir as dívidas técnicas certas. A saúde financeira de nossos negócios depende da nossa capacidade de gerenciar e pagar essas dívidas (mesmo que seja contraindo dívidas “mais baratas”).
Em tempo, Há o “nós” e “eles”! Mas, quando se trata de dívidas técnicas, o preço é pago por “todos”.
Vim lendo e pensando, não existe “nós” e “eles” quando estamos todos no mesmo barco, então veio a conclusão do post, que foi perfeita! E mais um vez o post vem num momento muito oportuno para o meu momento. ???
Parabéns pelos posts e principalmente por este que coloca em foco um dos pontos que venho discutindo, conversando e debatendo tem algum tempo que é, “qual o nosso papel é responsabilidade na entrega de valor, pois com as ‘novas metodologias’ fica parecendo que a responsabilidade é da área de ‘negócio’”. Mas quem faz parte do negócio, somente “eles”? E se “eles” não existissem, “nós” existiríamos?
Já sugiro aqui uma palestra sobre o tema para a indústria de software.