Continuidade aplicada aos processos de engenharia de software

Tempo de leitura 5 minutos

Não faz muito tempo que me tornei líder técnico pela primeira vez em minha carreira e, logo em seguida, também fui considerado staff engineer. Isso mudou tudo, de alguém imerso na programação (ainda porque eu amo isso) para a pessoa que representa a visão técnica de uma equipe e tenta levar o grupo a um lugar melhor, tecnicamente falando.

Me encontro mais frequentemente pensando no futuro e nos processos do que eu estava acostumado, longas discussões com equipes de produto e design, idas e vindas de ideias, Provas de Conceito (POCs) e a coisa mais terrível que todo engenheiro odeia, negociar tempo para trabalhar em débitos técnicos e melhorias.

Tem sido interessante! Aprendi muito, e embora não tenha sido tanto tempo assim nesta posição, já me vi em situações bastante complicadas e tenho pensado muito sobre continuidade a longo prazo. Acho que posso elaborar uma fórmula matemática para provar que a continuidade a longo prazo pode ajudar nos processos de desenvolvimento de software. Isso não seria uma tese de mestrado ou algo assim? Talvez eu devesse voltar à vida acadêmica.

Os casos de sucesso e os processos de continuidade ocultos

Você pode se perguntar, "Por que Diel está falando sobre isso agora?" As situações mais complicadas em que estive relacionam-se à negociação de tempo, e se há algo com que sou obrigado a concordar com os coachs de negócios do YouTube é que o tempo é finito, o recurso mais desejado e caro.

Então, por que algumas áreas têm sucesso e outras não? Não posso simplesmente aceitar que seja apenas porque elas têm tempo para se focar. Sejamos honestos; muitos erros são cometidos ao longo do caminho, mesmo quando se dedica tempo integral a algo, o que pode ser traduzido como "tempo perdido", e nós perdemos muito tempo. O tempo é essencial, mas não é o único fator de sucesso a ser considerado.

Você sabe já sabe onde quero chegar, a continuidade aplicada ao tempo é um fator de sucesso. Dê uma olhada rápida ao seu redor:

• Um produto só oferece novos recursos por causa de um processo contínuo de entrega de novos recursos.
• O mesmo vale para os bugs, espero. O produto continua a arrumar bugs por meio de um processo de resolução contínua de bugs.
• Você mantém todos na empresa alinhados por meio de um processo de manutenção contínua do alinhamento.
• Seu software usa as dependências mais atualizadas por meio do processo contínuo de atualização delas.

Experimente você mesmo:

{A ação desejada é bem-sucedida}, por causa de um processo contínuo de fazer {ação desejada}.

O gráfico de continuidade e seus surpreendentes efeitos colaterais

Desmond Tutu disse com sabedoria: "Há apenas uma maneira de comer um elefante: uma mordida de cada vez." Ele quis dizer que tudo que parece assustador, avassalador ou até mesmo impossível pode ser realizado gradualmente, assumindo um pouco de cada vez.

Um pouco de cada vez... continuidade.

Sempre teremos grandes projetos para trabalhar, o que é ótimo. Eu odiaria não ter nenhum problema impactante ou complexo para resolver, o que geralmente se traduz em muito trabalho em muitas frentes diferentes. Como podemos progredir em várias áreas enquanto mantemos um bom ritmo na entrega de novos recursos, melhorias na experiência do usuário/desenvolvedor, manutenção, correção de bugs e mais?

Não estou advogando ter uma equipe que se concentre em todas essas coisas ao mesmo tempo, mas ser crítico e pensar sobre o que pode ser paralelizado, levando em consideração a capacidade da equipe para que possamos ter progresso contínuo e saudável em áreas que terão um impacto positivo, mas nunca seriam priorizadas.

Sua empresa não irá à falência se a equipe levar três semanas a mais para entregar aquele grande recurso e, ainda assim, corrigir alguns bugs e melhorar a experiência do desenvolvedor ao longo do caminho. Mas você só pode começar com pessoas que acreditam que a empresa lhes dá espaço para ter sucesso e apoia um processo sólido e saudável.

Aplicando a fórmula de continuidade

Vamos supor que temos um trabalho de migração para fazer, nós iríamos:

• dividir e ter uma compreensão clara do trabalho necessário.
• Aplicar e dividir groupos deste trabalho em cima do tempo disponível ou desejado.

Esta lista de ações nos dá uma linha constante muito chata:

Ninguém vê o efeito colateral dessa representação visual constante; nós comemos o elefante uma mordida de cada vez. O efeito colateral é que você começará com muito trabalho a ser feito, mas também diminuirá linearmente este número e se aproximará de zero no final. Isso não é como tudo funciona em desenvolvimento de software?

Os efeitos colaterais não mensuráveis

Como tudo que envolve seres humanos, haverá alguns efeitos colaterais que gosto de chamar de não mensuráveis; eles são não mensuráveis porque estamos falando de sentimentos humanos, motivações e crenças.

Pense nisso: se sua equipe vem mencionando e pedindo para trabalhar em uma longa migração que se tornou um problema significativo para a velocidade e qualidade da equipe por anos, isso afetará diretamente a felicidade e motivação da equipe. Não abordar grandes preocupações/projetos como esse pode diminuir drasticamente a confiança da equipe na capacidade da empresa de apoiar um processo sólido e saudável.

Os efeitos colaterais também se estendem além das métricas de produtividade. Isso pode aumentar a inovação e a resolução criativa de problemas aplicando continuidade e devolvendo tempo às equipes, já que elas não estão gastando todo o tempo e energia tentando descobrir como comer o elefante.

No final, todos nós temos um objetivo: produzir com qualidade e mais rápido.