Como tirar o seu projeto de software do caos (ou como evitar chegar nele)

AGRADEÇA AO AUTOR COMPARTILHE!

Essa história já aconteceu com você?

“Na minha empresa o backlog é imenso. Na equipe, cada um de nós se esforça mas não dá conta. O ambiente é caótico. Toda hora apagamos incêndios de problemas que requerem nossa atenção imediata. Demandas se tornam urgentes do nada depois de passar dias ou semanas no backlog sem a devida atenção. Projetos importantes levam o dobro, o triplo do tempo que precisariam para serem entregues. A satisfação dos clientes, a motivação da equipe e a qualidade dos produtos se desgastam a cada dia e não temos a mínima ideia sobre como reverter isso.

Um dia desses aconteceu o que sempre acontece. Já estava bem no finalzinho do dia quando o telefone tocou. Só de ouvir o telefone tocar, o meu nível de ansiedade já vai para as alturas. O volume do nosso backlog já é tão alto que parece que eu estou devendo tudo pra todos. Era um cliente. Muito irritado porque nos pediu um relatório há quase dois meses e até hoje não tínhamos implementado no sistema. Dez minutos depois, chega o meu diretor. A ordem é parar tudo pra implementar o relatório. O cliente está sofrendo auditoria e a ausência das informações pode gerar uma grande multa.

Fui olhar o histórico do pedido do tal relatório e percebi que já tinha passado na mão de dois programadores.

Conversei com os dois e a justificativa era sempre a mesma:

— Tivemos que interromper o relatório por causa de outras prioridades.

Enfim, levou três dias para o relatório ficar pronto. No último dia, o programador ficou até às 11 da noite pra cumprir o prazo. E ainda nem sabemos se vai voltar com algum problema pra corrigir.

Olhando pra trás eu começo a me perguntar:

— De quem é a culpa? Do cliente que não soube priorizar? Minha que não tratei o risco? Dos desenvolvedores que não se esforçam para entregar mais e mais rápido?

Depois que tudo acabou, fui fazer a conta:

  • 47 dias desde que o cliente fez o pedido até receber de volta
  • 3 dias para implementar
  • 6% de tempo de execução e 94% de espera em uma fila que não tem fim. E o pior, com um desgaste emocional que deixa o nosso ambiente de trabalho extremamente desmotivador.

Tem que ter um jeito de melhorar isso!”

Esse é um cenário muito comum nas empresas atualmente.

Nosso backlog está repleto de bombas-relógio. Demandas que permanecem lá por dias ou semanas e, do nada, se tornam urgentes, pra ontem. Qualquer tentativa de planejamento não sobrevive aos primeiros dias de fogo cruzado no cotidiano dos nossos projetos.

A pressa na resposta, além da pressão para se livrar de um incêndio, geram efeitos colaterais no nosso software, que retornarão como bugs emergenciais em algum momento no futuro. Enfim, as bombas-relógio estão lá no código e não sabemos quando serão ativadas.

A interrupção frequente no trabalho dos desenvolvedores é real. Os projetos em andamento levam muito mais tempo do que precisariam. Muitos nem chegam a ser concluídos já que perdem o timing de geração de valor para os clientes.

No fim das contas, o que sobra é:

  • Ansiedade e desmotivação da equipe
  • A sensação de que o produto não evolui
  • Clientes procurando alternativas junto aos competidores
  • Pessoas entrando e saindo dos quadros das empresas em busca de melhores ambientes de trabalho

Talvez esse cenário de caos ainda não seja sua realidade. Mas, se você já começa a perceber alguns sinais de situações como essa, é bom ficar preocupado… Nesse caso, a estrutura sistêmica que causa tais comportamentos já está instalada. E o que te separa do caos é o crescimento no volume de interações rodando nessa estrutura.

Veja o exemplo do backlog. Um aumento súbito no número de clientes ou o surgimento de novas prospecções de negócios podem pressionar sua estrutura de desenvolvimento com mais demanda de implementações. Um backlog maior pode te levar a investir em mais pessoas para atender a demanda. Quanto mais demandas e mais pessoas, maior o número de interações entre os elementos de uma estrutura sistêmica inadequada. E assim você chega a esse mesmo nível de caos em poucos meses sem se dar conta.

A ideia de que o seu ambiente de trabalho é um sistema composto de elementos que interagem entre si gerando comportamentos é tratada por um tema que tem sido cada vez mais explorado na gestão moderna: Systems Thinking. E é nesse modelo de pensamento que está o caminho para a melhoria.

Na nossa história há várias pistas sobre como melhorar esse sistema de trabalho e começar um processo de reversão dessa situação de caos.

1) Primeiramente, os números. Ter dados tangíveis sobre o comportamento do sistema é chave para saber onde intervir. Quando você descobre, por exemplo, que o tempo de resolução de um pedido corresponde apenas a 6% do tempo total, você percebe que otimizar o trabalho dos desenvolvedores não vai causar nenhum efeito no todo. Ter mais desenvolvedores trabalhando ou pensar em estratégias para fazê-los trabalhar mais ou serem mais produtivos não vai causar o efeito desejado sob o ponto de vista do cliente. E pior, vai intensificar o número de interações em um sistema que, em sua estrutura, produz bombas-relógios o tempo todo. Saber onde intervir é definitivamente o seu primeiro passo.

2) Desenvolvimento em grandes blocos com atribuição direta do trabalho. É comum a prática de passar demandas ou projetos inteiros diretamente para desenvolvedores específicos. Isso precisa ser evitado pois gera uma especialização excessiva, mata a colaboração e o senso de time e aumenta a probabilidade de interrupções frequentes. Diminuir o tamanho dos blocos de trabalho (releases, features e tarefas) afeta dramaticamente o fluxo do trabalho e a flexibilidade com a qual a equipe pode se coordenar no dia-a-dia.

3) Estruturação do fluxo de alimentação do sistema com demandas de acordo com seu perfil de risco. É preciso trabalhar em um processo estruturado que faça as demandas fluírem para dentro do sistema de acordo com o risco que elas apresentam, sempre subordinando esse fluxo à capacidade do sistema. Na nossa história, o agendamento para atender o relatório em questão estaria mapeado e sendo acompanhado desde o momento em que a demanda chegou à empresa. Isso pode ser feito por meio da implementação de um sistema puxado, usando um kanban com limites explícitos para o trabalho em progresso.

Essas três questões fazem parte de um conjunto mais amplo de estratégias que permitem que você faça intervenções de gestão na forma como o sistema está estruturado, causando grande impacto nos resultados.

Para entender melhor como implementar isso, você pode ter acesso a um conjunto de vídeos, artigos e a um e-book que, juntos, vão te mostrar o poder de visualizar o seu projeto de software como um sistema. Assim, você saberá onde e como intervir para melhorar a forma como a empresa como um todo interage, e aí sim, sair do caos (ou evitar chegar nele).

Clique aqui e se inscreva para receber todo esse material gratuitamente por e-mail…

AGRADEÇA AO AUTOR COMPARTILHE!

Alisson Vale

Mais artigos deste autor »

Desenvolvedor de produtos de software, educador e empreendedor. Com mais de 20 anos de experiência em desenvolvimento e liderança de projetos de software, tem sido um praticante e divulgador de métodos modernos de gestão desde 2003 com uma grande participação em congressos e fóruns de debate no Brasil e no exterior. Em 2008, implementou o primeiro estudo de caso do método Kanban no Brasil e, logo depois, ganhou o prêmio internacional Brickel Key Award por essa implementação. Em 2014, fundou o Software Zen, um empreendimento de educação digital que tem levado conteúdo inovador sobre gestão a milhares de pessoas.


Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">