Há tempos venho pensado (e passado por) – em situações em que nós, programadores somos cobrados no quesito prazo de entrega de projetos. Inclusive, dias atrás fiz, em minha cabeça, uma breve comparação em como cada uma das empresas que trabalhei e a que trabalho hoje, agem em relação à isto.
Hoje, meio que “sem querer, querendo”, encontrei um post que trouxe à tona exatamente a conclusão que cheguei na comparação que fiz anteriormente. Segue abaixo o post de Paulo Soares:
Eu sei o que é desenvolver?
Acredito que, muitos dos problemas que são enfrentados no dia-a-dia de um profissional de TI (Tecnologia da Informação), certamente, estão relacionados ao não entendimento dos conceitos que cercam a computação. Os gerentes de TI (entenda nossos chefes), talvez por pouca experiência, criam esperanças que as coisas poderiam ser melhores, que os prazos poderiam ser cumpridos, que os projetos poderiam ser entregues no primeiro prazo acordado etc., porém não analisam o contexto no qual submetem seus colaboradores.
Primeiro, você sabe o conceito da palavra “desenvolver”? O melhor entendimento que extraí está no dicionário Michaelis:
de.sen.vol.ver: Adiantar, aumentar, melhorar, aperfeiçoar, fazer progredir
Pois bem, adiantar, aumentar, melhorar, aperfeiçoar, fazer progredir necessita que alguma coisa exista antes. E, geralmente, quando fazemos sistemas, a coisa nasce do zero. Tá bom, não é bem do zero, mas nada que se aproxime do que você realmente precisa existe. A menos que você esteja em uma manutenção evolutiva, as coisas nascem do zero, certo? Por que não usar a conotação bíblica? “No princípio, Deus CRIOU os céus e a terra”. Deixa eu repetir, CRIOU. Do zero… Então, se você parte do zero, você CRIA, e não DESENVOLVE.
Primeiro mito desvendado, você não desenvolve sistemas, você os cria. Eu criei isso.
Perceba que seu problema começou antes mesmo de você saber que estava em um problema. Quando você é nomeado/contratado para fazer parte de uma equipe de desenvolvimento de sistemas, você já está entrando em um barco furado e não tem noção disso. Mas, calma, como dizia Murphy: “Não há nada tão ruim que não possa piorar”.
No seu primeiro dia de trabalho, seu chefe lhe dará uma tarefa:
- Severino (esse é você), vamos iniciar o desenvolvimento do Sistema de Pagamento de Pessoal. A equipe é composta por todos os integrantes da Seção de Desenvolvimento de Sistemas, ou seja, somente você. Tudo bem?
É óóóóóóóbvio que você vai responder:
- Tudo bem, chefe. Estou aqui para desafios!
Detalhe, você nunca ouviu falar naquelas milhões de siglas que tangem a área de Pagamento de Pessoal, sem falar nos cálculos, consolidações, análises etc. Isso envolve pesquisa, seleção, construção, refinamento… Tranquilo, você sabe disso, mas seu chefe não. E não tarda para aparecer a pergunta matadora:
- Em quantos dias você me entrega isso?
Pode ter certeza, nessa hora dá vontade de “bater” num camarada desses. Pois bem, é melhor voltarmos à teoria.
Por que é tão difícil estimar?
O trabalho de criação de sistemas é tão complexo quanto o trabalho de criação de qualquer coisa inédita. Alguém, em sua sã consciência, teria a ousadia de perguntar ao Thomas Edison:
- Ei, Edison, em quantos dias você inventa a lâmpada?
Não há como medir a velocidade de criação de uma pessoa. Esse é um evento espontâneo que varia de pessoa para pessoa. Não existe regra, é o acaso que determina isso.
Por isso é tão difícil para qualquer técnica precisar, com eficiência, o prazo de criação de um sistema. Por mais que você envolva as melhores práticas de gerência de projetos, que você reduza os impactos dos riscos, que você derrube barreiras que geram atrasos, você vai acabar caindo na técnica do CHUTE, para emitir qualquer estimativa.
Segundo mito desvendado, a única técnica para mensurar o tempo de desenvolvimento de um sistema é o chute. Eu acho.
Bem, agora você deve estar achando que fiquei louco e estou falando abobrinha. Vamos ver se isso confere.
Se você é do tipo “Gerente de Projetos”, você deve estar falando: “Eu uso PERT (Análise de três pontos) e, geralmente, acerto meu cronograma”. Primeiro, acerta o cronograma um @#$%*… Você mexe no cronograma todo dia e a data de término é sempre mais longa. Segundo, o PERT usa a análise de três chutes: o prazo quando tudo dá errado, o mais provável e quando tudo dá certo. Daí se aplica um cálculo, alguma medida de dispersão, como: média ponderada, aritimética, desvio-padrão etc., e se chega a um valor que será usado para todas as atividades do projeto. Certo, é um chute calculado, mas não deixa de ser um chute.
O pessoal do XP (Extreme Programming) nem tem o que reclamar, é o chute da equipe. Então, quanto menor a equipe, maior a chance de erro. Esse é um chute bem às escuras mesmo. Mas quanto mais se treina, mais próximo do acerto estamos.
A galera da APF (Análise de Ponto de Função) se baseia numa tabela para analisar a complexidade de uma funcionalidade e daí aplica um percentual para saber quanto tempo o pessoal do desenvolvimento irá precisar. Olha só o absurdo, se você usa uma entidade com 51 atributos a complexidade é a mesma que se você usasse uma entidade com 151 atributos. Detalhe, a medida é usada para qualquer tipo de projeto. É claro que pode-se usar os Pontos de Função Ajustados, mas, isso ainda não deixa de ser um chute.
Bem, chute por chute, quanto mais simples melhor. XP, estou com vocês, viu?
Enfim, vamos aos finalmentes. E eu já inicio com o terceiro e último mito.
Terceiro mito desvendado, hoje é o seu último prazo, amanhã reavaliaremos a situação.
Já me aconteceu, salvo engano, em 100% dos casos, o último prazo não era o último. Sempre há espaço para mais uns dias de trabalho.
Não adianta você passar madrugadas em claro, sair correndo de casa, acelerar tudo que seu carro pode oferecer de potência para chegar mais cedo ao trabalho e adiantar aquele trabalho hiper-atrasado. Não precisa disso. Os prazos não são compromissos escritos em pedra. Eles mudam.
Geralmente, prazos para desenvolvimento de sistemas são negociados. Você é cobrado por prazos incumpríveis simplesmente para satisfazer o ego de alguém (chefes?). Neste caso, é a confiança que está em jogo.
Seu chefe prometeu algo para alguém e você é quem deve cumprir. Mas você não foi consultado disso. Normal, chefes adoram fazer isso. Seu chefe cobra que você entregue no prazo estipulado por ele, simplesmente, para que a confiança nele seja mantida perante os clientes. Mal sabe ele que, se entregar algo no prazo, isso, apesar de soar bem, é ruim para a equipe. Pois vão acreditar que, se você se esforçar um pouco mais, poderá entregar antes. E aí, meu querido, ninguém lembra que você dormiu 4 horas e levou duas multas de pardal para chegar ao trabalho. Você não está no seu limite, você está além.
Eu considero que há duas situações onde o rigor do prazo correto deva ser aplicado:
- Quando tem gente morrendo;
- Quando tem gente perdendo dinheiro.
Se esse não for o seu caso, dê um sorriso bem grande e relaxe! Sempre há uma luz no fim do túnel.
Bom. Nem preciso dizer que concordo com o que o Paulo disse em seu post, né? E você, o que pensa a respeito? Deixe seu comentário.
Navegando pela net hoje, encontrei no Profissionais TI um banner de um dos maiores eventos realizados pela comunidade de programadores PHP e Web do Brasil. Dessa vez, a edição será no Distrito Federal e vai contar com palestras de excelentes profissionais da área de desenvolvimento de sites, sistemas e aplicativos móveis.
Quem nunca tentou acessar o Gmail e este estava com problemas? Isso é normal que aconteça se tratanto de um aplicativo 100% web e com milhões de acessos no mundo inteiro. Mais normal ainda se torna quando ativamos um monte de labs e recursos extras.
Todo mundo sabe que há um grande comentário na web afora de que o flash não é compatível com mac, com linux e alguns browsers no próprio windows. Ou que, quando é compatível, tem péssimo desempenho se comparado ao Windows. Para sistemas mobiles então, falar é flash é o mesmo que falarmos de vírus. Eis as últimas, digamos “bombásticas”, notícias em relação a nova versão do plugin Adobe Flash, divulgada pela própria Adobe:
