TI Corporativa

Ξ Deixe um comentário

Procrastinação da solução

publicado por Bruno Amaral

Este é o 5o. artigo sobre Equipas de Performance – Procrastinação da solução está dividido em duas partes: A primeira parte trata-se de uma história do livro.

A máquina que mudou o mundo  de Dr. James “Jim” Womack contada por Jeff Sutherland em Scrum, a Arte de Fazer o Dobro do Trabalho na Metade do Tempo. E a segunda parte, separei três casos de procrastinação relacionados a Qualidade,

Visão e Prioridade.

..todos se unem em torno do ponto em que a esteira parou, não para reclamar com o sujeito que a paralisou, mas para resolver o problema.

Acerte de primeira!

No livro “A máquina que mudou o mundo“, Dr. James “Jim” Womack -, fundador e presidente da Lean Institute, conta-nos uma história sobre os perigos do retrabalho.

Jim e sua equipe passaram anos a viajar por vários países para analisar o maior empreendimento de fabricação já realizado por seres humanos: a produção de carros. Ele queria descobrir por que algumas empresas fabricavam carros mais rapidamente e com menos defeitos do que outras.

Hoje em dia, qualquer fabricante minimamente racional usa o que Jim resolveu chamar de “produção enxuta”, mas naquela época era tudo diferente. Uma das maiores discrepâncias entre os fabricantes estava no mercado de carros de luxo. No Japão, empresas como a Toyota, a Honda e a Nissan gastavam uma média de 16,8 horas a produzir um automóvel de luxo. As peças entravam em uma extremidade da fábrica e, cerca de 17 horas depois, um Lexus surgia na outra. E esses fabricantes tinham 34 defeitos a cada cem veículos. Nada mau.

Na Europa, porém, a história era diferente. Empresas como a Mercedes-Benz, a Audi e a BMW levavam 57 horas para produzir um carro e apresentavam 78,7 defeitos a cada cem veículos.

Por que os europeus demoravam tanto? E por que apresentavam tantos defeitos? A BMW não é conhecida por fabricar carros de baixa qualidade. Eis o motivo: em uma fábrica da Toyota, qualquer funcionário pode parar a linha de montagem quando surge um problema. Quando isso acontece, todos se unem em torno do ponto em que a esteira parou, não para reclamar com o sujeito que a paralisou, mas para resolver o problema. Ninguém quer que os carros fiquem prontos com defeitos a serem corrigidos depois. Solucionam o problema de uma vez e pronto, está resolvido para sempre.

Caso contrário, a mesma falha pode acabar a aparecer em centenas de veículos.

Nas montadoras europeias de carros de luxo, a fabricação era feita de uma maneira diferente. No fim da linha de produção, dezenas de funcionários a usar jalecos brancos circulavam a corrigir todos os defeitos. Eles se certificavam de que a porta do BMW fazia um clique característico ao fechar, ou que o motor ronronava no tom certo. Garantiam que todos os componentes se uniam da forma correta. Não se viam como fabricantes, mas como artesãos que produziam algo belo.

Isso é ótimo quando se está a produzir poucos carros. No entanto, quando se fabricam milhões de veículos, esses custos se tornam muito altos. Womack relata em seu livro: […] a fábrica alemã tinha mais trabalho para corrigir os problemas que tinha acabado de criar do que a fábrica japonesa tinha para produzir um carro quase perfeito de primeira.

É isso mesmo. Os alemães gastavam mais tempo a consertar um carro recém-produzido do que os japoneses levavam para fabricar um. A Toyota se tornou a fabricante de automóveis número 1 do mundo por um motivo: ela acertava de primeira.

Casos de Procrastinação

Nos casos abaixo, troquei os nomes das empresas para garantir a privacidade das mesmas.

Procrastinação por falta de Definição de Pronto ou Qualidade na entrega

Luiz Duarte em seu livro Scrum e Métodos Ágeis: Um Guia Prático fala que durante sua passagem em uma startup de TI do Rio Grande do Sul (Brasil), perdia-se clientes na mesma velocidade que novos eram adquidiros, devido a inúmeros bugs na ferramenta. Ele ainda enfatizava que uma simples Definição de Pronto bem elaborada poderia ter resolvido esse problema.

Na empresa Stallion Security também tínhamos este problema. Os inúmeros de bugs (diários) deixavam nossos clientes inquietos e a quantidade de clientes que entravam era praticamente as que saiam e não conseguíamos aumentar nosso quadro de clientes.

