Quase não tenho tempo mas preciso dizer: Muricy, técnico do São Paulo, acabou de dar uma breve entrevista ao vivo no programa da bela Renata Fan (Band). Acho que ele nunca vai virar palestrante ou autor de livros sobre vitórias e liderança. Mas, sinceramente, parece ser o cara daquele universo (esportes) mais gabaritado para tal. Exemplos:

• Humildade: sabe que só mantém o cargo com vitórias - currículo não vale (quase) nada. E se cobra diariamente: "preciso vencer."
• Humildade 2: fugiu da comparação com Luxemburgo: "ele tem a vida dele, eu a minha. Não penso nos títulos dele: preciso vencer."
• Seriedade: "se eu ficar vaidoso a coisa aqui vira uma festa. Aqui não tem lugar pra isso. Aqui é lugar para trabalhar."
• Honestidade: "a melhor coisa que eu faço é dormir bem toda noite."
• Sinceridade: "o melhor elenco do futebol brasileiro hoje é do Inter. É o time que soube investir melhor."
• Sinceridade 2: "eu sou chato mesmo, não sou muito agradável."

Venha ou não o tri (tomara que não!), o fato é que o Muricy não é competente só na base das "hard skills" (técnica, tática, estratégia) não. É um manager completo e, vale dizer, bastante moderno.

Our culture does not think of movie directors, executive chefs, astronauts, brain surgeons, or rock stars as project managers, despite the fact that much of what these cool, high profile occupations do is manage projects. The difference is these individuals would never describe themselves primarily as project managers. They’d describe themselves as directors, architects or rock stars first, and as a projects manager or team leaders second. They are committed first to the output, not the process. And the perspective many PMs have is the opposite: they are committed first to the process, and their status in the process, not the output.

- Scott Berkun (pra variar, em outro fantástico artigo.)

Fiquei sabendo no Buteco do Alessandro Almeida que os capítulos brasileiros do PMI acabaram de publicar o "Estudo de Benchmarking em Gerenciamento de Projetos Brasil 2007" (opção Benchmarking GP - É gratuito mas requer registro). Vivo reclamando mais e melhores estudos deste tipo aqui em Pindorama. Vivo ignorando que o PMI.br, através de voluntários, elabora este desde 2003. Ele é muito genérico e a população amostral é muito pequena, mas é melhor do que nada.

184 empresas toparam participar deste tipo de 'biópsia'. São das mais diversas áreas e o estudo cobre projetos de qualquer natureza. O relatório, com dois anexos, merece mais tempo de análise. São mais de 300 páginas, centenas de gráficos. Mas eu busquei alguns pontos para ter uma noção geral de como estamos e para onde vamos quando o tema é o gerenciamento de projetos.

Sumário executivo: quando o retrato não é feio nem hilário, é deveras curioso. Se apenas o supra-sumo da gestão de projetos participou do estudo, não há dúvidas de que o buraco está milhas abaixo. Claro, há outra forma de ler os números. Muitos falarão: "estamos evoluindo!". Me apego ao lado negativo para mostrar que podemos avançar bem mais e mais rapidamente. Se começarmos do básico!


No apanhado geral os números de sempre, bem próximos daqueles que pintam no Chaos Report (que trata só de projetos de software):

• 78% dos projetos atrasam;
• 64% estouram os orçamentos;
• 44% apresentam problemas de qualidade; mas só (!?)
  
• 39% dos clientes reclamam.

Entre os principais problemas apontados, os suspeitos de sempre:

• 62% de mudanças no escopo;
• 60% de escopo mal definido.

A estranheza começa quando comparamos os números acima com outros dados. Por exemplo, quando o estudo pergunta quais foram os benefícios obtidos com a implantação de práticas de gerenciamento de projetos:

• 81% dos pesquisados diz ser um "maior comprometimento com os objetivos e resultados"; enquanto
• 72% aponta uma melhoria na qualidade dos resultados.

