Manutenção Ágil – Parte 2: Uma nova perspectiva

No artigo anterior, eu defendi a ideia de que seria necessário repensar a forma como estamos tentando aplicar os princípios, práticas e métodos Ágeis para os contextos relacionados com a manutenção de nossos produtos de software.

Enquanto muitos confiam que a aplicação de um método Ágil é a resposta para dominar a complexidade desse tipo de ambiente, no mundo real, não é bem assim. Mas isso não significa que não podemos “ser Ágeis” nesse tipo de cenário. Desde que o “ser”, nesse caso, venha da apreensão dos princípios que fazem da Agilidade o que ela é, seguido de uma posterior materialização desses princípios em uma nova forma, devidamente adaptada, é claro, para o propósito em questão. Pense nisso como se o espírito Ágil pudesse encarnar-se em um outro corpo, formando uma nova parceria espírito-corpo capaz de fazer coisas novas. Dentre elas, aquelas coisas que você precisa para resolver seus problemas nesse tipo de ambiente.

Também mencionei no artigo anterior a crença comum do mercado de que “Kanban serve para manutenção”. Sim, também serve pra isso. Ao contrário do que se pensa, Scrum pode ajudar em processos de manutenção também. Mas ambos por si só não são suficientes – Scrum, sozinho nesse cenário, pode até ser perigoso. É preciso usar os métodos como repertório. Precisamos compreender com mais profundidade as peculiaridades do ambiente de manutenção para que possamos puxar dos métodos e práticas Ágeis, aquilo que vai nos ajudar a endereçar as necessidades concretas que temos em tais cenários.

Lembrando que em projetos de manutenção, temos cinco preocupações sempre presentes:

  • reagir rápido aos desastres;
  • ser flexível para absorver demandas urgentes;
  • ser leve no planejamento e na entrega de releases com ajustes e melhorias;
  • garantir a entrega continuada de novos projetos de expansão do produto;
  • Otimizar as questões técnicas do produto e melhorar o processo de trabalho.

Se fossemos seguir a ideia de implementar um método para resolver nosso problema, seria simples. No caso do Kanban por exemplo, daríamos visibilidade às demandas, encontraríamos pontos de handoff, mapearíamos os estágios do processo, limitaríamos o WIP e faríamos o trabalho fluir. Sim, isso precisa ser feito, mas o “como” é que é o grande problema, já que ele nem sempre é derivado do método em si, mas do entendimento do problema e de suas manifestações específicas. É preciso entender o sistema, como ele se forma e como ele atinge seu propósito.

Ao contrário do que muitos pensam, um produto de software não entra em manutenção quando ele é colocado em produção. No meu entendimento, o momento que define a transição do desenvolvimento para a manutenção é o ponto onde o negócio do seu cliente passa a depender do seu produto. Em outras palavras, quando seu software deixa de ser apenas “software” e passa a ser parte integrante e indissociável do negócio do cliente ou da empresa. Se você está adotando práticas Ágeis para desenvolver seu produto, isso acontecerá bem mais cedo do que você imagina.

É nesse momento de transição que o seu projeto muda a estrutura de riscos em que opera. Até esse ponto você tem uma composição de riscos que está ligada a questões associadas com ROI (Retorno sobre o Investimento). Ao transicionar para um cenário de manutenção, você começa a conviver com uma estrutura de risco completamente diferente, e ainda sem perder a composição anterior, que continuará atuando. Isso mudará, de forma definitiva e muito impactante, todo o seu modelo de gestão.

A pouco, nesse texto, eu descrevi cinco preocupações que estão sempre presentes em times de manutenção. Espero que se lembre. Pois saiba que a nova composição de riscos que seu projeto incorporará, assim que entrar em manutenção, está diretamente ligada a essas preocupações. Afinal, porque você acha que nos preocupamos com alguma coisa? A resposta é simples: a preocupação vem quando riscos se apresentam.

Estamos o tempo todo olhando para as demandas e tentando encontrar um jeito de processá-las o mais rápido possível. Só que quanto mais a gente entrega, mais demandas novas surgem, e mais problemas geramos para nós mesmos. Ninguém parece notar, mas quanto melhor ficamos em entregar, quanto mais eficientes ficamos, pior fica.

A alternativa é olhar para os riscos! Essa é a grande mudança de percepção que nos fará ter um novo olhar para a dinâmica de manutenção nos nossos times. As demandas que se apresentam para nós emergem da estrutura de riscos à qual estamos expostos nesse tipo de ambiente. O erro que cometemos é tentar desenhar sistemas que respondam às demandas quando, na verdade, o que precisamos é desenhar sistemas que respondam aos riscos aos quais nos submetemos. É o perfil de risco das demandas que nos ajudará a sempre fazer a coisa certa, tomando decisões que mantenham o sistema aderente a seu propósito.

A mudança de perspectiva, da gestão de demandas para a gestão de risco, é a grande chave para a Agilidade na gestão de softwares em manutenção.

Isso não quer dizer, de maneira nenhuma, que não processaremos as demandas no volume desejado, e com a eficiência necessária. Com esse novo olhar, seremos capazes de entregar sempre as demandas certas, aumentando a confiança no sistema, e diminuindo a pressão de volume que ele recebe. Eu vou detalhar esse modelo de foco em riscos e explicar como lidar com cada um deles no curso que darei sobre Gestão Ágil para Softwares em Manutenção.

No próximo artigo dessa série especial, falarei sobre o maior desses riscos: o risco de desastre. Ao falar sobre isso, terei a oportunidade de te ajudar a entender um pouco mais sobre a problemática da aplicação pura e simples do método sem a devida adaptação para o seu cenário.