As 5 histórias que vou contar hoje

Hoje às 20hs começa o muito aguardado curso de “Gestão Ágil para Softwares em Manutenção”. 

Ele só acontece uma vez por ano, e não há nada no mercado de Agilidade que enderece de forma tão específica os problemas vividos por quem trabalha em projetos sobrecarregados pelo volume de demandas, e pela constante luta contra as urgências e emergências que aparecem o tempo todo. 

Logo mais à noite, eu vou abrir o curso contando cinco histórias que talvez ressoem com a realidade que você vive, ou com a realidade de times na sua empresa que poderiam ser ajudados por esse programa:

História #1: 
Seu software gerencia o processo de embarcação de produtos em um navio enquanto ancorado no porto. Um problema no sistema está atrasando a movimentação apropriada da carga. O bug é reportado às 08 da manhã. Ele é cadastrado no sistema de tickets, mas o time está ocupado em outras tarefas. Os funcionários da operação no porto se ocupam da movimentação da carga, mas de forma ineficiente. Às 11:30 os usuários voltam a ligar cobrando uma resposta. Alguém finalmente pega o problema para olhar. O ticket é atribuído para um desenvolvedor que também está ocupado fazendo outra coisa. Todos vão almoçar. Às 15 horas, a supervisão da empresa que opera o navio liga direto para o diretor da empresa de software. Este (o único que de fato entende a repercussão do problema até esse ponto), corre para a sala de desenvolvimento e manda parar tudo para dar atenção ao problema. O problema é resolvido em 15 minutos pelo desenvolvedor. A versão com o bug corrigido é publicada às 17 hs. Depois de um cálculo final, o retardo na movimentação da carga custou R$ 25 mil para o cliente em taxas portuárias excedentes.


História #2:
Está marcada para a próxima sexta-feira a reunião trimestral do board de diretores da empresa em que você trabalha. Nessa reunião, o Diretor Financeiro apresentará números que vão servir de base para a decisão do conselho sobre um grande investimento que a empresa precisa fazer no próximo ano. O gerente do setor é incumbido de montar um resumo executivo de alguns dos principais indicadores financeiros da empresa. Para isso, o gerente já sabe que conta com os dados do sistema de gestão que a empresa mantém pelo seu departamento de TI. Três dias antes da reunião, o gerente abre os relatório e descobre, para seu espanto, que os números não batem. Há erros de cálculo nos relatórios que estão gerando informações incorretas. Sem esses relatórios, o diretor não conseguirá fazer sua apresentação. Vários membros do comitê já tem viagem marcada para participar da reunião, e esta não pode ser desmarcada. O gerente liga para a TI e relata o problema. Um desenvolvedor precisa ser interrompido para descobrir e acertar o problema o mais rápido possível para que o gerente consiga produzir o resumo executivo correto que será usado na reunião do board.

História #3:
Daqui a 3 meses, a empresa que você trabalha vai sofrer uma auditoria de um órgão de controle do governo. É um novo tipo de auditoria, que vai requerer dados de diferentes sistemas da empresa. O departamento de TI é contactado para desenvolver uma nova funcionalidade que produza os dados necessários para os auditores fazerem o seu trabalho quando chegarem à empresa. A demanda é colocada no backlog. O dia-a-dia da TI é repleto de demandas como essa, urgências e emergências que aparecem a todo momento. A demanda fica então esquecida no backlog. Uma semana antes, o responsável liga para a área de TI para saber sobre o andamento do pedido, descobrindo que a demanda ainda não havia nem começado. Já não há mais tempo para construir uma solução paliativa manualmente. O problema escala para a alta direção da empresa que vê o risco de receber uma multa ou ter seus negócios suspensos. Um desenvolvedor é então interrompido do projeto que estava trabalhando e começa a trabalhar nessa demanda. Para conseguir entregar a tempo, ele precisa trabalhar à noite e durante o fim de semana. Na segunda-feira, a entrega é realizada, mas ainda com vários problemas. Depois de mais algumas idas e vindas e de alguma paciência dos auditores (que já estavam na empresa aguardando os dados), finalmente a TI consegue fechar a demanda e as auditorias conseguem ser realizadas.

História #4: 
Sua empresa desenvolve um produto para gerenciamento hospitalar. Ao pesquisar o mercado a empresa descobriu uma oportunidade de criar diferencial no produto fornecendo, dentro da plataforma, a capacidade do hospital se comunicar melhor com toda a comunidade de saúde: pacientes, médicos, professores e outros colaboradores. Além de criar diferencial, esse novo módulo aumentaria a receita da empresa por meio de aumento nos preços das licenças de uso e dos contratos de manutenção. A feira nacional de soluções hospitalares está marcada para ocorrer em 4 meses. A diretoria se empolga com a possibilidade de apresentar esse novo módulo do produto nessa feira. Ao conversar com o gerente de desenvolvimento da equipe que mantém o produto, descobre-se que não há pessoal disponível para conduzir esse novo projeto. Toda a equipe já está sobrecarregada com o backlog de ajustes, bugs e outras atividades do dia-a-dia. A diretoria insiste e uma pessoa é separada do time e alocada para esse desenvolvimento. Durante o período do projeto, o desenvolvedor fica extremamente sobrecarregado, pois como é o membro mais experiente da equipe, ele continua dando suporte ao time, inclusive pegando um problema grave aqui e outro ali pra resolver. Depois de muito stress, trabalho nos fins de semana e horas extras, o projeto é concluído e apresentado na feira. 

