A história começa sempre do mesmo jeito: a agência briga por mais prazo, o cliente acha um absurdo e quer o projeto entregue no menor tempo possível.

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:

Planejamento: fase onde os neurônios devem ser gastos para levantar todas as possibilidades, cenários, regras de negócio, fluxos, esquemas, perfis, permissões; enfim, ter claramente documentado como o projeto irá funcionar antes que algum diretor de arte pense (ouse) em abrir o Photoshop.

Gasta-se tempo nesta fase para não perder tempo depois. E neste momento temos, além da aprovação do briefing em si (de-briefing), o fechamento de toda arquitetura de informação, deixando claro para o cliente que, embora o que ele veja sejam caixinhas cinzas dizendo “aqui vai x”, aquilo ali indica como funcionará o website dele depois de pronto.

Desenvolvimento: efetivamente a criação e produção do que foi conceituado anteriormente; se todo planejamento foi executado corretamente, esta fase fluirá com naturalidade. Eventualmente surgem detalhes em tempo de projeto, mas a única pergunta que não deveria ser feita é “como funciona essa área?”

Implementação: uma vez finalizado o projeto e exaustivamente testado internamente (dá-lhe estagiário!), passa-se o resultado final para avaliação do cliente, o famoso QA (Quality Assurance).

O atendimento tem que estar mais do que presente nesta fase para garantir que ajustes solicitados pelo cliente sejam efetivamente ‘ajustes’ e não alterações no escopo do projeto ou alterações de layout depois de aprovado na fase de desenvolvimento. Vamos acabar fazendo do mesmo jeito, mas quanto mais puder ser validado, menos menções à supra-citada progenitora terão que ser feitas.

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 tasks? 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? [Webinsider]

.
 

JC Rodrigues

JC Rodrigues (@jcrodrigues) é publicitário pela ESPM, pós-graduado pela UFRJ, MBA pela ESPM. Foi professor da ESPM, da Miami Ad School e diretor da Disney Interactive, na The Walt Disney Company.