Manutenção Ágil – Parte 3: Dominado pelo imprevisível, refém do caos

No artigo anterior dessa série, eu defendi a ideia de que, para lidar com a gestão no âmbito de um projeto de manutenção, é necessário uma mudança de perspectiva. Mais especificamente, é necessário parar de olhar para a demanda e começar a olhar para a rede de riscos a qual nos mantemos entrelaçados enquanto mantemos um produto de software.

Quando eu digo “parar de olhar para a demanda” o que quero dizer é parar de achar que absolutamente tudo precisa ser resolvido; que a meta é limpar o backlog e não dever nada; e que para alcançar esse estado utópico de eficiência, é preciso fazer mais, mais rápido, contratar mais gente, cortar a internet das equipes, distribuir mais horas extras e fazer mutirões aos sábados. Olhar para o risco implica uma gestão alinhada com o propósito do projeto, pensar no “pra quê ele serve” ao invés de “o quanto entregamos”.

Também mencionei que os riscos são o que está por trás das nossas preocupações, a causa delas. Ficamos preocupados porque intuímos risco. Como, junto do risco vem a possibilidade do sofrimento, a preocupação – também tecnicamente conhecida como ansiedade – é a resposta do nosso organismo a esse futuro incerto. A ansiedade nos coloca em estado prontidão. Isso é bom, porque nos mantém vivos, mas caso se torne parte do cotidiano pode gerar um efeito de longo prazo devastador, tanto psicologicamente para as pessoas, como socialmente para a organização. E isso é péssimo para os negócios que sofrem com desperdício, ineficiência e alta rotatividade.

O pensamento mais comum é o de que as coisas ruins que acontecem com nossos produtos são causadas por erros humanos. Alguns são, sem dúvida. Mas muito do que acontece é decorrente da própria estrutura de risco a qual nos submetemos e que, ingenuamente, tratamos como se fosse a mesma de um projeto como outro qualquer. Essa estrutura de risco que opera em projetos de manutenção gera um sistema de trabalho com suas próprias particularidades. É esse sistema singularizado por uma estrutura de riscos diferenciada que entrega os resultados que você obtém, não os indivíduos específicos da sua equipe.

Em um cenário de manutenção, estamos entrelaçados a uma estrutura de riscos que contempla:

1) O risco de nosso software (ou o seu mal-funcionamento) causar perda financeira direta ou perda irrecuperável de credibilidade a nós ou a nossos clientes.

2) O risco do produto (ou o seu mal-funcionamento) aumentar o custo ou a ineficiência para uma dada operação de negócio do cliente (perda financeira indireta) gerando uma redução em nossa credibilidade ou na credibilidade dos nossos clientes perante a quem eles atendem.

3) O risco do produto não acompanhar as mudanças que ocorrem no ambiente de negócio que ele suporta.

4) O risco do produto não permitir a expansão do negócio que ele suporta na direção de novas oportunidades, inovação ou ganho de eficiência e lucratividade. 

5) O risco do software não se ajustar ou evoluir tecnicamente de forma a se manter apto a dar conta de toda a rede de riscos em que ele opera. 

Há vários nomes para as demandas que surgem quando o risco (1) se manifesta: “bug crítico”, “pára-tudo”, “prioridade zero”, “emergência”. Quando tal evento não é tratado com prontidão, ele gera uma crise, e crises podem se gerar desastres. Já o risco (2) se reflete em demandas ou bugs que aparecem de pára-quedas e interrompem o planejamento da equipe. Na prática a diferença entre o (1) e o (2) é que, enquanto o primeiro interrompe um membro do time de forma imediata, o segundo interrompe o que foi planejado. (1) e (2) se referem às famosas demandas não-planejadas. 

O risco (3) se manifesta nas infindáveis demandas que não param de chegar e que mantém o seu backlog crescendo em uma velocidade maior do que você é capaz de dar conta. As demandas provenientes desse risco são planejáveis, mas extremamente voláteis em termos de prioridade devido a velocidade das mudanças e às disputas de interesses em torno delas.

