O incrível mundo dos cronogramas de projetos online

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

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 (@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.

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

Mais lidas

20 respostas

  1. Isso é a grande realidade de toda empresa que presta este tipo de serviço, não há cronograma perfeito que agrade ambos os lados, não há projeto que não mude, como dizia um amigo meu:

    – A única constante de um projeto é a mudança!

    Porém o poder da labia é algo essencial para quem for negociar com o cliente e mostrar para ele por A + B que o seu cronograma mais a necessidade dele precisa chegar a um denominador comum.

    Excelente artigo !

    Abraços,

  2. Pois é, eu só não concordo com este conformismo de que sempre acaba-se mudando o layout depois de aprovado e da fase de desenvolvimento já estar concluída. Acho que se mudar o cliente tem que entender que isto vai ter um custo e que vai ser cobrado. Venho da área de arquitetura e neste mundo físico e não virtual mudar o layout depois do desenvolvimento significa literalmente ter que quebrar parede. Eu nunca vi isto acontecer e os pedreiros, mestres-de-obra, arquitetos e engenheiros fazerem a alteração sem serem devidamente remunerados.

  3. E se é assim em todos os lugares, por que seguimos tentando encaixar a lógica da fábrica de parafusos no nosso negócio? 🙂

  4. Mas se tudo é tão corrido, quando sobra tempo para escrever estes artigos?

    – Ah, você almoça?

    hehehehe
    é bem assim mesmo…

  5. Cara…adorei esse artigo e o seu senso de humor também, pois é exatamente o que acontece nos ambientes de desenvolvimentos.
    Esse artigo é muito importa, e muitos desenvolvedores passam por cima de tudo isso, esquecem de fazer uma boa analise de seu projeto e no fim de tudo, acabam ganhando dores de cabeça.

    Bom…parabens…
    Vaelu..

  6. Hahahaha… parece que esse texto foi feito a mão para nós desenvolvedores. Pressionados por prazos curtíssimos temos que, realmente, desovar o mais rápido possível o projeto e isso me faz as vezes passar mal, pois quero sempre desenvolver usando padrões de desenvolvimentos, inovar e isso tudo as vezes fica pra trás.

    Trabalhar por conta própria e estipular prazos e cronogramas definidos por você mesmo é ótimo. Ser subordinado e entrar no cronograma do seu chefe é uma tarefa complicada, mas a gente se arruma.

    Ótimo artigo, todos da área deveriam ler!

    Abraço,
    Éder Prado
    ederprado.wordpress.com

  7. A pura e cruel realidade. Senti até uma calafrio na espinha quando você disse: …geralmente a área de tecnologia acaba sendo pressionada, pois é a última etapa da fase de desenvolvimento…. Vivo isso em todos os projetos!

  8. Apesar de todos problemas que sofremos com prazo, creio que o pior cenario eh quando temos que deixar nossa criatividade de lado e desovar o mais rapido possivel o projeto. Ou seja, esqueca W3C, Ajax e tableless; e vamos acabar logo este projeto. Horrivel!

    Pode parecer mal de minha parte falar isso, mas a Internet brasileira se tornara mais um setor buracratico, tipo trabalho administrativo. Enquanto isso youtubes, diggs e googles sao criados pelo mundo a fora.

    Desculpe a falta de acentos, meu note eh padrao USA

  9. A artigo está muito bom, parabéns. Eu só queria complementar dizendo que o Microsoft Project vai muito além de montar cronogramas, tomem cuidado para não comprarem uma ferramenta dessa, que não é barata e só utilizar para fazer cronogramas, ela vai muito além disso, faz o controle, gera relatórios e muito mais. Além disso existem técnicas de gerenciamento de projetos que proporcionam previsões de custo e tempo e outras que fazem com que o projeto não estoure o prazo dado para o cliente. Aconselho a trabalharem de maneira bem profissional nessa área, procuram informações em livros, revistas ou procurem um consultor. O gerenciamento de projetos é algo essencial que chega a determinar que fica e quem sai do mercado.

  10. Acredito que você ouça essa piadinha constantemente pelo seu nome, mas bicho, depois dessa tenho que dizer: JC vc é o cara!.

    Parabéns pelo texto, muito bom, ri sozinho enquanto lia e me colocava nas enrascadas. Já mandei o trackback da matéria e pode ter certeza que ela será divulgada aos clientes. Será que lendo o texto eles pouparão as devidas mães?

    Grande abraço e parabéns! 😉

  11. Não sei porque, mas é exatamente a descrição do projeto que estou participando. Se não fosse o MSProject, não sei o que seria deste projeto.

    Uma dúvida.

    Mal de brasileiro, querer tudo pra última hora?
    Ou mal da profissão, ter que apagar incêndio dos outros?

    Belo artigo.

    Um abraço!

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *