Em maio passado participei da PMExpo 2008 Virtual promovida pela GanttProject.
Fiz esse pps no mesmo dia da PMExpo (maio) para alguns colegas que não foram. Não reparem os erros. Não é uma apresentação-relatório, apenas é uma intenção de mostrar como é realizado um Congresso Virtual e os principais tópicos abordados.
Foi mttt interessante e estou esperando a próxima.
O nivelamento dos recursos pode alterar a folga total de uma atividade e, assim também, o Caminho Crítico. Atividades sem folgas de fato direcionam o prazo final do projeto. Como também as dependências que existem entre as atividades tal como "montar muro" e "pintar muro". Se a atividade “montar muro” sofrer um atraso, ela moverá a atividade “pintar muro” junto com ela, e isso atrasará o projeto como um todo.
Quando observamos além desses componentes (folgas e dependências), os recursos envolvidos, devemos fazer a mesma análise. Um mesmo recurso não pode realizar duas atividades ao mesmo tempo e, isso, frequentemente gera dependências entre atividades. Se João tem que realizar as atividades "Escrever" e "Ler" provavelmente será necessário que ele complete uma atividade primeiro e depois inicie a outra. No cronograma isso pode ser representado como uma dependência entre as duas atividades.
Há ainda a possbilidade de inserir mais um recurso e nivelar o esforço: cada recurso faz uma atividade. Isso gera mais velocidade ao projeto, mas mais custo.
Isso por si só mostra que os recursos envolvidos também influenciam (e muito!) o prazo final do projeto. No exemplo acima, após a constatação de que um mesmo recurso está em duas atividades concorrentes, se fez o nivelamento do projeto. Esse é o motivo de identificar um novo Caminho Crítico que leve em conta as dependências lógicas assim como também, as dependências de recursos. Tal caminho é chamado de Caminho Crítico de Recursos-CCR.
E por projeto considere o sentido mais amplo possível da palavra, que vai desde “um ajustezinho no texto”, a criação de “um banner simples, sem frescura” ou um site “que o rapaz aqui mesmo pode fazer” e pode desembocar na integração do front-end com 22 sistemas legados da companhia, desenvolvidos por áreas diferentes, em plataformas diferentes e certamente por pessoas que não estão mais na empresa para explicar o que aquela variável está fazendo ali…
Para tornar um pouco mais didática a descrição deste momento quase mágico vamos considerar a existência de três tipos de cronograma (a mágica, digamos assim, está no job description de quem é responsável por zelar pelos prazos).
O cronograma ideal
O cronograma ideal é aquele que não existe. É lindo, é completo… como o brinquedo caro que a criança deseja mas não pode levar para casa.
No cronograma ideal, os timings de análise, produção e implementação são sempre muito bem estimados e há previsão para duas ou três etapas de aprovação para cada fase. Geralmente é assim na primeira formulação, onde encontramos termos como “debriefing” e “3ª fase - Ajustes”. Uma vez feito, o próximo passo é salvar o baseline e esquecê-lo.
O principal problema para as agências e produtoras online é conseguir criar e produzir com um deadline já estipulado, usualmente atrelado à veiculação de uma campanha de mídia off. Mas não é assim com todo mundo? Bem, sim e não. Claro que todos no Brasil trabalham com prazos apertados; entretando, as diferenças entre a comunicação off e online comprometem geralmente o segundo.
Inicialmente, o processo criativo no ambiente online trabalha não somente sobre forma (como irá ficar, qual a “sacada criativa”), mas também sobre funcionalidade. Ou seja, o que afinal de contas o usuário vai “fazer” naquele resultado criativo.
Salvo exceções, filmes e anúncios impressos demandam um consumidor passivo, receptor da mensagem transmitida. No ambiente online, ninguém fica sentado “assistindo” ou “lendo” um site, pois há interatividade, sincronicidade, redes colaborativas e relacionamento; usuários deixam de ser espectadores e passam a agentes ativos, que realizam coisas.
Que me perdoem os mais tradicionais, mas é preciso mais tempo para conceber criativamente um ambiente assim e também produzí-lo. No ambiente off-line temos gráficas, produtoras de video e áudio, fotógrafos e uma rede de terceiros que dão corpo ao conceito criativo. A produção online na maioria dos casos é feita dentro da própria agência (se existirem terceiros serão para gerar elementos que deverão ser agrupados ainda dentro da agência).
Aliado a isto, da parte do cliente temos demoras em aprovações e a falta de compreensão sobre as diversas fases que compõem um projeto online. É importante sim gastar um tempo vendo arquitetura de informação e, depois de aprovado o layout, não, não e não dá pra alterar posicionamento dos elementos no website produzido (mas a gente acaba fazendo assim mesmo).
Em resumo, o cronograma ideal serve de referência desejável sobre como tudo funcionaria sem dores-de-cabeça.
Quando o despertador toca e voltamos à realidade, temos o que chamamos de:
O cronograma requerido
O mentor quase intelectual deste cronograma usualmente é o cliente. Nele estão refletidos variáveis incontroláveis como a convenção de companhia, uma reunião de staff ou apresentação de resultados.
O objetivo do cronograma requerido é o de, sobretudo, provocar úlceras nos gerentes de projeto e atendimentos em geral. Um pouco diferente do cronograma ideal, cuja existência resume-se a um plano superior, o cronograma requerido por vezes torna-se o cronograma real (dependerá da noção de realidade do cliente e da envergadura dos membros inferiores do atendimento).
Quando apresentado à equipe de produção interna, os comentários são os mais variados possíveis, sempre com um mesmo pano-de-fundo, geralmente envolvendo a progenitora do cliente (e do atendimento, claro).
Quando entretanto o “veja bem” funciona na contra-argumentação com o cliente, temos o:
O cronograma possível
Agora sim a sagrada escritura toma forma. O cronograma possível situa-se entre o cronograma ideal e o cronograma requerido (ok, convenhamos que puxando bem mais para o segundo do que para o primeiro).
Ao contrário de projetos de engenharia, por exemplo, cronogramas de projetos online são mutáveis, pois a natureza do trabalho envolve questões não previstas, como reduções repentinas de equipe, trabalhos simultâneos (pois ninguém é alocado pra somente UM projeto) e emergências em geral que acabam por comprometer os prazos inicialmente estipulados. Para quem mexe com isto, é como termos aproximadamente 15 baselines.
Mesmo no cronograma possível, as fases de execução do projeto não mudam (a não ser a redução do número de ajustes), onde pode-se citar:
Em toda esta dinâmica algumas verdades absolutas (praticamente dogmas) precisam ser colocadas:
Cronograma deve ser feito em MS Project ou software similar; cronograma em Excel é uma aberração da natureza, um desacato, praticamente um sacrilégio.
Como estabelecer relações?
Como determinar precedentes entre as diferentes tarefas?
Ao ver um “crono” em Excel, de duas as duas: a pessoa não sabe usar o Project E não sabe usar o Excel (que é uma planilha de cálculo, não um coloridor de célula, por mais que células arco-íris sejam visualmente mais bonitinhas do que um Gantt todo azul e preto)
Ao montar um cronograma, considera-se no mínimo 10% do tempo total de projeto para QA e outro mínimo de 10% do tempo total de gordura. Gordura é aquele respiro que você tem para acertar o cronograma e responder pra alguém que te perguntar “E se der problema, hein…?”.
Quando algo der errado no projeto (e sempre dá), este tempo de gordura nos ajuda a ter um pouco de respiro; quando algo der ainda mais errado no projeto (sempre e infelizmente), o tempo de QA é comprometido e a equipe interna que realizar esta fase (quando der para realizar) em 1/10 do tempo estipulado inicialmente.
Quando algo der ainda mais e mais (sim, dois “mais) errado no projeto, geralmente a área de tecnologia acaba sendo pressionada, pois é a última etapa da fase de desenvolvimento - neste momento já temos velas acessas, oferendas e promessas feitas a santos (uma amiga, atendimento, ficará um ano sem comer chocolate após a entrega do último job).
Mas se tudo é tão corrido, quando sobra tempo para escrever estes artigos?
- Ah, você almoça?
JC Rodrigues - contato@jcrodrigues.com.br é publicitário, pós-graduado em Tecnologia Internet, professor na ESPM e gerente de projetos online da JWT. http://www.jcrodrigues.com.br/.
Os gregos foram verdadeiros amantes do discurso e aprecivam a eloquência da fala mais do que qualquer outro povo antigo. Na Grécia, com a democracia, o povo passou a ter a cultura de reunir-se em assembleia geral para tratar e decidir todos os tipos de questões. Logicamente, os que melhor falavam eram também os mais influentes. Não é preciso dizer muito que rapidamente os dotes oratórios se tornaram objetos de estudo e de grande valor.
Porém, ao se encontrar com profissionais de gerenciamento, esses profissionais "scramble eggs" são geralmente desmascarados. Por isso, não gostam de compartilhar seu "conhecimento" e evitam falar com outras pessoas senão aquelas que já conhecem e podem aplicar o "scramble eggs". Projetos com pessoas scramble eggs, geralmente são gerenciados em 2 níveis: um de gerenciamento e outro técnico. Não se misturam e não há colaboração. Apenas, conflitos de interesses e acordos sucessivos. Não há como dominar um profissional scramble eggs, é um tormento para um projeto. O Gerente de Projetos deve-se basear nas técnicas de gestão de pessoas de tecnologia e contar com patrocínio forte para poder dar ritmo à execução e contar com um planejamento técnico sob seu controle. 
Um dos grandes segredos do gerenciamento de projetos é proteger o seu escopo. Projetos que alteram o escopo durante sua execução têm sérias dificuldades em cumprir o cronograma e estouram o orçamento. O risco mais comum que envolve o escopo do projeto é o que o PMI chama de “scope creep”, quando o escopo vai crescendo à medida que o cliente vai entendendo suas necessidades e reformulando seus objetivos e essas entregas fogem co controle do gerenciamento do projeto. 
Bom final de semana a todos!Uma vez quando cheguei para dar uma palestra numa fábrica e havia um palco fixo, um pouco distante, vinte fileiras de vinte cadeiras. Não gostei da organização e para aproximar as cadeiras do palco, desci e comecei a puxar as cadeiras, uma por uma. Quando estava na quinta cadeira da primeira fila, alguns operários lá no fundo ofereceram ajuda. Eles perguntaram se podiam fazer de outra maneira. Como estava apressado, respondi que não e que se queriam ajudar, bastava dar continuidade ao que eu já havia começado. Ao fim, o chefe dos operários fez questão de me dizer seria mais fácil pegar apenas a última fileira e colocar na frente de todas as demais que daria o mesmo efeito. "Fui arrogante em não dividir o problema, pois achei que eu já sabia, que eu me bastava". Realmente o que comecei a fazer era uma solução, mas não a melhor.
**********************************************************************************
Outra vez, em uma fábrica paulista de uma das maiores multinacionais do planeta, havia um problema sério: na esteira de aço, no final do processo, vez ou outra, embalava-se uma caixa vazia. Para resolver o problema, dois engenheiros com pós-doutorado, durante três meses gastaram oito milhões de reais e chegaram a uma solução genial: um programa de computador acoplado a uma balança ultra-sensível, acusava diferença de peso toda vez que passava uma caixinha vazia; o sistema travava, e um braço hidráulico rejeitava a embalagem. Uma auditoria, cinco meses depois, apontou o funcionamento com sucesso, mas também que o sistema comprado pelos Engenheiros estava desligado há três meses. Ao serem perguntados o porquê disso, os operários contaram que tinham desligado o sistema porque aquele braço parava a esteira a todo momento e atrapalhava a produção deles e da fábrica. Ao pensar na solução do assunto, tiveram a idéia de fazer uma “vaquinha” e comprar um ventilador. Colocaram o ventilador ligado na frente da esteira e quando passava uma caixinha vazia, o vento a empurrava para fora da esteira a embalagem vazia sem ter que parar a produção. Uma solução de 30 reais mais eficaz e eficiente. Por que não foram envolvidos no problema antes?
Mario Cortella