O risco (4) surge na forma de grandes projetos que demoram meses (ou anos) para ficarem prontos. E a justificativa é sempre a mesma: “- Tivemos que parar isso pra resolver aquilo.”. Como são longos, esses projetos acabam sempre interrompidos em nome de outras demandas mais urgentes. Quanto mais eles são interrompidos, maior a chance de serem postergados ad infinitum. Uma conversa rápida com membros de uma equipe de manutenção revela a dramaticidade dessa situação:

– “Há quanto tempo esse projeto está em andamento?”, você pergunta

– “Acho que já faz quase 6 meses desde que começamos”, responde o desenvolvedor com naturalidade

– “E se você trabalhasse nesse projeto full time e sem nenhuma interrupção. Quanto tempo você acha que levaria?”

– “Ahh.. certamente dá pra fazer em mais ou menos 1 mês. Inclusive, essa foi a estimativa inicial que eu dei.”, conclui o frustrado desenvolvedor. 

Times de manutenção raramente conseguem entregar projetos novos. Há várias razões. A primeira grande razão é que “desenvolvimento de novos projetos” é bastante diferente de “manutenção de projetos já desenvolvidos”. Ambos requerem modelos de gestão e organização bem diferentes. Outra razão é que os riscos seguem uma hierarquia de dano potencial. Serão raríssimas as circunstâncias onde os riscos (1), (2) e (3) não superarão o risco (4) em impacto, especialmente no curto e curtíssimo prazo.

Por último, a falta de entendimento das leis que operam em um projeto de software também causa todo o tipo de disfunções de gestão. Nesse curto diálogo que eu usei como exemplo anteriormente, você já percebe várias dessas disfunções: o desenvolvedor trabalha sozinho no projeto (criando especialização, desmotivação e redução na qualidade do que está sendo feito); o projeto não está quebrado em pequenos entregáveis de curta duração (o que o expõe ainda mais às interrupções); e as estimativas são baseadas no tempo de execução previsto (touch time), ao invés de no tempo que o sistema produz (lead time). Quando o desenvolvedor diz “dá pra fazer em um mês”, o gestor na verdade ouve: “vou receber em um mês”. O que ambos não entendem é que, quem entrega o que se pede não é o desenvolvedor, mas um “sistema de desenvolvimento”, e que esse não está ligando nem para a boa-vontade do desenvolvedor, nem para o desejo do gestor de receber no prazo. A entrega será feita no tempo que o sistema leva, não no tempo que o desenvolvedor leva.

Com relação ao último risco, o (5), este nos mantém preocupados com a qualidade técnica interna do produto. Na medida que o tempo passa, o código do produto vai se avolumando em redundâncias, em aumento de complexidade do código e no surgimento de algoritmos complicados que ninguém quer mexer, pois qualquer alteração aumenta a probabilidade do risco (1).

Entendida então qual é a estrutura de risco que está envolvida no seu projeto de manutenção, o próximo passo é entender o argumento original que me trouxe até esse ponto, ou seja, porque implantar um método Ágil, seguir a receita, não é o caminho nesse cenário, e como fazer então já que essa não é a direção.

Para entender isso, vamos olhar com mais detalhes o risco (1), aquele que tem mais impacto, e cujo sinistro que vai passar por cima de qualquer idealidade de postura que não lide com a realidade concreta. Esse risco está relacionado com a necessidade que toda a equipe de manutenção tem que endereçar: lidar com desastres. Conforme eu já expliquei no artigo anterior, o que define o seu software como “em estágio de manutenção” é o fato de ele se tornar parte essencial do negócio para o qual ele serve. Se seu software não faz o que deveria fazer, o negócio sofre, perde dinheiro, credibilidade, posicionamento, etc.

Como você já deve ter ouvido falar, negócios giram. O propósito do software é apoiar o negócio a qual ele está ligado, mantê-lo girando. Esse giro é potencializado por ganhos de eficiência. E é aí que entra o seu produto. Ele aumenta a eficiência dos processos de negócio, fazendo aumentar a velocidade de giro e, consequentemente, a sua lucratividade. No entanto, para que isso aconteça, o negócio tem que se subordinar ao software, depender dele. E é aí que entra a primeira camada de risco: seu software não pode interromper o giro do negócio, nem ameaçar sua credibilidade ou sustentabilidade.

