Por que o Processo Importa?
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Esse post faz parte de uma série sobre Criando Times Eficazes.
Nossa indústria passou de um foco orientado a processo, com metodologias Waterfall e depois Ágil, para um foco em pessoas, onde temos nos concentrado em engenheiros conduzindo o resultado dos times de forma independente. Embora essa mudança tenha melhorado muitas coisas, ela alterou alguns aspectos fundamentais para pior.
Acredito que essa é uma situação que podemos melhorar. Mas por que o processo importa?
O processo como obrigação
O processo como obrigação
Quando se fala em processo, o pensamento parece ir direto para algo rígido e inflexível. Engenheiros que são velhos (ou azarados) o suficiente terão vivenciado projetos verdadeiramente waterfall onde existem práticas difíceis de compreender. E quando confrontando uma ineficiência aparente, a resposta seria “é assim que se faz aqui.” É o processo que seguimos.
Embora o exemplo do waterfall seja óbvio, o mesmo acontece com abordagens mais modernas. Os princípios do Manifesto Ágil criaram as práticas do Scrum, Kanban, etc. E então, os métodos foram expandidos, e esquecemos os princípios na maioria dos casos. Começou o mesmo comportamento mecânico descrito no parágrafo acima. Quer dizer, você não precisa ir longe. Um exemplo pequeno mas irônico é que todos nós ainda fazemos reuniões de “stand-up” com todo mundo sentado em uma videochamada.
Seguir cegamente um sistema rígido é um problema. Você acaba eventualmente executando rotinas onde ninguém entende o raciocínio por trás delas. John Seddon resume isso bem.
Aprendi que assim que você introduz controles sobre o comportamento humano, você perde o jogo, particularmente quando esses controles estão em desacordo com o trabalho — John Seddon
Com isso em mente, é fácil entender a aversão a processos que temos na indústria de tecnologia, onde as coisas mudam bem rapidamente. Quando o contexto está frequentemente em fluxo, aderir a práticas específicas pode inibir a inovação. E fazer com que funcionários altamente qualificados e difíceis de encontrar sigam regras ineficientes só pode inibir motivação e retenção também.
Sempre existe um sistema
O desafio com o pensamento anti-processo é que sempre existe um sistema.
Portanto, não defini-lo ativamente apenas significará que um sistema orgânico vai emergir, determinado principalmente pelas pessoas e personalidades que existem no time. Na minha experiência, adotar essa abordagem em times de software leva a resultados subótimos.
A tendência que tenho visto é que indivíduos focam em seus pontos fortes, trabalhando em áreas em que se sentem confortáveis e que lhes renderão pontos no placar. Infelizmente, isso eventualmente leva a silos de conhecimento, engenheiros heróis e regras de participação pouco claras que inibem inclusão e aprendizado.
Exemplos de isso dar errado são abundantes. Em um time que gerenciei, o sistema de planejamento que emergiu era tão técnico que o product manager vinha até mim depois das reuniões para me perguntar o que tinha acontecido. Ele não tinha uma visão clara de como o projeto que estava entregando estava progredindo. Em outra situação, a definição de trabalho foi deixada para os indivíduos, e pessoas que eram novas no time não conseguiam definir bem seu trabalho por falta de contexto. Isso significava que elas também não entregavam bem individualmente e eram consideradas de menor desempenho.
Tenha isso em mente. Se você gerencia um time e não se importa com o sistema, isso apenas significa que você está deixando outras pessoas defini-lo, intencionalmente ou não. E haverá consequências não apenas no resultado do time, mas também na carreira de cada indivíduo.
A arte da entrega de software
Outra preocupação comum é que desenvolvimento de software é um processo criativo. Um movimento significativo (e necessário) em torno de software craftsmanship destaca o quanto da disciplina é baseada na experiência e inspiração do engenheiro.
Embora isso seja verdade, precisamos estar cientes de que até artistas verdadeiramente criativos precisam de uma rotina. Chuck Close nos lembra que “Inspiração é para amadores. O resto de nós simplesmente aparece e começa a trabalhar.”
Assim como em um time esportivo ou qualquer outro esforço colaborativo, o objetivo é criar um sistema que eleve o time e os indivíduos. Ele deve permitir que os engenheiros foquem em seus pontos fortes e habilidades, ao mesmo tempo que viabiliza colaboração, aprendizado e alta produtividade para o grupo.
Nesse cenário, focar no indivíduo é a abordagem errada. Como Deming afirmou, a maioria das melhorias de produtividade está em como o sistema funciona.
O fato é que o sistema em que as pessoas trabalham e a interação entre as pessoas podem ser responsáveis por 90 ou 95 por cento do desempenho. — W. Edwards Deming
Encontrando o equilíbrio certo
Ter um sistema bem definido significará que indivíduos podem focar em seus pontos fortes, e todos entendem como participar. Também significa que você pode melhorá-lo continuamente, já que tem uma base sólida para se apoiar. É impossível iterar se tudo o que o time faz é mudar práticas em um processo que nem sequer foi definido.
Outras indústrias fizeram isso de forma eficaz. Sistemas de Produção Lean são o principal exemplo de uma área onde o processo é rigorosamente aplicado, mas também é de responsabilidade dos seus participantes e está em constante evolução.
Embora engenharia de software não seja uma linha de produção, os mesmos benefícios podem ser vistos nela. Tendo feito isso para múltiplos times ao longo dos anos, posso dizer que regras claras de trabalho para times de software permitirão que engenheiros foquem mais em engenharia e menos em gestão, criarão regras mais equitativas de participação e, em última instância, aumentarão a produtividade.
Embora cada time e organização precise definir os sistemas ótimos para si, compartilharei algumas das ideias e práticas que apliquei ao longo dos anos nos próximos posts desta série.