Hoje eu li cada besteira

Kanin Dragon:

Me questiono, como vender um projeto para uma grande cia definindo custo e prazo com esse conhecimento empírico :?:

Definir custo e prazo é um tanto duvidoso,a inda mais em um projeto grande, para uma grande companhia. Nao raramente eles falham, estouram prazo, budget e trocam de fornecedor. Acho que deve ser preferivel continuar ser desenvolvedor que tentar inventar estimativas e custos duvidosos, apenas para ganhar um projeto, ja adicionando clausulas draconianas para qualquer mal entendido.

Talvez dizer que nao existe estimativa nenhuma seja demais, mas estimar com essa. Fico bem mais para o lado dos desenvolvedores que dizem ser dificil estimar a medio-logno prazo, e prefiro a abordagem deles de revelar os nomes e sobrenomes, sem usar pseudonimos.

Concordo plenamente.

Você pode ser honesto com o seu cliente e dizer que não tem como estimar o projeto se ele for muito grande. Ou você pode tentar enganar ele (e a si mesmo) com APF.

Infelizmente pode acontecer muitos “problemas” no andamento de um projeto que ninguém pode prever.

Eu acho sim possível estimar custo e prazo independente do tamanho do projeto.

PMBOK está ai pra isso, existe uma cacetada de processos e metodologias para auxiliar o GP. Análises PERT por exemplo. E claro, sempre ter uma opinião especializada sobre o assunto (o próprio desenvolvedor).

Leonardo Gaona:

Eu acho sim possível estimar custo e prazo independente do tamanho do projeto.

PMBOK está ai pra isso, existe uma cacetada de processos e metodologias para auxiliar o GP. Análises PERT por exemplo. E claro, sempre ter uma opinião especializada
sobre o assunto (o próprio desenvolvedor).

Você tem 3 cases de sucesso onde isso foi realidade?

Não é provocação, é curiosidade mesmo.

Leonardo Gaona:

Eu acho sim possível estimar custo e prazo independente do tamanho do projeto.

PMBOK está ai pra isso, existe uma cacetada de processos e metodologias para auxiliar o GP. Análises PERT por exemplo. E claro, sempre ter uma opinião especializada sobre o assunto (o próprio desenvolvedor).

Então pode estimar…Isso significa que não pode ter exatidão…

Por mais que você siga normas e procedimentos, dificilmente poderá estimar com exatidão. Existem fatores nos ambientes interno e externo que acabam influenciando qualquer ‘previsão’…

Leonardo Gaona:

Eu acho sim possível estimar custo e prazo independente do tamanho do projeto.

PMBOK está ai pra isso, existe uma cacetada de processos e metodologias para auxiliar o GP. Análises PERT por exemplo. E claro, sempre ter uma opinião especializada sobre o assunto (o próprio desenvolvedor).

Sim, o PMBOK está aí, cada vez mais dividindo espaço com o Scrum. Talvez porque entregas rápidas estejam gerando mais resultado do que longos meses de planejamento.

Concordo com todos,

mas existe algumas formas de engenharia de software, que determina um padrão a ser seguido, um exemplo é a técnica de desevolviment espiral, que é feito em 4 partes e com determinados modulos, sendo que ao fazer um contrato, você determina a quantidade de dias para entrega de cada modulo, analisando juntamente com o cliente se é realmente isso que ele quer, se é realmente dessa forma que ele deseja.

mas existem outras maneiras, mas assim iqual falaram, encontrar uma forma exata de dizer que em tal data irá entregar é dificil.

Att
Cleidson Corrêa

Paulo Silveira:

Kanin Dragon:

Me questiono, como vender um projeto para uma grande cia definindo custo e prazo com esse conhecimento empírico :?:

Definir custo e prazo é um tanto duvidoso,a inda mais em um projeto grande, para uma grande companhia. Nao raramente eles falham, estouram prazo, budget e trocam de fornecedor. Acho que deve ser preferivel continuar ser desenvolvedor que tentar inventar estimativas e custos duvidosos, apenas para ganhar um projeto, ja adicionando clausulas draconianas para qualquer mal entendido.

Talvez dizer que nao existe estimativa nenhuma seja demais, mas estimar com essa. Fico bem mais para o lado dos desenvolvedores que dizem ser dificil estimar a medio-logno prazo, e prefiro a abordagem deles de revelar os nomes e sobrenomes, sem usar pseudonimos.

Paulo, até concordo com você. Só que, no entanto, eu devo ressaltar que dificilmente empresas grandes vão aceitar o argumento de “não posso estimar porque o projeto é grande/existem muitos riscos/e por aí vai”. O problema é que se você chega numa empresa e fala isso, eles vão escolher a outra empresa que oferece, de fato, um prazo (ainda que esse prazo seja tão inventado quanto astrologia).

Acho que o ideal é fazer, de fato, uma estimativa, usando quaisquer dessas técnicas (seja APF, PERT/CPM, whatever), e deixar claro pro cliente que, com tais variáveis envolvidas, existe um desvio padrão de X% (note que eu não estou falando de gordura, aqui, isso quer dizer que o projeto pode tanto atrasar quanto adiantar X%. E, mesmo assim, o desvio padrão não contempla todos os casos, afinal, você não pode prever o tempo que vai durar o projeto se cair um meteoro no planeta e a vida acabar).

Na verdade, só o que as pessoas querem é algo em que possam se apoiar para fazer previsões. Afinal de contas, um gerente também não quer chegar no chefe dele e falar “eu não sei quanto tempo o projeto vai durar, mas você tem que confiar em mim que vai durar somente o tempo necessário”. O que as pessoas sabem é que existem chances de coisas darem certo ou errado. Porque dizer, então, que se possui uma estimativa exata quando todos sabem os riscos envolvidos?

[]´s

Será que Gestão do Tempo e Gestão de Custos são realmente a melhor opção ?

Kanin, tem certeza de que é preciso criticar de forma tão dura este artigo? Será que o autor falou besteira mesmo? Vamos a alguns comentários:

• Estimativa não é pode ser exata! Ou é exata ou é estimativa! O próprio artigo fala isso.

• 50 anos de experiência da nossa área tem mostrado que projetos baseados em processos que exigem prazos e custos definidos previamente quase sempre saem mais caros do que deveriam, levam mais tempo do que deveriam e não fazem o que o cliente quer.

• Estimar software é sim um processo empírico. O uso de APF indiscriminadamente acaba superestimando quase sempre. A equipe deve levar em conta sua experiência para ajustar a estimativa.

• Projetos de escopo aberto já são uma realidade. E tem funcionado muito bem. É difícil conseguir mudar a mentalidade? Claro. E O PRÓPRIO ARTIGO FALA SOBRE ISSO!

Kanin, acredito que você acabou extrapolando aqui por impulso. Mas ao falar uma coisa dessas, você passa uma impressão muito ruim. As pessoas que conheço que soltam pérolas dessa costumam:

• sonhar em virar gerentes,(até aqui, no problem)
• Achar que o gerente é o único responsável pelo sucesso do projeto (aqui sim começam os problemas)
• tratar programador como trabalhador braçal
• fugir das responsabilidades, apontar culpados, e usar o trabalho dos outros como se fosse seu
• acreditar piamente que processos e ferramentas são a salvação da lavoura e que o programador tem pouca importancia no processo.
• Atormentar a equipe perguntando a cada 5 minutos se a tarefa está pronta
• marca mais reuniões do que deve, exige mais relatórios do que é aconselhável
• ao invés de remover os impedimentos ao trabalho dos desenvolvedores, pressiona e ua o famoso “te vira”;
• atrapalha mais do que ajuda

Ser gerente de uma equipe não significa mandar nela, mas facilitar a vida dessa equipe. O gerente é um membro, ão o dono.

Você fala como se “programar” fosse um castigo destinado aos incompetentes. Cuidado. Isso, é ofensivo. Existem pessoas que amam programar e tem orgulho disso. Pessoas que querem seguir essa carreira. E muitas dessas pessoas são os melhores profissionais que conheço e que você vai conhecer.

Tem certeza que quer tratar assim seus colegas?

asaudate:

Paulo Silveira:

Kanin Dragon:

Me questiono, como vender um projeto para uma grande cia definindo custo e prazo com esse conhecimento empírico :?:

Definir custo e prazo é um tanto duvidoso,a inda mais em um projeto grande, para uma grande companhia. Nao raramente eles falham, estouram prazo, budget e trocam de fornecedor. Acho que deve ser preferivel continuar ser desenvolvedor que tentar inventar estimativas e custos duvidosos, apenas para ganhar um projeto, ja adicionando clausulas draconianas para qualquer mal entendido.

Talvez dizer que nao existe estimativa nenhuma seja demais, mas estimar com essa. Fico bem mais para o lado dos desenvolvedores que dizem ser dificil estimar a medio-logno prazo, e prefiro a abordagem deles de revelar os nomes e sobrenomes, sem usar pseudonimos.

Paulo, até concordo com você. Só que, no entanto, eu devo ressaltar que dificilmente empresas grandes vão aceitar o argumento de “não posso estimar porque o projeto é grande/existem muitos riscos/e por aí vai”. O problema é que se você chega numa empresa e fala isso, eles vão escolher a outra empresa que oferece, de fato, um prazo (ainda que esse prazo seja tão inventado quanto astrologia).

Acho que o ideal é fazer, de fato, uma estimativa, usando quaisquer dessas técnicas (seja APF, PERT/CPM, whatever), e deixar claro pro cliente que, com tais variáveis envolvidas, existe um desvio padrão de X% (note que eu não estou falando de gordura, aqui, isso quer dizer que o projeto pode tanto atrasar quanto adiantar X%. E, mesmo assim, o desvio padrão não contempla todos os casos, afinal, você não pode prever o tempo que vai durar o projeto se cair um meteoro no planeta e a vida acabar).

Na verdade, só o que as pessoas querem é algo em que possam se apoiar para fazer previsões. Afinal de contas, um gerente também não quer chegar no chefe dele e falar “eu não sei quanto tempo o projeto vai durar, mas você tem que confiar em mim que vai durar somente o tempo necessário”. O que as pessoas sabem é que existem chances de coisas darem certo ou errado. Porque dizer, então, que se possui uma estimativa exata quando todos sabem os riscos envolvidos?

[]´s

oi,

como tudo na vida acho que temos que ter o meio termo

eu também acho impossível vender projetos em grandes empresas sem ter esta “estimativa” de custo e prazo inicial, mesmo que um projeto dure 2 anos

a grande questão é que se vende software como produto, e não como serviço

abs

Kanin Dragon:

Pelo amor de Deus, tive a INFELICIDADE de ler este artigo de estimativa de custo pensando em absolver algo útil, porem me deparei com um verdadeiro BESTEIROL.

Isso foi a gota d agua: “Desenvolvimento de sistemas, ao menos no meu ponto de vista, é algo empírico e pronto! Não acredito numa correta mensuração em um processo empírico e não acho necessário.” … veja mais no link.

