Um cuidado que devemos ter e ao estimar prazos ou ao pedir que o facam e que temos que ter em mente que estimativas sao aproximacoes e nao uma medida precisa. Esta consciencia deve ser tanto da equipe de projeto quanto dos clientes.Mesmo sabendo que os prazos num projeto sao aproximados e natural que as pessoas ao serem indagadas para fornecer tempo para execucao de uma tarefa embutam neles uma margem de seguranca, uma vez que temos intrinsecamente a ideia de que isto gera um compromisso. Agora imagine que cada pessoa dentro da hierarquia de uma equipe de projeto coloque sua margem de seguranca. Tomemos como exemplo uma equipe apenas com dois niveis, desenvolvedores e gerente. O desenvolvedor acha que pode terminar a tarefa em 10h mas, por "seguranca" passa para o gerente que deve levar umas 13 h este por sua vez no momento de elaborar o cronograma coloca a tarefa com duracao de 15 h. So ai temos um acrescimo de 50% no tempo da tarefa.Por esse ponto de vista a maior parte das tarefas de um projeto deveriam terminar ou antes ou muito proxima do prazo. Mas isnto nao e o que acontece na maiora dos casos.Isto ocorre segundo a lei de Parkinson que diz que o trabalho se expande para preencher todo o seu tempo disponivel para ser concluido.Como Evitar?A tecnica do XP de ter o cliente sempre disponivel nos ajudou a resolver o primeiro problema, que era fazer o cliente enxergar estimativa como algo aproximado. E claro que nao basta ter apenas o cliente por perto, e sim de construir um relacionamento de confianca. Quando uma atividade atrasava o cliente era informado (detalhadamente) atraves de reunioes periodicas.Da mesma maneira, evitar a "gordura extra" depende de um bom relacionaemento com a equipe de desenvolvimento. Os desenvolvedores precisam ter tempo razoavel para realizar as estimativas e precisam saber que o gerente nao os ira "chicotear"caso uma estimativa dada nao se confirme. Em todos os nossos encontros para estimar prazos gostava sempre de enfatizar que me passassem o prazo real. E claro que sempre comparava os tempos estimados anteriormente para tarefas semelhantes com os tempos passados para a nova tarefa.Em resumos os principios de nossa forma de estimar prazos foram:Construir confianca do cliente;conscientizar que estimativas sao aproximacoes minimizando as gordurinhas nos prazos;sempre fazer a comparacao com estimativas anteriores____________________________________________________________________ Esta pergunta foi feita num comentario do ultimo post. E uma pergunta recorrente, mas que sempre rende muita discussao. Nao acredito que para ser um bom gerente de TI precise necessariamente ser um expert em programacao. Diga-se de passagem, esta ideia se aplica nao so a TI mas a outros ramos tambem.Um gerente que nao tenha conhecimentos avancados de informatica pode conduzir um projeto na area de TI. Claro que para isso tera que se apoiar (confiar) em membros do time que possuam conhecimento para realizar determinadas atividades (que exigem conhecimento tecnico especifico). Ai e onde residem algumas das habilidades requeridas para um bom Gerente: identificar as potencialidades de sua equipe, fazer com que estes potenciais sejam aproveitados de maneira mais eficaz,