Traduzindo: a coisa conseguia ser ainda mais feia? Pelo jeito, sim.


Alinhamento estratégico é minha obsessão de cabeceira há algum tempo. Então mergulhei um pouco mais na porção "estratégica" do relatório. 18% das empresas pesquisadas dizem ter seus projetos "sempre alinhados ao planejamento estratégico da organização". Outras 48% juram que "quase sempre" se alinham - mas têm "genuína preocupação" com isso. Deu 66%, certo?

Pois bem, acontece que 55% das empresas falaram que "não há um processo estruturado para seleção de projetos". Pior, em 66% não há um "processo estruturado para a priorização de projetos". Traduzindo: tem 21% de respondentes que conseguem "genuinamente" buscar o alinhamento sem saber ao certo quais projetos são necessários e quando. Vão na base da sorte, do 'achômetro' ou da 'força política' de determinado diretor?

Finalizando a parte 'genérica', uma curiosidade: em 28% das empresas é a área de TI que mais utiliza o gerenciamento de projetos. Normal. 11% engenharia - pouco. Mas o que chama a atenção é a área de marketing: só 6%? Estranho porque quase tudo em marketing pode ser visto e administrado como projeto. Porque tamanha distância? Será falta de conhecimento ou resistência? Bem que alguém podia tentar descobrir.


Um dos anexos do estudo mostra os resultados por setor. Claro, degustei um pouco os números específicos de TI e Telco. Das 184 empresas consultadas, 58 (32%) são de TI. Outras 7 (4%) de telecomunicações. Aqui alguns "indicadores" pioram consideravelmente:

• 82% dos projetos de TI atrasam; em Telco é pior
• 88% de "problemas com prazos";
• 66% dos projetos de TI têm problemas com o orçamento;
• 88% dos projetos de Telco estouram orçamentos.
• 46% dos projetos de empresas de TI apresentam problemas com a qualidade, o que gera 41% de insatisfação dos clientes.
• 75% dos projetos de empresas de telecomunicações falham na qualidade - 63% dos clientes reclamam.

Problemas com definição de escopo e mudanças também ganham números bem acima da média, algo entre 81% e 86%. A única diferença, bastante perceptível, é o aspecto "mudança de escopo" em telecomunicações: só 7%. O que, de certa forma, piora ainda mais os números acima - a percepção que temos deles.

Usando uma lupa (literalmente - a qualidade de alguns gráficos do estudo é muito ruim) podemos perceber algumas causas para os efeitos listados acima.

Só metade das empresas de TI utilizam uma metodologia "de fato". Tratamos aqui de metodologias para gerenciamento de projetos. Curioso, não? Em Telco é mais assustador: só 1/4 das empresas empregam uma "de fato".

Riscos? Em TI, só 33% dos pesquisados dizem possuir uma "metodologia formal". Minha tradução: daquela metade que diz ter uma "metodologia", em 17% a "metodologia" é cambeta. Como se gerencia projetos sem gerenciar riscos? Ufs... Uma justificativa torta aparece no mesmo relatório: para muitas empresas, gerenciar projetos é gerenciar escopo e prazos. Só!

Quando a pesquisa vai para o lado "pessoal", outras possíveis causas pulam como pipoca. Nas empresas de TI a qualidade mais valorizada em um gerente de projetos é a Liderança. Em Telco, a Atitude! 0%, ZERO empresas citaram "trabalho em equipe". Assusta que em ambos os setores problemas de comunicação apareçam em 86% das empresas? Claro que não.

Mas não se preocupem: 86% (TI) e 88% (Telco) da alta administração "percebe claramente os benefícios obtidos com o gerenciamento de projetos".


O estudo é bom, necessário. Uma iniciativa louvável. O grande problema agora está com a qualidade das respostas. Há muita incoerência. Se uma parte é fruto direto de nossa falta de maturidade, outra não pode ser explicada de outra forma: teve gente "dourando a pílula", "puxando sardinha", dizendo não-verdades. Se em 0% das empresas de Telco há processos para seleção e priorização de projetos, como 12% delas podem ter um PMO com o nível 4 de maturidade?