Acho que isso nem é artigo, o autor apenas reuniu alguns comentários tirados de outro fórum e resolveu dar o seu pitado.

Outros tem que aprender interpretar o que lêem, o artigo não fala de projetos B2B em nenhum momento.

Acho que estão fazendo uma pequena confusão aqui…

Pode e deve fazer uma estimativa,mas é impossivel prever com exatidão… :roll:

(Se a mãe Dina entra nessa área,ficara rica)… :roll:

rmendes08:

Leonardo Gaona:

Eu acho sim possível estimar custo e prazo independente do tamanho do projeto.

PMBOK está ai pra isso, existe uma cacetada de processos e metodologias para auxiliar o GP. Análises PERT por exemplo. E claro, sempre ter uma opinião especializada sobre o assunto (o próprio desenvolvedor).

Sim, o PMBOK está aí, cada vez mais dividindo espaço com o Scrum. Talvez porque entregas rápidas estejam gerando mais resultado do que longos meses de planejamento.

Você pode muito bem utilizar práticas do PMBOK Guide em conjunto com SCRUM. Não são metodologias “concorrentes”…

O SCRUM é um framework que pode ser muito bem utilizado seguindo as práticas do PMBOK Guide. Sem falar que segundo estimativas do próprio pessoal do SCRUM, 98% das empresas pensam que usam o SCRUM da forma correta.

Anime:

Leonardo Gaona:

Eu acho sim possível estimar custo e prazo independente do tamanho do projeto.

PMBOK está ai pra isso, existe uma cacetada de processos e metodologias para auxiliar o GP. Análises PERT por exemplo. E claro, sempre ter uma opinião especializada sobre o assunto (o próprio desenvolvedor).

Então pode estimar…Isso significa que não pode ter exatidão…

Mas é pra isso mesmo que existe a gerência de projetos. Estimar com mais precisão do que apenas um chutômetro baseado em conhecimento de projetos passados. Estimativas 100% precisas são impossíveis, a menos que o seu GP seja o Walter Mercado, a Mae Diná ou algum outro vidente em um momento inspirado.

Se em projetos de curto prazo podem ocorrer n fatores que atrasem o cronograma do projeto, a longo prazo esse risco pode ser exponencialmente maior. E o próprio PMBOK Guide aborda isso. Gerenciamento dos riscos é um processo muito importante.

Qualquer chute de tempo/custo antes de se ter uma EAP e o escopo completo e assinado é chamado de Estimativa de Ordem de Grandeza, onde se pode variar pra -50% a +50%

Anime:

Acho que estão fazendo uma pequena confusão aqui…

Pode e deve fazer uma estimativa,mas é impossivel prever com exatidão… :roll:

(Se a mãe Dina entra nessa área,ficara rica)… :roll:

Sim, é impossível prever com exatidão (por isso mesmo estimativa)

Mas na maioria dos “grandes projetos” das “grandes empresas” das “grandes consultorias” você tem uma data para o sistema entrar em testes, outra para entrar em homologação, outra pra entrar em produção, outra pra entrega da documentação, etc… (ou seja, tenta-se prever com exatidão)

E sim, eu trabalho com MS project e todas estas datas estão lá em algum lugar do futuro…

Se tiver alguém aqui que trabalha em uma empresa com mais de 5 mil funcionários e atendida por algumas dezenas de consultorias vendendo projetos o tempo todo e não passa por isso que atire a primeira pedra…

edit: concordo com você Leonardo

Estimativa de risco é o termo que deve ser muito bem pensado e desenvolvido, inclusive ele está contido na elaboração do cronograma e também do orçamento certo?

Conheço muito pouco do PMBox, mas pelo que tenho visto ele pode sim ajudar bastante quando usado dentro do contexto apropriado

Não estou sabendo me expressar… :roll: Claro que existe prazo,data…Nunca falei em chutômetro,até por que não conhecia essa palavra… :roll:

Obs:Toda vez que faço uma brincadeira com a mãe Dina,vem alguém e fala … :?

Eu concordo… mas a questão é justo essa. Eu nao encaro mais emrpesas grandes que so queiram trabalhar assim. Prefiro nem epgar o cliente do que ter uma relacao de eterna briga com ele.

Anime:

Não estou sabendo me expressar… :roll: Claro que existe prazo,data…Nunca falei em chutômetro,até por que não conhecia essa palavra… :roll:

Obs:Toda vez que faço uma brincadeira com a mãe Dina,vem alguém e fala … :?

Estimativa pra mim é na base do chutômetro, por isso concordo plenamente com o autor do artigo.

Paulo Silveira:

asaudate:

Paulo, até concordo com você. Só que, no entanto, eu devo ressaltar que dificilmente empresas grandes vão aceitar o argumento de “não posso estimar porque o projeto é grande/existem muitos riscos/e por aí vai”. O problema é que se você chega numa empresa e fala isso, eles vão escolher a outra empresa que oferece, de fato, um prazo (ainda que esse prazo seja tão inventado quanto astrologia).

Eu concordo… mas a questão é justo essa. Eu nao encaro mais emrpesas grandes que so queiram trabalhar assim. Prefiro nem epgar o cliente do que ter uma relacao de eterna briga com ele.

Entendo que estimativa é importante para a empresa e seus processos, mas não para o desenvolvimento do software em si, quem tiver a oportunidade de separar as duas coisas terá mais chance de sucesso (e consequente menos dor de cabeça!).

Enfim, acho que esse foi o ponto que o autor do artigo tentou passar, que em software só se sabe quanto tempo algo vai levar pra fazer se este algo for realmente feito.

Paulo, sem duvida definir custo e prazo é algo muito complicado, mas não podemos dizer que é possível fazer isso utilizando conhecimento empírico.

Esta tarefa deve ser designada aos gestores que utilizarão técnicas para mensurar o tamanho e custo do projeto de forma a adequar as expectativas dos usuários ao orçamento existente, assim é feito em qualquer CIA minimamente séria, ou seja os projetos (qualquer que sejam inclusive os de TI) devem estar alinhados como as estratégias de crescimento da empresa e ao orçamento disponível para tal, é inconcebível para uma grande CIA iniciar um projeto sem ter a estimativa de custo/prazo, isso seria o mesmo que iniciar algo que não sabemos bem o que é nem onde terminará.

Hoje área de TI é parte estratégica de qualquer empresa e atrasos podem gerar grandes prejuízos financeiros que comprometerá toda sua estratégia de crescimento.

Paulo, neste caso fico do lado dos executivos das empresas que dizem ser díficil administrar sem saber a médio e longo o quanto do capital da empresa estará em risco nos projetos.

Anime, usando sua afirmação o cliente também pode ser honesto com você e responder que senão houver controle nos projetos não tem como gerir a empresa e decidir contratar algum concorrente que possa agregar valor em seus projetos minizando riscos e passando estimativas confiáveis, dando previsibilidade para que o cliente possa executar seu plano crescimento ao lado de um parceiro de TI que entenda essa necessidade e seja um agente que promova soluções e não ser mais um problema a ser administrado.

Fazendo uma analogia se você fosse reformar a sua casa contrataria o pedreiro por empreitada ou pagaria por dia?

O que você citou apenas isenta a responsabilidade da consultoria sobre o prazo do projeto e dessa forma “empurrar” todo o problema gerencial de controle do projeto para o cliente.

Josenaldo , tudo isso que você escreveu a única coisa que devo ressaltar, são as desculpas a quem se sentiu ofendido e frustrado.

marcosvinicius.rj, primeiramente bem vindo, realmente o artigo não fala de B2B, porem quando falamos de prazos e custos estamos falando de empresariais, eu nunca estimei custos e prazos para desenvolver em casa, se bem que não seria uma prática ruim.

Pessoal, são por esses motivos que a engenharia de software está atrás das outras engenharias (civil, mecânica, etc.). Quando você constrói uma casa os engenheiros e arquitetos criam um projeto estimam prazo e custo para execução, e caso não aconteça nenhuma catastrofe natural os projetos são entregues de acordo com as estimativas iniciais, claro se considerarmos os profissionais sérios do mercado, não os aventureiros.

Infelizmente a maioria dos profissionais de TI mal utilizam diagramas e especificações para orientar o desenvolvimento, pior ainda se considerar aqueles que usam essa documentação como projeto para as aplicações e preocupan-se somente com a tecnologia (JAVA no caso). Seriam os pedreiros da construção civil que ao construirem uma parade não conseguem enxergar o projeto todo, de veriamos sim agir como engenheiros ou cientistas preocupando-nos com gestão de projeto, metodologia, ferramentas, elaborando projetos sérios para nossos clientes.

malconL:

Anime:

Não estou sabendo me expressar… :roll: Claro que existe prazo,data…Nunca falei em chutômetro,até por que não conhecia essa palavra… :roll:

Obs:Toda vez que faço uma brincadeira com a mãe Dina,vem alguém e fala … :?

Estimativa pra mim é na base do chutômetro, por isso concordo plenamente com o autor do artigo.

sem comentários

Paulo, sem duvida definir custo e prazo é algo muito complicado, mas não podemos dizer que é possível fazer isso utilizando conhecimento empírico.

Esta tarefa deve ser designada aos gestores que utilizarão técnicas para mensurar o tamanho e custo do projeto de forma a adequar as expectativas dos usuários ao orçamento existente, assim é feito em qualquer CIA minimamente séria, ou seja os projetos (qualquer que sejam inclusive os de TI) devem estar alinhados como as estratégias de crescimento da empresa e ao orçamento disponível para tal, é inconcebível para uma grande CIA iniciar um projeto sem ter a estimativa de custo/prazo, isso seria o mesmo que iniciar algo que não sabemos bem o que é nem onde terminará.

Hoje área de TI é parte estratégica de qualquer empresa e atrasos podem gerar grandes prejuízos financeiros que comprometerá toda sua estratégia de crescimento.

Paulo, neste caso fico do lado dos executivos das empresas que dizem ser díficil administrar sem saber a médio e longo o quanto do capital da empresa estará em risco nos projetos.

Anime, usando sua afirmação o cliente também pode ser honesto com você e responder que senão houver controle nos projetos não tem como gerir a empresa e decidir contratar algum concorrente que possa agregar valor em seus projetos minizando riscos e passando estimativas confiáveis, dando previsibilidade para que o cliente possa executar seu plano crescimento ao lado de um parceiro de TI que entenda essa necessidade e seja um agente que promova soluções e não ser mais um problema a ser administrado.

Fazendo uma analogia se você fosse reformar a sua casa contrataria o pedreiro por empreitada ou pagaria por dia?

O que você citou apenas isenta a responsabilidade da consultoria sobre o prazo do projeto e dessa forma “empurrar” todo o problema gerencial de controle do projeto para o cliente.

Josenaldo , tudo isso que você escreveu a única coisa que devo ressaltar, são as desculpas a quem se sentiu ofendido e frustrado.

marcosvinicius.rj, primeiramente bem vindo, realmente o artigo não fala de B2B, porem quando falamos de prazos e custos estamos falando de empresariais, eu nunca estimei custos e prazos para desenvolver em casa, se bem que não seria uma prática ruim.

