Pessoas acima de processos, e processos acima de ferramentas.

Trabalhando como consultor nas empresas, sempre me vejo praticando uma metodologia implícita que me ajuda a me concentrar em melhorias de curto prazo enquanto trabalho para obter ganhos a longo prazo. A metodologia aplica-se a muitos aspectos do ciclo de vida do desenvolvimento de software que abrange desenvolvimento, teste e operações.

A metodologia começa procurando pessoas ou pessoas certas para desempenhar um papel necessário. Em segundo lugar, assegure-se de que o processo seja correto e otimizado. Por fim, melhore a eficiência do processo, reduzindo os passos através de alguma automação baseada em ferramentas. Aviso: ferramentas e automação são os últimos! Eu chamo essa metodologia: “Pessoas acima de processos, e processos acima de ferramentas”. É o meu mantra nos ultimos meses.

As pessoas com quem trabalho são tipicamente técnicos e, como muitos técnicos, muitas vezes é preferível reagir primeiro para processar problemas com ferramentas. O pensamento é assim: as ferramentas instituem uma metodologia, incorporam um processo e, através do uso, aplicam uma política. As ferramentas podem parecer uma bala de prata (esse nome em homenagem a um antigo gestor meu). Dirija todos os problemas de uma só vez em um novo projeto de ferramenta.

O que encontro é: selecionar e instituir uma ferramenta é quase sempre o pior primeiro passo para melhorar uma função importante, especialmente quando a função está espalhada por mais de uma equipe. Isso ocorre porque quase sempre é mais fácil ver como a função está sendo feita – quem faz isso e como. Escolher, desenvolver, implementar uma ferramenta é um investimento e que não pode pagar se as pessoas e o processo certos não são colocados em primeiro lugar.

Alinhar o time à função e depois consertar ou otimizar o processo que eles usam é quase sempre muito mais direto e é um pré-requisito para o uso de novas ferramentas ou automação.

Pessoas

Muitas vezes, o passo mais fácil para melhorar é garantir que haja uma pessoa responsável pela função em questão. Isso parece óbvio, mas muitas vezes a mudança organizacional resulta em ambiguidades sobre o que a pessoa ou o grupo é realmente responsável.

Por exemplo, um processo pode ser repetido dentro de vários grupos. Aproximadamente, o mesmo processo pode ocorrer em cada grupo, mas não há compartilhamento de conhecimento ou procedimento entre eles. Para resolver este tipo de deslocamento, a organização pode centralizar essa função em uma única atividade ou agendar uma reunião periódica para garantir práticas comuns. Em outros exemplos, talvez o conjunto de habilidades necessárias não exista para essa função. A solução nesse caso seria definir as habilidades necessárias para o papel e oferecer treinamento ou preencher essa posição de acordo.

Processo

As pessoas certas podem estar no trabalho, mas como o trabalho feito não é correto ou é muito difícil. Processos incorretos são aqueles que não terminam com o resultado desejado. Processos incorretos podem ter indocumentadas suposições ou condições prévias. As etapas podem não ser explicadas com precisão ou apresentadas na ordem errada. Muitas vezes, os processos evoluem ao longo do tempo e se tornam dogma, mesmo que representem muitos obstáculos ou exceções à pessoa que o realiza.

Nesses casos, um olho no processo (re) engenharia pode ajudar. Concentrar-se na precisão e na ordem são as primeiras prioridades. A otimização e a redução da duração devem vir depois.

Ferramentas

Uma vez que as pessoas certas estão realizando o processo certo, pode-se procurar ganhos adicionais usando ferramentas para automatizar etapas. Assumindo que vale a pena o custo e o esforço. Eu sempre gosto de enfatizar o lado do custo e do esforço da decisão. Pode ser óbvio para os desenvolvedores de ferramentas como a automação fará melhorias drásticas, mas eles não podem criar um caso de negócios necessário para suportar seus esforços no longo prazo.

Para os fabricantes de ferramentas com as habilidades certas, um projeto de desenvolvimento que gera ganhos de produtividade sempre parece ser falta de inteligência. Mas como eles provam isso em sua gestão? Mais importante ainda, como eles podem aumentar suas chances de que sua ferramenta seja adotada pelas pessoas que o usarão em oposição às pessoas que trabalham em torno dela. Descobri que construir um relacionamento com os futuros usuários finais é sempre o primeiro e mais importante passo.

Ao invés de começar com o código, comece por analisar o processo de uma perspectiva organizacional. Certifique-se de que não há deslocamento nos pontos de saída. Verifique se o procedimento está correto e repetitivo manualmente. Só então procure ferramentas disponíveis ou uma justificativa para escrever a sua.