É tanta coisa a ser feita que assusta. Não gosto de falar do PMI mas vai aqui uma dica / provocação: os números respingam aí. Que tal desviar um pouco os olhos do umbigo-certificação e começar a se preocupar com números tão ruins? Que tal colocar algumas metas, principalmente para aquelas entidades que valorizam tanto sua certificação? Uma última, bem legal: que tal, na próxima edição, nos mostrar os números das empresas que contam com profissionais certificados em separado? Assim fica mais fácil justificar sua existência, não?

Ao resto do mundo: valorizemos o básico. Esqueçamos, por enquanto, ferramentas, PMO's, OPM's, BSC's. Nada disso gera resultado sem uma forte cultura de projetos. E cultura nenhuma nasce com "nível 3 de maturidade". Vamos valorizar o básico. Vamos falar de escopo e mudanças, riscos, comunicação e trabalho em equipe. Depois a gente viaja. Agora é hora de pé no chão e trabalho sério.

Eu não sabia, mas a dupla "Arquiteto e Engenheiro" está junta até na festa. Na última terça, dia 11/dez, foi o Dia do Arquiteto e também o Dia do Engenheiro. Não creio que seja coincidência, mas também não corri atrás para descobrir. Não importa. Coincidência é que depois de amanhã (sab, 15/dez), um dos maiores arquitetos do mundo esteja celebrando 100 anos de idade. E eis que todo mundo abre generosos espaços para contar um pouquinho da vida e da obra de Oscar Niemeyer.

O caderno "Mais", da Folha do último domingo, trouxe curiosas leituras das "revoluções" de Niemeyer. Prós e contras!? Como toda unaminidade é beócia, adorei saber que existem "contras". Rica também está uma série de reportagens especiais do Jornal da Globo [1]. O capítulo de ontem foi especialmente chamativo: Engenheiros passavam noites em claro, atrás de soluções para os "problemas" criados por Niemeyer. A palavra "problema" com certeza não apareceu. Mas foi assim que li: o Arquiteto é um "criador de problemas".

E o que esse papo tem a ver com o Graffiti? Tudo. Não é de hoje que brigo muito para que TI "copie" mais outras áreas de conhecimento. Que aprenda com outras áreas. Há tempos, independente do trabalho, insisto (particularmente lá no finito) que tiremos das costas dos coordenadores de projetos uma parte do peso que eles carregam. Considerando sua formação básica, formalizada pelo PMBoK, sugiro que a disciplina "Gerenciamento do Escopo" vá para outra pessoa: para um Arquiteto.

Não estou sendo nada original não. Lá no distante 1975, Fred Brooks já dizia [2]:

Pensadores são raros. Executores são raros. Pensadores-executores são raríssimos.

Já defendia a tese quando conheci a proposta Scrum, um processo para gerenciamento de projetos. Tem algo muito parecido ali. Há um Product Owner - dono do produto, um Arquiteto (na minha leitura), e um ScrumMaster - o gerente do projeto. O primeiro é o pensador. O segundo, o executor. Jeff Sutherland, um dos "inventores" do Scrum, tem uma didática analogia: como numa equipe de Rally, o primeiro é o "Navegador" e o ScrumMaster é o "Piloto".

A mesma lógica ganha implementações diferentes, provocativas e promissoras. Não me lembro onde vi, mas a Promon tem desafiado alguns dogmas com coragem. Seus departamentos agora têm dois responsáveis. Um cuida do dia-a-dia, enquanto o outro "pensa a longo prazo". Sei, é um tanto diferente do que foi proposto no parágrafo anterior. Mas também serve para ilustrar a "tese".