Pessoal, são por esses motivos que a engenharia de software está atrás das outras engenharias (civil, mecânica, etc.). Quando você constrói uma casa os engenheiros e arquitetos criam um projeto estimam prazo e custo para execução, e caso não aconteça nenhuma catastrofe natural os projetos são entregues de acordo com as estimativas iniciais, claro se considerarmos os profissionais sérios do mercado, não os aventureiros.

Infelizmente a maioria dos profissionais de TI mal utilizam diagramas e especificações para orientar o desenvolvimento, pior ainda se considerar aqueles que usam essa documentação como projeto para as aplicações e preocupan-se somente com a tecnologia (JAVA no caso). Seriam os pedreiros da construção civil que ao construirem uma parade não conseguem enxergar o projeto todo, de veriamos sim agir como engenheiros ou cientistas preocupando-nos com gestão de projeto, metodologia, ferramentas, elaborando projetos sérios para nossos clientes.

Concordo plenamente com o Kainin Dragon, pois definir custo/prazo de projetos no chutometro e no conhecimento empirico é coisa de “POGUEIRO”, para iniciar um projeto o minimo que se espera é organização e planejamento.

malconL:

Anime:

Não estou sabendo me expressar… :roll: Claro que existe prazo,data…Nunca falei em chutômetro,até por que não conhecia essa palavra… :roll:

Obs:Toda vez que faço uma brincadeira com a mãe Dina,vem alguém e fala … :?

Estimativa pra mim é na base do chutômetro, por isso concordo plenamente com o autor do artigo.

Deus do céu…

Digno do título do tópico

Leonardo Gaona:

malconL:

Anime:

Não estou sabendo me expressar… :roll: Claro que existe prazo,data…Nunca falei em chutômetro,até por que não conhecia essa palavra… :roll:

Obs:Toda vez que faço uma brincadeira com a mãe Dina,vem alguém e fala … :?

Estimativa pra mim é na base do chutômetro, por isso concordo plenamente com o autor do artigo.

Deus do céu…

Digno do título do tópico :D

Então vc inventou o chutômetro e o pessoal gostou…rsrs… :roll:

Bom, o artigo me pareceu bem imparcial em relação ao assunto e até levantou questões que aqui foram levantadas novamente… O que dá a entender é que alguns simplesmente não entendem o atigo e lançam pérolas…

Outro fator que deve ser levado em consideração, é como o assunto estava sendo discutido no Tectura e como cada um viveu experiências na área…

Algo que funciona com A, nem sempre funciona com B… Temos tantas variáveis dentro desse cenário que é muito fácil querer aplicar conceitos como algo único e verdadeiro…

Hoje estou numa empresa que determinou Projeto de Escopo fechado… O Projeto já está atrasado em 2 anos, a margem de erro eram 2 meses… Porém, o cliente não ajuda, greves de trabalhadores, má vontade dos gestores em homologar e implantar o Sistema, etc. Tudo isso são fatore não previsíveis, pois quando o mesmo Projeto começou, era tapinha nas costas de todos os lados… Logo, eu acredito que um Escopo aberto aqui funcionaria melhor… Porém, eles queriam definição de prazos e custos…

Já, outras pessoas aqui, podem ter se dado bem com a abordagem… e aí ??? quem sou eu pra dizer que não…

Prefiro me guiar pelo que o Paulo disse… Correrei atrás de clientes que entendam as vantagens do escopo aberto e negarei os que não aceitarem pelo menos tentar… O motivo ??? Simples, saberei se estou trabalhando com quer Projeto entregue e entende que isso esbarra em fatores de risco (sendo o maior deles, o humano) ou quem quer tirar o seu da reta e empurrar a bronca no rb de alguém de menor escalão. Esse último, pode até não ser, mas minha pouca experiência até agora só me deu 100% de certeza…

Abs []

Leonardo Gaona:

malconL:

Anime:

Não estou sabendo me expressar… :roll: Claro que existe prazo,data…Nunca falei em chutômetro,até por que não conhecia essa palavra… :roll:

Obs:Toda vez que faço uma brincadeira com a mãe Dina,vem alguém e fala … :?

Estimativa pra mim é na base do chutômetro, por isso concordo plenamente com o autor do artigo.

Deus do céu…

Digno do título do tópico :D

Nada contra usar PBOK ou seja lá o que for… se vc é pago pra fazer estimativas…

adriano_si:

Bom, o artigo me pareceu bem imparcial em relação ao assunto e até levantou questões que aqui foram levantadas novamente… O que dá a entender é que alguns simplesmente não entendem o atigo e lançam pérolas…

Outro fator que deve ser levado em consideração, é como o assunto estava sendo discutido no Tectura e como cada um viveu experiências na área…

Algo que funciona com A, nem sempre funciona com B… Temos tantas variáveis dentro desse cenário que é muito fácil querer aplicar conceitos como algo único e verdadeiro…

Hoje estou numa empresa que determinou Projeto de Escopo fechado… O Projeto já está atrasado em 2 anos, a margem de erro eram 2 meses… Porém, o cliente não ajuda, greves de trabalhadores, má vontade dos gestores em homologar e implantar o Sistema, etc. Tudo isso são fatore não previsíveis, pois quando o mesmo Projeto começou, era tapinha nas costas de todos os lados… Logo, eu acredito que um Escopo aberto aqui funcionaria melhor… Porém, eles queriam definição de prazos e custos…

Já, outras pessoas aqui, podem ter se dado bem com a abordagem… e aí ??? quem sou eu pra dizer que não…

Prefiro me guiar pelo que o Paulo disse… Correrei atrás de clientes que entendam as vantagens do escopo aberto e negarei os que não aceitarem pelo menos tentar… O motivo ??? Simples, saberei se estou trabalhando com quer Projeto entregue e entende que isso esbarra em fatores de risco (sendo o maior deles, o humano) ou quem quer tirar o seu da reta e empurrar a bronca no rb de alguém de menor escalão. Esse último, pode até não ser, mas minha pouca experiência até agora só me deu 100% de certeza…

Abs []

Primeiramente Olá Adriano,

Acho que o conceito de escopo aberto está um pouco perdido nessa discussão, o fato de ter um escopo aberto não quer dizer que não existe estimativa de custo e prazo no projeto, isso implica em dizer que o projeto como um todo tem um escopo variável e que esse escopo é dividido em entregas(Milestone, releases o que você quiser chamar…) só que cada entrega tem um escopo menor e acima de tudo é um sistema funcional e usavel. O Scrum por exemplo define a Sprint (Isso não seria considerado uma estimativa de tempo?) o XP por sua vez define que existem 4 variáveis, TEMPO, CUSTO, ESCOPO e QUALIDADE.

O que eu quis dizer no final das contas é que sendo Escopo aberto ou Fechado existe sim a necessidade de ser um planejamento (Inicial e por sua vez variável) de custo e prazo.

É difícil imaginar uma empresa (qualquer que seja seu tamanho) que não se preocupe com o ROI (Return On Investment)…