Assim, o risco 1 se manifesta quando seu produto causa a interrupção direta ou indireta da operação de negócio que ele apóia, gerando perda financeira direta, ou prejudicando-o a ponto de implicar em perda financeira futura ou em ameaça ao negócio como tal.

Um software de ponto de venda começa a travar na hora que o cliente precisa fechar uma venda? Um e-commerce erra no cálculo do preço de frete gerando cobrança a menor em centenas de pedidos? Um ERP calcula erradamente a guia de imposto a pagar pela empresas que o utilizam? 

Problemas como esse têm o potencial de se transformar em grandes crises em questão de horas. Quando a perda não é direta, pode vir na forma de redução da credibilidade ou da confiança no negócio, ou no produto ou até na capacidade da equipe de desenvolvimento de sustentar o negócio com a competência esperada. 

Equipes de manutenção convivem com o desastre iminente. Algumas sofrem com eventos dessa natureza semanalmente, ou até diariamente. Mas repare que não é possível eliminar completamente situações dessa natureza. Fazem parte de estrutura de risco do jogo. Embora todos os esforços para evitar sejam válidos, é muito importante estar preparado para responder a elas. Uma solução de contingenciamento para esse tipo de risco precisa ser construída.

Vamos supor que você resolva implantar o método Kanban, afinal todo mundo diz que “Kanban serve para manutenção”. Nesse caso, talvez você considere uma boa ideia usar uma classe de serviço expedite para endereçar essa questão.

Segundo a receita, demandas classificadas como expedite furam as filas e entram direto no sistema em um espaço de capacidade pré-reservado. Para que um sistema mantenha sua capacidade de produzir com certo ritmo e previsibilidade, é preciso limitar a quantidade de itens desse tipo no sistema.

O problema é que, assim como todas as práticas, o expedite é uma abstração, genérica, que só será de fato concreta quando adotada na prática no seu contexto. Uma equipe de manutenção conhece o quadro de riscos em que opera. Se você der essa receita como solução de gestão para uma equipe que sofre muito com esse tipo de incidente, ela saberá na hora que não vai funcionar e as pessoas resistirão. Se sua agenda for a de implantar o método, você usará todo o tipo de racionalização para descrever o quanto aquelas pessoas são fechadas para a mudança, para o novo. Elas poderiam ser Ágeis. Elas poderiam ser Lean. Elas escolhem o velho, entretanto. Aquele que tem lá os seus problemas, mas que as permite chegar ao dia seguinte, com o negócio no ar, girando.

Vamos deixar então uma raia de entrada com itens expedite sem uma limitação pré-estabelecida? Nesse caso você resolve o problema da existência de uma resposta imediata para a crise (mesmo que surja mais de uma em um mesmo período de tempo). Mas aí como a gente lida com o impacto disso no resto do sistema? Afinal, a prática existe da forma que existe por uma razão. Será que tudo não vai virar expedite e a equipe não vai ficar refém só de falsas emergências, impactando a entrega de outros tipos de demanda? Será que isso não vai afetar a previsibilidade do sistema? E as métricas?

Esse é um exemplo do fenômeno da impedância do método a qual me referi no artigo anterior. Quando o método não cobre o mundo real, é preciso parar de olhar para a solução e começar a focar no problema que precisa ser endereçado. Agora, repare que o exemplo que eu dei, o do expedite, tem uma impedância bem pequena. Não é a solução para esse tipo específico de problema, mas está bem próximo. Imagine, então, quando alguém propõe que o time de manutenção em questão deveria passar a usar o Scrum como método de trabalho. A discrepância, nesse caso, entre o método e a realidade que ele cobre, é surreal.

Como eu tenho defendido desde o início dessa série de artigos, a solução não é implantar um método, é entender o problema com profundidade e usar o conhecimento trazidos pelos métodos para desenhar a solução, e é isso que veremos durante o curso de “Gestão Ágil para Softwares em Manutenção” que começa na próxima segunda-feira dia 04/02.

Espero te ver por lá! 😉