Por que é difícil mensurar prazos exatos para um projeto web
Publicado em 29.08.2007 na categoria Gerenciamento
Uma das tarefas difíceis na área de gerenciamento de projetos para a web é a mensuração de prazos. Embora todos - clientes, produtoras e funcionários - gostem de trabalhar com datas exatas, é complicado elaborar um cronograma desse tipo por conta de uma simples palavra: aprovação.
Quando um desenvolvedor recebe o escopo de um projeto ele pode, baseado em suas experiências passadas e em seu conhecimento do nível de complexidade das tarefas, fazer uma esimativa de quanto tempo será preciso para concluir a demanda.
Até aí tudo bem. O problema é que, dentro de um projeto web, várias etapas precisam passar pela aprovação do cliente. Digamos que em dois projetos semelhantes, um teve o layout aprovado de primeira pelo cliente sem nenhuma modificação, enquanto outro sofreu ajustes e mais ajustes, num vai-e-vem infindável entre desenvolvedor e cliente.
O primeiro caso vai conseguir cumprir facilmente o prazo acordado, a não ser que o desenvolvedor tenha estimado mal o tempo ou não consiga cumprir as tarefas restantes por algum motivo. Já no segundo caso, o desenvolvedor fica absolutamente impossibilitado de cumprir as datas, já que o cliente pede sempre mais mudanças.
O que fazer nesses casos? O ideal é deixar claro na proposta que o prazo fornecido é uma estimativa média baseada em projetos anteriores de escopo semelhante. Explique também que a entrega poderá ser feita antes, caso tudo ocorra bem nas intervenções dos clientes, ou depois, caso sejam necessários muitos ajustes.
Isso não quer dizer que os clientes têm sempre que gostar das nossas interfaces ou layouts, porém é preciso perceber quando o excesso de mudanças atrapalha o andamento do projeto. Dependendo do caso, isso pode afetar até mesmo outros projetos que a produtora esteja desenvolvendo e o projeto tornar-se deficitário, financeiramente falando. Como disse no começo, não é tarefa fácil.
É verdade, o fator “aprovação” é o que mais contribui para os problemas de prazos num projeto. Quando você já conhece um cliente, ao fazer a estimativa pode já levar isso em conta. Eu tinha alguns clientes assim, eu sabia que as etapas de aprovação seriam cheias de vai-e-vem, então jogava isso na estimativa dos prazos. Com clientes que você já conhece, dá para embasar o prazo sugerido com base nas experiências passadas e dizer que se as aprovações forem mais eficientes e mais rápidas o projeto será concluído antes. Mas com clientes novos é mais complicado, porque você não conhece ainda o comportamento deles. Nestes casos o jeito é estimar mesmo o tempo que você acha que será consumido por aprovações, deixando claro não somente em contrato, mas também verbalmente, o que este prazo significa e qual a participação e a responsabilidade do cliente no processo. Isso tem que ficar muito claro. Nos meus muitos anos gerenciando projetos vi que embora isso não elimine completamente o problema, certamente o ameniza e nos deixa imbuídos de embasamento na hora de renegociar prazos que não puderam ser cumpridos por atraso nas etapas de aprovação. Perguntar ao cliente quanto tempo ele acha que levará nas etapas de aprovação também ajuda. E é importante também entregar um cronograma detalhado, incluindo as etapas de aprovação. Eu sempre fiz assim e ao lado de cada etapa coloco o prazo e o responsável respectivo (agência ou cliente). Desta forma, já no primeiro atraso do cliente você revê o cronograma se necessário e mantém a comunicação aberta com o ele, enviando o cronograma novo, mostrando que o atraso na aprovação dele terá impacto nas próximas etapas. Boa comunicação é a alma do negócio.
Mesmo assim tem cliente que não tem bom-senso. Eu peguei um projeto uma vez quando trabalhava numa agência grande de um cliente corporativo que vou deixar anônimo por questões éticas. Numa sexta-feira eles pediram um hotsite complexo para a segunda-feira. Era viável, mas precisava ter MUITA agilidade das duas partes. Isso foi deixado claro. Juntou-se uma equipe grande para trabalhar o fim-de-semana todo, varando noite e tudo mais. O cliente simplesmente não tinha bom-senso e pediu uma quantidade absurda de alterações (não passadas de uma única vez, mas a cada meia hora), todos detalhes que não tinham relevância nenhuma no contexto maior, ou seja, não eram problemas funcionais, nem de identidade visual, etc e poderiam impactar o cumprimento do prazo, podendo até inviabilizar a realização do projeto como um todo no prazo combinado. E no fundo, eles não sabiam muito bem o que queriam e passaram boa parte do tempo pedindo para “testar” alternativas, na maioria das vezes escolhendo a opção originalmente sugerida pela agência. Aí fica complicado, se você quer um projeto pronto em 2 dias, tem que no mínimo já ter bem claro o que quer, não há tempo para testar alternativas. Claro, se houvesse um prazo mais flexível o ideal seria ter tudo 100%, mas quando um cliente pede um projeto deste porte para ser executado em dois dias tem que ter o bom-senso de saber que é possível que existam algumas limitações. Num projeto como este, alguma coisa tem que ceder. O que é mais importante: o prazo ou a perfeição absoluta? Não dá pra ter os dois numa situação como esta e o cliente que não enxerga isso não tem bom-senso. (tem um artigo ótimo sobre isso aqui, em inglês: http://37signals.com/svn/archives2/2005/04/getting_real_pi.php) E, lógico, no domingo à noite, o cliente estava stressadíssimo, soltando fogo pelas ventas, com medo de o hotsite não ficar pronto alegando que “a agência deu sua palavra que estaria no ar na segunda-feira de manhã”. Este tipo de cliente é problemático.
Mas, no restante dos casos, boa comunicação, boa documentação e um contrato bem embasado são suficientes.
Primeiro comentário para o post do Walmar: sinto que os problemas de prazo com o cliente, em questão de vai e vem de aprovações de layouts, não ficam junto ao escopo do projeto.
Onde trabalho, tudo é baseado em estimativa, mas tudo mesmo. Se a criação de um layout leva uma semana, a aprovação e mudanças não estão nesse prazo. Como você disse, precisa acordar muito bem com o cliente isso, aprovação está fora do escopo e tempo.
Seguido da produção, HTML e CSS, outro prazo, que não entra em conflito com essa aprovação. Se o cliente precisa do projeto entregue em 3 semanas, e você estimou 1 semana para cada parte, criação, produção e desenvolvimento, fica a responsabilidade dele aprovar tudo dentro do tempo, e não julgar a culpa do atraso ao fornecedor.
O que acontece muito por aqui, é a criação de uma nova estimativa para requisições de mudança.
Para o comentário da Patricia: acho que você está 100% correta. Mas só não concordo em aceitar um projeto em que o tempo é curtíssimo, 2 dias, e sobrecarregar sua equipe apenas para entregar o projeto.
Nesse caso, acho que seria interessante uma reunião com o cliente a fim de decidir uma nova data de entrega. Se é um produto novo, e o hotsite precisa ir ao ar sem nenhum atraso, simplesmente não pegaria o projeto. Custo e riscos muito grande onde a qualidade do projeto iria ficar comprometida.
Nossa, eu “sofro” com isso constantemente, principalmente na questão do prazo quando esqueço de avisar o cliente que é estabelecido com o sistema em funcionamento e não tem mudanças de acordo com o combinado. Essa área é muito dolorosa.
Super relevante o artigo, todo profissional ate mesmo em outras áreas que TI sofre com esse tipo de situação. Gerenciar projetos de qualidade demanda tempo de experiência e maldade em algumas decisões (foco relevante). Acho que o ideal é sempre contar com inesperado e dar um prazo um pouquinho maior, assim o cliente fica satisfeito quando é entregue na hora ou ate mesmo antes. Avaliar o tipo de cliente também é uma ótima passo se ele for indeciso você deve cobrar mais dele ao ponto que feche o conteúdo antes do inicio do projeto.
Estou adotando a técnica de criar todas as telas e ele vai fechando cada uma, assim depois implemento o sistema ou versão 1.0 com toda analise daquilo quer mudar versão 2.0 outro serviço … e vamos aprendendo… t+ …
Isso mesmo. Antes de tudo é muito importante lembrar que o prazo passado é somente uma média, e não um tempo exato.
O engraçado é que quando o cliente “descobre” que precisa de um site e contrata um desenvolvedor web, tudo é “pra ontem”: ele quer o layout em 1 dia, o protótipo em mais 1 dia, etc. No entanto, quando a parte de criação/desenvolvimento termina, e a bola passa novamente para o cliente ( para criação do conteúdo), normalmente o projeto fica parado por várias semanas… ou seja, não era tão urgente assim né?
Por isso, acredito que é sempre importante estimar prazos jogando a bomba para o cliente: DEPOIS que você aprovar o layout eu poderei fazer o protótipo… DEPOIS que você entregar o conteúdo poderei publicar o site… DEPOIS que você entregar as imagens, etc…
Eu acho que a aprovação do cliete depende da capacidade do desenvolvedor. É inteligência do desenvolvedor captar o que o cliente quer nas reuniões de briefing.
Minha opinião: Se você constantemete tem esse problea, reveja a SUA maneira de trabalhar.
Eu considero falha minha quado o cliente não aporva determinado trabalho. De fato é muito fácil colocar a culpa no cliente, mas no fundo o responsável pelo atrasado é o contratado.
Os casos que o cliente aprova de primeira não é sorte, na verdade foi um bom entendimento das necessidades do cliente, por parte do desenvolvedor, que possibilitou o desenvolvimento do que era esperado.
Abraços
Eu acho que a aprovação do cliente depende da capacidade do desenvolvedor. É inteligência do desenvolvedor captar o que o cliente quer nas reuniões de briefing.
Minha opinião: Se você constantemente tem esse problema, reveja a SUA maneira de trabalhar.
Eu considero falha minha quando o cliente não aprova determinado trabalho. De fato é muito fácil colocar a culpa no cliente, mas no fundo o responsável pelo atraso é o contratado.
Os casos que o cliente aprova de primeira não são sorte, na verdade são casos de um bom entendimento das necessidades do cliente, por parte do desenvolvedor, que possibilita o desenvolvimento do que era esperado.
Abraços
Walmar,
Eu acho que o problema não está só aprovação e sim antes, na fase de Pesquisa. Se for feita uma boa fase pesquisa, onde se conseguiu mapear bem o usuário e a empresa e as restrições do projeto e que teve uma forte participação do cliente as aprovações são bem mais fáceis.
Outras coisas que podem atrapalhar nas aprovações são:
- O cliente não entende os documentos de especificação, especialmente os de AI. Assim logo que começa o projeto explique cada uma das atividades e quais são os documentos para acertar as experctativas
- A empresa tem muitos aprovadores diferentes, de áreas e com graus hierárquicos diferentes. Precisa ser negociado com o cliente que se tenha um ponto focal, um responsável pelo projeto, especialmente para dar a palavra final no caso de impasse. Se você preve que a empresa será assim (pergunte no briefing quantas pessoas estão envolvidas na aprovação) aumente as horas estimadas para aprovação.
- Se quem fez o projeto (arquiteto de informação, designer gráfico, redator, etc) não tem bons argumentos. Se o projetista não tiver pensado em todos os detalhes ao fazer o projeto, se deixou de seguir recomendações de usabilidade, se não fez uma boa conceituação e se armou de argumentos para fazer uma boa defesa do seu projeto ele apanha e apanha feito na hora de aprovar =)
Nós temos esse tipo de problema também, mesmo colocando no contrato e na proposta do projeto o cliente ainda sim fica se apegando a modificações que muitas das vezes não fariam diferença nenhuma no projeto, alguns clientes mesmo vc mostrando à eles que fazendo determinadas mudanças compromete o layout e a usabilidade do site o cliente mesmo assim ignora isso e acaba deixando o site com a cara dele e não com uma cara que traria retorno a ele, isso é complicado fica dificil e como você mesmo disse a gente acaba ficando preso a esses projetos e compromete o prazo dos futuros projetos que a gente acaba pegando, varia muito de cliente também tem clientes que são mais “mente aberta” e outros são mais fechados e tudo tem que ser do jeito deles..
Acho dificil isso mudar mesmo colocando no papel as “regras” de desenvolvimento.
Abraços
Acredito que o problema não está na definição de uma data exata. Esta data pode e deve ser definida de acordo com a experiência de cada um. Caso a data tenha sido bem definida, e haja demora na aprovação, o escopo do projeto mudou, conseqüentemente a data de entrega.
Um grande problema dos profissionais de TI é não saberem informar ao cliente que esta ou aquela alteração está fora do escopo do projeto. Os profissionais de TI devem aprender a dizer não. A terminar o projeto e daí, numa segunda fase, realizar as alterações solicitadas.
Uma amiga consultora sempre fala que não somos pasteleiros. Por mais que sejam clientes, não podem chegar pra gente e pedir “um de carne, dois de queijo e uma alteração/upgrade/aplicação de patch”…
Cabe a nós mostrar nosso valor!