atividades extraordinarias? Para fins de calculo, vou considerar o valor dos americanos ... 30%. Logo, das 40 horas de trabalho semanal que voce alocou em seu plano de projeto, restaram apenas 28 horas para voce fazer realmente o que agrega valor a um produto de software! Mas isso nao e tudo ...Desperdicios da Burocracia e do Retrabalho (Muda Tipo II)Este e um tema que, muitas vezes, me deixa chocado quando converso com alguns profissionais de empresas de software que desconhecem os desperdicios (muda, em japones) ensinados no pensamento enxuto da Toyota. Ele esta diretamente relacionado ao percentual de trabalho semanal que gastamos em atividades burocraticas e correcoes de falhas, pois nao agregam qualquer tipo de valor ao produto final de nosso trabalho. E aquele tipo de trabalho pelo qual deveriamos desenvolver alguma alergia ou vergonha caso o praticassemos de forma sistematica em nossas empresas. Para mim, um trabalho mais nocivo que a atividade extraordinaria, pois demonstra a falta de comprometimento da empresa com a qualidade do produto, do processo e satisfacao do cliente. Para o modelo de gestao enxuta, ele deve ser totalmente eliminado!Quanto voce apostaria ser o desperdicio semanal de sua equipe em atividades burocraticas e de retrabalho? Aqui podemos encontrar uma grande variacao devido a natureza das equipes de desenvolvimento de software, mas voce poderia pensar em exemplos relacionados a seis dos sete desperdicios identificados no modelo de gestao da Toyota: 1) percentual de nao conformidades existentes em seu backlog de trabalho, 2) tempo gasto com excessos de producao (fazer alem do necessario), 3) tempo gasto com o gerenciamento da informacao (estoques dos excessos de producao), 4) tempo gasto com movimentacoes desnecessarias (layouts indevidos ou mudanca de tarefas), 5) tempo gasto com o transporte de informacoes (atividades burocraticas) e 6) tempo gasto com esperas diversas (falta de sincronizacao dos membros da equipe). Voce pode responder um valor em torno de 20%, 50% ou ate mesmo 100% (ja vi equipes totalmente dedicadas a correcao de falhas, comprovando o total desperdicio de seus profissionais devido a ineficacia de seu processo de desenvolvimento). Para voce nao desistir do resto da analise, pense na organizacao como um todo e faca uma estimativa ...Para fins de calculo, vou considerar os mesmos 30% das atividades extraordinarias, que e um valor otimista porem aceitavel para os niveis de eficiencia (excesso de atividades burocraticas) e eficacia (numero de falhas a corrigir) de nossas empresas. Logo, das 28 horas de trabalho restantes do item anterior, subtrairemos 12 horas do desperdicio da burocracia e do retrabalho, resultando em 16 horas disponiveis para voce realmente agregar valor ao produto de software!Sera que e por isso que planejamos uma "margem de seguranca" no final do cronograma de projeto? Ate agora, voce ja pode multiplicar a duracao estimada para seu projeto por um fator de 2,5 e ainda assim pode ser pouco para a realidade de sua equipe ...Quer saber por que eu escrevi que esse tema me deixa chocado quando converso com alguns profissionais de outras empresas? Porque diversas vezes ouco afirmacoes do tipo:"Nao existe software sem falhas ...""Nao tem problema se