Aldo Dórea vs Fred Brooks

Eu não tenho nada contra a maioria dos gerentes de projetos mas se tem alguma coisa que me irrita é alguém que acha que gerenciar projeto de software e levantar um prédio é a mesma coisa. Veja bem: eu tenho uns bons dez anos de experiência com projetos e recomendo fortemente uma abordagem ágil, iterativa e incremental para eles, mas estou falando de projetos de software, não de projetos em geral. Eu não tenho a menor idéia se isso funcionaria para levantar um prédio, sei que funciona para software e por isso você não vai encontrar neste blog ou em alguma publicação minha qualquer dica para gerenciar a reforma do seu banheiro. Na verdade eu até evito comparações com outras engenharias porque elas sempre são danosas (o próprio conceito por trás do nome ‘engenharia de software’ é danoso).

Neste cenário temos o número atual da Mundo PM e um artigo de Aldo Dórea Mattos, M. Sc.. Aldo é um profissional com bastante experiência no mundo da construção civil. Segundo seu mini-curriculum na revista ele é engenheiro, advogado, mestre, já trabalhou em projetos em 4 países e é autor do livro “Como Preparar Orçamento de Obras”. Aldo escreveu um artigo com o título muito interessante de “Por que os cronogramas ‘furam’?”.

Em seu artigo Aldo foca em um relatório apresentado num grande congresso do PMI com este tema. O relatório foca… construção civil. Eu realmente achei que era uma leitura interessante até porque eu sempre tenho a dúvida se só nós sofremos com tantos problemas quando alguém cisma de usar técnicas de waterfall e controle total nos nossos projetos, mas o autor faz questão de citar este infeliz exemplo:

[...]O desenvolvimento de um cronograma é feito a partir de premissas de planejamento, que são pressupostos assumidos pelo GP e sua equipe. As premissas de planejamento estão na definição das produtividades que geram as durações das atividades - por exemplo produtividade do pedreiro no levantamento de uma parede de alvenaria (em m² /h), produtividade de um programador no desenvolvimento de linhas de programação (linhas/dia), produtividade de uma máquina na fabricação de componentes industriais (un/h)[...]

-Mundo PM #17, Pg 34

O que está errado na frase acima? Eu imagino que Aldo tenha muito conhecimento sobre construção civil, não imagino quanto de conhecimento ele tem sobre indústrias mas definitivamente não creio que ele saiba muito sobre programas de computador e quem os escreve.

Veja bem: ele compara o levantamento de uma parede -algo que é feito por um profissional com conhecimento meramente operacional- ou a produtividade de uma máquina à de um programador. Enquanto ainda não faz tal comparação infeliz o texto diz:

[...]A quantidade de recursos pode definir a duração da atividade ou, ao revés, ser determinada por ela. É só pensar numa tarefa alvenaria, cujo quantitativo seja de 600m² e cujo recurso prioritário seja pedreiro, com uma produtividade de 10m²/dia. Pode-se proceder de duas maneiras[...]fazer a parede em 15 dias, são requeridos 4 pedreiros; ou[...]com uma equipe de 5 pedreiros levanta-se a alvenaria em 12 dias[...]

-Mundo PM #17, Pg 33

Posso tirar pelo trecho seguinte, mostrado acima neste post, que o autor não faz distinção entre o tal pedreiro e sua parede do programador e seu código.

Como vocês estão carecas de saber eu já fui consultor, tanto autônomo quanto associado à uma empresa, incluindo empresas de três letras. Já entrei em muitos enormes clientes ansiosos por uma resposta aos seus problemas: por que eles não conseguem sequer prever o prejuízo num projeto de software? E sei que um artigo deste tipo cai como uma bala de prata.

Ops, bala de prata? Já que estamos neste tema vamos chamar ao diálogo Frederick Brooks, autor do paper seminal chamado “No Silver Bullet”. Fred também é uma pessoa importante no seu meio. Hoje dá aulas na Universidade da Carolina do Norte -onde fundou o departamento de Ciência da Computação- mas é mais conhecido como “o pai do Operating System/360″, um dos maiores projetos de software já realizados. Por este trabalho ele ganhou a medalha nacional de tecnologia dos EUA em 1985. Seu livro “Mythical Man-Month, The: Essays on Software Engineering” ganhou um dos prêmios mais importantes do mundo da computação, o Turing Award.

E lá vem Brooks discordar:

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.)

Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

–Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, Capítulo 1

Não faz muito sentido comparar isso com um muro de tijolos, faz? E quem será que entende mais de software? E sobre recursos em um projeto?