História #5: 
O processo mais crítico do sistema de RH da empresa é a rotina de cálculo da folha de pagamento dos funcionários. Vitor é o único desenvolvedor que mexe ali. O período de fechamento da folha do mês está chegando e as demandas por ajustes e correções começam a chegar.  Toda vez que ele vai trabalhar nessa parte do sistema ele lembra de quantas conversas já teve com o resto da equipe e com seus gestores sobre a necessidade de refatorar o código e adicionar uma bela suite de testes unitários. Isso tornaria o código mais fácil de ser alterado, seria mais seguro fazer alterações sem colocar a operação em risco. e também outras pessoas poderiam ajudar ali. Mas diante da infinidade de demandas e problemas, nunca há tempo pra fazer. Ele pensa também o quanto é contraditório o discurso da empresa. Por um lado, a gestão está sempre reclamando da quantidade de demandas que essa área do sistema gera; por outro lado, nunca há investimento naquilo que, pra ele, seria óbvio e necessário para contornar o problema.

Dentro de cada uma dessas histórias reside as características que tornam os ambientes de manutenção muito difíceis de serem geridos.

Mas toda essa dificuldade não vem de complexidade, mas da perspectiva que aplicamos ao problema. Trazemos os modelos, ferramentas e o modo de pensar de processos de desenvolvimento – e de gestão tradicional de projetos – para um ambiente que claramente mudou de natureza. E essa é que é a grande questão. Que nova natureza é essa?

Vamos explorar esse tema na aula de hoje. Os modelos de gestão que normalmente são tentados para organizar ambientes de manutenção são os que buscam garantir a entrega de demandas no prazo. Tais modelos raramente funcionam, porque estão preocupados com a definição de um plano e depois com a sua concretização, quando o que precisamos é nos organizar em torno dos riscos.

Os Métodos Ágeis mais comuns também acabam caindo nessa categoria, e na sua forma original, não conseguem resolver o problema. Como a Agilidade não está no método, mas na forma de pensar, é possível extrair dos princípios do Ágil, do Lean e do Kanban aquilo que precisamos para estruturar um modelo de gestão que dê conta do recado. O segredo é sair da gestão de escopo e migrar para um novo modelo: o de gestão de risco.

Quando você começa a enxergar a rede de riscos na qual estão envolvidos os projetos de manutenção, tudo passa a ser percebido de maneira diferente, e o modelo de gestão se revela. Cada uma das histórias que eu contei acima nos mostra que vivemos sob riscos permanentes no nosso dia-a-dia.

Corremos constantemente o risco de:

  • gerar grandes perdas diretas – às vezes, irreparáveis – para os negócios de nossos clientes. É o que nos conta a história #1 e é daqui que surgirão as emergências.
  • tornar o negócio de nossos clientes ineficiente, gerar desgastes e transtornos para as operações do dia-a-dia. É o que nos conta a história #2 e é daqui que surgirão as urgências.
  • não responder às melhorias e ajustes requeridos pelos usuários e pelo negócio como um todo. É o que nos conta a história #3, e é daqui que surgirão os ajustes, melhorias e novas funções solicitadas quase que diariamente pelos usuários.
  • não ser capaz de evoluir para se adaptar e prosperar no mercado. É o que nos conta a história #4, e é daqui que surgirão os novos projetos.
  • não ser capaz de evitar a deterioração interna do produto ou do processo, prevenindo o aumento de todos os outros riscos citados acima. É o que nos conta a história #5, e é daqui que surgirão as necessidades de melhoria técnica interna no produto ou do seu processo de desenvolvimento.

A grande questão é como lidar com tudo isso acontecendo ao mesmo tempo?

Hoje à noite começaremos a desatar esse nó. 

Se você já fez sua matrícula, deve estar ansioso! É só aguardar que começaremos hoje às 20hs em ponto.

Se ainda não fez sua matrícula, e esse cenário acontece com você, ou com alguma equipe que você poderia estar ajudando, então essa é a oportunidade de ganhar as habilidades necessárias para lidar com um dos contextos mais desafiadores na gestão de projetos de TI. 

Nesse caso, ainda dá tempo, é só clicar aqui e se matricular…


Estamos adicionando ao programa do curso, um estudo de caso com o Agile Coach Anderson Silveira. Ele aplicou o conteúdo do curso para ajudar um time de serviços de banco de dados na sua empresa. A equipe recebia demandas de mudanças no banco de dados corporativo dos vários times de desenvolvimento da empresa. Essas equipes dependiam dessas intervenções no banco para fazerem suas entregas. O volume de demandas era muito grande para uma equipe pequena. As urgências e emergências dos times para cumprirem seus cronogramas tomava conta do dia-a-dia da equipe. O  estado anterior era de extrema insatisfação, tanto da própria equipe, quanto dos outros times de desenvolvimento que dependiam dela para rodar scripts, aprovar modelos, criar índices, rever performance de queries, etc. Depois de aplicado o modelo descrito no curso, o time duplicou sua eficiência e começou a entregar de forma muito mais eficaz, fazendo a coisa certa na hora certa de modo a não deixar seus clientes na mão quando precisavam cumprir os cronogramas, e de modo a continuar tocando os projetos importantes para a empresa. A satisfação com o trabalho voltou, e os clientes internos e alta gestão sentiram a diferença de tal forma que a equipe ganhou um prêmio de excelência pelos resultados dentro da empresa. Esse case será apresentado no dia 27/01 para aqueles que estiverem participando do curso.