Não é piada: o “sistema” que dá nome a este post aparece em uma embalagem de xampu. E me incomoda, a cada banho, há algumas semanas. Até xampu consegue fazer uma blindagem inteligente! Então por que seria tão difícil para algumas organizações isolar e proteger, ou seja, blindar um time de projetos? A questão passou a me atazanar com mais frequência depois que publiquei uma breve compilação sobre problemas mais comuns na adoção do Scrum. Aquele artigo passou batido pelo problema. Tentarei corrigi-lo agora. E vou fazê-lo através de um causo real minimamente maquiado por razões óbvias¹.
∞
A empresa YYZ, um imenso conglomerado com presença global, desenvolveu seu próprio ERP. Lá se vão anos desde que aquele imenso monolito viu a luz. Ele fora concebido para cuidar do núcleo do negócio e, claro, das finanças. Com o passar do tempo, ganhou inúmeras novas responsabilidades, da produção até a logística de armazenamento e entrega passando por tudo o que é possível existir entre estes polos. Ou, melhor dizendo, quase tudo. Não se aventurou a cuidar do RH, por exemplo. Apenas um detalhe. O fato é que o ERP, cimentado firmemente em um desenho Cliente/Servidor (de duas camadas e milhares de Stored Procedures), é grande. Quase imensurável.
São onze os times que cuidam da manutenção e evolução do sistema. Sete deles cuidam de verticais específicas, como Vendas, Administração e Produção, por exemplo. Os outros quatro “prestam serviços” para eles. Bem, para dizer a verdade, eles não são vistos assim na maior parte do tempo. Um deles é o Controle de Qualidade. E não é tão comum assim ver este “departamento” sendo percebido ou se apresentando como um “Prestador de Serviços”. A verdade é que ninguém lá dentro precisava de um consultor para informar que a qualidade e seu respectivo controle deveriam ser incorporados aos times. Acho que apenas a própria área de qualidade. Consultor? Retomemos o causo.
“Paulo, você nos ajuda a implantar o Scrum?” Claro, por que não? Mas, diga aí, por quê? Ops… perguntinha maldita, não? Alguns meses se passaram até que a contratação fosse fechada e, mais importante, até que a perguntinha maledeta fosse respondida:
Ter uma fila única de demandas- Saber o esforço que cada demanda consumiu
- Reduzir o tempo de entrega
- Fechar acordos de níveis de serviços (SLA) com áreas usuárias
- Tornar as demandas visíveis para as áreas usuárias
- Ter tempo para o planejamento estratégico
- Medir o desempenho dos integrantes das equipes
Rabisquei o diagrama acima para determinar uma sequência de trabalho. Conclui que a realização do item 3, a redução do tempo de entrega, favoreceria a satisfação de todos os outros requisitos. E que o fechamento de SLA’s (item 4) só seria possível depois que todos os outros objetivos fossem minimamente atingidos. Portanto, o próximo passo era descobrir a razão das entregas serem tão demoradas (60 dias, em média, entre o registro da demanda e sua entrega definitiva para os usuários).
Não nos custou um dia o diagnóstico dos quatro principais fatores que retardavam as entregas:
- As especificações, elaboradas por analistas de negócios, são muito extensas (e de pouca ou nenhuma utilidade após as entregas);
- A área de qualidade só sabe que algo é prioritário quando ouve gritos. No mais, administra uma fila que mistura tudo das sete verticais de negócios. E tem pouca gente para tanto trabalho, apesar de não cobrir 20% dos tipos de testes possíveis;
- Dada a complexidade da distribuição – várias unidades espalhadas geograficamente – é compilada e entregue apenas uma “versão” por mês; e
- Os desenvolvedores são atropelados diariamente por problemas, de bugs até o mal entendimento de determinadas funcionalidades pelos usuários, passando pelo que é mais grave: novas demandas urgentes.
Me sinto à vontade para descrever o causo principalmente porque sei que os quatro problemas acima podem apontar para um sem número de empresas ao redor do globo. Não há nada de particular aqui, o que pode tornar este artigo realmente útil. Voltando para a história.
Seria relativamente fácil solucionar os três primeiros problemas. Existe um padrão único para especificação de demandas. Requisitos imensos e minúsculos recebem o mesmo tratamento (burocrático), o que não faz sentido. Mais: toda a análise de impacto e definição do “como” (protótipos de telas, lista de alterações nos bancos de dados etc) é realizado pelos analistas de negócios, o que torna a vida dos desenvolvedores um sossego (e uma chatice só). Qualidade, o segundo problema, deveria ser incorporada (de fato e de direito) pelas verticais de negócios. Que deveriam ganhar também autonomia em relação a atualização de versões. Apesar do jeitão monolítico do ERP, vimos que era perfeitamente possível gerar mais de uma versão por mês. Daí a estimar (salivando) que seria possível uma redução de 60 para 15 dias do tempo médio de entregas foi um pulinho. Ingênuo pulinho.
O quarto problema – o atropelo das verticais de negócios por questões do dia a dia – se apresentou monstruoso logo no primeiro dia da experiência com o Scrum. A empresa YYZ tem uma bela política de “portas abertas” para todos. Aliás, mal existem portas (e paredes). O que gera um efeito dramático na área de TI: usuários aparecem a qualquer momento com seus choramingos e requisitos. E não atendê-los está fora de questão.
“Oras, Paulo, parece que fazes tormenta numa pequena caneca d’água! Não bastaria separar alguém do time ou parte do tempo de todo o time para o atendimento das demandas imprevisíveis?” Como, respondo perguntando, em um cenário onde elas consomem cerca de 80% do tempo útil de toda a equipe?
O papo segue na parte II. Inté!
∞
Observações:
- Não revelo a identidade de meus clientes de consultoria exatamente para ter a liberdade de tratá-los como causos, aqui no {finito} e em meus cursos e palestras.
- Não, o xampu com “Sistema de Blindagem Inteligente” não é meu, ok?
- “getting away from it all” é outro cartoon que surrupio do HikingArtist.com
