Pergunta errada. Resposta errada.
O quão comum é tentar resolver o problema através de suas conseqüências ao invés de suas causas? Eu tenho visto acontecer com grande freqüência e o resultado é que as soluções apenas causam mais problemas. O que me faz pensar no quanto a cultura da Toyota é interessante ao propor perguntar “por que?” cinco vezes antes de tentar resolver um problema. É a instituição oficial da análise da causa raiz. Agora, sem esforço, consigo me lembrar de dois casos nos quais a pergunta errada – ou a análise apenas das conseqüências – implicava uma resposta errada com resultados, digamos, indesejados.
Ontem encontrei um artigo sobre quanto tempo um desenvolvedor deve gastar para resolver bugs encontrados em projetos no emprego anterior. A questão basicamente era: “É seu código, seu bug, mas não é mais seu emprego. Quanto tempo gastar para ajudar a resolver?”. Enquanto alguns comentários debandavam para questões legais ou o desenvolvedor agora talvez trabalhar para a concorrência, eu pensava: meu código? Meu bug? Não, obrigado. Ambos não deveriam ser meus. Ambos devem ser de propriedade e responsabilidade do time. Trabalhar em times quer dizer, ou ao menos deveria, que tarefas importantes não devem ficar sob responsabilidade de apenas uma pessoa. É uma maneira efetiva tanto de evitar que o trabalho pare se um individuo se ausentar quanto de permitir que pessoas com conhecimentos diferentes tornem o resultado final melhor. XP leva isso ao extremo ao propor programação em par e propriedade coletiva do código. Não é seu código ou bug e qualquer um dentro do time pode se encarregar da tarefa. Percebeu como faz pouco sentido chamar alguém que já saiu para resolver um problema?
A segunda pergunta era: “fazer a aceitação de um release dá muito trabalho, não seria melhor fazer releases em intervalos maiores?”. Não, não seria. A aceitação só é muito trabalhosa se os testes de aceitação/funcionais são feitos manualmente. O caso não é de aumentar o ciclo para poupar esforço com muitas releases, mas automatizar os testes para que as releases sejam feitas semanalmente, de preferência. Aumentar o ciclo de releases não resolve o problema. Apenas aumenta já que, falta de automação + ciclos maiores resultará em mais funcionalidades para testar e menos feedback sobre erros. A resposta errada não resolveu o problema, apenas criou outros.
Ambos os casos acima remetem para meu post anterior sobre problemas se tornarem oportunidades. Mas nem sempre é fácil perceber as implicações de respostas erradas, principalmente quando quem as dá não é quem vive os resultados delas, ou sofre os problemas na pele . No fim das contas, as vezes é mais fácil dar as respostas erradas do que fazer as perguntas certas.
Arquivado em:agile, gente, iniciativa, qualidade | 3 Comments
Como anda a manutenção do componente de transcodificação de áudio? Muitos números mágicos pela frente? 😉
Depois ainda vêm falar que pair programming é quando duas pessoas estão fazendo o trabalho de uma, fala sério.. =)
T+
A pergunta é “por que?” ou o “o que provocou esse bug?” ? Pedir ao cliente para executar na frente do desenvolvedor todos os passos que ele deu foi uma forma que encontrei de achar bugs.
Muito pertinente os comentários.
Mas não podemos esquecer o contexto em que o artigo está inserido. Nem todo mundo trabalha com uma equipe bacana e motivada ao ponto de dividir responsabilidades (e códigos). Eu diria até que nem todo mundo conseguiria sequer dividir tais responsabilidades simplesmente porque a equipe de desenvolvimento é tão enxuta que chega até a ser insuficiente pro volume de trabalho que ela tem que desenvolver. Acredito inclusive que a discussão acerca deste artigo poderia envolver algumas questões relacionadas com o tipo de vínculo empregatício americano e o nosso, mas aí talvez fugiria um pouco do foco empregado.