O Rodolpho Ramirez publicou um artigo com três dicas para gerenciar um projeto interativo. As dicas 1 e 2 são ótimas, mas descordo totalmente em relação a terceira dica, por vários motivos.
Quanto mais informações temos disponíveis, melhores são nossas decisões. Uma dessas informações é o tempo disponível para executar o projeto. Com menos tempo disponível o time de desenvolvimento vai ter que fazer cortes na qualidade e/ou funcionalidade. A melhor forma de desestimular um desenvolver é tirar dele a chance de escrever código de qualidade e de usar sua criatividade.
A ideia de que há dois prazos – um real e um fictício – simplesmente significa que não há confiança entre a gerência do projeto e o time de desenvolvimento. Este tipo de comportamento mostra falta de maturidade em projetos web e de software.
Em qualquer relacionamento, confiança é um dos aspectos mais importantes para o sucesso. Desenvolvedores, como o Ramirez mesmo disse, são espertos e a grande maioria deles se esforça para fazer um ótimo trabalho. Mentindo para um time é uma péssima forma de incentivar e valorizar o trabalho de uma equipe. Confie em mim, já participei de vários projetos onde todos os desenvolvedores sabiam que a data alvo era fictícia.
Inclusive escrevi sobre esse cenário em outro artigo aqui no Webinsider.
Está provado que as estimativas são mais acuradas quando feitas pelos responsáveis pela execução das tarefas.
Estimativas de software devem ser feitas pelo time de desenvolvimento e se há datas fixas para release do produto, o que é comum, então funcionalidades e escopo precisam ser negociadas e acompanhadas ao longo do projeto. Devemos focar nossos esforços em colaboração e desenvolvimento mútuo entre todos as pessoas envolvidas no projeto.
Meu conselho é exatamente o contrário. O prazo de entrega do projeto deve ser claro e todos devem entender porque (o que deve ser óbvio) é importante entregar no prazo.
Envolva o time de desenvolvimento na estimativa das tarefas que ele é responsável. Envolva também o cliente, ele precisa entender que toda e qualquer funcionalidade tem um custo (tempo, qualidade, recursos) e infelizmente seria mais fácil prometer que “tudo é possível” mas a realidade é diferente e no final todos saem ganhando quando a conversa é sincera.
Construa um time onde há confiança mútua, onde todos trabalham para o sucesso do projeto e que todos são honestos com suas estimativas e horas alocadas no trabalho.
Existem técnicas e metodologias muito mais eficientes que a mentira para lidar com membros/equipes que não estão comprometidos com o sucesso do projeto. [Webinsider]
.
Handerson Ferreira Gomes
Handerson Ferreira Gomes (handerson.gomes@summa-tech.com) é consultor senior da Summa Technologies nos Estados Unidos.
12 respostas
Aqui onde eu trabalho, uma multinacional, os dois prazos são muito utilizados, mas essa questão de respeito não procede, pois o gerente de projetos nos informa essa técnica.
Nós informamos um prazo, por exemplo, 4 dias, e ele, por sua vez, informa 7 dias, como prazo.
Perfeito ! Se houver qualquer imprevisto, há tempo para trabalhar e corrigir, e aí sim, estaremos dentro do prazo de uma forma ou outra !
E cá pra nós, um gerente d eprojetos precisa se precaver e se antecipar ao erro, não importando a confiança que ele tem no time.
Hmmm… Willer, vc deve estar meio distraído, ou teria notado que o Handerson escreveu este artigo RESPONDENDO o que vc menciona, do Ramirez. Está no PRIMEIRO PARÁGRAFO, provavelmente vc leu muito rápido a matéria e não viu :-).
Caro Handerson,
Parabéns pela matéria. Sempre levei, em minha filosofia de trabalho, a idéia de que a mentira tem pernas curtas. Aliás, para todas as áreas da vida.
Mas, achei engraçado, e um tanto inusitado, quando, ao sair de sua matéria, entro na aba Desenvolvimento deste site e na matéria:
Três dicas para gerenciar um projeto interativo – Por Rodolpho Ramirez (colega de vocês)
Ele fala sobre as três dicas que nós, gerentes, deveríamos usar para com nossos projetos. E, a terceira dica dele é: MINTA!
Achei interessante compartilhar este fato e saber se vocês acompanham as matérias um do outro.
Abraços,
Willer.
Parabéns pela matéria, afinal como podemos confiar em um gerente que não é transparente e não confia em sua equipe!
Não lí o artigo inteiro ainda, somente o primeiro parágrafo.
Qualquer pessoa em sã consciência há de discordar do Sr. Rodolfo Ramires.
Vivemos a era da informática, isso não quer dizer que é a era dos computadores e sim a era da INFORMAÇÃO.
Mais informações para equipe de desenvolvimento e mais tempo, gera um trabalho com mais qualidade.
Nunca minta para sua equipe. Qualquer gestor ou líder sabe disso.
Parabéns pela resposta, Handerson Ferreira Gomes.
Por isso que a prática de metologias ágeis como SCRUM é importante, ajuda o gerente a estimular os desenvolvedores a fazer um trabalho crítico com um prazo curto. Evitando assim a pressão tradicional de faz isso aqui, faz isso alí, que acaba muitas vezes estressando o profissional mais do que o necessário.
Handerson,
Concordo plenamente com você. A verdade é que o Rodolpho vive a realidade de uma agência, onde o drive do projeto nem sempre é qualidade, mas sim prazo ou custo.
Abraços!
Boa Handerson! Ótima resposta!
É difícil de acreditar que existam pessoas como o Rodolpho que pregam a desonestidade!
Não há coisa que funcione melhor que o jogo limpo tanto na relação entre os colaboradores da empresa como também com o cliente.
Mentiras são irreais e uma hora ou outra uma das partes descobre. E a confiança não só morre como também o acontecido repercute como um vírus no meio comercial acabando com a imagem da empresa. Os publicitários sabem muito bem: propaganda negativa se espalha muito rápido e eficientemente.
Prazo é sempre um assunto delicado em se tratando de projetos na área de desenvolvimento web/software e mentir só acoberta o gerente imaturo e sem confiança na equipe, além de poder contibuir para uma desmotivação geral e consequentemente, projetos mal-sucedidos.
Muito bom o artigo. Parabéns!
Perfeito! Eu como desenvolvedor concordo plenamente, sempre tento desenvolver de modo que o código fique simples, otimizado e de fácil manutenção; com prazos muito curtos para projetos grandes isso se torna muito díficil uma vez que o programador irá logo começar a escrever o código e não analisar o projeto como um todo .
A consequência disto são possíveis problemas (bugs) após o lançamento do projeto que acarretaram mais horas de correção para o desenvolvedor ou para a equipe. Sem contar que bugs são muito piores do que um atraso uma vez que o cliente ficará insatisfeito e perderá a confiança na empresa.
A meu ver não há lucro mentindo e sim prejuízo financeiro e profissional.
[]s
Nunca minta e cumpra o prazo. Não entregue nem antes nem depois.
Ao inves de liberar antes, aproveite o prazo extra pra executar mais testes e até chamar o cliente, mas deixando claro que o sistema está passando testes ainda e será entregue no prazo.
Na minha opnião as dicas do Rodolpho são úteis, acho que podemos ter prazos duplos, mas também concordo com o Handerson, porém na dica do Rodolpho apenas inverteria a situação. Ao falar o prazo para sua equipe diga o prazo real e para o cliente o prazo + x dias, apenas como margen de segurança, caso não ocorra problema no andamento do projeto antecipe a reunião e seu cliente ficará super contente pois o projeto foi entregue antes do prazo.