Precisamos de uma visão mais sistêmica (http://pt.wikipedia.org/wiki/Visão_sistêmica).

Qual será o ROI de um projeto de escopo aberto?

Corremos o risco de enfrentar os mesmos problemas, porém nos isentando (desenvolvedores) da responsabilidade pelo resultado final (o mais importante num projeto).

Valeu Kanin Dragon! Precisamos de “questionadores”!

Realmente relendo, me expressei mal em relação ao escopo aberto… Sei como funciona e sei que prazos e custos também devem ser medidos, afinal você não pode usar o chute como base também…

Aqui o Projeto precisava de 1 PRAZO e 1 CUSTO… foi nesse sentido que achei que o Escopo aberto seria mais viável…

Valew pelo detalhamento.

Abs []

Olá Adriano, teu motivo não é contestavel em relação ao seu apoio a opnião do Paulo, ja o Leonardo descreveu realmente algo que condiz com o que o Kanim Dragon devende desdo inicio do Post.

Apoio o Kanin nessa! pois, dentre as empresas onde trabalhei nunca em nenhum projeto, ocorreu chutometro na gestão de um projeto, mas sim Pontos veridicos tantos de fatores de risco quanto de fatores a “favor do projeto”.

Quem foi que disse que waterfall estava morto? rs

Ninguem, infelizmente.

rcviana:

É difícil imaginar uma empresa (qualquer que seja seu tamanho) que não se preocupe com o ROI (Return On Investment)…

Precisamos de uma visão mais sistêmica (http://pt.wikipedia.org/wiki/Visão_sistêmica).

Qual será o ROI de um projeto de escopo aberto?

Corremos o risco de enfrentar os mesmos problemas, porém nos isentando (desenvolvedores) da responsabilidade pelo resultado final (o mais importante num projeto).

Valeu Kanin Dragon! Precisamos de “questionadores”!

Perfeito cara, o Kanin levantou muito bem a questão…

A minha dúvida que ficou é a seguinte: você acha que o escopo aberto não te trás ROI ???

Até onde sei, perceba que aqui é minha falha, escopo aberto tem o Objetivo de quebrar o prazo e o escopo em pedaços menores a fim de dar ao cliente Software Usável em pouco tempo… Justamente sem as “gorduras” que estão citadas pelo Rubem no artigo… Isso pra mim traz um grande benefício:

• Se o cliente não gostar do teu trabalho, ele pode mudar, se ele não foi com a tua cara, se ele não gostou da qualidade do Produto, se ele acordou azedo no dia e decide que não quer mais Software… Enfim…

Esse tipo de pensamento assusta Muitas pessoas da TI, pois não entendem que esse risco é quase 0 e quando você faz Software de Qualidade e que funcione, o cliente vai querer você pra prestar o serviço, gerando mais e mais ROIs pra tí e pra ele…

Outro dia conversando com um gerente aqui o mesmo ficou espantado ao saber que fizemos um Projeto que foi estimado em 1 ano e foi entregue em 8 meses… Ele achou um absurdo e perguntou se mesmo assim cobramos pelos 12 meses do escopo… Nós dissemos que não, e ele usou a palavra “burros” pra dizer que estávamos perdendo dinheiro…

Pois bem, nosso projeto nos rendeu mais 2 indicações de Projetos, que mesmo tendo seu Escopo “Fechado” procuramos fazer ele de forma aberta ao Cliente (não sei se fui claro aqui, pois são cláusulas contratuais mesmo) e se tivéssemos esperado bater os 12 meses, a equipe ainda estaria terminando de entregar o Software… Ou seja, estaríamos alocados, totalmente sem necessidade, tudo porque o escopo foi fechado em 12 meses…

Perceba que NÃO digo que isso é a REALIDADE de todos aqui, mas é esse tipo de pensamento que vejo quando alguém define um Prazo de um Projeto com base em métricas irreais… Lembrem, temos o fator humano e humanos adoecem, humanos caem em depressão, humanos acordam bem em um dia e péssimos em outro, humanos passam por problemas familiares e humanos decidem seguir outros rumos… Não adianta considerar pessoas como recursos, não adianta colocar mais gente (exemplo das 9 mulheres fazendo 1 filho em 1 mês), não adianta tentar prever, só podemos estimar…

E embora tenha uma série de artigos e métricas acadêmicas, eu nunca ví nada igual ao que fazemos hoje com nossos Projetos novos. Definimos prazos curtos de pequenas entregas e definimos um Prazo maior, se conseguirmos (mesmo com os problemas citados acima) entregar 1 só dos escopos e o cliente já ter um SOftware Funcional… cara, tens que ver a alegria que o mesmo fica, vendo que não está sendo enrolado, sabendo que os 12 meses podem se transformar em 8… e melhor ainda, que se isso acontecer ele só vai pagar os 8… Muda o clima, o cara te ajuda, o cara te indica, o cara vira teu amigo…

Já a realidade da empresa para a qual presto consultoria… é TI X Cliente, um querendo ferrar o outro… PERCEBAM, antes que eu seja apedrejado, não estou dizendo que é culpa da metodologia utilizada, mas afirmo com 100% de certeza que é culpa da Mentalidade… Aquela que o Josenaldo destacou no início do tópico…

Abs []

Olá Adriano, teu motivo não é contestavel em relação ao seu apoio a opnião do Paulo, ja o Leonardo descreveu realmente algo que condiz com o que o Kanim Dragon devende desdo inicio do Post.

Apoio o Kanin nessa! pois, dentre as empresas onde trabalhei nunca em nenhum projeto, ocorreu chutometro na gestão de um projeto, mas sim Pontos veridicos tantos de fatores de risco quanto de fatores a “favor do projeto”.

Fala Saulo… perceba que em nenhum momento discordo do Kanim, e se você ler meus POSTS ainda declaro que não sei se estou certo quanto ao uso… Tudo o que coloquei foi com base em minhas experiências… Acho que levantar a questão é completamente válido e sadio… Mas precisamos ter cuidado ao analisar alguns pontos, pois a relatividade impera e como disse nesse POST que você me citou, muitas vezes o que coube bem em A, nem passará pela cabeça de B…

Abs []

Curioso como a maioria aqui do GUJ pensa que o negócio de software se resume a serviços de consultoria.

Fica um recado para outros, que como eu, gostam de criar soluções: Existem outras maneiras de pentear o macaco, basta um pouco de criatividade!

malconL:

adriano_si:

Aqui o Projeto precisava de 1 PRAZO e 1 CUSTO… foi nesse sentido que achei que o Escopo aberto seria mais viável…

Quem foi que disse que waterfall estava morto? rs

Obrigado pela participação, sem você a discussão não seria a mesma.

Olá Adriano, teu motivo não é contestavel em relação ao seu apoio a opnião do Paulo, ja o Leonardo descreveu realmente algo que condiz com o que o Kanim Dragon devende desdo inicio do Post.

Apoio o Kanin nessa! pois, dentre as empresas onde trabalhei nunca em nenhum projeto, ocorreu chutometro na gestão de um projeto, mas sim Pontos veridicos tantos de fatores de risco quanto de fatores a “favor do projeto”.

Fala Saulo… perceba que em nenhum momento discordo do Kanim, e se você ler meus POSTS ainda declaro que não sei se estou certo quanto ao uso… Tudo o que coloquei foi com base em minhas experiências… Acho que levantar a questão é completamente válido e sadio… Mas precisamos ter cuidado ao analisar alguns pontos, pois a relatividade impera e como disse nesse POST que você me citou, muitas vezes o que coube bem em A, nem passará pela cabeça de B…

Abs []

Agora condordo com vc.

[]s

Valeu adriano_si !

A pergunta não foi se trás ou não, mas qual.

Se conseguirmos responder essa pergunta (qual) provavelmente estaremos estimando…

Abs.

PS: Kanin Dragon, vc está no twitter?

malconL:

Curioso como a maioria aqui do GUJ pensa que o negócio de software se resume a serviços de consultoria.

Fica um recado para outros, que como eu, gostam de criar soluções: Existem outras maneiras de pentear o macaco, basta um pouco de criatividade!

Hauauahauahuaahuahauahu… mas cara… isso foi uma mentalidade que foi enraizada na nossa mente…

Lembro das minha primeiras aulas de Engenharia de Software, que dizia que a mesma tinha surgido porque mais 80% (não lembro bem o valor) dos Projetos de Software atrasavam… Quando entrei no mercado, percebí que os mesmos percentuais continuavam reais, comecei a buscar e percebi que não é a Engenharia de Software que não presta, não é o PMBOK, não é o Scrum… Isso, como diz um colega de trabalho, “foi inventado por alguém pra ganhar dinheiro com ele” heueheueheueeuhue… Eu concordo com ele pela brincadeira é claro, mas as vezes é o que dá pra entender… ele me apresentou pessoas que trabalharam com ele na época do Cobol, tanto clientes quanto funcionários, e dos 6 - 7 que já conhecí, todos falam a mesma coisa, esse cara só entregava Projeto certo e no Prazo… Daí ele tirava onda comigo, na brincadeira é claro, que esse pessoal novo que conhece Java, não entende o que é isso…

Eu concordo um pouco com ele, pois não interessa a era, não interessa a forma e não interessa como… o que importa, e isso o cliente enxerga, é entregar certo e no prazo…

Abs []

Não sou contra planejamento,mas acho que esse pessoal que pensa que é assim e pronto,só porque tem uma técnica para isso,nunca pegou um projeto (médio) para fazer sozinho…

Qual o problema nisso?

rcviana:

A pergunta não foi se trás ou não, mas qual.

Se conseguirmos responder essa pergunta (qual) provavelmente estaremos estimando…

Não sei se entendi sua pergunta… e agora me preocupei se entendi bem tbm o seu primeiro POST… heueheueheueheu

Você quer saber qual ROI você obtém como Prestador de Serviços, ou qual ROI o seu cliente Obtém com o Serviço ???

Acho que nas duas hipóteses, não daria pra entrar em contato com alguém que já trabalhou assim ??

Sei te falar de cara os benefícios, como citei aí pra cima nos POSTs… Agora o ROI, realmente teria que medir e acho que não sou a pessoa mais indicada pra isso…

Abs []

Qual o problema nisso?

Programar por Hobbie pelo resto da vida vc ate pode, não estou discriminando a profissão, fui desenvolvedor um bom tempo, porem se vc é um profissional que esta acomodado com sua posição de desenvolvedor, querendo isso pro resto da sua vida, e esta feliz com isso, boa sorte!!!

Kanin Dragon:

esta acomodado com sua posição de desenvolvedor, querendo isso pro resto da sua vida, e esta feliz com isso, boa sorte!!!

:shock:

Um desenvolvedor não pode ser reconhecido pelo seu trabalho,experiência e crescer profissionalmente…

Não acredito que li isso.

Anime:

Kanin Dragon:

esta acomodado com sua posição de desenvolvedor, querendo isso pro resto da sua vida, e esta feliz com isso, boa sorte!!!

:shock:

Um desenvolvedor não pode ser reconhecido pelo seu trabalho,experiência e crescer profissionalmente…

Não acredito que li isso.

Acho que pra ele o próximo passo na carreira evolutiva do desenvolvedor é ser gerente, por isso a importância de estimativas.

Num futuro onde as empresas vão passar a consumir cada vez mais software pronto (ao invés de desenvolvimento in-house), boa sorte pra ele!

Kanin Dragon:

Programar por Hobbie pelo resto da vida vc ate pode, não estou discriminando a profissão, fui desenvolvedor um bom tempo, porem se vc é um profissional que esta acomodado com sua posição de desenvolvedor, querendo isso pro resto da sua vida, e esta feliz com isso, boa sorte!!!

Cara… eu não tenho menor interesse de sair da Programação… Se Deus quiser em breve minha empresa estará na ativa, sei que vou ter que aprender conceitos de Marketing e Administração, essas coisas mais gerenciais, mas não pretendo sair da área técnica não…

Não vejo mal nenhum nisso e permanecer pra sempre como um Programador não quer dizer que você não evoluiu, ao contrário, quer dizer que você será um Programador muito melhor do que já foi…

Não sei como você vive o mercado, mas empresas hoje estão mudando esse conceito de que para crescer, a pessoa precisa se tornar Analista, Gerente Júnior, Gerente de Projetos, etc… Eu presto consultoria pra uma empresa que tem carreira em Y, ou seja, há técnicos ganhando o mesmo que Gerentes de Projetos, pelo simples motivo, Perfil…

Não pense que ser Analista é uma evolução do Programador, até porque nessa daí eu já ví cada bizarrice… Pra te ser sincero, EU ACHO que o mundo seria melhor se cada “Analista”, um dia tivesse sido um cara bom em Programação, porque os últimos Experts que se achavam o suprasumo da inteligência, enquanto o Programador era a “RALÉ”, eram uns verdadeiros lixos como Profissionais… Pelo jeito, você seguiu bem o caminho na TI e pretende ser um Gerente… Parabéns cara, agora como o josenaldo lhe falou, não desdenhe seus Técnicos, eles são o motor da sua empresa e lá no lugarzinho “insignificante” deles, podem entender mais do negócio do que seus melhores “Analistas”…

Abs []

Anime:

Kanin Dragon:

esta acomodado com sua posição de desenvolvedor, querendo isso pro resto da sua vida, e esta feliz com isso, boa sorte!!!

:shock:

Um desenvolvedor não pode ser reconhecido pelo seu trabalho,experiência e crescer profissionalmente…

Não acredito que li isso.

Como desenvolvedor você pode sim crescer profissionalmente mas para os lados, afinal oque vem depois de “Desenvolvedor Senior” ?

Querendo ou não você vai estar acomodado, vai estár em uma posição que a única coisa que vai crescer e seu sálario.

Kanin Dragon:

Como desenvolvedor você pode sim crescer profissionalmente mas para os lados, afinal oque vem depois de “Desenvolvedor Senior” ?

Querendo ou não você vai estar acomodado, vai estár em uma posição que a única coisa que vai crescer e seu sálario.

Não entendi,ou será que entendi,mas não quero comentar… :roll:

malconL:

Anime:

Kanin Dragon:

esta acomodado com sua posição de desenvolvedor, querendo isso pro resto da sua vida, e esta feliz com isso, boa sorte!!!

:shock:

Um desenvolvedor não pode ser reconhecido pelo seu trabalho,experiência e crescer profissionalmente…

Não acredito que li isso.

Acho que pra ele o próximo passo na carreira evolutiva do desenvolvedor é ser gerente, por isso a importância de estimativas.

Num futuro onde as empresas vão passar a consumir cada vez mais software pronto (ao invés de desenvolvimento in-house), boa sorte pra ele!

Errado, não penso que você precise virar um gerente para chegar ao topo da piramede, eu mesmo não optei pela carreira de gerencia e não pretendo seguir esse caminho.

Em relação a estimativas acho que não precisa ser um gerente para perceber sua importancia, prós e contras.

Sempre gostei de programar porisso me tornei um arquiteto porque e uma forma de sempre manter contato com a área tecnica.

Kanin Dragon:

Anime:

Kanin Dragon:

esta acomodado com sua posição de desenvolvedor, querendo isso pro resto da sua vida, e esta feliz com isso, boa sorte!!!

:shock:

Um desenvolvedor não pode ser reconhecido pelo seu trabalho,experiência e crescer profissionalmente…

Não acredito que li isso.

Como desenvolvedor você pode sim crescer profissionalmente mas para os lados, afinal oque vem depois de “Desenvolvedor Senior” ?

Querendo ou não você vai estar acomodado, vai estár em uma posição que a única coisa que vai crescer e seu sálario.

Quer dizer então que um advogado não pode ser advogado a vida toda ? Necessariamente ele precisa virar juiz ? Ou um médico ? Um médico não pode ser médico a vida toda ?

leonardom.pessoa:

malconL:

adriano_si:

Aqui o Projeto precisava de 1 PRAZO e 1 CUSTO… foi nesse sentido que achei que o Escopo aberto seria mais viável…

Quem foi que disse que waterfall estava morto? rs

Obrigado pela participação, sem você a discussão não seria a mesma.

Eu vou continuar usando agile nos meus projetos, mas uma coisa precisamos reconhecer, uma consultoria que usa agile é melhor nem anunciar o que usa, porque corre o risco de perder o cliente.

Mas é aquela coisa, quem quer continuar a enganar a si mesmo e esperar um cliente clamando por XP ou Scrum cair do céu, beleza.

Kanin Dragon:

Como desenvolvedor você pode sim crescer profissionalmente mas para os lados, afinal oque vem depois de “Desenvolvedor Senior” ?
Querendo ou não você vai estar acomodado, vai estár em uma posição que a única coisa que vai crescer e seu sálario.

Kanin Dragon:

Errado, não penso que você precise virar um gerente para chegar ao topo da piramede, eu mesmo não optei pela carreira de gerencia e não pretendo seguir esse caminho.
Sempre gostei de programar porisso me tornei um arquiteto porque e uma forma de sempre manter contato com a área tecnica.

Opa… desculpe se entendi errado sua intenção…

Abs []

Calma pinto… é a opnião dele, que acho que foi até refutada depois…

Não podemos nos condenar se não nos conhecemos como Profissionais… Aqui são opniões das mais variadas… Se você sabe que não é assim, relaxe, ignore, saia do tópico… Mas sem ofensas…

NO STRESS… 8)

pinto:

Kanin Dragon:

Como desenvolvedor você pode sim crescer profissionalmente mas para os lados, afinal oque vem depois de “Desenvolvedor Senior” ?
Querendo ou não você vai estar acomodado, vai estár em uma posição que a única coisa que vai crescer e seu sálario.

Cara, eu estava tentando evitar, mas devido ao seu desrespeito para com a categoria e as pessoas e suas opções, e à sua insistência em ser preconceituoso e arrogante, tenho que dizer que o seu crescimento profissional tambem está bem definido: ou é ou será uma merda de líder, e nunca vai ter o respeito dos seus subordinados.

Pelo menos ele será um líder que dará prazos para cumprirem as ordens. :twisted:

Verdade, eu engordei uns 20 kg nos ultimos anos…

pinto:

Kanin Dragon:

Como desenvolvedor você pode sim crescer profissionalmente mas para os lados, afinal oque vem depois de “Desenvolvedor Senior” ?
Querendo ou não você vai estar acomodado, vai estár em uma posição que a única coisa que vai crescer e seu sálario.

Cara, eu estava tentando evitar, mas devido ao seu desrespeito para com a categoria e as pessoas e suas opções, e à sua insistência em ser preconceituoso e arrogante, tenho que dizer que o seu crescimento profissional tambem está bem definido: ou é ou será uma merda de líder, e nunca vai ter o respeito dos seus subordinados.

Calma Jovem,

Não ofendi ninguém, simplemente informei minha ideia de crescimento profissional, que não necessariamente ea mesma idéia das outras pessoas porisso existe o forum para debatar cada um com sua opinião, pesso desculpas para os outros usuário se acabei sendo arrogante mas não foi minha intenção acho que acabei me expressando mal ou as pessoas me interpretaram mau.

Pinto, em relação a respeito ou não da minha equipe não irei debater aqui porque não e da sua conta.

rmendes08:

Kanin Dragon:

Anime:

Kanin Dragon:

esta acomodado com sua posição de desenvolvedor, querendo isso pro resto da sua vida, e esta feliz com isso, boa sorte!!!

:shock:

Um desenvolvedor não pode ser reconhecido pelo seu trabalho,experiência e crescer profissionalmente…

Não acredito que li isso.

Como desenvolvedor você pode sim crescer profissionalmente mas para os lados, afinal oque vem depois de “Desenvolvedor Senior” ?

Querendo ou não você vai estar acomodado, vai estár em uma posição que a única coisa que vai crescer e seu sálario.

Quer dizer então que um advogado não pode ser advogado a vida toda ? Necessariamente ele precisa virar juiz ? Ou um médico ? Um médico não pode ser médico a vida toda ?

Sim pode ser um médico pelo resto da vida, pode ser um advogado pelo resto da vida, um padeiro e etc…

Mas como advogado no meu caso de virar um promotor e depois um juiz, como médico gostaria de coordenar uma equipe médica e depois abrir uma clínica e administra-la, isso vai de cada um.

Gosto mais dessas carreiras em Y
onde eu posso escolher pra onde crescer

tipo ser um programador o resto da vida, nao quer dizer que voce vai ser um “programador” o resto da vida

mas é mesma coisa de dizer que todos os analistas precisam ser antes programadores
ou que um analista obrigatoriamente ganha mais que um programador pois é um passo alem da profissão

sei lá, meio controverso, mas eu vejo muita gente que ve assim tambem…

mas não posso negar que é um ponto de vista

Galera,
não quero mudar o foco do assunto, apenas citei o meu ponto de vista a respeito do plano de carreira. Isso é relativo de cada um e não estou dizendo
que desenvolvedor é ruim, mas creio que a grande maioria quer evoluir na carreira. Os profissionais que se identifica com a parte técnica pretende se tornar especialista
ou arquiteto e assim por diante.

Esta discussão esta fugindo do tópico em questão.

Kanin Dragon:

Sim pode ser um médico pelo resto da vida, pode ser um advogado pelo resto da vida, um padeiro e etc…

Mas como advogado no meu caso de virar um promotor e depois um juiz, como médico gostaria de coordenar uma equipe médica e depois abrir uma clínica e administra-la, isso vai de cada um.

Kanin, deixar de ser médico e coordenar uma equipe médica é uma nova competência, com novas habilidades e pré-requisitos, não se caracterizando necessariamente como uma evolução do cargo médico.

A sua questão sobre programador nos arremeteu uma idéia de que para você, se tornar um gerente ou coordenador é uma evolução do cargo e não uma nova função com novas características. Mas, como você mesmo disse que é arquiteto, deve saber que esta sim pode ser considerada uma evolução na carreira de um programador, porque uma é a total plenitude das competências da outra.

editado: agora que vi sua resposta sobre desvirtuar o tópico, portanto não precisa responder, apenas foi um novo ponto de vista sobre planos de carreira

grato

RafaFloripa:

Gosto mais dessas carreiras em Y
onde eu posso escolher pra onde crescer

tipo ser um programador o resto da vida, nao quer dizer que voce vai ser um “programador” o resto da vida

mas é mesma coisa de dizer que todos os analistas precisam ser antes programadores
ou que um analista obrigatoriamente ganha mais que um programador pois é um passo alem da profissão

sei lá, meio controverso, mas eu vejo muita gente que ve assim tambem…

mas não posso negar que é um ponto de vista

Fala Rafa… tbm achei legal essa idéia de carreira em Y… confesso que não a conhecia… Quanto ao fato de Analistas, Gerentes terem sido bons Programadores eu acho uma ótima idéia… Perceba, não estou dizendo que é regra, mas mesmo o cara que abriu uma clínica médica, um dia foi um residente… Acho que é importante saber criar antes de escrever o que deve ser criado…

Mas também conheço gerentes e excelentes gerentes que não foram Programadores… Mas se você conversar com o cara, verá que o mesmo sabe bem o que fala, não larga certas pérolas que ouvimos por aí…

Já Analista não… nunca conheci um bom Analista sem que o mesmo nunca tenha Programado… As ERs sempre são sujas, telas mal elaboradas, idéias de doer na alma para usabilidade e afins…

Só pra constar… Teve uma vez que uma analista de qualidade de uma empresa onde trabalhei pediu pra voltar uma documentação de um Projetista nosso, alegando que ele havia projetado o Diagrama de Classe e havia usado “STRIG” (ela escreveu STRIG mesmo não STRING) e no Dicionário de dados, o campo era Varchar2… Isso atrasou o Projeto em 2 dias, porque ela não queria liberar o documento enquanto isso não fosse ajeitado e tiveram que explicar pra bichinha porque um era String e o outro era Varchar2… Quase deu um nó na cabeça da coitada…

Heueheueheueheu

Abs []

josenaldo:

Kanin, tem certeza de que é preciso criticar de forma tão dura este artigo? Será que o autor falou besteira mesmo? Vamos a alguns comentários:

• Estimativa não é pode ser exata! Ou é exata ou é estimativa! O próprio artigo fala isso.

• 50 anos de experiência da nossa área tem mostrado que projetos baseados em processos que exigem prazos e custos definidos previamente quase sempre saem mais caros do que deveriam, levam mais tempo do que deveriam e não fazem o que o cliente quer.

• Estimar software é sim um processo empírico. O uso de APF indiscriminadamente acaba superestimando quase sempre. A equipe deve levar em conta sua experiência para ajustar a estimativa.

• Projetos de escopo aberto já são uma realidade. E tem funcionado muito bem. É difícil conseguir mudar a mentalidade? Claro. E O PRÓPRIO ARTIGO FALA SOBRE ISSO!

Kanin, acredito que você acabou extrapolando aqui por impulso. Mas ao falar uma coisa dessas, você passa uma impressão muito ruim. As pessoas que conheço que soltam pérolas dessa costumam:

• sonhar em virar gerentes,(até aqui, no problem)
• Achar que o gerente é o único responsável pelo sucesso do projeto (aqui sim começam os problemas)
• tratar programador como trabalhador braçal
• fugir das responsabilidades, apontar culpados, e usar o trabalho dos outros como se fosse seu
• acreditar piamente que processos e ferramentas são a salvação da lavoura e que o programador tem pouca importancia no processo.
• Atormentar a equipe perguntando a cada 5 minutos se a tarefa está pronta
• marca mais reuniões do que deve, exige mais relatórios do que é aconselhável
• ao invés de remover os impedimentos ao trabalho dos desenvolvedores, pressiona e ua o famoso “te vira”;
• atrapalha mais do que ajuda

Ser gerente de uma equipe não significa mandar nela, mas facilitar a vida dessa equipe. O gerente é um membro, ão o dono.

Você fala como se “programar” fosse um castigo destinado aos incompetentes. Cuidado. Isso, é ofensivo. Existem pessoas que amam programar e tem orgulho disso. Pessoas que querem seguir essa carreira. E muitas dessas pessoas são os melhores profissionais que conheço e que você vai conhecer.

Tem certeza que quer tratar assim seus colegas?

Perfeita colocação!

Josenaldo , tudo isso que você escreveu a única coisa que devo ressaltar, são as desculpas a quem se sentiu ofendido e frustrado.

Isso sim é uma ÓTIMA colocação! A UNICA coisa proveitosa da colocação do josevaldo, o Kanin se redimiu com uma OTIMA resposta!

Kanin passa tb seu Twiter. Abraço.

adriano_si:

RafaFloripa:

Gosto mais dessas carreiras em Y
onde eu posso escolher pra onde crescer

tipo ser um programador o resto da vida, nao quer dizer que voce vai ser um “programador” o resto da vida

mas é mesma coisa de dizer que todos os analistas precisam ser antes programadores
ou que um analista obrigatoriamente ganha mais que um programador pois é um passo alem da profissão

sei lá, meio controverso, mas eu vejo muita gente que ve assim tambem…

mas não posso negar que é um ponto de vista

Fala Rafa… tbm achei legal essa idéia de carreira em Y… confesso que não a conhecia… Quanto ao fato de Analistas, Gerentes terem sido bons Programadores eu acho uma ótima idéia… Perceba, não estou dizendo que é regra, mas mesmo o cara que abriu uma clínica médica, um dia foi um residente… Acho que é importante saber criar antes de escrever o que deve ser criado…

Mas também conheço gerentes e excelentes gerentes que não foram Programadores… Mas se você conversar com o cara, verá que o mesmo sabe bem o que fala, não larga certas pérolas que ouvimos por aí…

Já Analista não… nunca conheci um bom Analista sem que o mesmo nunca tenha Programado… As ERs sempre são sujas, telas mal elaboradas, idéias de doer na alma para usabilidade e afins…

Só pra constar… Teve uma vez que uma analista de qualidade de uma empresa onde trabalhei pediu pra voltar uma documentação de um Projetista nosso, alegando que ele havia projetado o Diagrama de Classe e havia usado “STRIG” (ela escreveu STRIG mesmo não STRING) e no Dicionário de dados, o campo era Varchar2… Isso atrasou o Projeto em 2 dias, porque ela não queria liberar o documento enquanto isso não fosse ajeitado e tiveram que explicar pra bichinha porque um era String e o outro era Varchar2… Quase deu um nó na cabeça da coitada…

Heueheueheueheu

Abs []

Opa,

Analistas de negócio em alguns lugares não são programadores, muito menos “tecnicos”
é dificil quando você tem uma necessidade muito especifica, por exemplo campos da medicina, juridico, economia, exercito
etc…

arabços

Qual o problema nisso?

Programar por Hobbie pelo resto da vida vc ate pode, não estou discriminando a profissão, fui desenvolvedor um bom tempo, porem se vc é um profissional que esta acomodado com sua posição de desenvolvedor, querendo isso pro resto da sua vida, e esta feliz com isso, boa sorte!!!

O problema Kanin, é que ao menos, aqui nesse país, a “evolução” de programador é conhecida como arquiteto, analista sênior, gerente ou o diabo a quatro que você queira pensar e imaginar. Porém, são coisas distintas e devem ser tratadas assim. Para mim é inconcebível alguém pensar que evolução de desenvolver é necessariamente essas palavras que falei agora a pouco. E é superestimar a área de gerência achando que é a salvação da lavoura.

O que ocorre é: empresas seguem metodologias e processos, ganham certificações, alcançam clientes antes não alcançados, mas esquecem de fazer o seguinte: treinar pessoas, qualificar a área técnica, criar sustentabilidade e área de pesquisa interna, focar mais em pessoas ao invés de processos, criar metodologias ágeis, sem tantas hierarquias e burocracias. Ao meu ver, esses pontos são mais importantes tanto para o sucesso do projeto, quanto para o sucesso dos seus envolvidos.

Só em locais como estes achar que gerência é evolução. E para ser sincero, a maioria dos gerentes que conheci eram fracos, tinham medo de desenvolver, caso se deparrassem com um código mais completo, ficavam desesperados, como se fôssem o diabo encontrando a cruz. Eram bons em mandar e-mails, criar planilhas, relatórios, e fazer cobrar, mas gerência, é muito mais do que isso, é envolver de fato no projeto, saber como ele funciona (se possível, até em termos de codificação). Se envolver em todas as suas etapas, pesquisar soluções e não ficar cobrando daqueles que realmente fazem todo o trabalho e são ?safrificados? para atender uma pequena massa de uma empresa que se beneficia dessas pessoas.

Infelizmente, essa é uma grande realidade.

Qual o problema nisso?

Programar por Hobbie pelo resto da vida vc ate pode, não estou discriminando a profissão, fui desenvolvedor um bom tempo, porem se vc é um profissional que esta acomodado com sua posição de desenvolvedor, querendo isso pro resto da sua vida, e esta feliz com isso, boa sorte!!!

O problema Kanin, é que ao menos, aqui nesse país, a “evolução” de programador é conhecida como arquiteto, analista sênior, gerente ou o diabo a quatro que você queira pensar e imaginar. Porém, são coisas distintas e devem ser tratadas assim. Para mim é inconcebível alguém pensar que evolução de desenvolver é necessariamente essas palavras que falei agora a pouco. E é superestimar a área de gerência achando que é a salvação da lavoura.

O que ocorre é: empresas seguem metodologias e processos, ganham certificações, alcançam clientes antes não alcançados, mas esquecem de fazer o seguinte: treinar pessoas, qualificar a área técnica, criar sustentabilidade e área de pesquisa interna, focar mais em pessoas ao invés de processos, criar metodologias ágeis, sem tantas hierarquias e burocracias. Ao meu ver, esses pontos são mais importantes tanto para o sucesso do projeto, quanto para o sucesso dos seus envolvidos.

Só em locais como estes achar que gerência é evolução. E para ser sincero, a maioria dos gerentes que conheci eram fracos, tinham medo de desenvolver, caso se deparrassem com um código mais completo, ficavam desesperados, como se fôssem o diabo encontrando a cruz. Eram bons em mandar e-mails, criar planilhas, relatórios, e fazer cobrar, mas gerência, é muito mais do que isso, é envolver de fato no projeto, saber como ele funciona (se possível, até em termos de codificação). Se envolver em todas as suas etapas, pesquisar soluções e não ficar cobrando daqueles que realmente fazem todo o trabalho e são ?safrificados? para atender uma pequena massa de uma empresa que se beneficia dessas pessoas.

Infelizmente, essa é uma grande realidade.

Grinvon,

Concordo com você, por isso disse que ser um gerente não e chegar no topo da piramede.

Opa… tranquilo… o problema é que eu trabalho com o perfil do Analista de Requisitos, que por aqui os cabeça de ovo ainda usam como a pessoa que conversa com o analista de negócios, esse papel, é o que modela o Sistema e passa aquele calhamaço de papel para as mãos do Desenvolvedor… enfim… Era desse que eu tava falando…

Abs []

Será que lemos o mesmo artigo?

O que eu li tratava de estimativas desenvolvedor x cliente, não entre empresas.

Realmente relendo, me expressei mal em relação ao escopo aberto… Sei como funciona e sei que prazos e custos também devem ser medidos, afinal você não pode usar o chute como base também…

Aqui o Projeto precisava de 1 PRAZO e 1 CUSTO… foi nesse sentido que achei que o Escopo aberto seria mais viável…

Valew pelo detalhamento.

Abs []

Escopo aberto é muito dificil de ser gerenciado. A linha é muito tênue entre um release “bom o suficiente” para uma versão inicial, e um sistema inútil que o cliente vai considerar como desperdício de recursos. Se formos associar a isso o ambiente conturbado por você descrito, torna escopo aberto impraticável.

Tópico interessante, mesmo que tenha perdido um pouco o foco inicial.

Mas concordo que uma boa evolução na carreira é se tornar um
arquiteto em vez de um gerente, e é isso que projeto ser no futuro.

Programar é legal, mas fazer a mesma coisa sempre e sempre e sempre
não é algo legal, mesmo que mude de tecnologias, problemas sendo resolvidos.
Mas isso é apenas uma opinião.

Oi,

No meu blog de informática,que de informática não tem nada…
Postei uma mensagem que fala sobre o valor de cada um,independente do cargo ou profissão.Quem quiser da uma olhadinha…

http://informaticaecia-tecnologia.blogspot.com/

simplesmente escroto. sei nem o que dizer. eu não sei se devo rir ou chorar.

Mais uma fonte de conhecimento dispensável!!!

Se está se referindo ao blog,ao contrario de você eu respondo.

Já estou passada com essas pessoas que entram,escrevem o que vem a cabeça,mas ninguém sabe quem é realmente,assim fica muito comodo criticar,já disse uma vez e repito,é covardia.

Anime.
Não leve ao pé da letra tudo o que as pessoas escrevem.

No fórum não é possível saber se a pessoa escreveu com bom humor,
ou se foi uma critica realmente.

johnny quest:

Anime.
Não leve ao pé da letra tudo o que as pessoas escrevem.

No fórum não é possível saber se a pessoa escreveu com bom humor,
ou se foi uma critica realmente.

Oi johnny quest,

Pode ser,mas duvido.De qualquer forma obrigada…

Jovem,

O que há de tão indispensável no seu blog, em relação ao tópico?

Sem mais…

Se está se referindo ao blog,ao contrario de você eu respondo.

Já estou passada com essas pessoas que entram,escrevem o que vem a cabeça,mas ninguém sabe quem é realmente,assim fica muito comodo criticar,já disse uma vez e repito,é covardia.

Calma Anime, eu tbm nao sei qm é vc =]