Comecei a entender a validade dessa "lógica" antes de conhecer qualquer teoria. Foi na prática, na necessidade, lá no início da década. Trabalhando na linha de frente, quase sempre eu levava para a empresa o problema já acompanhado de uma "idéia de solução". Um mix de requisitos do freguês com idéias que eu não conseguia segurar. Foi doloroso o aprendizado. Eu "carregava" demais em minhas próprias idéias. Aprendi que é um método muito eficaz de diferenciação. Mas, na dose errada, cria problemas. Corrigindo: cria mais problemas do que deveria. Porque, como eu disse lá no início, o arquiteto é (ou deveria ser) um "criador de problemas".

Depois, em outras funções, pude aprofundar um pouco mais as minhas experiências. Repito em minhas palestras e oficinas uma estranha dica: "Tenha um Arquiteto pessimista e um Engenheiro otimista". Combinação fantástica [3].

O Arquiteto pessimista é mais pé no chão. Domina bem a tecnologia em questão e compartilha com o freguês as suas "dores". Mas não viaja. É pragmático e ágil no desenho das soluções possíveis. Quando avaliando todas as possibilidades, em conjunto com a equipe, sempre fala "não" antes do "sim". Aqueles "nãos" que eram pura teimosia costumam morrer em 24 horas. E se converter em criativos e valiosos "sims". Repare: o desenho da solução acontece em grupo. O arquiteto guia o processo. E seu voto é mais valioso que os demais. A razão é simples: ele, por princípio, é o único com a visão do todo.

O Engenheiro otimista não é menos pé no chão que o arquiteto. A diferença fundamental é que ele não é tão negativo. Por natureza, ele não coloca barreiras. Entende que sua principal função é exatamente o oposto disso: eliminar barreiras. Ele trabalha com o time e para o time. Ou seja, é muito distante daquela figura clássica de "gerente". A hierarquia é mero detalhe. Sua liderança brota da experiência e do relacionamento que mantém com todos os envolvidos. Um otimista costuma se relacionar melhor. E suas "brigas" são sempre mais sutis, elegantes. Afinal, todos entendem e compartilham os mesmos objetivos. O engenheiro nunca esquece seus objetivos.


Como nos ensina Domenico de Masi [4], "criatividade é a síntese de fantasia e concretude". Ou seja, não basta gerar brilhantes idéias. É preciso ter a capacidade de realizá-las. Um grande mito [5] que assombra inovação e criatividade é aquele do gênio, do inventor solitário. Brasília não existiria se não fossem os esforçados engenheiros que conseguiram transformar as fantasias de Niemeyer em concretude - em realidade.

Equipes de projetos são obrigatoriamente equipes criativas. Por definição elas estão criando. Quando compostas por pensadores e executores que se complementam, suas chances de sucesso aumentam bastante.


Notas:

1. Já reparam que todo conteúdo de melhor qualidade a Globo esconde nas madrugadas? Pq cargas d'água a série não entrou no Jornal Nacional? Seria demais para os Hommers, Mr Bonner? Santa Infelicidade.
2. "The Mythical Man-Month". Outro conteúdo dos bons que fica "escondido" da gente. Clássico com quase 33 anos de idade, nunca mereceu uma edição em PT-BR. Pode?
3. Nelson Ponce e Luis Felipe Braga foram as cobaias mais frequentes dessa experiência. Trocando chapéus, conhecimentos e algumas palavras de baixo calão - entre eles ou comigo no meio. Não importa. Como eu disse, foi uma combinação fantástica.
4. "Criatividade e Grupos Criativos". Publicado originalmente pela Sextante com quase 800 páginas. Depois, tentando popularizar o título, a editora dividiu-o em duas partes. Para Hommers, Beócios ou preguiçosos?
5. "Os Mitos da Inovação", de Scott Berkun, está saindo em PT-BR?!? Por isso não pára de chover. Mas seu primeiro título (que está mudando de título?!?), ainda é inédito por aqui. Chamava-se "The Art of Project Management". Não importa. Leia o novo e pegue um tira-gosto do antigo aqui.
   

