Entre o Relógio e a Bola de Cristal
Série "De Brooks a Berkun" - 1ª Parte
No segundo capítulo de "The Mythical Man-Month", homônimo, Fred Brooks mostra um fac-símile do cardápio do Restaurant Antoine, de New Orleans. Destaca um Avis au Public, que aparece logo no cabeçalho do menu:
Brooks apresenta cinco razões para nossos constantes e intermináveis atrasos. O primeiro é o incurável otimismo de programadores e afins. Ele diz que nossas técnicas de estimativas são pobres e refletem uma situação irreal: de que tudo vai dar certo. Esse mesmo otimismo nos faria negligenciar, particularmente, a fase de testes de um projeto.
O segundo motivo seria a confusão entre "Esforço" e "Progresso". Tal confusão nasceria com a falsa crença de que Homens e Meses (Horas) são intercambiáveis. Brooks reforça que só conseguimos trocar alguns 'meses' por um monte de 'gente' em um conjunto de atividades que não exijam nenhum tipo de interação entre as pessoas. Acho que nem panha de café se encaixa...
A terceira razão relacionada por Brooks para os atrasos em nossos projetos é chata e provocativa: nós não somos sinceros como o chef do Antoine. A facilidade com que damos 'chutes' e apresentamos cronogramas sem um mínimo de embasamento é realmente assustadora. Pior: apresentando-os como 'sérios'. E a responsabilidade é tanto de quem pede quanto de quem dá. Já vi empresa muito grande solicitar uma proposta para um projeto de milhões apresentando um documento de 7 (sete!) páginas e fazendo uma reuniãozinha com os possíveis contratados. Tamanha negligência em qualquer outra área deve ser caso de polícia. Na nossa parece 'normal'.
A forma como acompanhamos e monitoramos a evolução de nossos cronogramas seria a quarta razão. A impressão que grande parte dos projetos nos transmite é que, assim que eles 'ganham ritmo', perde-se o controle.
Por último Brooks cita sua lei como outra grande razão para nossos atrasos. Segundo ele, adicionar pessoas a um projeto atrasado é como "tentar apagar um incêndio com gasolina". Cada novo membro pode significar uma nova cadeia de interações e restrições. A quantidade de meses de um projeto dependeria de suas restrições sequenciais. O número máximo de pessoas dependeria do número de sub-tarefas independentes. Podemos elaborar um cronograma mais 'demorado' utilizando menos pessoas. Mas não podemos encurtar seu prazo 'natural' adicionando mãos!
Recentemente Scott Berkun publicou uma série de 'exceções' à Lei de Brooks. Alertando que não queria, de maneira alguma, sugerir o abandono da lei. O próprio Brooks já reconheceu que sua lei é "ultrajantemente super-simplificada". Abaixo as exceções apontadas por Berkun:
Cronogramas são só um tipo de Previsão
Mas há quem os trate como se fossem 'documentos sagrados'. Para Scott Berkun os cronogramas "não são remédio para um projeto (design) ou práticas de engenharia ruins e também não podem proteger um projeto de uma liderança fraca, objetivos obscuros e comunicação pobre". Independentemente do tempo gasto e do capricho com que um cronograma foi elaborado, "no final das contas eles são apenas uma lista de palavras e números". Uma lista que, segundo Berkun, deve ter três objetivos bem claros:
E não é que tem cliente que, inconscientemente (quero acreditar), prefere ver um cronograma atualizado do que software rodando? Querendo ou não, os cronogramas viraram o 'grande' documento de um projeto de software. Responsabilidade demais para algo que deveria ser só mais uma ferramenta. Pior: para algo que deveria evoluir junto com o projeto.
É impossível gerar um cronograma com um mínimo de acuracidade no momento inicial de um projeto. Berkun afirma e milhares de projetos confirmam esta 'lei'. Mas continuamos insistindo. Berkun adaptou "Software Engineering Economics", de Barry Boehm, e gerou o gráfico abaixo. Nos momentos iniciais de um projeto nosso 'chute' pode ter uma variação de 400%. Há quem arrisque 4 dígitos...
Berkun afirma que a volatilidade dos requisitos, dentre outros fatores, pode gerar estimativas de baixa qualidade. E que não há nada de errado com elas desde que sejam apresentadas como tal: Estimativas de Baixa Qualidade. E sugere a adoção de Níveis de Confiabilidade para nossas estimativas:
Uma boa estimativa dependeria principalmente de dois fatores: bons requisitos e um bom design (temas que serão tratados posteriormente).
E Berkun ainda pede: confie em seus programadores como você confiaria em um neuro-cirurgião. Se este falar que aquela operação no cérebro demorará 12 horas, você tem coragem de pedir para que ele reduza para, digamos, 4 horas? Você seria o louco o suficiente?
continua...
No segundo capítulo de "The Mythical Man-Month", homônimo, Fred Brooks mostra um fac-símile do cardápio do Restaurant Antoine, de New Orleans. Destaca um Avis au Public, que aparece logo no cabeçalho do menu:
"Good cooking takes time. If you era made to wait, it is to serve you better, and to please you.”
Brooks apresenta cinco razões para nossos constantes e intermináveis atrasos. O primeiro é o incurável otimismo de programadores e afins. Ele diz que nossas técnicas de estimativas são pobres e refletem uma situação irreal: de que tudo vai dar certo. Esse mesmo otimismo nos faria negligenciar, particularmente, a fase de testes de um projeto.
O segundo motivo seria a confusão entre "Esforço" e "Progresso". Tal confusão nasceria com a falsa crença de que Homens e Meses (Horas) são intercambiáveis. Brooks reforça que só conseguimos trocar alguns 'meses' por um monte de 'gente' em um conjunto de atividades que não exijam nenhum tipo de interação entre as pessoas. Acho que nem panha de café se encaixa...
A terceira razão relacionada por Brooks para os atrasos em nossos projetos é chata e provocativa: nós não somos sinceros como o chef do Antoine. A facilidade com que damos 'chutes' e apresentamos cronogramas sem um mínimo de embasamento é realmente assustadora. Pior: apresentando-os como 'sérios'. E a responsabilidade é tanto de quem pede quanto de quem dá. Já vi empresa muito grande solicitar uma proposta para um projeto de milhões apresentando um documento de 7 (sete!) páginas e fazendo uma reuniãozinha com os possíveis contratados. Tamanha negligência em qualquer outra área deve ser caso de polícia. Na nossa parece 'normal'.
A forma como acompanhamos e monitoramos a evolução de nossos cronogramas seria a quarta razão. A impressão que grande parte dos projetos nos transmite é que, assim que eles 'ganham ritmo', perde-se o controle.
"Adicionar pessoas a um projeto de software atrasado só adiará a sua entrega."
- A Lei de Brooks
Por último Brooks cita sua lei como outra grande razão para nossos atrasos. Segundo ele, adicionar pessoas a um projeto atrasado é como "tentar apagar um incêndio com gasolina". Cada novo membro pode significar uma nova cadeia de interações e restrições. A quantidade de meses de um projeto dependeria de suas restrições sequenciais. O número máximo de pessoas dependeria do número de sub-tarefas independentes. Podemos elaborar um cronograma mais 'demorado' utilizando menos pessoas. Mas não podemos encurtar seu prazo 'natural' adicionando mãos!
Recentemente Scott Berkun publicou uma série de 'exceções' à Lei de Brooks. Alertando que não queria, de maneira alguma, sugerir o abandono da lei. O próprio Brooks já reconheceu que sua lei é "ultrajantemente super-simplificada". Abaixo as exceções apontadas por Berkun:
- Depende da pessoa: lógico! O acréscimo de uma ou mais pessoas mais experientes que aquelas da equipe atual pode, eu disse Pode, gerar um efeito positivo no projeto.
- Alguns times podem assumir mudanças mais facilmente: sinceramente não vi relação direta com a lei. Mas claro, cada time, assim como cada pessoa, é único.
- Há coisas piores que estar atrasado: com certeza, como entregar algo totalmente diferente daquilo que o cliente espera. Berkun lembra bem: "a única coisa que a lei fala é que o projeto atrasará 'mais' com a adição de mais pessoas". Mas tal acréscimo pode ser benéfico ou crucial para o resultado final do projeto.
- Há diferentes maneiras de adicionar pessoas à um projeto: mas Berkun lembra bem que nossa 'tradição' é 'jogar gente lá para ver no que é que dá'. Se bem pensada, a adição (ou troca) de pessoas em um time pode ser benéfica.
- Depende da razão do atraso do projeto, para começo de conversa: claro! Se o(s) motivo(s) não for(em) bem identificado(s), de que adianta jogar mais pessoas na frigideira?
- A adição de pessoas pode ser combinada com outras ações do coordenador: de novo e pela última vez: Claro!
Cronogramas são só um tipo de Previsão
Mas há quem os trate como se fossem 'documentos sagrados'. Para Scott Berkun os cronogramas "não são remédio para um projeto (design) ou práticas de engenharia ruins e também não podem proteger um projeto de uma liderança fraca, objetivos obscuros e comunicação pobre". Independentemente do tempo gasto e do capricho com que um cronograma foi elaborado, "no final das contas eles são apenas uma lista de palavras e números". Uma lista que, segundo Berkun, deve ter três objetivos bem claros:
- Descrever quais tarefas devem ser executadas, quando e quais produtos serão gerados;
- Funcionar como em elo de ligação da equipe, indicando dependências e amplificando os compromissos mútuos; e
- Fornecer para o time uma ferramenta que possibilite o acompanhamento da evolução do projeto e que permita estruturá-lo em etapas mais gerenciáveis.
E não é que tem cliente que, inconscientemente (quero acreditar), prefere ver um cronograma atualizado do que software rodando? Querendo ou não, os cronogramas viraram o 'grande' documento de um projeto de software. Responsabilidade demais para algo que deveria ser só mais uma ferramenta. Pior: para algo que deveria evoluir junto com o projeto.
"A elaboração do melhor cronograma, usando as mais capacitadas pessoas e as melhores ferramentas, também será uma tentativa de prever o futuro. Algo que nossa espécie raramente faz bem."
- Scott Berkun
É impossível gerar um cronograma com um mínimo de acuracidade no momento inicial de um projeto. Berkun afirma e milhares de projetos confirmam esta 'lei'. Mas continuamos insistindo. Berkun adaptou "Software Engineering Economics", de Barry Boehm, e gerou o gráfico abaixo. Nos momentos iniciais de um projeto nosso 'chute' pode ter uma variação de 400%. Há quem arrisque 4 dígitos...
Berkun afirma que a volatilidade dos requisitos, dentre outros fatores, pode gerar estimativas de baixa qualidade. E que não há nada de errado com elas desde que sejam apresentadas como tal: Estimativas de Baixa Qualidade. E sugere a adoção de Níveis de Confiabilidade para nossas estimativas:
- 40% - é só um chute
- 70% - uma boa estimativa
- 90% - estudamos e detalhamos (quase) tudo
Uma boa estimativa dependeria principalmente de dois fatores: bons requisitos e um bom design (temas que serão tratados posteriormente).
E Berkun ainda pede: confie em seus programadores como você confiaria em um neuro-cirurgião. Se este falar que aquela operação no cérebro demorará 12 horas, você tem coragem de pedir para que ele reduza para, digamos, 4 horas? Você seria o louco o suficiente?
continua...
Marcadores: de_brooks_a_berkun, gerenciamento_de_projetos, livros
quinta-feira, 9 de março de 2006 |
Assine o finito
Lista completa no del.icio.us
Paulo
Parabéns pela iniciativa
Iniciei a leitura há pouco, e tudo indica que irei gostar muito
Quanto à segunda exeção apontada por Berkun: "Alguns times podem assumir mudanças mais facilmente", creio que a relação com a lei de Brooks seja que essas equipes, por suas características específicas, minimizam as dificuldades criadas pela inclusão de pessoas (interações, restrições, comunicação).