Aliás, o seu exemplo é perfeito, onde entram as pessoas aí ?
"
"
Alguém poderia pelo amor de Deus, dos ETs, dos Orichas e tudo mais, citar uma, apenas uma empresa que tenha um renome bom, que seja um exemplo de qualidade em projetos de software usando PMBox e sua trupi?
Bom,
lendo o topico descobri que o motivo de todos os projetos que eu ja participei usando algum “guia”(CMM, MPSBR…etc) não deram certo pq as pessoas não souberam aplicar esse guia(e não foram poucos).
Com isso eu fico com a ideia dos metodos ageis. Pq ela foca nas pessoas, não em recursos. E sem pessoas não importa o que vc use, vai dar errado.
E pensando agora… os projetos que eu participei sem guias, mas focado nas pessoas foram os que deram certo.
[]´s
"
"
Pessoas são recursos? Esse tipo de mentalidade costuma afundar projetos.
Principalmente em projetos de software, não dá para achar que você pode usar um guia milagroso e processos “bem definidos” tornando as pessoas totalmente descartáveis, podendo ser trocada a qualquer momento por outra e manter a mesma produtividade e qualidade.
Se é tão ampla, qual é o valor além do didático? Porque na prática dá pra dizer que qualquer método segue o guia.
Não, pessoas não são recursos. Recursos são descartaveis, pessoas não.
Acho que nesse ponto esta a diferença entre os “guias” e as metodologias ageis.
Todas as fabricas de software que utilizam “guias”, tratam pessoas como recursos. Inclusive quem aplica os “guias”.
É nesse momento que as coisas começam a dar errado.
Por isso ainda fico com metodos ageis. E não pq li na Info uma materia a respeito. Mas pq e todos projetos que participei nesses ultimos 8 anos que utilizaram metodos ageis as coisas correram bem melhor do que qunado usamos algum desses famosos “guias”.
[]´s
Pessoas são pessoas, pensar em um ser humano apenas como um número, um custo, um objeto necessário para algo funcionar, como um parafuso, é o que fizeram até hoje as “fábricas de softwares”, e elas são os melhores exemplos do fracesso do PM* e suas crenças ultrapassadas e equivocadas. Software é trabalho empírico, não é uma ciência mensurável por algumas formulas matemáticas como em engenharia.
vc conhece Lean? conhece o manifesto ágil? scrum?
Se a resposta for sim, vc acaba de atestar que escreveu uma grande baboseira, se for não, esta perdoado pela baboseira que escreveu rs
"
"
[quote=marcosalex]
Quem te falou que recursos são descartáveis? Onde está escrito isso? Vamos mudar o nome dos departamentos de RH então? “Pessoas humanas” hheheheh
Você não está colocando recursos materiais e recursos humanos no mesmo balaio? O PMBok não fala isso, acho que aí é um dos motivos da confusão. Se alguém faz isso na empresa onde você trabalhou, não, ele não segue o PMBok.[/quote]
Com certeza, tanto que ja existem empresas que nem usam mais o nome Recursos Humanos para essa area. De uma olhada se o Google tem a area de Recursos Humanos por exemplo.
Outra coisa, acho meio simples isso de dizer que o “guia” falhou pq não foi bem aplicado. Acho muita coincidencia todas as empresas que ja vi utilizarem isso nao ter ninguem capaz de fazer-lo.
Se é dificil de aplicar, p/ mim ja não tem uso. No minimo consigo o mesmo resultado que os “guias” prometem(e ate agora não vi cumprirem) com muito mais simplicidade.
[]´s
"
"
Faço minhas suas palavras… onde estão os dados (estatística) mostrando isso?
E ainda não citou uma empresa, como lhe pedi anteriormente… deve estar difícil encontrar alguma no google né rs
"
eu sou apenas um smaltalk ainda hehe
mas… no tempo que eu trabalhei em uma filial da IBM, um gerente nos disse que quem quisesse subir era estudar ITIL e PMBok…
a eficiencia talvez seja discutivel mas se 2 pessoas com conhecimentos e experiencia bastante semelhantes, uma tem o certificado e a outra nao? :roll:
Provavelmente ler o PMBOK e outros guias da vida servem, também, para vocabulario, permitindo troca de ideias entre PMs.
Da mesma forma que, mesmo que não vá usar Scrum um PM deveria conhecer Scrum para saber o que é um Sprint, caso uma parte da empresa esteja adotando, senão terão serios problemas (imagine um PM depender de um recurso que esta em uso por uma equipe Scrum? Se o Sprint está em andamento não é bem assim para partilhar recursos, o correto seria sinalizar o quanto antes para isso ser debatido num Sprint Planning da Vida). Da mesma forma que conhecer RUP não significa que devemos seguir feito ^C ^V 