Há muito tempo prometi aqui no Graffiti comentar sobre produtividade em Sampa. Falava então (sorry, não vou vasculhar o arquivo para achar a postagem original - Tô com preguiça) que a hora (60 minutos) aqui no Sul das Geraes vale muito mais que a hora de Sampa. Claro, em Sampa perde-se muito tempo (trânsito e afins). Mas não é só isso.

Ontem eu fiz uma maratona entre a Rua dos Pinheiros, Ana Rosa, Paulista e Vila Olímpia. Um total de 4 reuniões e 1 palestra. Trampo que rolou direto, das 9 até 21 horas. Em todos os compromissos cheguei com, no mínimo, uns 10 minutos de antecedência. Tive reunião de 20 minutos. Outra de hora e meia. Mas nada fugiu do planejado. Não tô (ou até estou) fazendo propaganda do meu planejamento. Mas eu queria era reclamar d'um terrível e nocivo hábito paulistano: a falta de respeito pelo tempo alheio.

Trânsito e afins viraram desculpas e agora viraram hábito: há pouco respeito pelo tempo dos outros. Caramba, TEMPO é a moeda mais cara dos dias de hoje. Não se recupera um minuto perdido. Grana você até recupera. TEMPO, nunca!

Na cola do hábito, marcam eventos às 9hs, por exemplo, com a expectativa de que ele comece "pontualmente" às 9h30. 30 minutos jogados no lixo! Dependendo do profissional, estamos falando de quase uma centena de reais. Dependendo da platéia da reunião, estamos falando de milhares de reais. E daí? A impressão é que muita gente não liga para isso.

Sem medo de errar: Sampa joga fora uma fortuna todo dia.

Mas o problema piora quando o hábito escorre para outras coisas. Projetos, por exemplo. É engraçado aquele cliente que exige o cumprimento do cronograma mas nunca chega na hora da reunião. É ridículo aquele coordenador que cobra entregas mas nunca consegue realizar uma reunião com horário e duração programados.

Só reclamo porque me preocupo: a coisa virou hábito. E hábitos não são eliminados com muita facilidade...

Na última sexta, em um grupo de discussão, encerrei um comentário falando que [uma coisa*] fazia parte da "fina arte do gerenciamento de projetos". Não sei porque, naquele momento, decorei a frase com a "fina arte". Nunca tinha usado o termo. Para falar a verdade, ficaria com os 2 pés atrás quando a visse. Desconfio muito quando um programador, por exemplo, fala que programação é uma arte. É que em 90% das vezes não é. É só trabalho técnico (e repetitivo, quando ferramentas e processos são arcaicos). Mas sobram 10%...

E [*aquela coisa] era sobre arte ou, para ser mais preciso, sobre a "administração da tensão criativa": Dois ou mais integrantes da equipe entram em um tipo de duelo, competindo mesmo, para criar a "melhor solução possível". Eles estão criando. É um tipo de arte. Então, administrar esse processo criativo também deve ser. Afinal o coordenador cria junto, sabendo perguntar e intermediar. Mais: sabendo extrair o melhor da equipe. Aquele papo de que o conjunto deve ter um valor maior que a soma dos indivíduos. É algo dificílimo. Uma "fina arte"?

Acho que seguirei desconfiando. Quando conheci o livro do Scott Berkun, "The Art of Project Management", quase passei direto. Só por causa do título. Só não o ignorei por causa das indicações. Sorte minha. Mas agora, sabe-se lá a razão, uma nova edição do livro sairá com outro título. Será por causa da "arte" no título? Pode ser...



Seguindo com mashups de áreas, gosto de aprender sobre gerenciamento em outras áreas, particularmente no cinema. Na primeira versão do Graffiti, por exemplo, cheguei a falar que Alfred Hitchcock foi o melhor coordenador de projetos de todos os tempos. Qualquer dia explico minha conclusão. Agora só queria passar uma dica: o Fernando Meirelles, um dos diretores de "Cidade de Deus", está filmando "Ensaio sobre a Cegueira", de José Saramago. Sorte nossa: Fernando criou um blog para documentar todo o projeto. Bela e agradável fonte de conhecimentos. Mais: fonte de inspiração! Vale a pena, mesmo que você considere esse papo sobre "arte" uma bullshitagenzinha.