The second fallacious thought mode is expressed in the very unit of effort used in estimating and scheduling: the man-month. Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them (Fig. 2.1). This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.
[...]
When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule [...]. The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging.

–Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, Capítulo 2

Não adianta você adicionar mais mulheres ao processo, a gestação dura quase sempre nove meses. Você não pode calcular progresso apenas pelo número de pessoas dividido pelo número de tarefas, isso é cálculo de padaria inútil no caso de software.

O problema não é nem a confusão feita pelo autor com relação à o que é um trabalhador relativamente operacional -pedreiro-, o que é uma máquina industrial e o que é um trabalhador de criatividade como um programador. O deslize de um é o de menos. O problema é que esse tipo de informação publicado numa revista que atinge a um mercado tão seleto quanto aos gerentes de projeto do Brasil (e que custa a bagatela de R$23,90) vai influenciar negativamente todo o mercado.

Eu tive que copiar trechos da SafariBookshelf (serviço que uso e recomendo) para fazer este post. Eu tenho o livro do Brooks, ou pelo menos tinha. Em algum momento de 2004 eu emprestei o livro para meu então Gerente de Projetos e ele nunca mais devolveu. Dia desses estive com ele e perguntei do livro, ele ficou de me devolver. Perguntei se ele leu e ele disse que não. O livro está na mesa dele há 3 anos e ele não leu, mas sei que ele assina a Mundo PM. A literatura ‘fácil’ ganha da literatura adequada, eu diria.

Eu continuo sem saber se construção civil e construção de software são parecidos o suficiente para utilizarem as mesmas técnicas de gerenciamento de projetos. O exemplo infeliz da revista me faz acreditar que não são, mas tem algo curioso nele: O artigo em si é sobre diversos problemas que resultam em atraso, problemas presentes em construção civil no caso mas que também acontecem em construção de software. As soluções que o autor propõe talvez funcionem em engenharia civil mas eu já as vi aplicadas à construção de software e… bem, não funcionam. Algo que tem funcionado com relativo sucesso para desenvolvimento de software, entretanto, é inverter os conceitos do artigo e tentar algo mais simples: metodologias ágeis. Se a construção civil sofre tanto de atrasos talvez, só talvez, seja a hora de uma das mais antigas engenharias aprender algo com uma das mais novas. Mas só talvez.

Se você quer saber como não fazer seus cronogramas ‘furarem’ em vez de gastar R$23,90 fiquem com uma frase de alguém que realmente entende de ciência da computação:

1. Estimates of the length of an activity, made and revised carefully every two weeks before the activity starts, do not significantly change as the start time draws near, no matter how wrong they ultimately turn out to be.

–Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, Capítulo 14

E pensem em como sua metodologia apóia este tipo de revisão de estimativa, como seu cronograma pode se adaptar a isso. Se não achou nada no seu cenário atual, mude.

