Vamos por partes.

Faço sistemas desde 1995. Passei por Clipper, Delphi, PHP e Java. Cheguei a conhecer algumas outras linguagens, porém nada muito extensivo.

Sou concursado pelo Ministério Público da União (MPU) desde 2005, onde sou Chefe de Implementação de Sistemas de Pequeno Porte pelo Ministério Público do Distrito Federal e Territórios, um dos ramos do MPU. Temos uma equipe de 4 pessoas, mas já chegamos a ter 8. Algumas pessoas saem do órgão quando passam em concursos melhores.

Concordo que após o dinheiro, o prazo é o item que é mais levado em consideração pelo cliente. Principalmente para equipes de desenvolvimento de software de órgãos públicos, o dinheiro gasto em um projeto, muitas vezes não é mensurado, então o prazo é o principal quesito para medição de desempenho de um projeto.

Conheço os princípios do XP e Scrum, e posso falar com propriedade que a análise que você faz gera um tempo de desenvolvimento diferente da análise que seu chefe faz. Da mesma forma, outra pessoa que acabou de entrar na equipe, também faz uma análise diferente e o prazo é diferente. Resumindo, o que você chama de análise, eu chamo de chute.

Sei que muita gente deve ter entendido chute como coisa de amador. Para mim, esse é um chute profissional. Um chute baseado na sua intuição e ratificado por sua experiência. Mas o que quero deixar claro é que não deixa de ser um chute. Algo que pra você é um valor, para outro, outro valor. É exatamente nesse ponto que surgem as estimativas erradas, e o prazo deve ser renegociado.

O Gerente de Projetos pode te chamar a atenção para a realidade, isso é verdade. Mas não há muito o que fazer se a estrutura da sua empresa é hierarquizada, em geral, o prazo já foi estipulado antes mesmo de chegar a você, e só te resta uma saída: cumprir o prazo. Essa é uma questão complicada, mas se você não faz parte do corpo decisivo da empresa, dificilmente você será consultada sobre questões gerenciais. Se você é consultada, sinta-se privilegiada.

O seu caso é diferente, vocês adotaram o Scrum como processo, e isso indica que você trabalha em uma estrutura projetizada. Certamente, você tem mais liberdade para definir prazos, mas seu cliente não irá gostar nada se você errar prazos por sprints consecutivos ou o que você entregar não estiver dentro dos critérios de aceite (tarefas não cumpridas, coisas que funcionavam não funcionam mais ou o que deveria funcionar nesse sprint não estar funcionando). Entendo que a tendência é de diminuição dos erros à medida que o projeto evolui, mas será que seu cliente entende isso? E pior, será que em um novo projeto, o cliente entende que sua velocidade pode ser diferente de outro?

Estar comprometido ou envolvido não é questão de gosto, é perfil. Tenho colegas comprometidos com o trabalho, mas também já tive colegas simplesmente envolvidos. Independente do local onde você coloca os “envolvidos” para trabalhar, percebi que eles eram do mesmo jeito. Não se interessavam pelo o que estavam fazendo. Por isso digo que é questão de perfil. Acredito, fortemente, que a pessoa esteja no local errado e eu, como chefe, tenho que tomar uma decisão sobre essa pessoa. Eu avalio a produtividade e interesse da pessoa, se ela se esforça, dou um voto de confiança. Se ela não se esforça, prefiro ter uma vaga na equipe do que uma pessoa dando trabalho para mim e para outros colegas que estão “comprometidos” com o trabalho.

Acho que não deixei entender que devia-se relaxar porque o prazo dado foi um chute. Isso também não tem nada a ver com falta de comprometimento. Acredito que, mesmo os comprometidos, têm problemas com prazos. Algo que subestimaram em um projeto pode acabar gerando a correria de final de prazo. Então, não tenho como concordar com você que um “PIG” não passaria por esses problemas.

Após a análise da demanda, existem inúmero outros passos a serem cumpridos além do prazo. Entregar um produto de qualidade, que atenda aos requisitos do cliente, que funcione conforme o esperado, que seja manutenível, documentado, que esteja dentro dos padrões da organização etc. Isso, pode ser contraproducente, porém seu cliente e seu chefe esperam que o produto esteja assim.

Eu achei injusto escrever um comentário pequeno diante do seu. Então, nada mais justo que detalhar bem.

Abraços,
Paulo Soares

Li esse livro no ano passado. Ele é bem interessante porque aborda a mesma filosofia do Extreme Programming (XP).

O XP leciona que devemos manter o cliente perto, sempre envolvido com o projeto, mas eu não vejo isso acontecendo pelos lugares que passei. Sei que esta é uma ótima forma para obter o aceite do produto, pois o cliente está sempre avaliando os resultados, mudando as prioridades e, às vezes, mudando definições no escopo. O problema é que, em geral, as pessoas estão envolvidas com suas próprias tarefas e processos, relacionados com sua área de negócio. Trazer o cliente (ou um representante) para o ambiente de projeto é muito complicado, porém levar um funcionário da minha empresa para junto do cliente é o que acontece. Mas isso não é novidade, acontece em todos os lugares. Se não, não teria como você levantar requisitos para a especificação do projeto, certo?

