Você “desenvolve” sistemas?
Oi pessoal,
Abordarei um tema pouco comentado em listas, porém muito reclamado pelas equipes de desenvolvimento de sistemas.
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 aos conceitos não assimilados 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.
Cordiais abraços,
Paulo Soares
Comentários são bem vindos
Paulo Soares
18 fev 10 at 23:53
Por mais que os “Grandes Gerentes” acreditem que suas poderosas ferramentas e métricas funcionem, ou seja, “forçarão” a equipe a cumprir o prazo, a melhor forma de estimar é a experiência. Já criou algo parecido antes, provável que leve +/- o mesmo tempo. Mesmo assim, não deixa de ser um chute. Nisso, como você bem disse, XP está na frente, e eu com eles
Juliano Biscaia
19 fev 10 at 9:31
Maravilha de “Artigo”… Pena que os Chefes e nem os GPs levam isso a sério.. nós Devs, Analistas.. Somos e sempre seremos o final do fluxo e onde o prazo vai chegar morto.. então.. apesar de tudo.. gostamos da nossa profissão… Estamos muito longe de um mundo(fluxo) perfeito..
Ederson
19 fev 10 at 9:33
Curti muito o seu texto… Parabéns!
Niler Barcelos
19 fev 10 at 9:34
Muito legal este texto, embora eu não possa concordar totalmente com ele.
Eu já “criei” muitos sistemas, conheço meu tempo de trabalho, sei quanto tempo demoro para fazer determinada tarefa, apesar de realmente ter que chutar um prazo, como você mesmo disse, ainda que um chute calculado, um chute.
Realmente o que você falou sobre o ultimo prazo nem sempre ser realmente o ultimo é verdade, muitas vezes podemos estender um pouco o prazo final, porem, muitas vezes não, como você disse, quando tem alguém perdendo dinheiro (maioria das vezes) temos que cumprir os prazos.
Realmente este é um ótimo texto.
Parabéns!
Luan
19 fev 10 at 9:34
Muito bom o texto Paulo!
Retrata exatamente o dia a dia de muitas Empresas.
Jaydson Gomes
19 fev 10 at 9:44
Bakana….
Parabéns
Relison Vital
19 fev 10 at 9:56
muito bom o post
Só quem trabalha com CRIAÇÃO de sistemas sabe o quanto é difícil estabelecer prazos, ao ler o seu post estava lembrando de Scrum para resolver esse tipo de problema, mas as suas estimativas tb não deixam de ser um chute com prazo de 2 a 4 semanas rs..
o melhor q tem a fazer mesmo eh como vc diz: relaxar
Willians de Paula
19 fev 10 at 10:19
Deixando de lado o academicismo, que sabemos quase cegar algumas pessoasm o funcionamento é geralmente esse mesmo.
Escolham o vernáculo que quiserem, criar ou desenvolver, não deixa de ser arte e não deixa de ser ciência.
O fato é que o prazo geralmente é decidido numa mesa de jantar, entre o comercial e o cliente, e não na sala da TI.
=D
Bruno
19 fev 10 at 10:24
Cara, muito muito bom o texto.
Desmistificou muita coisa.
Abração
ps: morri de ri aqui:
“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.”
Paulo Roberto
19 fev 10 at 10:27
Nossa, muito bom…
verdade total, tem 7 meses que sou estag em uma empresa de CRIAÇÃO web, na minha segunda semana, deram um sistema para eu estudar e perguntaram quanto tempo eu ia levar para fazer, falei que faria em uma semana, demorei um mês e meio… he he!!
Mas é isso ae.. muito bom o post estou recomendando para todo mundo!!!
Raphael Santo
19 fev 10 at 10:30
Os sistemas sempre existiram..
nunca tiramos nada do nada,
ninguém usa banana para fazer maçã pois
não existe um sistema capaz de fazer isso..
dificilmente sistemas são realmente criados,
apenas nas inovações..
enquanto ao prazo de entrega?
não só depende da capacidade do programador,
do gerente, das ferramentas e principalmente por causa do chef ^^
todos sabem que com o tempo nós paramos com os chutes..
leonardo
19 fev 10 at 10:32
Concordo totalmete com o post resposta do letrar (http://letrar.com.br/faca-se-o-software/).. e tenho pena da sua pobre alma. esse artigo não tem nada de profissional.
Quando alguém te pede um sistema de pagamento, e um prazo, você vai estudar o que você vai ter que fazer nos deptos. que irão utilizar o sistema e, depois, estipular um prazo… então em vez de dizer um prazo chutado para o seu chefe, peça um prazo para dar um prazo!… e se o babaca não aceitar, mude de emprego.. ou continue sendo um amador que só pensa no salário porcaria de um orgão público.
Porém, também trabalho em um orgão publico, e aqui ocorrem atrasos, mas o motivo é outro, é devido a “outros” projetos que ficam passando um por cima dos outros, infelizmente.
Carlos André Ferrari
19 fev 10 at 10:49
Cara, parabéns pelo texto.
Sensacional !
Luiz Henrique
19 fev 10 at 12:32
Paulo,
O artigo é bem bacana, parabéns!
Porém, como você finalizou existem 2 situações onde definir prazo é importante e deve ser definido a “rigor” e “perder dinheiro” é algo que sempre acontece quando um prazo não cumprido, ou seja, o cliente fica insatisfeito, a empresa perde o cliente (entenda também como perde dinheiro $$) e o funcionário (desenvolvedor) será demitido.
O problema é que em um mercado de tecnologia crescente como brasileiro os desenvolvedores não estão nem ai se perderão ou não seus empregos, se a empresa na qual trabalham perderá clientes e dinheiro e depois terá que mandar 50 funcionários embora porque não são os desenvolvedores que tomam esta decisão, não saõ os desenvolvedores quem mandam as pessoas embora…
Ou os desenvolvedores “caem na real do dólar” que se o prazo não for cumprido toda a empresa, funcionários e departamento serão afetados ou realmente a preocupação com o prazo não deve existir, afinal, não é na sua b#¨&* que a água vai bater, não é na sua b#¨&* que vai sobrar os pepinos que terão que ser descascados.
Pensem nisso e quem sabe vocês entenderão melhor os seus chefes e porque eles tomam certas posturas e atitudes. (obs.: é claro que sempre existirão péssimos líderes e gerentes e neste caso o prazo não é a questão mas sim a gerencia, o cara que está acima de vc!! cobre dele orientação, treinamento, metodologias de desenvolvimento e mais que ele faça a empresa toda entender isso, somente assim, quando necessário os prazos poderão ser negociados interna e externamente) (obs1.: o comentário dos dois caras acima do meu complementam o meu…estou com eles!)
Lucas Nunes
19 fev 10 at 13:27
Boa Noite a todos.
Recebi esse link pelo twitter, e já estou vendo a repercussão que está dando.
Hoje sou gerente de TI de uma empresa, especificamente da empresa que o Lucas (comentário acima) é diretor. Comecei minha carreira a mais de 15 anos, criando, desenvolvendo ou qq outra coisa que vcs queiram chamar, em Clipper, acho que muitos dos que estão lendo nem sabe o que é. Foi num tempo que não existia XP, Scrum, e outras metodologias de estimativa de tempos/prazos.
No inicio, meus superiores estimavam meus prazos da seguinte maneira, eles multiplicavam o tempo que eles levariam pra fazer determinada coisa por 2 ou até 3. Até eu atingir maturidade suficiente pra eu mesmo estimar meus prazos sem “muito” erro, pois isso sempre acontece.
Nunca criei/desenvolvi um sistema de pagamento de pessoal, mas não deve ser nada além de que um monte de cadastro com uma porção de calculo, gerando uma pilha de relatórios, então eu seu fazer um desse e sei estimar o tempo.
Passei esse link pro Lucas (comentário acima), pois estamos tendo alguns problemas com prazos aqui na empresa. Será que é culpa do gerente de projetos??? ou dos desenvolvedores que estão “chutando os prazos”, não acho que a função do GP é ajustar prazo de entrega, e sim cobrar a equipe dos prazos que elas mesmas deram pra desenvolver/criar alguma coisa que não passa de formulario com calculo e emissão de relatórios.
Esses chutes as vezes acontece por aquele webdesigner que não tem a minima noção de desenvolvimento, e pega um site/projeto de alguma empresa que quer gastar pouco, e que pede alguma coisa que esse fulano não sabe fazer.
Concordo com outro comentário acima que cita “pobre alma” pra quem pensa assim.
Esse texto foi muito bem escrito, mas pensar assim na minha opinião é “meio amador”.
Passei esse link pra algumas pessoas pra ter um feedback do que pensavam, e acho que vou esperar mais comentários antes de passar pra minha equipe de desenvolvimento!!!
Marcelo Morote
19 fev 10 at 18:45
Olá Luan Muniz,
Percebo que você entendeu muito bem a mensagem.
É isso mesmo! Apesar de você conhecer a sua velocidade de trabalho, ainda assim você vai se deparar com situações onde o prazo de entrega de um projeto é algo intangível. Isso acontece em projetos cujas áreas de negócio você não domina. Se sua velocidade pode variar de um projeto para outro, imagine o que acontece com uma equipe um pouco maior, de cinco ou seis pessoas. Seus problemas são escalados exponencialmente. E aí dar um prazo certo é bem complicado, porque você vai lidar com situações anômalas.
Em tempo, a maioria dos prazos podem ser renegociados, porém como eu disse, existem alguns prazos que devem ser seguidos a rigor. No artigo reduzir esses casos aos dois citados para que ficasse gravado na mente do leitor, porém outras situações envolvem prazos inadiáveis. Por exemplo, do que adianta um projeto de campanha para um político após as eleições? Então, como se percebe, existem outras situações em que os prazos devem ser cumpridos a rigor sob o risco de falência do projeto.
É isso!
Abraços,
Paulo Soares
Paulo Soares
20 fev 10 at 10:33
Então, Bruno.
Muita gente se ilude achando que o ministrado na academia (universidade) é simples como foi ensinado. Muitas variáveis estão envolvidas, e elas influenciam diretamente no resultado do projeto. Porém, nem sempre as complicações do dia-a-dia são passadas aos discentes.
O que você disse é a pura verdade. Muitas vezes nem vale a pena discutir prazo, pois o prazo já foi acertado com o cliente. Então, pra que se discutir prazo? Já me aconteceu de ter que entregar um produto sem passar pela equipe de Testes. Um absurdo, porém o chefe queria isso e o cliente também. Mesmo alertando sobre os riscos, isso não foi suficiente. O que foi acertado da primeira vez, foi o que ficou decidido.
Abraços,
Paulo Soares
Paulo Soares
20 fev 10 at 10:50
Olá Raphael Santo,
Relaxe, isso acontece nas melhores famílias
Abraços,
Paulo Soares
Paulo Soares
20 fev 10 at 10:51
Olá Leonardo Rivillini,
Não concordo que, com o tempo, paramos com os chutes. Acredito que os chutes são mais certeiros. E vez ou outra, você irá errar feio.
Abraços,
Paulo Saores
Paulo Soares
20 fev 10 at 10:59
Olá Carlos André Ferrari,
Não vou fazer guerra com você ou o Rômulo Gnomo (letraR) por aqui. Acredito que sempre cabe o respeito entre os profissionais. Por isso preservarei os leitores do blog quanto a esta discussão infinda e fútil.
Mas, não tenha receios, meu e-mail fica à disposição para qualquer esclarecimento quanto às minhas qualificações técnicas para falar com maestria e profissionalismo sobre o tema abordado. Se preferir, no google procure: “Paulo Augusto Borges Soares”. Deve ter muita coisa útil para analisar minha “pobre alma”, meu “amadorismo” e o meu “salário porcaria de um órgão público”.
Quanto ao seu problema de atrasos, você não é o único. O preterimento de projetos é comum, pois as necessidades são voláteis em função do tempo. Sua instituição vai lidar com isso com muito embaraço até constituir um Comitê formado pela alta cúpula do órgão (diretores, gerentes, coordenadores), de todas as áreas demandantes. Esse comitê é quem deve priorizar o trabalho.
Abraços sem rancores,
Paulo Soares
Paulo Soares
20 fev 10 at 12:05
Cara, que me desculpe, mas você sequer sabe o que é um sistema!! Sugiro que leia sobre o mesmo na Wikipedia (está porco, mas pelo menos são poucas linhas): http://pt.wikipedia.org/wiki/Teoria_de_sistemas
Bom, eu ia comentar seu texto, mas este cara já o fez bem e respeitosamente:
http://letrar.com.br/faca-se-o-software/#more-202
Douglas
21 fev 10 at 1:05
Para começar eu quero dizer que o texto está muito bem escrito, divertido e fácil de ler. Meus parabéns…
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.
paulocanedo
21 fev 10 at 14:26
Gostei mais da polêmica que isso gerou…
É um sinal que este assunto(estimar tempo para realizar uma tarefa) é bem importante. Continue escrevendo e lendo também, pois uma boa base sustenta mais os argumentos.
Renê Dettenborn
22 fev 10 at 12:26
Olá Renê Dettenborn,
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.
Paulo Soares
22 fev 10 at 13:24
Boa tarde Paulo,
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.
Marcelo Morote
22 fev 10 at 17:18
Lógico!
paulosoares arroba gmail ponto com
À disposição para você e qualquer outro leitor interessado!
Abraços,
Paulo Soares
Paulo Soares
22 fev 10 at 18:35
Parabéns pelo POST. Tens razão em muito que disseste, mas isso é parecido com o conflito social/filosófico entre classes. Enxergando o cenário de “Desenvolvimento de software” o que hoje tenta-se fazer é aproximar-lo de linha de produção, e por isso sempre tentamos alinhar os processos de engenharia de software (Ferramenta) e a necessidade do cliente, visto que estamos de software como produto. O cliente não pode esperar que o gênio ou artista de software acorde inspirado para concluir a obra prima. Conclusão o Cliente dita a necessidade e como foi dito o resto é negociável, mas é sempre preciso um deadline para poder ressuscitar o projeto apos isso se necessário e também com o tempo podemos melhorar a pontaria, pois querendo ou não existem tarefas de desenvolvimento que também são rotineiras (linha de montagem).
“Porque é tão difícil estimar?… existem diversas maneiras de fazer isso, alguma delas tem que dar certo para você. Se nenhuma delas funcionar, crie a sua própria maneira, vale qualquer coisa, desde que dê certo.”(letraR) – CHUTE!? Então concorda então.
Ademir José
23 fev 10 at 13:54
@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
Carlos André Ferrari
25 fev 10 at 7:37
Olá Carlos André Ferrari,
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
Paulo Soares
25 fev 10 at 11:52
Olá Paulo!
Realmente seu post gerou polêmica e é um assunto digno de uma “mesa redonda” hehehe!
Parabéns por abordar esse tema que tem grande importância, porém, pouco debatido.
Eu nao sei como é na empresa que você trabalha e o tamanho de sua experiência como desenvolvedor. Mas eu comecei a programar há apenas 1 ano em JAVA e posso dizer que aprendi muito sobre a linguagem, mas o que mais aprendo é sobre trabalho em equipe e cumprimento de prazos, mesmo porque depois do dinheiro, é o que o cliente mais leva em consideração, ao meu ver.
Nós trabalhamos para DESENVOLVER, o sistema em si já existe ( assim como a luz, que no nosso caso é uma idéia ou uma folha de papel) com o objetivo de alcançarmos o nosso escopo voltado para o segmento do cliente ( no exemplo de sistema de RH)
Na empresa em que trabalho, nós utilizamos o Scrum, onde é dado todo poder de estimativa aos próprios programadores/desenvolvedores estipulando horas necessárias por tarefas e grau de dificuldade de cumprir o mesmo. Portanto não acho que chutamos o tempo e sim, ANALISAMOS.
Concordo que errar faz parte, mesmo por falta de experiência, por não contar com imprevistos ou interrupções, ou por termos que estipular algo que nem temos idéia por onde começar, pra isso temos a supervisão do GP ( no nosso caso, Scrum Master) que tem a experiência e a sabedoria que nos falta, e ele entende possíveis contratempos e entende a experiência de seus desenvolvedores, e se ele não achar possivel cumprir o prazo que a equipe estipulou, deve nos chamar para realidade. Concordo com o comentário acima onde foi dito que devemos pedir um prazo para estipularmos um prazo, sem PRESSA. Nada melhor do que reunir a equipe para julgar e trocar idéias entre pessoas com mais e menos experiência, sem PREGUIÇA.
Seguimos um conceito de PIG e CHICKEN.(http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/) Onde uma charge nos lembra que um PIG está realmente envolvido com o projeto que desenvolve e um chicken não. Acredito que essa seja a diferença: Vc, como desenvolvedor estipular um prazo, e como um PIG, ver que o prazo foi estipulado erroneamente, mas fazer o possível para cumprir com o prometido ou chegar o mais perto possível e diminuir os erros no próximo OU ver que o prazo não será cumprido e o desenvolvedor simplesmente “relaxar” porque era um chute. Isso se chama comprometimento. Aí que está: Vc com certeza vc não estava “louco” quando estipulou o prazo, por que de repente a realidade ficou tao distante?
Tendo esse cenário vc realmente acredita que deve “relaxar”?? Só porque vc sabe que em “toda empresa” esse prazo pode ser “esticado”?
Eu como uma PIG não consigo conviver com essa idéia, e acredito que se eu realmente estiver envolvida com o projeto, se realmente estiver comprometida com o objetivo, não teria que “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.”
E quanto a “Você é cobrado por prazos incumpríveis simplesmente para satisfazer o ego de alguém (chefes?)” Nao tento cumprir prazos pra satisfazer o ego dos chefes ou do cliente, e sim pra satisfazer o meu ego e não cometer o mesmo erro quando eu for estipular o prazo de um novo projeto.
Concordo com o caso apenas no fato de quando o cliente quer estipular o prazo, nem que isso faça vc ter que “pular” a equipe de testes. Aí sim eu concordo, vc deve orientar o cliente ou seu chefe sobre os problemas que isso pode acarretar e daí sim relaxar e dormir tranquilo mais de 4h por noite.
E outra “Eu considero que há duas situações onde o rigor do prazo correto deva ser aplicado:
1.Quando tem gente morrendo;
2.Quando tem gente perdendo dinheiro. “
Ao meu ver nós estamos perdendo dinheiro!! Não cumprindo o prazo, perdemos o cliente, que é a fonte de renda (entre outras) da empresa, que deixa nossos superiores “putos” que deixa de nos “motivar”
Lembre-se Paulo, a partir do momento que vc ANALISA a demanda, cumprir o prazo é sua “única” obrigação. E se isso não acontecer, o único quem errou foi vc e é a única pessoa que deve corrigir isso, sendo passando noites em claro ou não.
Pois novamente digo que nao sei como é na sua empresa, mas aqui somos promovidos, ganhamos almoços, bonificações, regalias conforme cumprimos nosso papel.
Nossa!É tanta coisa pra debater que meu “comentário” ficou comprido demais…ahahahah
Como aqui é um blog serve pra isso mesmo. Gerar polêmicas, debater, vc expressar suas opiniões e tenta convencer ou ser convencido mesmo sem precisar ficar citando livros, invenções,autores…
Parabéns de novo Paulo!Continue com seus posts!E só uma sugestão..tenta se auto-motivar mais..faça as coisas por vc e não pra encher ego dos outros….No pain, no game!
p.s: Devo comentar: Sou desenvolvedora JAVA da mesma empresa do Luca Nunes e Marcelo Morote.
Até mais!
Inah
5 mar 10 at 17:26
Olá Inah,
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
Paulo Soares
5 mar 10 at 18:56
Trabalho como desenvolvedor J2EE e analista a pelo menos 3 anos. Normalmente quando temos que desenvolver algo, nós levantamos tudo o que deve ser feito e como, e estimamos qual o tempo para se fazer aquela implementação. Esse estimar, pra mim é um chute calculado, mas um chute. Nenhum dos métodos que vi até hoje tem precisão matemática para calcular com exatidão quantas horas você levará para construir algo, principalmente se for uma aplicação genérica que poderá ter muitas parametrizações e que terá telas completamente dinâmicas (tudo com ajax, por exemplo, e diferente para cada produto da empresa) e que poderá ser reaproveitado por diversas produtos diferentes da mesma empresa, com parte em comum das funcionalidades, mas também com algumas particularidades. Mas para sistemas que tem uma complexidade simples, um cadastrinho, por exemplo, quase sempre a previsão (chute) está correto. Por isso para sistemas complexos, acho recomendável estimar (chutar) e acrescer cerca de 20 a 30 porcento de gordura, pois muitos imprevistos irão aparecer ao longo do desenvolvimento, principalmente quando se depende de outras pessoas para construir o sistema.
Dênis
11 mar 10 at 19:11
Paulo, você me autoriza a publicar partes do texto em meu blog?
Parabéns pelo artigo espetacular.
A melhor frase foi: “a única técnica para mensurar o tempo de desenvolvimento de um sistema é o chute”. Sempre quis falar isso mas nunca tive coragem! hehehe
Abraços,
Rafael
18 mar 10 at 0:49
Pode sim Rafael, porém, além de citar a fonte, tome o cuidado para que tais partes não fiquem sem sentido.
Abraços,
Paulo Soares
Paulo Soares
18 mar 10 at 11:44
Paulo,
Legal o seu texto, legal e divertido. Parece que todo informático vive este filme, ou ja viveu algum dia, ou viverá (…um chute…)!
Foi uma maneira descontraída de registrar nossa triste realidade.
Mas acho uma boa estimativa (chute) é sempre válida em especial quando não se tratar de marinheiro de primeira viagem!
Se vc programa, então conhece seu ritmo, as ferramentas de desenvolvimento, as necessidades do contratante!
Imagine um hacker/cracker que estou um tempão e gosta de trabalhar desenvolvendo programinhas, será que ele vai demorar muito para colocar seu produto no ar?
Acho que o tempo necessário para criação de um sistema/programa está ligado a alguns fatores, tais como:
– pendor (dom – habilidade),
– conhecimento,
– interesse,
– necessidade,e
– cobrança.
Qualquer pessoa programa, qualquer pessoa medica, qualquer pessoa coordena. Mas Programar, Medicar, Coordenar mesmo, precisa de algo diferencial….
Parabéns pelo artigo, gostei mesmo!
Roberto
27 ago 10 at 10:17
Olá Roberto,
Primeiramente, obrigado pelo feedback, e fico feliz por ter gostado do texto.
Obviamente minha intenção foi fazer uma provocação de maneira informal e descontraída.
Sei que existem “N” fatores que podem influenciar a produtividade na criação de qualquer produto. Com a Engenharia de Software isso não poderia ser diferente.
Minha provocação vai de encontro exatamente na sistemática de como isso é feito. Acredito em métricas sim, mas métricas simples, objetivas e que permitam a incerteza (intuição). Este último, é repudiado por Pressman. Porém, infelizmente (ou felizmente), minha humilde mente ainda não aprendeu a aceitar sua opinião.
Assim, “o chute”, me parece algo tangível, isso mesmo, tangível para o assunto.
Abraços,
Paulo Soares
Paulo Soares
28 ago 10 at 1:10