Uma abordagem financeira para tratar engenharia de software e débito técnico
O Débito técnico é um mecanismo de alavancagem de negócio, assim como a alavancagem financeira mediante crédito. Pois em ambos os cenários, essa manobra aumenta o potencial de lucro ou prejuízo mediante crédito, trazendo o resultado no tempo presente com o compromisso de quita-la no futuro.
Pessoas de tecnologia, em especial com foco em arquitetura tem uma aversão natural a decisões deficitárias tecnicamente, pois sabe o custo sob o tempo dessas escolhas.
Essa visão é limitada, pois, o problema não é contrair dividas, e sim a capacidade de paga-las em dia, e mais do que isso, contrair as dividas certas em favor de alavancagem do negócio, ou seja que gerem o maior valor sem comprometer o caixa operacional da empresa, que no caso de software é o tempo e esforço gasto para manter a operação funcionando.
Por outro lado pessoas não técnicas tendem a minimizar a complexidade de algumas decisões e acabam assumindo riscos e pagando uma taxa de juros muito alta por essas decisões.
Vamos pensar em engenharia como um mecanismo de geração de valor onde o seu capital é o tempo/esforço/experiência. Ou seja, você tem um caixa limitado de capacidade para distribuir esse esforço, que na melhor das hipóteses estará gerando mais valor. Portanto se você gasta 75% de sua capacidade produtiva resolvendo problemas de débitos, seu potencial real de gerar valor é de apenas 25%, que na verdade pode ser ainda menor, se considerar o desgaste emocional do time.
O cenário acima é realidade em muitas empresas e times no Brasil e no mundo que em algum momento optaram criar alguns débitos em favor da alavancagem, porém negligenciaram os riscos ou o caixa.
O efeito colateral disso é que a capacidade de pagar esse débito no longo prazo pode se tornar impraticável pois existe uma tendencia a gerar novas dividas para continuar operando, como juros do rotativo do cartão de crédito, e quando se dão conta, já estão super endividados.
Empresas com muito capital, costumam compensar essa ineficiência com uma operação de engenharia cada vez maior, escalando o negócio com pessoas.
Nesse aspecto o advento da transformação digital e a velocidade que ela demanda de gerar novos negócios e oportunidades, causou uma nova crise do software, diferente da vivida na década de 70, mas com muitas semelhanças.
Uma das grandes diferenças é que hoje temos muito mais acesso a informação que há 50 anos, porém temos ciclos de inovação e crises em ciclos mais curtos, bolhas nascendo e estourando em 4 anos, tecnologias e arquiteturas ficando obsoletas em menos de 10 anos, um mundo mais conectado e uma concorrência cada vez maior, além de uma escassez de profissionais, que colabora com o aumento da demanda reprimida.
Talvez o somatório de todos os fatores acima traduzam o momento da engenharia de software hoje, mas não deveríamos esperar uma grande crise para reagirmos, seja como negócio ou como engenharia. Bastaria que tivéssemos uma reeducação de produto e engenharia, algo parecido com uma reeducação financeira.
Mas qual a solução
De forma resumida, com um bom planejamento, estruturando negociando suas dividas, e reorganizando seu caixa.
Devemos projetar software com base no seu e seu ciclo de vida de negócio, nesse caso, se a proposta é um MVP para explorar uma demanda inexplorada, sabe de antemão que não faz sentido construir um software extremamente resiliente e modular. Uma forma de medir isso é negociar o SLA e SLO que tolere mais indisponibilidade, afinal, soluções rápidas, riscos altos, portanto a melhor medida são os indicadores de disponibilidade e de erros que são toleráveis.
Vale lembrar que reduzir o prazo de um projeto necessariamente consiste em reduzir escopo, seja ele funcional ou não, portanto, ao optar pela alavancagem por débito, tenha em mente que a taxa de juros que seus indicadores de disponibilidade gerarão para sua operação diária, sobretudo os não funcionais.
Já do ponto de vista de negócio, contraia dividas sem comprometer todo o caixa, e assuma riscos de disponibilidade aceitáveis que não comprometa muito a experiência do cliente e nem sobrecarregue sua operação e atendimento.
Referências
Engenharia de Confiabilidade do Google (SRE)
https://www.amazon.com.br/Engenharia-Confiabilidade-Google-Administra-Sistemas/dp/8575225170/ref=asc_df_8575225170/?tag=googleshopp00-20&linkCode=df0&hvadid=379787347388&hvpos=&hvnetw=g&hvrand=16517087642200465451&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1001754&hvtargid=pla-809202560056&psc=1
Lean Software Systems Engineering for Developers
https://www.amazon.com/Lean-Software-Systems-Engineering-Developers/dp/1484269322