Moral da história: Uma boa Definição de Pronto pode reduzir consideravelmente bugs em produção

Resultados:

1) O projeto do Luiz Duarte foi cancelado
2) A Stallion Security passou a responder por várias insatisfações no Reclame Aqui e a sua ouvidoria interna atendia cada vez mais chamados.

Procrastinação por falta de visão

Na empresa OnTheGo vendíamos softwares e serviços. Chegou um momento em que a linguagem a qual tinha sido utilizada para desenvolver o software estava ultrapassada há muitos anos (luz). Quando algum responsável de TI dos novos clientes perguntava a linguagem a qual o sistema fora desenvolvido, ficava com receio de responder. Para diminuir o impacto do susto, acabava por dizer que a nossa TI já estava a desenvolver uma versão nova com linguagem mais atual e que estaria em breve disponível para homologação e instalação. Mas esse breve nunca chegou.

Moral da história – Não pagou-se o preço da inovação no seu devido tempo.

Resultado: Perdemos clientes grandes e houve enxugamento da equipa

Leitura complementar: A Lei do Preço a Pagar

Procrastinação por não entender o que é prioridade

Tudo na empresa GreenStar era prioritário e nós tínhamos uma equipa pequena para tantos incidentes e problemas a serem tratados.

Certa vez, o time de manutenção estava dividido para solucionar três bugs de três diferentes áreas de negócio.

Um diretor de uma outra área de negócio decidiu desligar um sistema. Este sistema atendia clientes VIP e os mesmos ficariam sem informações. Dez dias antes do mesmo ser desligado, fui convidado para ir a uma reunião a qual mais tarde saberia que teria que desenvolver um novo sistema para substituir o que fora desligado.

Um dos três bugs foi escolhido como “menos prioritário” e foi substituído por esta nova demanda.

Três pontos a serem destacados:
1) O bug adiado encontrava-se em produção e afetava mais de 60% dos usuários, a incluir os VIPs.
2) Não houve um planeamento prévio para desligar o sistema. Como a política de “Quem grita mais alto, Ganha!” era a política em vigor, o diretor sabia que seria atendido no momento em que ele gritasse.
3) O diretor já tinha data acordada com o fornecedor para desligar o sistema.

Moral da história – Quando tudo é prioridade nada é prioridade.

Resultados:
1) 5 dias com 100% dos clientes VIPs sem o sistema, pois o mesmo só foi entregue depois da data de desligamento do sistema.
2) Após publicação em produção, alguns dos clientes VIPs recebiam mensagem de erro 500. Foi difícil encontrar o bug, mas conseguimos identificar e corrigir 2 dias depois.
3) 2 semanas com cerca de 60% dos usuários a sofrer com o bug que só fora corrigido após conclusão dos outros dois bugs.

Conclusão

Acredito que estes três casos mais a história de Jim são ótimos exemplos da importância da não procrastinação da solução.

Em dois casos, metodologias ágeis poderiam ser a solução. O Scrum com a Definição de Pronto sendo bem elaborada pelo time de desenvolvimento e sempre evoluindo e a criação de Squads para as áreas de negócio para a questão de prioridades. Veja mais sobre o caso NuBank.

No outro caso, adotando apenas 3 dos 12 princípios do Manifesto Ágil já seria o suficiente para não pagar o preço que pagou:

  1. Garantir a satisfação do cliente, através da entrega rápida e continua de software funcional;
  2. Os projetos devem ser criados em torno de indivíduos motivados. Dê-lhes o ambiente e o apoio que necessitam, e confie-os para começar o trabalho feito.
  3. A atenção contínua à excelência técnica e ao bom design aumenta a agilidade.

A competição é alta. Você está numa selva cheia de leões famintos pelos seus clientes. Vai devorar-te mais cedo ou mais tarde enquanto você estiver aplicando soluções paliativas em vez de definitivas.

No próximo artigo falarei dos valores de uma equipa.

Até lá.

Autor

PSM I, PACC, SFC, ISMF, SMAC, IPOF, STMAC, ITILv3 e MCTS. Possuo 20 anos de experiência em TI com background em desenvolvimento. Desde 2008 a liderar equipas de performance. Desde 2010 a trabalhar com Scrum, Kanban e XP. Desde 2017 a desempenhar papel de Scrum Master e Agile Coach. Desde 2018 a escrever artigos sobre Scrum, Equipas de Performance e Metodologias Ágeis.

Bruno Amaral

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes