Como negociar prazos com seu gerente



O gerente de desenvolvimento da sua empresa o chama para uma reunião e o questiona sobre uma nova implantação que deve ser feita no sistema. Por cima, ele diz a você qual a necessidade do cliente e o questiona: “Em quanto tempo você coloca isso em produção?”

Reticente, pois o gerente não foi capaz de definir claramente o escopo do projeto, você hesita em dar uma estimativa de prazo, mas ao ser pressionado você acaba pedindo 30 horas baseado na sua experiência em projetos similares.

Como resposta o gerente diz que acredita muito no seu potencial e por isso estipula um prazo desafiador de 8 horas para a implantação. Como subordinado você aceita o prazo e para mostrar competência e corresponder às expectativas do seu gerente você pula o planejamento e a documentação indo direto para a alteração necessária nos códigos do sistema.

Você acaba entregando o projeto em 20 horas e o seu gerente ainda ironiza dizendo que você estava valorizando ao prever 30 horas para o projeto.

A situação acima, apesar de fictícia, lembra um pouco o dia-a-dia de trabalho de alguns departamentos de TI.

Em geral, quando um projeto desses consegue ser entregue dentro do prazo estipulado pelo gerente (nas condições acima), ou o escopo não foi claramente entendido pelo líder da equipe e portanto o resultado do trabalho não atenderá às necessidades do cliente ou então houve um assassinato da qualidade, o que implica em falta de documentação e excesso de códigos complexos para realizar tarefas simples, o que vai em curto prazo gerar um excessivo número de “bugs” e em longo prazo impactará em uma dificuldade em dar manutenção gerando maiores custos e degradando a performance da aplicação até que um dia a empresa percebe que está na hora de reescrever a aplicação a partir do zero (isso quando não resolvem instalar uma solução de terceiros e acabam com a área de desenvolvimento interna que passa a ser vista como um custo e não como um investimento).

Uma abordagem para o caso acima seria dizer a seu gerente que pela experiência que você possui a implantação levará de 22 a 52 horas, mas que para dar uma estimativa mais correta você precisa primeiro conhecer claramente o escopo das mudanças necessárias e verificar a disponibilidade de recursos para executá-las.

Durante o seu planejamento procure envolver a equipe de desenvolvimento. Sua equipe é quem fará de fato a implementação e portanto deve ser ouvida, até mesmo para levantar questões como a falta de conhecimento para utilizar determinada tecnologia, o que acarretará em um gasto maior de tempo para concluir uma tarefa aparentemente simples.

Não deixe de documentar todas as atividades que você achar necessário fazer para concluir o projeto, não esquecendo de planejar tempo para a elaboração de documentação funcional, técnica, desenvolvimento e testes.

Para este trabalho, não é necessário utilizar ferramentas sofisticadas de gestão de projetos como o MS Project. Esta tarefa pode ser facilmente realizada com uma planilha convencional e será até mesmo mais fácil para quem não está habituado com o MS Project.

Após detalhar as atividades, envolva os seus desenvolvedores e peça que eles respondam as seguintes questões para cada atividade que você escreveu em sua planilha:

  • a) Qual o prazo para concluir essa atividade?
  • b) Digamos que tudo ocorra bem, e nenhum contratempo aconteça. Neste cenário, qual o tempo mínimo para concluir a atividade?
  • c) E se tudo der errado? Qual será o tempo máximo para concluir a atividade?

Estudos comprovam que na maioria das vezes a estimativa da pergunta “a” será o tempo real, mas que desvios podem acontecer e para isso existe um cálculo matemático simples para prever com maior exatidão o prazo da atividade levando em consideração esta variação (das perguntas b e c).

Para isso, antes de colocar a estimativa de prazo na sua planilha, multiplique a resposta da pergunta “a” por 4, some com os tempos das perguntas “b” e “c” e então divida o resultado da soma por 6. É simples, veja o exemplo abaixo:

Estimativa: 10 horas

Se tudo der certo: 8 horas

Se tudo der errado: 15 horas

( 10 * 4 + 8 + 15 ) / 6 = ( 40 + 8 + 15 ) / 6 = ( 63 ) / 6 = 10,5 horas

Ainda que meia hora isolada não represente uma grande alteração, em um projeto de longa de duração, meia hora em cada atividade pode representar dias de trabalho.

Após estimar o prazo para todas as atividades, avalie os riscos envolvidos (como falta de conhecimento da equipe, possibilidade de perder funcionários chave, parada de servidor não programada, etc) e tente quantificar o quanto de tempo cada risco pode custar ao projeto.

Por exemplo, você sabe que o servidor de banco de dados de desenvolvimento costuma ficar parado pelo menos um dia por mês devido a falhas na restauração do backup de produção, então contabilize (para uma atividade estimada de 1 semana) 2 horas como tempo extra para este risco (como calcular? em um mês = 8 horas parado, então em 1 semana, 8h (parada mensal)/4(semanas) = 2 horas por semana).

Ao final, some as estimativas de tempo e adicione separadamente as estimativas de tempo para os riscos que você detectou.

Para apresentar a estimativa ao seu gerente, leve com você esta planilha que criou e entregue ao seu gerente uma cópia, incluindo a listagem das atividades, o tempo estimado para cada atividade (se possível, inclua também o nome do funcionário que deverá executar a atividade).

Ao final, após a soma total de tempo estimado, inclua a relação de riscos e o tempo extra correspondente, que poderá ser utilizado para compensar os riscos listados.

Veja aqui um modelo preenchido de planilha.

Com base em todo este material que você coletou e elaborou, você terá bastante argumento para convencer seu gerente a respeito da estimativa de prazo que você passou, evitando ter de sacrificar a documentação do sistema e o processo de planejamento, elementos essenciais quando se pensa em alta performance, reutilização de códigos, documentação de sistemas, etc.

Ah, e não ache que passar estimativas de prazo altas e entregar em tempo excessivamente melhor vai fazer com que seu gerente acredite que você seja um bom líder. Ao contrário, se isto ocorrer com freqüência vão pensar que você é um péssimo líder pois não sabe estimar com precisão o tempo necessário para concluir suas atividades e aí cada vez mais a história hipotética do começo desse artigo vai acontecer no seu dia-a-dia.


Autor: Renato Ucha


Artigos Relacionados


Inteligência De Mercado é Destaque Na Folha De S.paulo

É Pra Ontem

Se Agarrando Ao Tranco Da Esperança.

A Morte Anunciada De Um Lóbulo

A Perspectiva Construtivista De Ensino

Da Sensação Do Místico

O Que é Evm - Earned Value Management