finito

Tag: The Mythical Man-Month

  • Como montar Times e influenciar Projetos

    Série “De Brooks a Berkun” – 2ª Parte

    A experiência prática de Fred Brooks, como citado anteriormente, foi com projetos mastodônticos: 1000 pessoas envolvidas ou mais. Mas ele lembra que desde aquela época os ‘gerentes de programação’ preferiam “pequenos e ‘agudos’ times formados por pessoas de ‘primeira classe’”. Brooks cita um estudo (de Sackman, Erikson e Grant) que mostra que um programador de ‘primeira classe’, que recebia US$20.000/ano, podia ser até 10 vezes mais produtivo que um programador de US$10.000/ano. Mas um pequeno grupo de ‘estrelas’ seria capaz de desenvolver um OS/360? Talvez em 10 ou 25 anos, segundo cálculos do autor. Por outro lado Brooks lembra que times grandes, orientados para a execução de um trabalho na base da ‘força bruta’, são “lentos, caros, ineficientes, e produzem sistemas que não possuem ‘integridade arquitetônica’. OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE, etc. A lista é longa”. E “o dilema é cruel”, escreve Brooks. Haveria solução?

    A sugestão de Brooks, baseada em uma proposta de Harlan Mills , dá título para o terceiro capítulo do seu livro, “O Time Cirúrgico”. Segundo ele, o time ideal é formado por:

    • Programador Chefe (Cirurgião)
    • Co-Piloto
    • Administrador
    • Editor
    • Secretárias (duas)
    • Bibliotecário
    • Almoxarife
    • Testador
    • Advogado (da Linguagem)

    Reparem bem. Nós temos praticamente 9 pessoas trabalhando para o programador! Dando-lhe “todo suporte que fará aumentar sua eficácia e produtividade”. Lembram-se que o Brooks também sugeria que alocássemos apenas 1/6 de nosso cronograma para tarefas de codificação? Outro mundo, não é mesmo? Pode e deve ser factível em um time cirúrgico de verdade mas aplica-se a equipes montadas para o desenvolvimento de sistemas?

    O ‘cirurgião’ seria responsável pela execução de todas as tarefas principais daquela parte do projeto: sua especificação, design, codificação, testes e documentação. Não difere muito de alguns job descriptions e anúncios de vagas que ainda vemos por aí. Seria um “analista-programador” que, segundo Brooks, deveria ter 10 anos de experiência.

    O mundo da programação mudou muito desde os tempos do COBOL e da PL/I. A complexidade e abrangência de nossas linguagens e arquiteturas de aplicações aumentaram ‘para os lados e para baixo’. E é cada vez mais comum que cada uma das tarefas listadas acima seja atribuída a um especialista. Uma divisão que é nítida em ‘fábricas de software’, por exemplo. Em caminho oposto, alguns advogados de métodos ágeis enaltecem a importância de um time formado por ‘generalistas’.

    A analogia com equipes médicas reaparece em um artigo de Peter Drucker publicado pela Harvard Business Review em 1988, “O Advento da Nova Organização” . Segundo Drucker, “informação é dado investido de relevância e propósito. Por conseguinte, a conversão de dados em informação requer conhecimento. E conhecimento, por definição, é especializado. (Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender).”

    Apesar de ser simpático aos chamados métodos ágeis, não acredito na possibilidade ou eficácia de um time composto por ‘generalistas’. Prefiro apostar em uma formação que valorize o perfil e a experiência de cada um de seus membros. No diagrama abaixo apresento um exemplo de um time desenhado para desenvolver uma aplicação web (ou ‘cliente/servidor n camadas’, como queiram):

    O arquiteto é o novo ‘cirurgião’. É o dono e principal responsável por aquele projeto ou módulo. Mas só coloca ‘a mão na massa’, codificando, para transferir conhecimentos. Ocupa-se com a concepção e manutenção da integridade arquitetônica da solução. Ele é diretamente apoiado por cinco especialistas:

    • Analista de Negócios (biz): cuida da coleta e organização dos requisitos, e apóia seu desenvolvimento, fazendo a ponte entre os usuários e a equipe de desenvolvimento;
    • Desenvolvedor de Interfaces (front): é especialista em usabilidade e ‘manda bem’ em conceitos de arquitetura de informações. Hoje deve ‘brincar’ com AJAX (Javascript), Flash, HTML, CSS, ASP, JSP, JSF e afins.
    • Desenvolvedor de Serviços (srv): domina orientação a objetos, componentização e, mais recentemente, serviços. É um programador clássico que, como tal, não leva o menor jeito com as ‘frescuras da camada de apresentação’.
    • Arquiteto de Informações (data): uma versão remoçada dos DBA’s (administradores de bancos de dados). Domina o desenho e desenvolvimento de bases tradicionais, transacionais, mas também sabe quando lançar mão de sistemas gerenciadores de conteúdo e bases analíticas.
    • Nosso antigo inimigo (infraestrutura): são os responsáveis por nossos servidores, redes, firewalls e outros brinquedinhos. Tê-los como parte da equipe de projeto desde os primeiros dias é uma prática que, com certeza, minimiza aquele ‘jogo de empurra’ que costuma acontecer um pouco antes ou um pouco depois do delivery da solução.

    Mas… e o coordenador? No próximo sub-capítulo falo especificamente sobre ele e sua convivência com o arquiteto.

    Agora, seguindo com o time cirúrgico proposto por Fred Brooks. O co-piloto que ele sugere é o ‘alter ego’ do cirurgião, capaz de executar qualquer tarefa atribuída à este. A única diferença é que o co-piloto seria menos experiente. Mas, ainda assim, funcionaria como um backup do cirurgião, inclusive representando-o em reuniões com outras equipes. Porém sua principal função é avaliar e discutir as idéias do programador-chefe. Lembra uma das práticas sugeridas pelo método conhecido como eXtreme Programming (XisPê – para os íntimos), a Pair Programming. A prática é polêmica e eu não disponho de dados que confirmem ou não as promessas de produtividade. Quero crer que a qualidade do código gerado realmente seja superior. Mas tenho algumas considerações que, por questão de tempo e espaço, tratarei em outra oportunidade.

    O ‘Administrador’ sugerido por Brooks é um tipo de Coordenador do Projeto. Apesar do cirurgião ter a palavra final em todas as questões, é o administrador que cuida do dia-a-dia da gestão financeira, de pessoal, suprimentos etc. Mais sobre o assunto no sub-capítulo seguinte.

    O ‘Editor’ é o responsável pela documentação. O cirurgião, segundo a proposta de Brooks, gera os documentos principais, tanto técnicos quanto aqueles para os usuários finais. Mas seria o editor o responsável pela compilação final, anexação de referências, bibliografia etc. É um luxo. Porém, ainda hoje brigamos para obter bons documentos de bons programadores, inutilmente.

    O ‘Bibliotecário’ – ‘escriturário’, ou program clerk, como sugerido por Brooks, não faz muito sentido nos dias de hoje. Mas parecia ser crucial nos tempos dos cartões perfurados e das intermináveis listas impressas em formulários contínuos. No entanto eu acredito que toda organização que esteja buscando o reuso de seus ativos de software, ou implantando uma SOA (Arquitetura Orientada a Serviços), demandará a presença de um bibliotecário, um especialista que em outro artigo eu chamei de GBA (Gestor da Biblioteca de Ativos).

    Se prestarmos atenção na complexidade dos atuais ambientes integrados de desenvolvimento (IDE’s – Integrated Development Environment), com seus frameworks, testes automáticos, integração com ferramentas de modelagem etc, veremos que pode fazer sentido o papel do ‘Almoxarife’, ou toolsmith, na nomenclatura original utilizada por Brooks. Um profissional especializado nas ferramentas e na sua adequação para cada tipo de projeto e função. Em equipes grandes ou em ‘fábricas’, parece ser uma função de grande utilidade.

    O ‘Testador’ é o nosso “Engenheiro de Testes”, uma função que aos poucos vai se tornando mais comum. Pena que muitos ainda o confundam com um ‘programador que não deu certo’. Teste é coisa séria, tanto que Brooks, como mostramos na 1ª parte desta série, dedicaria 50% do esforço de um projeto exclusivamente para ele.

    Por fim Brooks sugere a alocação de um ‘Advogado da Linguagem’. Creio que nossos espertíssimos e modernos IDE’s, nossos ‘testadores’ e, lógico, o arquiteto, eliminam a necessidade de um ‘language lawyer’. Advogado não, né?

    continua…

    ===

    1. Mills, H., “Chief Programmer teams, principles, and procedures”, IBM Federal Systems Division Report FSC 71-5108, Gaithersburg, Md., 1971.
    2. Artigo republicado em “Gestão do Conhecimento” (Harvard Business Review on Knowledge Management), Editora Campus, 2001.

  • Questão de Confiança

    Série “De Brooks a Berkun” – Continuação da 1ª Parte

    Berkun diz que o problema com nossos projetos não está nos cronogramas mas sim na forma como eles são elaborados e usados. O coordenador deve confiar nas estimativas apresentadas pelos programadores e demais membros do time. Se cada estimativa apresentada for bem justificada, não há porque desconfiar delas. Uma questão de validação: quão prováveis são os prazos fixados? “Se nenhuma probabilidade é oferecida e nenhuma pré-condição é colocada, então a realização do cronograma pode até ser possível, mas não é provável”.

    Que base de comparação, quais referências nós possuímos para avaliar corretamente as estimativas apresentadas? Tanto Brooks (em 75!) quanto Berkun insistem: só o domínio do nosso histórico, tanto de equipes quanto dos indivíduos, permitirá um julgamento justo. Qual a nossa produtividade, nossa ‘performance histórica’? Qual o índice de incidência de bugs? Existem estimativas para módulos/projetos semelhantes? Como elas foram elaboradas e quais fatores elas consideraram? Não há mágica!

    Por outro lado, os programadores devem confiar no plano, no cronograma apresentado. Como? Entendendo a lógica que o criou.

    O tema me faz lembrar duas provocações daquelas, feitas por Watts Humphrey:

    “Por que profissionais competentes concordam com cronogramas quando não têm a menor idéia sobre como irão cumpri-los?”

    “Por que executivos racionais aceitam tais cronogramas quando os engenheiros não oferecem a menor evidência de que poderão respeitá-los?”

    Berkun fecha o tema apresentando uma série de pequenas dicas muito úteis:

    • A duração de uma iteração deve ser coerente com a volatilidade do projeto. Quanto mais volátil, menor** deve ser a duração da iteração;
    • Devemos ser otimistas na elaboração do Documento de Visão (que será apresentado posteriormente) e pessimistas no cronograma*;
    • Devemos apostar no Design;
    • E planejar pontos em que as alterações de escopo serão permitidas;
    • Tornar pública a ‘filosofia’ do Plano – Cronograma;
    • Considerar a experiência da equipe no tipo de projeto que estamos tratando;
    • Assim como seu entrosamento;
    • E antecipar os riscos. Sempre! (o ‘Sempre’ foi meu).

    Só então, estabelecido um compromisso entre todos aqueles que se envolverão diretamente no desenvolvimento do projeto, é que o cronograma deveria ser Negociado com o cliente. Choque de realidade: muitas equipes são estruturadas após o ‘fechamento do negócio’. É triste, mas temo que não seja uma exceção.

    Não é difícil entender o ‘outro lado’. Normalmente, quando um projeto sai da área de negócios para aquisição, via departamento de TI, ele já está atrasado. Já é ‘para ontem’. Normal…

    … O problema começa quando a aquisição é fechada, o cronograma é apresentado desprovido “da menor evidência de que poderá ser cumprido”.

    Aos poucos estamos aprendendo que a Aquisição Progressiva é uma alternativa muito superior para contratações de projetos de software. Em linhas gerais: um projeto é fatiado em fases (normalmente todos já são); e as partes negociam apenas a fase imediatamente seguinte, aquela que apresenta o menor grau de incerteza. As partes começam com um grande número e um cronograma ‘genérico’, e concordam em refiná-lo no decorrer do projeto. O contratante pode optar por abrir uma nova concorrência a cada iteração/fase, mostrando independência e, principalmente, muita maturidade (em seus processos de desenvolvimento e aquisição de sistemas).

    Cronogramas: Um Meta-Modelo

    No texto original de “The Mythical Man-Month” Fred Brooks apresenta um ‘meta-modelo’ que deveria guiar a construção de todos os cronogramas. As regrinhas:

    • 1/3 – Planejamento
    • 1/6 – Codificação
    • 1/4 – Testes individuais
    • 1/4 – Testes de integração

    No capítulo 19 da edição especial do livro, “… after 20 years”, Brooks admite que seu modelo é muito waterfall (cascata). Pode ser, mas também pode ser adaptado para modelos de ciclo de vida mais modernos, iterativos (cíclicos) e incrementais.

    Mas… que luxo! Gastar 33% do tempo do projeto só em em planejamento!! E 50% do tempo do projeto em testes!?!

    Scott Berkun não deixa por menos e nos apresenta a “regra dos terços”:

    • 30% – Design
    • 30% – Programação
    • 30% – Testes

    Provavelmente gastamos os 10% que restam tentando justificar o cronograma, não é mesmo? Brincadeirinha…

    A simplicidade e objetividade das duas sugestões acima assustam um pouco. Mas, pense um pouco: Elas são válidas! Ambos começam concordando que devemos consumir cerca de 30% de todo o tempo do projeto apenas em seu planejamento e arquitetura. Isso não significa que, em um projeto de 9 meses, os três primeiros serão consumidos exclusivamente em atividades de planejamento e design. Em um processo de desenvolvimento mais moderno (apresentados na última parte da série), você planeja cada iteração. Mas se trata de um número justo. Eu diria ‘generoso’, se considerarmos diversos de nossos projetos.

    Berkun é também um desenvolvedor. Brooks nunca foi. Talvez isso explique o fato de Berkun dar o dobro de tempo para as atividades de codificação. Um pouco mais de 15%, como sugerido por Brooks, realmente é muito pouco. Mesmo com todos os frameworks e geradores de código ‘da vida’.

    Por fim temos as atividades tão ignoradas em tantos cronogramas: os famigerados Testes. Brooks pesa a mão e destina 50% de um cronograma exclusivamente para eles. Berkun se contenta com 30%. (Por favor, tentem esquecer por alguns instantes que ele trabalhou na MS, no projeto Windows, ok?).

    Régua, Esquadro e Bom Senso

    São os três elementos que devem existir entre o relógio-cronograma e a bola de cristal que apóia nossas estimativas. A Régua é nosso histórico de métricas, nossos índices de produtividade e coisas do tipo. Concordo que a máxima “não se gerencia o que não se mede” não se aplica totalmente em nossa área. Mas ignorar nossos números, definitivamente, não ajudará em nada.

    O Esquadro deve representar nossas ferramentas de apoio e ajuste. Se estamos em uma fase inicial do projeto, talvez os Use-Case Points sejam úteis. Já temos informações suficientes para municiar estimativas baseadas em Análise por Pontos de Função? Lancemos mão dela! Desde que não ignoremos o que a Régua nos ensinou.

    Por fim o mais importante: o tal Bom Senso. Na boca de muitos e em tão poucos projetos! O cliente não forneceu informações suficientes para uma boa estimativa? Então seja sincero e diga para ele que a estimativa apresentada é de ‘baixa qualidade’. Você suspeita que os requisitos são muito voláteis? Por que não sugerir um contrato de Aquisição Progressiva? Você não tem uma mínima equipe apoiando-o na elaboração das estimativas? Cobre o chefe. Ou contrate a mãe Diná, sei lá…

    —

    ** (update, 15/mar): estava aqui o erro apontado pelo Jonas Fagundes nos comentários. Tks!

    * Tem outra ‘regrinha’ que brinca com o equilíbrio “Otimismo X Pessimismo” que gosto bastante: tenha um Arquiteto pessimista e um Engenheiro otimista. Contradiz a regrinha do Berkun, mas costuma funcionar bem. Mas isso é assunto para o próximo post.

    Semana que vem: “Como montar equipes e influenciar projetos“.

    ps: Não, não sou fã do pai de todos os livros de auto-ajuda, “Como fazer amigos e influenciar pessoas”. Nada contra. Até já ganhei umas três cópias de alguns ‘amigos’. Mas, sei lá, entende? É uma questão de confiança.

  • 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:

    “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…

  • De Brooks a Berkun – Prólogo

    No ano passado comemorou-se 30 anos do lançamento da primeira edição de “The Mythical Man-Month“, de Frederick P. Brooks Jr. O livro pode ser considerado o primeiro clássico das áreas de Engenharia de Software e Gerenciamento de Projetos. Fred Brooks trabalhou por 8 anos na IBM, entre 1956 e 1964. Seu último ano foi dedicado ao desenvolvimento do OS/360, um empreendimento que envolveu mais de 5 mil homens/ano. Surge então a provocação que o levaria ao livro, uma ‘pergunta básica’ de Thomas Watson (CEO da IBM na época):

    “Por que programação é tão difícil de ser gerenciada?”

    Três décadas de avanços tecnológicos e de consolidação das ciências Engenharia de Software e Gerenciamento de Projetos não foram suficientes para tornar o texto obsoleto. Muito pelo contrário: até hoje o livro é considerado uma referência obrigatória. Em 2004, quando questionado sobre a razão da longevidade de sua obra-prima Fred Brooks respondeu: “Eles falam que o livro é a Bíblia da Engenharia de Software… é por isso que todo mundo o lê mas ninguém o usa!”.

    No ano em que comemorou seu trigésimo aniversário, “The Mythical Man-Month” ganhou um tipo de upgrade, de complemento. Trata-se de “The Art of Project Management“, de Scott Berkun. Não é só uma coincidência de temas, afinal existem milhares de títulos sobre Gestão de Projetos e Engenharia de Software. Mas vários outros aspectos aproximam as duas obras. Scott Berkun trabalhou por dez anos na Microsoft, em projetos como Windows, MSN e Internet Explorer. Ou seja, Berkun reviveu experiências parecidas com aquelas de Brooks em uma corporação de porte e relevância quase idênticas. Não é por acaso que os dois livros possuem linguagem e estrutura muito parecidos. São chamados “histórias de guerras”. Ambos são muito fáceis de ler e seguem uma ordem própria, em detrimento de padrões, nomenclaturas e sequências que caracterizam 9 em 10 títulos sobre gerenciamento de projetos lançados nos últimos tempos.

    Esta série de artigos foi concebida originalmente para comemorar os 30 anos de “The Mythical Man-Month”. Compará-lo ao recém lançado “The Art of Project Management” é só uma maneira de tornar a homenagem e, por que não dizer, as provocações, um pouco mais ricas.

    Estruturei a série em 5 grandes partes:

    1. Entre o Relógio e a Bola de Cristal
    2. Como Montar Times e Influenciar Projetos
    3. Castelos de Areia…
    4. … e a Inevitabilidade das Marés
    5. A Receita e o Bolo de Fubá

    Semanalmente publicarei aqui um novo capítulo ou sub-capítulo. Ao término da série, com a compilação das (esperadas) contribuições externas, será disponibilizado um arquivo PDF com seu conteúdo integral.

    Por incrível que pareça, nem “The Mythical Man-Month” nem “The Art of Project Management” mereceram uma edição em ‘português do Brasil’. Um lapso que ainda pode ser corrigido. E deveria. Como são best sellers, mesmo por aqui, razão comercial não há. Como Gestão de Projetos está na moda, resta-nos torcer para que, no meio daquele tanto de livro lançado para “ajudar a gente a passar na prova”, apareçam mais títulos como os de Brooks e Berkun.

    Este artigo não deve ser visto, de forma alguma, como uma alternativa aos textos originais. Ele deve servir como um incentivo para a leitura de ambos. Ou releitura, por que não? A última edição de “The Mythical Man-Month” comemorou seus 20 anos em 95. Ele traz uma série de artigos e capítulos complementares. Mas o texto original, como era de se esperar, foi mantido.

    Minha motivação parece ser a mesma de Berkun, resumida nessa provação de Douglas Adams:

    “Seres humanos, que são quase únicos em sua capacidade de aprender com as experiências dos outros, também se caracterizam por sua resistência em fazê-lo.”