As reuniões com o cliente acontecem sempre ao final de uma interação, quando necessário, há a renegociação de prazos, porém isso não é traumático para meus clientes porque não estão com a “corda no pescoço”. Ainda bem

Aqui não funciona esse negócio de “sempre pode-se trocar um funcionário que não está rendendo o que deveria”. Então, nem sempre isso acontece.

Quanto a “um prazo mais folgado” isso deve ser visto com muito cuidado. Você deixar um “gordura” no cronograma do projeto é uma boa para completar tarefas atrasadas, porém quando o cliente percebe isso, você fica sem argumentos. Geralmente, o cliente não paga por sua “gordura”.

Abraços,
Paulo Soares

Bom Paulo, realmente não deveria te chamar de amador, pois esta afirmação depende do ponto de vista e apenas no meu ponto isso se enquadra em amadorismo.

No mais, para equipes em geral (as que atrasam ou não [relativo pois depende do projeto]) existe o Getting Real em que uma das pregações é desenvolver por funcionalidades, então, se você vai atrasar, pelo menos você já vai alimentando seu cliente com partes 100% funcionais do sistema. o livro também foca a utilização de equipes pequenas, exatamente porque a “comunicação” e gerenciamento é muito melhor.

Outro ponto é manter um funcionário do cliente que entenda do processo na sua empresa ou um funcionário da sua empresa junto ao cliente, testando 100% do tempo.

reuniões de tempos em tempos ajuada muito na correção de estimativas. e sempre pode-se trocar um funcionário que não está rendendo o que deveria. “acredito” (EU) que trocar o funcionário é melhor do que aumentar a equipe, pois um desenvolvedor vai se dedicar muito mais para não ser substituido.

e por ultimo, sempre é bom pedir um prazo mais folgado, ou simplesmente dizer que “não será possível concluir o projeto no tempo estipulado” antes mesmo de aceitar o serviço. (Principalmente se você tem certeza disso e SABE que vai perder dinheiro).

Taí o link do livro Getting Real:
http://gettingreal.37signals.com/GR_por.php

E desculpe por ter te etiquetado como amador indevidamente.

Carlos A. Ferrari.
http://ferrari.eti.br
http://github.com/caferrari
http://github.com/secom-tocantins

paulosoares arroba gmail ponto com

À disposição para você e qualquer outro leitor interessado!

Abraços,
Paulo Soares

Voltei porque realmente achei o seu post bem interessante. A idéia não foi gerar discordia, mas colocar pontos de vista contraditórios, e deixar claro que o programador não pode virar noites pra cumprir o prazo simplesmente se tem:
1- gente morrendo
2- gente prdendo dinheiro

Vamos ao seu exemplo:
E se esse programador foi contratado pra fazer esse sistemas de pagamento de RH, ele “chuta” o prazo, e no final não consegue cumprir?
Será que o cliente desiste do projeto?
Pede parte do que foi investido de volta?
A empresa que contratou esse programador tem obrigação de continuar com ele?
Acho que a pessoa não deve ter “medo” ou “vergonha” de dizer:
-Nunca fiz nada assim antes, preciso de mais informação para “criar ou desenvolver” esse projeto.
É bem melhor que chutar sem pensar lá na frente, é meio falta de responsábilidade. Concorda???

Quanto ao exemplo da lâmpada, eu já havia lido em algum outro lugar sem ser o livro, esse exemplo é um pouco estranho de comparar, pois ninguém havia feito uma lâmpada antes, nem o proprio Tomaz sabia que iria inventar a lâmpada.

Aliás, estou estudando bastante sobre gerencia de projetos, poderiamos trocar algumas infos.

Algumas pessoas expuseram críticas em função de não haver revisão literária explícita. Concordo que isto pode parecer um erro. Mas foi propositalmente feito assim reforçar minha experiência de mercado, além de trazer informalidade e leitura agradável.

Meus próximos posts trarão citações com embasamentos científicos, mesmo que, às vezes, o leitor se sinta desconfortável. Acredito que isto, conforme sugerido por você, possa sustentar mais os argumentos e gerar menos polêmica.

De toda forma, para quem não percebeu, algumas idéias, como a comparação da lâmpada, foram tiradas do livro “A Practical Guide to Extreme Programming” de Dave Astel, Granville Miller e Miroslav Novak. (coloquei em negrito para que não passe despercebido)

Assim, espero que o leitor mais crítico possa conferir a bibliografia e analisar com mais calma o que foi falado.

Eu concordo com muitas coisas, até me sinto um pouco contextualizado em seu post lá no meu trabalho.

Infelizmente tivemos leitores meio revoltados que perderam a razão e partiram para baixaria, francamente chamar alguém que nem conhece de amador, pelo simples fato de discordar dos seus pensamentos.
Tenho certeza absoluta que uma pessoa que defende seu ponto de vista utilizando-se de argumentos técnicos está muito longe de amadorismo.