Home » Insights » O dilema do time to market vs qualidade

O dilema do time to market vs qualidade

Índice

    A cada dia que passa temos menos tempo para lançar novas features e atualização de nossos produtos em produção. Velocidade pode nos fornecer bastante valor nos negócios, porém somente se for acompanhada de qualidade.

    Takt Time e Time to Market

    Takt time é um termo de origem alemã que refere-se ao bastão utilizado pelos maestros, na hora de marcar a velocidade ou cadência de uma orquestra.

    No sistema Lean Manufacturing, Takt Time simboliza o tempo necessário para que um produto seja produzido. Dentro do software, podemos dizer que Takt Time é o tempo necessário para que uma funcionalidade seja colocada em produção. Ou seja, é o tempo que um time precisa para que uma ideia de feature saia da especificação e vá para a utilização dos usuários.

    Time to Market é o tempo que um produto leva até chegar ao mercado.

    O risco de priorizar a velocidade (a curto prazo) perante a qualidade

    É muito comum que as empresas,na ânsia da busca pelos seus concorrentes, acabem priorizando a velocidade perante a qualidade. De fato, é muito importante nos dias de hoje gerarmos valor para nossos clientes e usuários cada vez mais rápido.

    Porém, quando ignoramos a qualidade para que tenhamos a falsa sensação de velocidade é que os problemas acontecem. Aquela condição que nos leva a fazer uma gambiarra ou não escrever aquele teste no nosso código pode fazer sentido de imediato, porém, não muito tempo depois você vai perceber que o sacrifício da qualidade naquele momento não trouxe nada além de ilusão. Dificuldade de manutenção, bugs e falta de performance, são alguns dos problemas de débito técnico que todos conhecem.

    Vamos imaginar um projeto de software, em que devido a uma pressão para lançamento, não foi pensado e nem realizado da melhor maneira, uma série de gambiarras e códigos sem qualidade foram feitos sem pensar no futuro. Depois de 6 meses o projeto cresceu, uma série de funcionalidades já estão em produção, você precisa colocar uma nova atualização no ar e você se depara com esse código:

    Imagine o tempo que você levará apenas para entender o que está acontecendo neste código, imagine arrumar ou implementar algo. Claro que eu usei um exemplo exagerado apenas para fins didáticos.

    Abaixo, simulei um gráfico de throughput para entendermos o que acontece nesses casos.

    No gráfico acima, ilustramos um caso (hipotético porém rotineiro) que no começo do projeto o time entregou mais tarefas, porém, com baixa qualidade. Dessa maneira, podemos observar que com o passar do tempo, a velocidade da equipe caiu drasticamente, por conta da dificuldade de manutenção do código.

    Como equilibrar time to market e qualidade?

    Como podemos ver, a falsa sensação de velocidade é péssima a longo prazo. Mas como podemos equilibrar a velocidade que precisamos para fazer do nosso negócio competitivo e manter a qualidade para que não a percamos durante o projeto?

    Metodologias ágeis

    O maior motivo de buscarmos essa falsa sensação é o desentendimento do que é realmente velocidade e geração de valor contínuo para o cliente. O que precisamos de verdade é fazer com que usuários possam experimentar novas funcionalidades o mais rápido possível. Ai que as metodologias ágeis como SCRUM e KANBAN entram, através de processos incrementais podemos lançar novas funcionalidade rotineiramente, dessa maneira não precisamos esperar 6 meses ou até mesmo 1 ano para descobrirmos se os usuários precisam ou não daquela nova feature.

    Entregas contínuas

    Para que possamos aproveitar 100% das metodologias ágeis precisamos automatizar aquele deploy em produção. Dessa maneira, conseguimos lançar novas funcionalidades praticamente em tempo real. Por exemplo, a Amazon, fez 1 novo deploy a cada 11,6 segundos em 2011, o que levou a companhia a testar muito mais com seus usuários.

    Segundo o artigo citado no link acima, esses foram os benefícios que as empresas que automatizam seu deploy encontram:

    • ~40% de redução de custo no desenvolvimento em geral
    • ~140% novos programas em desenvolvimento
    • 78% de redução no custo de desenvolvimento por programa
    • 5x de aumento de recursos que impulsionam a inovação

    Testes unitários

    Para que as entregas contínuas funcionem, precisamos que o sistema esteja muito bem testado, dessa maneira, testes unitários são os mais simples e recomendados de serem implementados.


    Publicado

    em

    por