Estou lendo o novo e fantástico livro novo do Frederick Brooks, de título The Design of Design. Para aqueles da nossa área que ainda não o conhecem, Brooks é o autor do clássico livro de engenharia de software The Mythical Man-Month (que considero leitura obrigatória para executivos da área de TI).
Os primeiros capítulos do novo livro de Brooks são os mais interessantes, pois evidenciam claramente os problemas de se tentar realizar o design e construção de um produto seguindo um modelo cascata ( Waterfall ).
O capítulo 3 se chama 'What's wrong with this model?' e é focado em explicar porque, nas palavras de Brooks: 'o modelo cascata é errado e perigoso; precisamos superá-lo'. Ele inclusive mostra como o próprio Winston Royce (suposto inventor do modelo cascata) critica fortemente o modelo cascata no mesmo artigo em que o descreve (Royce apenas o usou como uma referência do que NÃO funciona).
O resultado de um processo de produto Waterfall (onde os requisitos são completamente definidos antes do design e implementação começarem) é um conjunto de requisitos enorme e gigantesco, a união de muitas listas de desejos, levantada sem nenhum tipo de restrição. E, para piorar, a lista não é priorizada ou medida em termos de custo versus benefício. As forças sociais envolvidas acabam proibindo o conflitos dolorosos ocasionais gerados pela priorização.
Nas palavras de Brooks: 'a proliferação de requisitos deve ser combatida, através de controle de natalidade e infanticídio destes requisitos'. Ele inclusive dá um excelente exemplo de uma pesquisa realizada por um comitê nacional americano em projetos militares dos EUA: 'Os projetos extremamente bem sucedidos tem um ou muito poucos objetivos e urgência de cronograma. Esses projetos começam com poucos requisitos de alto nível. Enquanto o desenvolvimento procedia, estes eram quebrados em requisitos mais específicos. Estes requisitos eram controlados e priorizados fortemente por gerentes capazes que continuamente balanceavam funcionalidade em relação a custo e prazo'.
Aí vem a grande pergunta de Brooks no capítulo 4, de título 'Requirements, Sin and Contracts': como podemos explicar a persistência de um modelo perigoso como o Cascata, quando já sabemos através de evidências maciças levantadas durante quase um quarto de século de que o modelo espiral/iterativo produz melhores resultados?
Antes da resposta, vamos supor o seguinte:
- O cliente ficará feliz em pagar para o seu fornecedor um preço justo pela sua experiência e trabalho.
- Ele conseguiu um fornecedor que age e usa suas habilidades para servir aos interesses reais dos clientes. Este fornecedor também realiza seu trabalho sempre almejando construir produtos com alta qualidade na melhor proporção de custo-benefício, dentro do prazo e orçamento.
- Todos são honestos, verdadeiros e a comunicação entre eles é excelente.
Tendo isso em vista, Brooks nos mostra que:
- Um contrato que pague o custo do fornecedor mais um bônus por metas irá dar ao cliente e ao fornecedor o melhor valor por dólar investido.
- Um modelo de processo espiral e iterativo vai gerar o produto mais apropriado para as necessidades principais do cliente.
Como podemos então explicar a existência de tantos projetos ainda seguindo um processo cascata? A resposta: Pecados... Especialmente Orgulho, Ganância e Preguiça.
Muitos olham as suposições acima e falam: 'Essas suposições nunca ocorrem! Os humanos são pecadores e não podemos confiar na motivação do outro. Como os humanos são pecadores, não podemos nos comunicar perfeitamente'. Por essa razão que entram contratos escritos. Precisamos de contratos para a proteção de faltas dos outros e para evitar nossa própria tentação de cometer transgressões.
E então, chegamos no ponto de Brooks: 'Claramente, é a necessidade por contratos dentro de uma mesma organização ou entre organizações que força a descrição muito precoce de objetivos, requisitos e restrições detalhados'. Portanto, segundo Brooks (e concordo com ele!), a necessidade por contratos detalhados melhor explica a persistência de um modelo errado como o cascata para projetar e construir sistemas complexos.
Não vou me atrever a opinar por este meio entre estes senhores tão eloquentes. É praticamente utópico no modelo atual de negócios da maioria do mercado de TI no Brasil, mas eu disse praticamente, não totalmente. Como já dizia uma candidato a presidente: "Yes, We Can".