Se está se referindo ao blog,ao contrario de você eu respondo.

Já estou passada com essas pessoas que entram,escrevem o que vem a cabeça,mas ninguém sabe quem é realmente,assim fica muito comodo criticar,já disse uma vez e repito,é covardia.

Me desculpe! mas quem é vc ??? uma covarde ? Haaaa me lembrei isso é um forum !

Vc está fazendo a mesma coisa ou até pior do que a que vc expos!!!

Anime:

Oi,

No meu blog de informática,que de informática não tem nada…
Postei uma mensagem que fala sobre o valor de cada um,independente do cargo ou profissão.Quem quiser da uma olhadinha…

http://informaticaecia-tecnologia.blogspot.com/

Como diria o topico: “Hoje eu li cada besteira …”

Se está se referindo ao blog,ao contrario de você eu respondo.

Já estou passada com essas pessoas que entram,escrevem o que vem a cabeça,mas ninguém sabe quem é realmente,assim fica muito comodo criticar,já disse uma vez e repito,é covardia.

Calma Anime, eu tbm nao sei qm é vc =]

Cara depois que eu vi essa sua imagem perdi completamente o que eu ia falar
asduuahsdauhsduhasd

Kanin Dragon:

Jovem,

O que há de tão indispensável no seu blog, em relação ao tópico?