Sim. Mas, segundo Seth Godin, não da forma "pragmática-mediana" que a gente costuma ver por aí. Saca só:

In response to projects, many organizations figure out the resources they've got and then work hard to do something good enough. On time, within budget. Meeting spec, after all, is your job.

You end up, if you're talented, with something good enough.

Is that enough? Is good enough enough to win? To change the game? To reinvent your organization and your career? In a crowded market, when all the competition is good enough, not much happens.

Good enough is beyond reproach. It's safe at the same time it represents quality. Good enough demonstrates effort and insight and ability. People rarely get fired for good enough, which is a shame.

If you redefined the objective to be, "makes some people uncomfortable, changes the entire competitive landscape and is truly remarkable in that many of the key people we reach feel compelled to talk about it," what would happen?

Leia o artigo completo. Ou você achou o trecho good enough?

A tirinha do Garfield de hoje me fez lembrar de um antigo projeto. Lá se vão 7 anos. Éramos uma dúzia, largados (alocados) num freguês. Não largados como "recursos cocoon*", como dizia um colega. Pelo menos este projeto tinha um prazo. E esse foi, por um bom tempo, um de seus grandes problemas: o projeto tinha um prazo! hehe.. (Traduzindo: multa em caso de atraso). Pouca coragem é bobagem.

Participei da fase inicial do projeto. Depois me afastei. O cordão umbilical mal cortado obrigou um retorno. Na primeira crise. Ou, melhor dizendo, na primeira vez que percebemos que havia uma crise. Crise interna e crise no relacionamento com o freguês. Eu, até então um tipo de "garoto enxaqueca", fui obrigado a me converter num "garoto lexotan". Faz parte. E até que deu certo.

Deu certo porque o time era muito bom. Processo e tecnologia eram... hmm... sofríveis (para não usar um termo de baixo calão). Configuração ruim (1 x 2). As chances de sucesso são pequenas. Mas, como eu disse, o time era muito bom. E criou uma prática que, de certa forma, compensou a falta de um processo. A prática "heavyload".

De quatro a seis vezes por dia, o time ou parte dele se reunia na "área do café". Era distante apenas uns 20 metros da "área de trabalho". Mas, psicologicamente, criava uma distância saudável. O time estava trabalhando sob uma pressão incrível. Que vinha de todos os lados. Então 80% do papo que rolava era bullshitagem genérica. Kool-aid-bullshitagem. Acompanhada de grandes doses de "heavyload". Explicando: tinha lá no freguês uma jurássica máquina de café. Umas quatro alavancas, cada uma com um ingrediente diferente (café, chocolate, leite em pó e sei lá mais o q). O "heavyload" consistia em doses (de médias a colossais) de cada um dos ingredientes. Receitinha pra fazer sucesso em qq franstarbuck da Paulista. Ainda mais nesses dias gelados. Os olhos de alguns ficavam como aqueles do Jon e do Garfield, hehe..

Descompressão vitaminada com energético? Equilíbrio. Duas ou três seqüências de gargalhadas. Três ou quatro dicas culturais. Se a porção feminina (2 dos 12) do time estivesse ausente, pintavam comentários sobre a playboy do mês, por exemplo. Durava de 10 a 30 minutos, dependendo do dia. E pronto: o time voltava com outro espírito para a "área de trabalho".

E os 20% do papo? Bom, eram utilizados (espontaneamente) para resolver problemas com o projeto. Até táticas e estratégias pintavam, sem problemas. O papo só não fluía quando o freguês ou algum alienígena circulava por ali. Hoje tem muita teoria (acompanhada de muita prosa-ruim) sobre times auto-gerenciáveis. A gente aprendeu na prática. Sem querer.

