finito

Categoria: Biblioteca

Dicas de livros e outras referências.

  • 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.”

  • Meme #009

    ManagementSpeak: This company is ISO 9000 certified.
    Translation: We have documents to prove who screwed up.

    Hehe.. Sou fã do Bob Lewis desde que li “IS Survival Guide”. No livro ele já tinha essa série, com “falas da gerência” e suas “traduções”. Hoje ele mantém o site “IS Survivor” e o mesmo bom humor.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Meme #008 – "You Get what You Pay For"

    Trechos de um excelente artigo de Bob Lewis, autor de “IS Survival Guide”:

    …

    What motivates most employees is achievement, approval, or a sense of belonging to an exclusive group that’s doing something important. The money is nice, but not their primary driver.

    Not that they ignore what they’re paid. Quite the opposite — they give it their closest attention. That’s because a company’s compensation system is the loudest, clearest, and most emphatic communications channel it has for explaining to employees what it considers important.

    The classic example, used in every introductory seminar on Total Quality Management ever given, is the company that decided it wanted quality. It preached quality, taught quality techniques, and measured quality improvement. The result, month after month, was a total lack of improvement in its defect rate. Why? The factory manager’s bonus depended on how many widgets rolled off the production line every month.

    Pay for quantity, beg for quality, and quantity will win every time. What you pay for explains your priorities far better than your company newsletter.

    Bring it home to IT. Many CIOs want to establish a more process-oriented perspective in their organizations, to get (all together now!) Repeatable, Predictable Results. Whether it’s an ITIL initiative or an attempt to rise to higher levels in the Software Engineering Institute’s Capability Maturity Model, they want the IT staff to “plan the work and work the plan” instead of coming to work every day as if the world had just been created fresh and new.

    Good for them. These are important goals for many IT organizations. So if you’re one of them, go ahead and want process, teach process techniques, and measure process results. And then …

    A project team finds itself under time pressure. The project manager rallies the troops, who work a succession of twenty-four hour days and seven-day weeks. Gasping for breath, exhausted but exhilarated, they meet their deadline with minutes to spare.

    Impressed, you give them all bonuses for going the extra mile.

    Outstanding. Except …

    Another project team doesn’t find itself under time pressure. Every week, every team member meets every milestone. The project manager spots risks and issues early and deals with them. If one team member gets into trouble, the rest help out immediately so the schedule is never in jeopardy. The deadline rolls around, they put the software into production, and go home to spend the weekend with their families.

    Boring. Why would you give them a bonus? They didn’t go an extra block, let alone an extra mile. All they did was the work in front of them.

    Making process happen in IT is hard. If you pay extra for heroics while ignoring those who do their work by the numbers, you’re preaching process in a whisper while shouting, in the loudest voice you can, that you really don’t care for it all that much.

    As with any good process, the results are predictable, and have been repeated so many times you’d think we’d have caught on by now.

    You get what you pay for. If you want process, start paying for it, instead of its opposite.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Meme #007 – "What needs 2 b done?"

    Se vc surrupiar uma frase de alguém para usar como ‘slogan’ corre o risco de ir parar na cadeia? Espero que não. A frase aí é do Drucker. Já tinha pintado por aqui no post “Ask a great question“. Fala tudo que o FINITO pretende falar.

    É mais “SLOGAN”, né? Pq uma frase tão boa quanto é uma do Fernando Sabino, que pintou como um graffiare no GrAFfiTi: “No fim tudo dá certo, se não deu certo é porque ainda não chegou ao fim.”

    Dúvida: um Meme pode ser uma pergunta?

    ps: graffiare no graffiti? SIC2x – a turma vai dizer que é tão ruim (no pior sentido mesmo) quanto “colocar o google no blog”, uma das frases ‘contumbantes’ de 2004.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Meme #006 – "Reality Shock – The Chaos Report"

    Pesquisa do Standish Group em 2004:

    .53% dos projetos em ‘alerta’ (atrasados, acima do orçamento etc etc)
    .29% de projetos bem sucedidos
    .18% de projetos cancelados

    O ‘Chaos Report’ está completando 10 anos. Em 1994, tínhamos os seguintes números:

    .52.7% de projetos em ‘alerta’
    .16.2% de projetos bem sucedidos
    .31.1% de projetos cancelados

    Praticamente dobramos o número de projetos bem sucedidos (ou reduzimos pela metade os cancelados). Mas mais da metade ainda é reportada como ‘em alerta’. Apesar… deixa pra lá.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Meme #005 – "Why Software Quality Matters"

    Software Quality: By The Numbers
    By Deborah Gage and John McCormick
    (surrupiado da Baseline)

    There can be as many as 20 to 30 bugs per 1,000 lines of software code.
    —Sustainable Computing Consortium

    There are no methods of removing software defects or errors that are 100% effective.
    —“Software Quality: Analysis and Guidelines for Success,” by Capers Jones

    32% of organizations say that they release software with too many defects.
    —Cutter Consortium

    38% of organizations believe they lack an adequate software quality assurance program.
    —Cutter Consortium

    27% of organizations do not conduct any formal quality reviews.
    —Cutter Consortium

    Formal design and code inspections average about 65% in defect removal efficiency. Most forms of testing are less than 30% efficient.
    —“Software Quality: Analysis and Guidelines for Success,” by Capers Jones

    Developers spend about 80% of development costs on identifying and correcting defects.
    —The National Institute of Standards and Technology

    Peer reviews of software will catch 60% of defects.
    —Institute of Electrical and Electronics Engineers

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Meme #004 – "O Lado Construtivo do Meme 003"

    Peguei pesado no Meme #003 (intencionalmente) e cometi um pecado mortal: só “desconstrui” – não coloquei nada no lugar. Tentarei me redimir.

    Há tempos o “Alinhamento Estratégico com o Negócio” aparece na lista das 10 prioridades dos CIOs. A capacidade de “vender” internamente um projeto é uma das melhores maneiras de se verificar o quão “alinhado” com o negócio está o CIO. Em uma empresa confusa, desprovida de um Plano Estratégico que, de maneira direta, aponte suas iniciativas no médio e longo prazos, será uma grande covardia cobrar “alinhamento” do CIO. Por outro lado, em todas as empresas que “sabem para onde vão”, deveria ser trivial “vender” um projeto para o board. Mas, aparentemente, não é. A “intangibilidade” e imensa “complexidade” dos projetos de TI seriam as maiores barreiras.

    Foi publicado no ano passado (2004) um excelente livro de Robert Kaplan e David Norton (inventores do Balanced Scorecard) chamado “Mapas Estratégicos“. A nova ferramenta proposta pela dupla visa exatamente facilitar o alinhamento dos ativos intangíveis de uma empresa com seu planejamento estratégico. É meio triste (e paradoxal) ver TI na mesma categoria de “capital humano” quando o critério de classificação é a sua tangibilidade. Ainda assim, a ferramenta proposta no livro para avaliação da “Prontidão do Capital Informacional” é excepcional. Não consigo mais imaginar um portfólio de projetos sem a visualização proposta na obra.

    Quem já teve oportunidade de utilizar a ferramenta percebeu que ela limita-se a tratar os ativos e projetos de TI em alto nível. Parece ser o nível ideal para a negociação com o board, mas deve ser detalhada para uso pela equipe de TI. Antes de ser acusado de “simplista” quero deixar claro que não vejo os Mapas Estratégicos como o “pulo do gato” da “Arte de vender bem um projeto” (chamada de capa da Info Corporate). Mas não tenho a menor dúvida de que uma boa “venda” começa na excelência da gestão do portfolio e dos ativos de TI.

    ps: Falo um pouco mais sobre Mapas Estratégicos neste artigo.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.