Sem mais…

Oi,

Em relação ao tópico nada,mas tem relação com o que foi discutido no tópico(se vc soubesse interpretar texto,teria percebido).

Esqueci…Realmente não ha nada de indispensavel no link que passei,se prestasse mais atenção não perguntaria isso,pois coloquei assim(Quem quiser da uma olhadinha).

Sem mais…

Resposta coletiva para quem perguntou quem sou eu…

Eu não participo do forum anonimamente,quem é da minha cidade por exemplo e tem o abto de ler o forum,se me encontrar em algum lugar vai me identificar,(se for uma pessoa observadora e com boa memória,como eu ).
Mesmo para quem não é daqui só não sabe quem sou,quem não quer…

Anime me convida pra ir pra SJRP =], fiquei sabendo que faz um frio lascado ai HAuhaUA =]

FabiaaaEEEE:

Anime:

Oi,

No meu blog de informática,que de informática não tem nada…
Postei uma mensagem que fala sobre o valor de cada um,independente do cargo ou profissão.Quem quiser da uma olhadinha…

http://informaticaecia-tecnologia.blogspot.com/

Como diria o topico: “Hoje eu li cada besteira …”

Primeiro post,interessante…

Pelo menos leu alguma coisa,deve ter ajudado de alguma forma,continuie lendo,leia muito,até o que não considera bom,ler desenvolve o raciocinio e a interpretação…

