Três dicas para gerenciar um projeto interativo

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

PMI, ITIL, CMM, Cobit, Use cases, Gantt – pode esquecer tudo isso!

Vou passar — de graça — as três dicas básicas para qualquer mortal (com idade acima de 20 anos) gerenciar um projeto interativo com sucesso e ficar bem na fita com o cliente e com a chefia.

(Este é um segredo profissional que resolvi tornar “open source”)

Primeira dica: ouça o cliente

Parece óbvio, mas nem sempre acontece. O cliente está sempre com pressa, quando não usa o tom ameaçador: “Tenho que desligar, entendeu? Me manda a proposta detalhada em 20 minutos senão já era…”.

Aí você manda aquela proposta genérica de uma página (pode ter um monte de outras páginas de blablablá explicando como você é bom, mas o que importa para o cliente é a descrição do serviço, o prazo e o custo). Errou.

A menos que você esteja desesperado para pegar o trabalho (e depois trabalhar muito mais do que imaginou), você deve entender do que o cliente precisa para poder enviar a proposta bem detalhada. Quando não puder detalhar, não pegue o trabalho!

Entender a necessidade do cliente é essencial para coordenar sua equipe. Se você não souber, como vai explicar a ela?

Outro erro clássico é o atendimento achar que sabe o que o cliente quer. Mas as vezes o atendimento é a estagiária loira (nada contra!) que acabou de ser promovida a assistente adjunta de atendimento e não sabe nem que dia da semana é hoje.

Para acertar, não tenha medo de conversar com o cliente e tirar o maior número possível de dúvidas, até conseguir propor soluções que irão atender ou superar suas necessidades.

Dica: tenha certeza de que seu contato no cliente está alinhado com a alta gestão. Com isso você evita um estresse enorme que sempre acontece quando o gerente de marketing vai mostrar o site para o presidente da empresa; que, por seu turno, está vendo tudo pela primeira vez. Basta ele falar: “Não gostei” para você ter de refazer todo o trabalho.

Depois que você entendeu o que o cliente precisa — quais são as metas com aquele trabalho — é sua obrigação ser criativo e propor estratégias e soluções incríveis que irão atingir os objetivos traçados (afinal de contas, você representa uma agência).

É evidente que tudo o que é proposto ao cliente deve ser passível de execução. Deve atender o prazo solicitado e o budget. Se for necessário, negocie com o cliente usando o famoso triângulo prazo – custo – qualidade (você só consegue fixar dois vértices, o outro irá variar inevitavelmente. Exemplo: o cliente quer o trabalho em um prazo impossível e barato; a qualidade será baixa. Ou quer o trabalho com excelente qualidade e rápido; o custo será alto. Para equilibrar os três vértices, negocie sempre um prazo razoável, com custo bom e garanta a qualidade dos serviços prestados).

Segunda dica: faça um protótipo

Esta é a mais importante das dicas. No mundo corporativo, os profissionais que hoje trabalham com internet vieram de áreas completamente diferentes. Alguns são mais ligados a tecnologia e novas mídias, outros menos.

Alguns até conseguem visualizar um produto que ainda não existe, mas a maioria só vai entender como o site funciona depois que ele já estiver pronto. Aí começam as mudanças (e o estresse, pois cada alteração irá gerar um custo adicional para o cliente e uma alteração no prazo, ou pior, você vai fazer sem alterar custo e prazo levando prejuízo e trabalhando até tarde).

No Brasil só há uma maneira de não ter retrabalho e garantir para o cliente que você entendeu o que ele precisa e que irá atender suas necessidades: fazendo um protótipo.

A prototipagem (ou construção de wireframes) é muito mais rápida de ser alterada (do que o produto final) e envolve somente o trabalho de um profissional, e não de toda a equipe de programadores e designers.

É como fazer uma maquete de um prédio para apresentar ao cliente ao invés de mostrar plantas e desenhos técnicos que ele não irá entender.

Terceira dica: minta

Se você fez uso da segunda dica e fez o protótipo, meus parabéns. Você tem uns 80% de chance de ser bem-sucedido.

Os outros 20% dependem somente de uma coisa: você deve mentir descaradamente. Você deve mentir para a sua equipe.

Passe para a equipe um prazo (bem) menor do que o prazo que você combinou com o cliente. E nunca, mas nunca, deixe que saibam. Se souberem que você faz isso com frequência, os programadores (que são inteligentes, mas às vezes usam essa habilidade para te enrolar) irão se acostumar e passar a contar com aquele prazo adicional. Você deve continuar mentindo.

Diga que a reunião de apresentação para o cliente é na terça às 11h, e somente às 10h45 avise a todos que o cliente sofreu uma congestão e resolveu remarcar a reunião para a quinta-feira às 17h — que já eram o dia e o horário combinados.

Essa é uma boa prática (que inclusive faz parte do PMBOK). Quando possível tenha dois cronogramas, um combinado com o cliente — com entregas parciais, e outro com a equipe — mais curto. Muitas vezes é necessário mentir para seu chefe também: ninguém pode saber seu segredo, senão “vaza” e você fica desmoralizado para sempre, não podendo mais usar essa técnica.

O atendimento (ou o gerente de projetos) é sempre aquele incompetente que não consegue entregar o trabalho no prazo (na visão do cliente), ou o chato que fica cobrando todo mundo (na visão dos funcionários). Usando esta técnica você fica bem com os dois lados: consegue mais tempo para que terminem o trabalho (na visão dos funcionários) e entrega o trabalho no prazo (na visão do cliente).

Se você tiver uma equipe madura talvez não seja necessário utilizar a terceira dica desta maneira (mentir sobre o prazo real). Poderá fazer um cronograma interno e outro para o cliente e sua equipe saberá a importância de atender os prazos internamente (mas isso funciona mais em software houses do que em agências interativas).

É claro que se você estudar, implementar novas técnicas de gestão de projetos, melhorar processos, motivar a equipe, etc. Tudo isso irá ajudá-lo. Em conjunto com as dicas acima, é sucesso garantido. [Webinsider]

.

<strong>Rodolpho Ramirez</strong> (rodolpho arroba pixel . com . br) é diretor da <strong><a href="http://www.pixel.com.br/" rel="externo">Pixel</a></strong> Comunicação Digital e mantém o blog <strong><a href="http://www.ramirez.com.br/" rel="externo">Techomunicabilidade</a></strong>.

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

Mais lidas