10 Responses to “Aldo Dórea vs Fred Brooks”

  1. Puxa Philip,

    Gostei muito do texto e também de saber que vc é fã do trabalho do Brooks. Parabéns!

    Mas o chato não podia deixar de colocar um alerta: a frase abaixo pode parecer a descoberta de uma ‘bala de prata’:

    “A solução que nós estamos achando é simples: métodos ágeis.”

    Ok: “estamos achando”. Pq tem muita bobeirinha que aparece também em algumas propostas ágeis. Do nível daquelas do Aldo.

    Abraços,

  2. Vinícius says:

    Excelente como sempre. Seus textos são ótimos.

  3. pcalcado says:

    Paulo,

    Perfeito! Substituindo a frase por algo menos tendencioso.

  4. Leandro says:

    Juridicamente, ao menos no Brasil, somos (não os engenheiros da construção cívil mas os ‘engenheiros’ de software) tratatos como artistas, ou seja, temos em lei que nosso trabalho (software) é fruto de inspiração da alma.

    Nunca gostei de tentar colocar engenharia num processo ‘artistico’. Uma das piores abordagens é o mal uso do conceito de “Fábricas de Software”. Tem empresas que realmente tratam (ou tentam) o processo de criação de software como um processo segmentado e fragmentado. Já vivi absurdos onde um analista analisa (tudo) passa para a Fábrica (tudo) e os programadores devem implementar isso sem recorrer aos analistas, se procurassem um analista e porque ou o analista não produziu um documento conciso ou o programador não entendeu o documentos…. um processo onde Analista cria produto A, programador com produto A implementa e entrega software, sem poder voltar, como numa esteira…. Temos muito o que aprender e rever E MAIS IMPORTANTE NÃO ACEITAR TUDO ASSIM TÃO FACILMENTE….

  5. Caro Phillip,

    A galera esta toda lendo você… realmente teus post são campeões de audiência… aprendeu com quem?

    Olha construção civil não esta tão bem assim não, mesmo sendo projetos com caracteristicas muito menos complexas, incertas, e imutaveis….

    Existe um método muito parecido a Scrum, da Lean Construction Institute, que se utiliza de Post-Its e onde quem planeja são as pessoas que executam, ele se chama LPS (Last Planner System) e com ele tem conseguido em construções complexas reduzir o time to market em até 50%, e em complexos hospitalares onde a quantidade de detalhes é muito grande estão conseguindo baixar o retrabalho, aumentar o valor e criar soluções sob demanda difíceis de ser planejadas upfront.

    O problema todo é definir quais são os requisitos e parâmetros mínimos de funcionamento de cada método e suas tolerância, por exemplo:

    Qual o grau de tolerancia de variancia?
    30x de produtividade entre desenvolvedores

    Qual o grau de Tolerancia de incertezas?
    Os usuarios e clientes tem dificuldade em determinar o que precisam antes de ver alguma coisa.
    Até 70% das funcionalidades não agrega valor.
    Grandes partes da solução podem perder valor rapidamente por mudanças no mercado, nas tecnologias, ou no modelo de negócios, durante o projeto.

    Qual o grau de Tolerância a mudanças?
    Grande maioria dos detalhes das funcionalidades do produto mudam durante o projeto, por conta do conhecimento que vai sendo gerado durante o processo.

    Se usamos um metodo para um trabalho que requer parametros que estão dentro da zona impossivel estamos usando o metodo errado, e ponto.

    Não é bala de prata é bobagem por exemplo eu querer fazer um plano “tatico” de compras e vendas de ações no day trading de 1 mês, vou me ferrar legal a menos que tenha bola de cristal. Porem posso fazer um plano “estrategico” definindo objetivos, pontos de compra e venda para garantir uma margem x%, um conjunto de ações com as quais vou trabalhar, etc. mais não quando vou comprar e vender o que, porque estou trabalhando com niveis de incertezas maiores que as que esse metodo pode me dar bons resultados, ele “sempre vai falhar” ou se tiver sucesso será por conta de uma sucessão de fatores externos dos quais não tenho controle, mesmo que faça analises de risco, trabalhe a moral do meu operador de bolsa, beije um santinho antes, as chances vão estar contra mim na maior parte do tempo.

    Bom me inspirei… um blog dentro de um blog… sacanagem….

    Abraços,
    Juan.

  6. Shoes,

    Vou escrever sobre gerenciamento de projetos de software na MJ de novembro. Sugerí o mesmo tema para a MundoPM, para ver se esses GPs abrem a cabeça. Mas acho que está Xiita demais para a MundoPM. A alma do artigo é “não confunda tradicionalismo com burrice”.

    Rodrigo Yoshima

  7. Eu também aprecio suas resenhas e me senti honrado ao constatar que você leu meu artigo na MundoPM.

    Os comentários que você tece fazem todo sentido, mas preciso fazer uma ressalva. O exemplo da alvenaria não se propõe a comparar um pedreiro com um programador, o que aliás seria desprovido de sentido. O que quis alertar é que o conhecimento das produtividades é crucial para um cronograma factível. Programadores também têm produtividade. Ou não?

    Parabéns pelos textos!

  8. pcalcado says:

    Oi, Aldo,

    Sim, m cronograma “de verdade” (e eu jah irritei muitos PMs camando os cronogramas deles de “de mentira”) precisa saber a produtividade para ter um mnimo de precisao. O ponto eh que isso nao eh dado desta forma.

    Recomendo a leitura sobre o conceito de “velocidade” que eh aplicado a times ageis. Eh ma metrica factivel e bem proxima da realidade para ser utilizada nestes casos.

    []s

  9. [...] levemente acoplada: não percam o artigo de hoje do Philip “Shoes” Calçado, no Fragmental. .:. Bookmark / [...]

  10. [...] lembro que, ainda estagiário, meu sangue esfriava e minha pressão baixava com medo das mudanças no projeto. era visível a cara de medo e tristeza na equipe quando a mudança era dita. quem nunca ouviu falar nas tais “solicitações de mudança”? Ai daquele que acha que produzir software é como levantar um prédio. [...]