Ué se vc quiser derreter pode vir…

Anime:

FabiaaaEEEE:

Anime:

Oi,

No meu blog de informática,que de informática não tem nada…
Postei uma mensagem que fala sobre o valor de cada um,independente do cargo ou profissão.Quem quiser da uma olhadinha…

http://informaticaecia-tecnologia.blogspot.com/

Como diria o topico: “Hoje eu li cada besteira …”

Primeiro post,interessante…

Pelo menos leu alguma coisa,deve ter ajudado de alguma forma,continuie lendo,leia muito,até o que não considera bom,ler desenvolve o raciocinio e a interpretação…

Só observo, qndo percebo algo horrendo, acabo postando… pois como vc pode perceber leio sim, infelizmente a frase que vc colocou não as aplicou. Mas não me importo que indique algo para enriquecer a minha mente e dos demais, porém coisas concretas logico serão sempre bem vindas e ainda por cima indicadas aos outros, coisas banais tb devem ser comentadas, porém devemos ter senso para aceitar as boas e más criticas, isso sim nos faz desenvolver o raciocinio e a interpretação. =)

hehe… o cara da Oracle que costuma dizer que TI é a verdadeira indústria da moda.

Ele está completo de razão, nenhuma outra área tudo muda tão rapido que a maioria nem sabe que indústria ela serve, muito menos qual estratégia adotar, PMBOK, Scrum, Waterfall, etc…

Isso sem dúvida acaba gerando muita confusão no mercado, vide os constantes apelos for algum tipo de regulamentação, mesmo que ninguém saiba como isso seria implementado na prática.

adriano_si:

Eu concordo um pouco com ele, pois não interessa a era, não interessa a forma e não interessa como… o que importa, e isso o cliente enxerga, é entregar certo e no prazo…

Abs []

Veja minha opinião sobre estimativas em outros posts. Quantos hits ou best-sellers fazem sucesso porque foram entregues “no prazo que o cliente estipulou”? Nenhum que me lembre.

São estes pensamentos que abrem espaço para estas tecnologias mirabolantes e de meia tigela como por exemplo Java Server Faces. É incrível mas é quase que um pré requisito para ser líder de projeto de desenvolvimento de sistemas.
Regra número 1 o programador é sempre um idiota e não tem capacidade de escolher uma tecnologia mais produtiva.
Regra número 2 por ser um idiota merece ficar esperando 3 minutos sempre que coloca uma virgula no código fonte.

Poderia abrir um outro tópico explicando o porque JSF seria uma Tecnologia Mirabolante e de meia tigela ??? estou curioso por ler suas explicações sobre o assunto…

rwolosker:

Kanin Dragon:

É como sempre digo, muitos tem que estudar e abrir a mente antes de sair escrevendo pela web, alguns merecem programar pelo resto da vida.

São estes pensamentos que abrem espaço para estas tecnologias mirabolantes e de meia tigela como por exemplo Java Server Faces. É incrível mas é quase que um pré requisito para ser líder de projeto de desenvolvimento de sistemas.
Regra número 1 o programador é sempre um idiota e não tem capacidade de escolher uma tecnologia mais produtiva.
Regra número 2 por ser um idiota merece ficar esperando 3 minutos sempre que coloca uma virgula no código fonte.

Olá Jovem,

1. Realmente fui infeliz no comentário acima, mas já pedi desculpas a quem se sentiu ofendido.
2. Você tem alguma opinião ou critica construtiva em relação o proposto pelo tópicou ou entrou somente para fazer flame ?

Abs,

Poderia abrir um outro tópico explicando o porque JSF seria uma Tecnologia Mirabolante e de meia tigela ??? estou curioso por ler suas explicações sobre o assunto…

Nem sempre a comunidade JAVA lança algo realmente inédito, é comum reutilizar funcionalidades apenas mudando o nome do conceito. É o que acontece, por exemplo, com a sutil diferença entre um Repositório da arquitetura DDD e os antigos DAO, padrão J2EE, porque fisicamente oferece a mesma solução, abstração do acesso ao armazenamento persistente. Java Server Faces também segue esta linha de pensamento.

JSF provoca uma mudança radical no desenvolvimento de sistemas porém, tem pouco a acrescentar. Ao mesmo tempo que ele promove uma abstração muito grande da camada de apresentação, ele engessa e castra a criatividade dos programadores em tempo de elaboração das telas. Os componentes JSF se apresentam com boa flexibilidade mas não são, é muito mais difícil criar um componente JSF do que uma simples TAG JSP. Ele desencoraja o uso direto de JavaScript podendo ser, de longo prazo, uma grande perda. JSF não faz ajax, quem faz é o richfaces ou talvez primefaces, experimente fazer na mão, impossível.

JSF é uma tecnologia incompleta e só é para ser viável, precisa ser utilizada em conjunto com outras ferramentas como JBOSS Seam, que em efeito cascata requer o JBOSS Tools que só funciona no Eclipse. É uma solução que criar dificuldades, uma ideologia 100% Microsoft.

Ainda há espaço para os frameworks do tipo ActionBase. Atualmente, quase todos eles também são capazes de mapear os controles HTML diretamente para os beans de negócio. Através do marketing, tenta-se vender JSF como uma tecnologia nova e de ponta, só não dizem que é uma tecnologia tão antiga quanto as outras.

JSF exige uma sobrecarga muito maior nos controles ou “serviços” justamente porque tira o javascript da camada de apresentação, porque os controles passam a trabalhar mais para alterar o comportamento das visões, aonde que fica a questão do acoplamento destas camadas?

Um outro fato interessante é que gostam muito de dizer que programador não nasceu para ser designer, então é um benefício, também, separar a visão do resto do sistema. Como um web designer consegue fazer uma tela com controles FACES sem rodar a aplicação?

então você quis dizer que JSF não é o supra-sumo da tecnologia ??? Concordo…

Tecnologia de meia tigela ??? discordo…

Uso, me satisfaz, aumentou a produtividade de nossa equipe, nosso designer gostou e aprovou… Uso-o com o Rich e com o Prime como você falou, pois realmente sem eles, as coisas ficam bem difíceis… Porém não uso o JBoss Tools e todos os Programadores utilizam o NetBeans…

Hei de concordar com vocẽ que a ferramenta precisa de complementos pra atender bem, mas o Java é meio assim, a maioria das soluções precisam de um algo mais pra funcionar legal, todo e qualquer Framework é feito pensando em abraçar o mundo e sempre precisa de um complemento pra funcionar legal… enfim… respeito sua opnião, só não concordo…

Abs []

Na minha opinião eu considero ótimo eliminar o contato direto com javascript em um projeto, pois
dá muita dor de cabeça ficar corrigindo erros nessa linguagem.

JSF 2.0 vem com ajax nativo.

Na minha opinião eu considero ótimo eliminar o contato direto com javascript em um projeto, pois
dá muita dor de cabeça ficar corrigindo erros nessa linguagem.

JSF 2.0 vem com ajax nativo.

Falando de Javascript puro talvez vc tenha razao, mas usando algo como Jquery, eu concordo plenamente com o Johny Quest.

Tambem sou um dos que abominam JSF.

por várias décadas, fomos catequisados de que o maior problema do JavaScript é a incompatibilidade dos navegadores. De tempos em tempo é bom sempre dar uma renovada no sermão da missa. Hoje a incompatibilidade é maior no CSS. Aliás, o Firefox é o único que está de acordo com o CSS do w3c, nem o chome escapou!

E que o JSF “facilita” essa compatibilidade entre os navegadores é conversa pra boi dormir.

rwolosker:

E que o JSF “facilita” essa compatibilidade entre os navegadores é conversa pra boi dormir.

Mas não facilita?
E outra, o JSF 2 já permite Ajax nativo e trabalha bem com vários frameworks javascripts, dentre eles o jquery.

Agora, que não é perfeito, nenhum até agora é.

Fugimos ao tema do tópico… por isso pedi que se abrisse em um novo… Hueheueheueheueheueheueheueheuehu

A discursão é boa… vamos migrá-la daqui… rwolosker, sinta-se a vontade pra abrir o tópico, afinal você levantou a questão… heueheueheueheu

Abs []

Certamente não é o melhor caminho se voce quer ter um controle fino do javascript, e muitas vezes tambem do HTML. Pode ate estar melhor hoje em dia, mas a abordagem action-based é incrivelmente superior se o seu caso é usar JQuery, por exemplo.

O pessoal aqui fica todo defensivo quando alguém critica a carreira de programador que até não consegue se articular para dar uma resposta adequada.

A área de Ciência da Computação é enorme. Lugar para crescer é o que não falta: computação gráfica, compiladores, sistemas operacionais, IA, etc, isso sem contar toda a teoria matemática que ajuda bastante. Basta escolher o que quiser e se esbaldar com projetos interessantes e desafios.

Crescer como programador é abocanhar uma fatia maior de conhecimento cada vez mais, para assim botar esses conhecimentos em prática de uma forma que ajude seus clientes.

De fato, programar a mesma aplicação web por anos, apenas trocando de framework a cada 2 ou 3 anos é um pé no saco. Mas não é necessário fazer isso.

Acho que o comentarista original tem um visão um tanto deturpada a respeito de carreira. Só cresce “para os lados” quem quer.

Poderia abrir um outro tópico explicando o porque JSF seria uma Tecnologia Mirabolante e de meia tigela ??? estou curioso por ler suas explicações sobre o assunto…

Eu utilizei JSF por anos e realmente atualmente acredito que seja um exagero, assim como muitas outras APIs Java.