29 respostas

  1. Se você é obrigado a usar a teerceira dica, é porque vc não é respeitado por ninguém. Seus colaboradores são seus parceiros n~eo seus concorrentes … o cliente sim que deve se ter um controle maior … mas mentir é algo muito anti-ético e total falta de segurança no seu nível profissional e de sua equipe como um todo.

  2. Se para o projeto dá certo, for necessário mentir, esse projeto não vale a pena ser desenvolvido. Além disso, ele dará errado.

    É melhor ser transparente sempre, e ter a adesão do grupo não por pressão ou mentira.

    Essas dicas são sem fundamento. Ainda tem gente que tem coragem de parabenizar esse tipo de afirmação. Com certza sabem ler, mas não sabem interpretar.

  3. Todos nos sabemos que os prazos se encurtam a cada projeto, clientes querendo o produto pra ontem e etc, nesse sentido e na visão de um desenvolvedor penso que a terceira dica é um abuso contra a equipe, principalmente para os desenvolvedores(os braçais do projeto), pois é fato que na maioria das vezes o projeto ja chega com um prazo curto, e o gestor nos passa um prazo menor ainda, pense apenas no abalo psicológico que essa correria pode causar a sua equipe, resultando apenas numa equipe exausta e num produto meia boca, que no fim das contas ainda vai sobrar pro desenvolvedor quando o cliente for reclamar do resultado.

  4. Rafael e pessoal!

    A terceira dica simplesmente mostra o caráter e o vão objetivo de quem o escreveu.

    Além do caráter, destaco o vão objetivo, porque para o autor pouco ou nada importa a qualidade. Isto ficou bem claro, pois o mesmo passa por cima de especialistas da área assim como George W. Bush passou pelos relatórios climáticos.

    Objetivo evidente: Entregar ao cliente, cumprir o prazo e pegar a recompen$a!

    C: – Mas não está funcionando! Faltou tal coisa!
    A: – Tudo bem, mas foi entregue no prazo…

  5. Acredito que o Rodolpho foi muito infeliz quando disse duas coisas:
    – PMI, ITIL, CMM, Cobit, Use cases, Gantt – pode esquecer tudo isso!
    – Terceira dica: minta

    Como dizer que deve-se esquecer padrões e boas práticas mundiais? Claro que nem tudo é 100% aplicável e deve ser adaptado a cada caso, mas dizer que é pra esquecer essas boas práticas que pessoas das mais diversas áreas usam, usam, melhoram, usam, usam………..acredito que isso deve ser desconsiderado pelos leitores deste artigo.

    As duas primeiras dicas entendo que sejam uma visão prática do que acontece na vida real, que pode variar de caso a caso, mas são boas dicas.

    Sobre terceira dica, não devemos mentir…
    Sempre pode existir quantos cronogramas o GP quiser, pois cabe a ele administrar isso, mas ele deve ter o controle interno da equipe e dos seus projetos, para poder definir:

    Prazos com equipe: com uma bom relacionamento com a equipe, da pra fechar prazos aceitaveis, que tenha o tempo necessário para a equipe desenvolver o projeto, após esses prazos definidos, devemos analisar o projeto no geral e definir um cronograma final, que será passado ao cliente.

    Cronograma para o cliente: nesse cabe uma folga, que deve ser o mínimo possivel, pra não segurar um projeto na empresa, e o máximo possivel para qualquer imprevisto, diretamente influenciado pelo gerenciamento de riscos, portanto acredito que isso não seria o caso de mentir e sim de planejar e administrar toda fase de desenvolvimento.

    Como sempre temos projetos em paralelo e outros por vir, a equipe tem que estar sempre ciente dos trabalhos atuais e futuros. Como citado por Giovanni Giazzon, tem o prazo pessimista e otimista, cabe ao Gerente de Projetos administrar isso junto com sua equipe e cliente.

  6. Artigo muito fraco, pois dizer que as ferramentas existentes como itil e as outras citadas não servem para nada é uma mentira. Ah é, o autor tem o hábito de mentir para sua equipe, então tudo bem…
    E outra, nunca podemos dizer que apenas três itens serão os definitivos para o bom andamento de um projeto, isso não é gerérico, existem diversos tipos deles!

  7. E Brasil…

    Honestidade? O que é isto? Vagner e Rodolpho? Isto existe!

    Ainda tem grande parte de população brasileira que veste a camisa da desonestidade ou é simpatizante imerso na ganância e enraizando cada vez mais a tão falada lei de Gerson.

    Cegos pelo resultado imediato não vêem que o mesmo não consegue ser duradouro e ficam presos neste círculo vicioso e enganar e ganhar.

    Com desonestidade, vocês não são melhores que ninguém! Creio que entender esta frase deva ser algo impossível pra vocês, mas a gente tenta…

  8. A terceira dica é vergonhosa. Mostra um profissional sem ética e respeito pelo próximo. Nunca devemos seguir a terceira dica deste cara.

  9. Artigo muito útil e objetivo! Sabemos que tem inúmeras técnicas de Gerencia de Projeto, mas o artigo conseguiu pegar três de tal importância que seguindo-os levarão ao sucesso do projeto.
    Mas um anexo à terceira dica é:
    – Se a equipe conseguiu respeitar o prazo real, ou seja, terminou o projeto antes do prazo estipulado com o Cliente, jamais entregue o projeto antes. Pois se o Cliente souber que você consegue fazer em um prazo menor que você estipular, nas próximas contratações ele poderá usar isso como argumento para diminuir o prazo.

    Parece óbvia a dica, mas também é muito óbvio pensar em entregar logo e espera o elogia O projeto ficou muito bom e concluído bem antes que combinamos!. Única coisa que eu acho que o adiantamento é elogiado é o pagamento.

    Abraço!

  10. Eu concordo 100% com o autor do artigo, esse pessoal é cheio de frescura, quem tá no mercado dando a cara pra bater sabe a realidade ! Todo mundo dá uma modificada no prazo para equipe ou até mesmo para um fornecedor, a palavra mentira faz os puristas subirem pelas paredes. Eu concordo com o autor, pela minha experiência, e com certeza o autor também tem experiência de mercado para dizer isso. Aliás, Muita coragem de sua parte. Muitos que criticam, são os velhos babões de livros e artigos americanos, que nunca nos serviram para nada, pois nossa realidade é bem diferente deles, afinal, muitos empresários na qual lidamos, querem por exemplo um site na internet só porque o seu amigo ou concorrente também fez, sem sequer saber os reais benefícios e como funciona. É a vida! É assim que as coisas funcionam, parem de ler teorias americanas e criemos as nossas, bem mais criativas e funcionais! Parabéns Rodolpho Ramirez.

  11. Amigos, acredito que não devemos levar a terceira dica ao pé da letra (minha interpretação).

    Penso que mais do que valorizar uma sobrevida para ajustes finais, o autor quis chamar a atenção para a importância dos prazos através de um recurso dramático.

    De qualquer forma, temos aqui nos comentários a visão da equipe, que poderia trabalhar com um pouco mais de tranquilidade, confrontada com a visão de quem se compromete com as entregas da forma mais firme possível.

    Excelente discussão!

  12. Muito fraco este artigo.

    As duas primeiras dicas são fundamentais. Não considero uma dica. Isso é básico principalmente se tratando de desenvolvimento de sistemas ou portais.

    A terceira dica então…

    Como você pretende que sua equipe cumpra com as responsabilidades que são repassadas aos profissionais. Se por algum momento eles desconfiarem desse seu método, você perderá todo o controle dos projetos.

    Não esqueça que você depende deles. Então faça com que eles assumam as responsabilidades de cada projeto que estão executando.

    Ética deve ser utilizada. Os clientes e os colaboradores gostam.

  13. Rodolpho,

    Não concordo com a terceira dica. No mercado de trabalho atual, não há como não manter a transparência.

    Se ético é fundamental para ser um bom gestor. Em nenhum momento suas palavras podem gerar dúvidas ou rumores. Mentir não é melhor caminho para se conseguir o que se quer e ser o terrorista pode desgastar sua relação com os subordinados de tal forma que eles comecem a te boicotar ou literalmente peçam pra sair.

    Fazer com que os empregados sintam-se parte do projeto, da empresa, do todo e que possam dar suas opiniões e recebam suas críticas de forma amigável é o caminho para a boa gestão de projetos. PMBOK é bom, mas não é pra tudo e quando falamos em software podemos dizer que tem erros.

    Bem, fica aqui minha opinião. Alteraria sua dica para: explique claramente quais os prazos do projeto e seja realista quanto as entregas e prazos para que todos se sintam comprometidos com o projeto. Se isso não funcionar, você não tem uma boa equipe e não adianta terrorismo ou pressão para resolver seu problema.

    Abraços!

  14. Como que uma pessoa que valoriza mentira no processo se considera profissional?

    Atenção webinsider, vamos filtar o que é publicado.

    * Vergonha alheia.

  15. Cara, na boa… Não vejo que essas dicas sejam boas… Mentir para a equipe acho que é a pior prática possível…
    Bons hábitos e boa gestão, sim, dão bons resultados ao trabalho desenvolvido.
    Se quer uma dica, dá uma olhada em Métodos Ágeis. Esse sim pode resolver muitos problemas como aqueles que tu apresentas acima.

    []s

  16. Ramirez,

    Uma das técnicas/ferramentas para construção do cronograma de um projeto que o PMBOK faz referência é o PERT (http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique). O PERT lhe dará 3 visões: pessimista, otimista e mais provável. Cabe a você, como Gerente de Projeto, saber a melhor forma de trabalhar este ponto com o cliente e a equipe do projeto. Cada caso é um caso e não se trata de mentir. Não creio que seja uma conduta recomendável a tua terceira dica. É um risco à sua credibilidade e envolve a motivação da equipe. O PERT lhe permite trabalhar este ponto sem precisar colocar em jogo alguns aspectos fundamentais do gerenciamento de projetos.

    Boa sorte em se justificar com sua equipe atual.. 😉

    Abraço,
    Giovanni Giazzon.

  17. A 3ª dica é RIDÍCULA!

    Que isto já acontece em vários lugares, as equipes de TI sabem, mas que escreveriam uma artigo incluindo isto…

    O problema do pessoal de atendimento é que os mesmos não têm a mínima noção do que é a engenharia de sistemas.
    Não é como criar um banner.
    Existe um conjunto de funcionalidades que devem ser planejadas, criadas e testadas. Tudo deve ser feito sem atropelo para garantir um produto com 100% de qualidade. Isto é um assunto muito complexo, até porque, só quem tem curso superior em TI tem esta noção.

    Portanto, a equipe de atendimento, se quiser saber mais do que a equipe de TI quanto a prazos, que faça um curso superior em TI, aí sim, estará apta a estipular prazos.

  18. Oi Fábio. É realmente arriscado, mas na realidade depende muito do tipo de empresa em que você trabalha.

    Há casos de equipes que têm problemas crônicos de atrasos. Atrasaram os últimos 5 projetos por exemplo. E neste projeto em especial não pode haver atraso. O cliente já está bravo e você sabe que se houver atraso o bicho vai pegar.

    Você sabe que não vai adiantar conversar com a equipe numa boa, pois não estão nem aí. Ficar estressando com a equipe também não resolve. Nesse caso uma mentirinha — as vezes alinhada com o dono da empresa (no meu caso eu mesmo sou o dono) — pode sim resolver.

    Se você trabalha em uma agência de propaganda grande pode ser bastante arriscado para a sua carreira se não tiver alinhado isso com os principais envolvidos, mas uma boa maneira de aplicar esta técnica sem mentir é combinar com seu chefe que irá passar um prazo para a equipe, e por segurança um prazo maior para o cliente. Avise sua equipe o prazo que ela possui e pronto. Os funcionários não precisam ficar sabendo qual é o prazo que você passou para o cliente.

    Abraço,
    Rodolpho

  19. Realmente temos que trabalhar com 2 prazos, o estipulado e o final. mas sempre trabalhando de forma que o estipulado para equipe seja sempre o definitivo, é nessa hora que os programadores sentem a real necessidade de configurar direito aquelas classes e realmente testar tudo. e assim obedecendo as regras básicas do Pmbok , conseguimos um produto bom, e um cliente realmente feliz.

    Só acho a dica da mentirinha um pouco faca de dois gumes, de um lado você tem velocidade do outro você tem sua credibilidade em jogo, arriscado, não?

  20. Oi Braga. A atividade de gestão de projetos requer maturidade profissional (e pessoal) que dificilmente é atingida por pessoas muito novas ou em início de carreira.

    Mas é claro que há exceções!

    Abraço.

Deixe um comentário

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