Mas o "heavyload" não nos isentava das reuniões formais. Tinha pelo menos uma por semana (só do time). E outras duas ou mais com o freguês, também semanais.

Conclusões, Divagações e Créditos Finais

A prática "heavyload" existe em todo lugar. Já a repliquei com 'n' variações. Do "café carioquinha" (invenção quase tão sem noção quanto o café descafeinado) até o "heavyload" versão offner (mais gostoso e num local bem mais aconchegante). Tom Stewart, autor do livro "Capital Intelectual", já disse que os melhores equipamentos já criados para a gestão de conhecimentos são as máquinas de café e de refrigerantes. É verdade. E não tem sharepoint que dê jeito nisso. Ainda bem.

Um time bão compensa processos e tecnologias ruins. Não discuto. Mas tem gente usando isso de forma errada.

"Time auto-gerenciável" é uma forma de dizer que cada membro da equipe sabe o que fazer e ajuda (espontaneamente) aqueles que não sabem direito o que deve ser feito. Tem muita gente interpretando isso de forma errada.

Em momentos de crise, ainda não inventaram melhor remédio do que a franqueza. Quem "enche linguiça" no meio de uma crise só tá adiando o desastre.

Em tempos de crise, a única informação útil vem de quem está no centro da crise. Mas um retrato fiel só é possível se todos os envolvidos apresentam suas versões. Para quem? Oras, para todos os outros.

Fred Brooks** disse há mais de 30 anos que "jogar mais gente num projeto atrasado é a mesma coisa que tentar apagar incêndio com gasolina". No caso acima, em determinado momento, o time teve 14 integrantes. Aconteceu na mesma época em que eles estavam trabalhando 2 horas a mais por dia. A única coisa que conseguiram: aumentar a insatisfação e reduzir a produtividade e o nível de qualidade. No ápice da crise o time foi reduzido e as horas extras foram abolidas. Sem demagogia. Produtividade na nossa área, particularmente em desenvolvimento de sistemas, é bem diferente daquela estudada por Taylor e Ford.

Posso estar cometendo uma grave injustiça. Mas tenho quase certeza de que quem criou o termo "heavyload" foi o grande e sumido Carlos Caseli.

* "Recurso cocoon", tenho certeza, ouvi do grande e desaparecido Zé Antônio. Quem assistiu ao filme dos anos 80 vai entender a piadinha.

** A lei de Brooks apareceu pela primeira vez em "The Mythical Man-Month", de 1975.

Moto contínuo. Sampa não pára. Quando se vive aqui, incorpora-se a dinâmica. Quem tá dentro não se percebe louco. O olhar externo, por habituado que seja, sempre estranha. blablablá... todo mundo já falou sobre isso.

Pois bem, minha agenda da semana estava "agressiva". Separei a noite de quinta para rever amigos, tomar um choppinhos, tirar o pé do acelerador... Optamos pela velha e boa Prainha, renovada, mais bonita e ligeiramente cara. Lógico que falaríamos de serviço, mas de boa. Projetos, novidades, fusões & aquisições. É bom saber que tá todo mundo bem. Aí pintou uma turma parecida em outra mesa - quase um espelho (lá no fundo):



Caramba! Escancararam o laptop e começaram a debater um projeto. No único slide que vi lia-se: "Gerenciando os Riscos do Projeto"!!! Será que debater um projeto em espaço público, consumindo álcool, é um risco? hehe..

Projetos pedem um pouco mais de calma. Mas Sampa não pára...

ps: Última chamada.

Acontecerá na Universidade São Marcos, em Sampa, no próximo dia 14 de abril (yes! um sabadão). Farei a palestra da abertura do Seminário, que ainda conta com 3 caras muito legais: Juan Bernabó, Adail Retamal e José Paulo Papo.

Vale a pena, até porque é uma pechincha subsidiada. E as inscrições feitas até o dia 30/mar ainda levam um descontão. Mais informações na página da Tempo Real Eventos.