Criar componentes é desnecessariamente complexo porque é necessário extender várias classes e alterar arquivos de configuração. Não usei a 2.x ainda, mas suponho que eles estejam usando Annotations?

Mesmo que tenham diminuído a complexidade, pergunto, para quê criar componentes no lado do servidor? Não seria mais fácil fazer uma separação entre cliente e servidor? A sua lógica de negócio certamente não dependerá da camada de visualização.

Um aplicativo web moderno tem a aplicação cliente rodando no browser em Javascript/CSS, alguma API Javascript ajudaria nesse ponto, fazendo chamadas servlet para o servidor. Muito mais rápido, simples e ainda por cima daria um aspecto mais responsivo para a sua aplicação.

Opa… blz cara /??? Pois bem, perceba que JSF não obriga que você coloque suas regras de negócio junto com as aplicações… Acho que atuando no MVC você consegue facilmente separar isso aí, independente de usar JSF, Struts, VRaptor, etc…

Concordo com você quando dizes que uso de tecnologias do lado do cliente são uma boa alternativa, mas lembre-se que qualquer Framework não é pra resolver todos os problemas da humanidade…

ele pode ter suas dificuldades e pontos fracos, assim como qualquer outro… Ainda não entendi porque é uma tecnologia de “meia tigela”… Apenas isso…

Abs []

No final das contas, usando APF ou use case point ou whatever o prazo será sempre na base do chutômetro.
A sim e o processo será GOHORSE

Opa… blz cara /??? Pois bem, perceba que JSF não obriga que você coloque suas regras de negócio junto com as aplicações… Acho que atuando no MVC você consegue facilmente separar isso aí, independente de usar JSF, Struts, VRaptor, etc…

Não, mas JSF força você a programar seus componentes no servidor.

Uma aplicação web moderna é composta por duas partes independentes, o browser rodando o aplicativo que faz a UI, e o servidor rodando a lógica. Programar UI no servidor com os componentes do JSF é desnecessariamente complicado.

adriano_si:

Concordo com você quando dizes que uso de tecnologias do lado do cliente são uma boa alternativa, mas lembre-se que qualquer Framework não é pra resolver todos os problemas da humanidade…

Frameworks não servem para resolver nada, são apenas gambiarras para limitações da linguagem de programação.

Uma linguagem de programação adequada permitiria a seus usuários extendê-la para acrescentar novas construções sintáticas. Tornando a existência de “frameworks” desnecessária.

Longino:

Uma linguagem de programação adequada permitiria a seus usuários extendê-la para acrescentar novas construções sintáticas. Tornando a existência de “frameworks” desnecessária.

Que linguagem é essa?

Lucas Emanuel:

Longino:

Uma linguagem de programação adequada permitiria a seus usuários extendê-la para acrescentar novas construções sintáticas. Tornando a existência de “frameworks” desnecessária.

Que linguagem é essa?

Ignora. Depois que eu li essa mensagem, reli o título. heheheheh

Acho que já passou da hora desse tópico ser trancado. O assunto original já era polêmico o suficiente, já deu o que tinha que dar, tem uns 20 posts que não tem nada a ver com um assunto … logo os trolls irão proliferar …

Lucas Emanuel:

Longino:

Uma linguagem de programação adequada permitiria a seus usuários extendê-la para acrescentar novas construções sintáticas. Tornando a existência de “frameworks” desnecessária.

Que linguagem é essa?

Existem várias: Lisp, Scheme, etc. O ato de desenvolver um software seria o de criar uma linguagem específica para aquele domínio. E isso acontece de uma forma natural, pois é uma extensão da própria linguagem.

As bibliotecas Java EE seriam muito mais simples e a quantidade de frameworks zero se Java tivesse algo parecido.

Quem falou que Java não tem algo parecido?

http://clojure.org/

Opa… Deus te ouça… =)

Concordo. Todas as estimativas são chutes, por isso são estimativas.

A grande diferença das estimativas ágeis, na minha visão, é que podemos estimar poucas coisas e acertar a estimativa e velocidade do time em curtissimo prazo. Diferente dos demais métodos, que tentam acertar 1, 2 anos naquelas unicas reuniões de start-up do projeto.

Mas as estimativas com story points também é chute. Outra coisa legal é que os métodos ágeis deixam isso bem claro e não tentam mascarar com pseudos métodos cientificos, como APF tenta fazer…

Abraços

malconL:

Quem falou que Java não tem algo parecido?

http://clojure.org/

Isso não é Java, e implementações Lisp existem várias rodando na JVM. Inclusive a minha: http://www.longino.com.br .

Longino:

malconL:

Quem falou que Java não tem algo parecido?

http://clojure.org/

Isso não é Java, e implementações Lisp existem várias rodando na JVM. Inclusive a minha: http://www.longino.com.br .

Sim, existem várias implementações de Lisp, eu mesmo durante a universidade fiz 3… de qualquer maneira não poderíamos esquecer de mencionar Clojure já que é o Lisp que a comunidade Java conhece.

O que gosto do Java é justamente as várias opções. Quem gosta da abordagem action based, tem várias opções de frameworks e bibliotecas. Quem acha frameworks baseados em componentes melhor e mais produtivos, tem vários que atendem.

Com isso, ninguém fica brigando em fórums discutindo que “x é o melhor e y não presta”. :lol:

malconL:

Longino:

malconL:

Quem falou que Java não tem algo parecido?

http://clojure.org/

Isso não é Java, e implementações Lisp existem várias rodando na JVM. Inclusive a minha: http://www.longino.com.br .

Sim, existem várias implementações de Lisp, eu mesmo durante a universidade fiz 3… de qualquer maneira não poderíamos esquecer de mencionar Clojure já que é o Lisp que a comunidade Java conhece.

Se exercício de faculdade conta como “implementação” então eu já fiz umas 20. Uma implementação geralmente se refere a algo usável em produção por ser estável e que tenha as bibliotecas necessárias, e não a execícios feitos por quem está aprendendo a programar.

E se existem outras implementações Lisp em Java é porque alguns da “comunidade Java” não acreditam que o Clojure seja uma boa opção.

É, LISP vai salvar o mundo nos próximos 5 anos… Pena que a cada 5 anos essa profecia é atualizada.

Longino:

Se exercício de faculdade conta como “implementação” então eu já fiz umas 20. Uma implementação geralmente se refere a algo usável em produção por ser estável e que tenha as bibliotecas necessárias, e não a execícios feitos por quem está aprendendo a programar.

Bom, eu não disse que conta como “implementação entre aspas”, apenas que fiz.

Longino:

E se existem outras implementações Lisp em Java é porque alguns da “comunidade Java” não acreditam que o Clojure seja uma boa opção.

Ah, sei não, acho que se existem outras implementações hoje é porque a JVM é uma plataforma estável, com bibliotecas disponíveis e serve como incubadora de novas linguagens, algumas com uma linhagem Lisp, outras não, mas a maioria com certeza não vai se tornar “de mercado”, por isso a comparação com academia é válida.

Mas se Clojure for o responsável por tal movimento por si só já é uma grande colaboração para a comunidade Lisp, já que mais dialetos seriam criados.

malconL:

Longino:

Se exercício de faculdade conta como “implementação” então eu já fiz umas 20. Uma implementação geralmente se refere a algo usável em produção por ser estável e que tenha as bibliotecas necessárias, e não a execícios feitos por quem está aprendendo a programar.

Bom, eu não disse que conta como “implementação entre aspas”, apenas que fiz.

Longino:

E se existem outras implementações Lisp em Java é porque alguns da “comunidade Java” não acreditam que o Clojure seja uma boa opção.

Ah, sei não, acho que se existem outras implementações hoje é porque a JVM é uma plataforma estável, com bibliotecas disponíveis e serve como incubadora de novas linguagens, algumas com uma linhagem Lisp, outras não, mas a maioria com certeza não vai se tornar “de mercado”, por isso a comparação com academia é válida.

Mas se Clojure for o responsável por tal movimento por si só já é uma grande colaboração para a comunidade Lisp, já que mais dialetos seriam criados.

E vai mais uma pra série: “como desvirtuar um tópico com apenas uma mensagem simples…”

malconL:

Mas se Clojure for o responsável por tal movimento por si só já é uma grande colaboração para a comunidade Lisp, já que mais dialetos seriam criados.

Que movimento? Clojure não criou movimento nenhum. Lisp tem mais de 50 anos de idade e implementações existem para todas as plataformas mundo afora. E nem na JVM ela veio em primeiro, porque já existiam outras antes.

Dialetos Lisp são como versões de Unix, para que criar outra se existe Linux, BSD, etc? O mundo precisa tanto de “dialetos” quando precisa de mais Unix. Lisp tem dois padrões principais, o Common Lisp e o Scheme.

Justamente por isso usei Common Lisp, já tem um monte de documentação e livros e eu o extendo como necessário para adaptá-lo para certas aplicações, assim como aplicações gráficas 3D, web, etc.

asaudate:

E vai mais uma pra série: “como desvirtuar um tópico com apenas uma mensagem simples…”

Desculpa aí. O tópico já estava bem fora porque estávamos discutindo JSF, mas acho que agora foi para o brejo de vez.

Longino:

malconL:

Mas se Clojure for o responsável por tal movimento por si só já é uma grande colaboração para a comunidade Lisp, já que mais dialetos seriam criados.

Que movimento?

Um movimento se caracteriza quando novas implementações de Lisp são criadas como resposta à clojure.

Mas novamente, não estou dizendo que tal movimento existe, estou apenas conjecturando com base no que vc disse.

Tem razão, o mundo não precisa de mais versões de Lisp ou UNIX, mas qual seu ponto? Que devemos ignorar que Clojure e iOS existem?

Longino:

Justamente por isso usei Common Lisp, já tem um monte de documentação e livros e eu o extendo como necessário para adaptá-lo para certas aplicações, assim como aplicações gráficas 3D, web, etc.

Se Common Lisp dispõe de tudo que vc precisa, porque que precisa extendê-lo?

malconL:

Longino:

malconL:

Mas se Clojure for o responsável por tal movimento por si só já é uma grande colaboração para a comunidade Lisp, já que mais dialetos seriam criados.

Que movimento?

Um movimento se caracteriza quando novas implementações de Lisp são criadas como resposta à clojure.

Mas novamente, não estou dizendo que tal movimento existe, estou apenas conjecturando com base no que vc disse.

Quem disse isso? Nada foi criado em resposta a nada. Longino existe porque eu tinha a necessidade de algo assim que eu pudesse adaptar para qualquer uso que quisesse, como computação gráfica e tal.

malconL:

Se Common Lisp dispõe de tudo que vc precisa, porque que precisa extendê-lo?

Por que uma linguagem é apenas uma linguagem e não define um universo de todas as coisas que você possa imaginar fazer com um computador.

???

AMigão, você ressucita um tópico desse pra não dizer nada ?

Sei que você é novo no fórum, portanto uma lida nas regras cairia bem…

Algum modera tranca aqui se puder se não vai voltar a tona a discussão que já havia se encerrado…

Abs []