Prazo, Custo e Escopo
Paulo Vasconcellos
Olá Alexandre e colegas, Cada projeto contratado a "preço fechado" que falha de alguma forma (estourando orçamento ou prazo ou não entregando o escopo esperado) é uma oportunidade para que a empresa discuta este modelo de contratação. Uma oportunidade que deveria ser melhor aproveitada por todos, inclusive ou principalmente pelos prestadores de serviços. Segue uma sugestão (que, reconheço, não é de fácil aplicação): Das três pontas do triângulo (prazo, escopo e custo), o cliente só pode fixar uma. Ele escolhe: .O 'time to market', a data, é fator crítico de sucesso. Então o cliente deve aceitar uma flexibilização de custo e escopo; .O orçamento tá fechadíssimo, o custo é 'imexível' (sic). Então o cliente deve aceitar alguma variação no prazo e/ou escopo. .A solução só faz sentido com todas as funcionalidades entregues - não se mexe no escopo. Então o cliente deve se contentar com prazos e custos variáveis. A flexibilização de duas pontas não significa um campo no contrato totalmente aberto. É indicado que apresentemos *estimativas*, tentando obedecer três regrinhas: 1. Alertando o cliente que "estimativa" não é sinônimo de profecia. Este lembrete funciona bem quando é registrado com fonte sem serifa, corpo 40 e cor vermelha; 2. Exibindo um range (pior e melhor cenário), nunca um número absoluto; e 3. Mostrando compromisso em rever e refinar as *estimativas* ao término de cada iteração. Se atentarmos para o fato de que software não é um jogo de "tudo ou nada" (que existem requisitos mais e menos fundamentais para a realização dos objetivos do negócio), veremos que na maioria das vezes será mais fácil flexibilizar o escopo do que prazo e custos. Acho mais fácil vender assim também. Mike Cohn apresenta uma sugestão mais "boazinha" e sofisticada que a minha no seguinte post: http://blog.mountaingoatsoftware.com/using-a-one-handed-clock-to-convey-project-goals
Ronan Lucio
Paulo Vasconcellos
Jean Streleski
Na minha opinião existe uma quarta ponta. Mas que não deveria ser uma das pontas. É a QUALIDADE.
Muitas empresas ao tentar atender as três pontas, acabam neglicengiando a qualidade, gerando soluçõões caóticas, de díficil manutenção e de péssima escalabilidade. Digo isto baseado em fatos de empresas que já trabalhei e de quem já contratei projetos.
No mais, que as empresas nunca se esqueçam que qualidade é commodity. Deve fazer parte de qualquer atividade a ser realizada em um projeto.
Abraço
--
Jean Rozan Streleski
jean.r.s...@gmail.com
msn: jea...@hotmail.com
Jean Streleski
Reforça o que disse quando ele escreve:
Quality is placed in the middle under the premise that we don’t mess with quality.
Paulo Vasconcellos
Rodrigo
Discordo.
Pelo PMBOK 2008, os projetos passam a ter 5 RESTRIÇÕES: Escopo, Prazo, Custo, Qualidade e Riscos. Cada uma delas podem ser alteradas em função de outras. Um projeto pode assumir mais riscos do que outro. Um cliente pode querer mais qualidade em um projeto e menos em outro. Assumir riscos e ter mais ou menos qualidade impacta diretamente em escopo, custo e prazo.
Ter menos orçamento impacta em diminuir o escopo ou diminuir prazo ou diminuir qualidade e diretamente pode aumentar os riscos do projeto.
Tudo deve ser avaliado e APROVADO pelo cliente!
Rodrigo Almeida de Oliveira, CBTS®
Gerente de Projetos/Gerente de Qualidade e Processos
Certificado em Testes de Software - CBTS
Paulo Vasconcellos
Daniel Assad
empresa contratada aceita, aprova e etc todas os requisitos do cliente
mas falha na execução do mesmo.
Não importa o quanto se deixa claro os riscos, ou o valor combinado
está abaixo do que realmente vale, o cliente sempre espera qualidade.
Do lado da empresa contratada, o que falta na minha opinião é admitir
que em determinados casos você simplesmente não tem a estrutura para
garantir qualidade e o justo a se fazer é talvez tercerizar a QA. Do
lado do cliente, hoje começo a ver que QA é cláusula de muitos
contratos. Ex: Após a entrega do módulo X, a empresa Y realizará
testes e validações e o pagamento do mesmo se deve ao aceite ou não do
módulo por parte da empresa Y.
Pessoal, esta é minha primeira contribuição às discussões do grupo.
Estou gostando muito da qualidade dos assuntos debatidos. Ontém passei
horas lendo o histórico!
Atenciosamente,
Daniel
2009/10/29 Rodrigo <rodrigoalmei...@gmail.com>:
>
> Pelo PMBOK 2008, os projetos passam a ter 5 RESTRIÇÕES: Escopo, Prazo,
> Custo, Qualidade e Riscos. Cada uma delas podem ser alteradas em função de
> outras. Um projeto pode assumir mais riscos do que outro. Um cliente pode
> querer mais qualidade em um projeto e menos em outro. Assumir riscos e ter
> mais ou menos qualidade impacta diretamente em escopo, custo e prazo.
>
> Ter menos orçamento impacta em diminuir o escopo ou diminuir prazo ou
> diminuir qualidade e diretamente pode aumentar os riscos do projeto.
>
>
>
>
>
> Tudo deve ser avaliado e APROVADO pelo cliente!
>
>
>
>
>
> Rodrigo Almeida de Oliveira, CBTS®
>
> Gerente de Projetos/Gerente de Qualidade e Processos
>
> Certificado em Testes de Software - CBTS
>
> http://www.linkedin.com/in/raoliveira
>
>
>
>
>
> From: an...@googlegroups.com [mailto:an...@googlegroups.com] On Behalf Of
> Paulo Vasconcellos
> Sent: quinta-feira, 29 de outubro de 2009 12:04
> To: an...@googlegroups.com
> Subject: [an.br :: 4477] Re: Prazo, Custo e Escopo
>
>
>
> Pois é, Jean
>
>
>
> Qualidade não é ou não deveria ser uma variável nessa equação.
>
>
>
> Abraços,
>
>
>
> Paulo
>
> (Respondi antes de ver o link que o Paulo sugeriu).
>
> Reforça o que disse quando ele escreve:
>
> Quality is placed in the middle under the premise that we don’t mess with
> quality.
>
>
Rodrigo
Caro Paulo, qualidade tem custo. E tem risco também.
Se eu sou cliente e quero uma Ferrari mas não tenho dinheiro para pagar, logo tenho duas opções:
1) Pagar pela Ferrari arrumando o dinheiro de alguma forma
2) Abrir mão da qualidade e ficar com o Uno-1996, que é o dinheiro que eu tenho para fazer o projeto.
Para fazer uma Ferrari terei mais riscos do que comprar um uno-1996. E para aceitar/evitar/mitigar os riscos da opção 1 terei mais custos do que na opção 2.
É simples assim. É uma questão de escolha. Se está no PMBOK é porque o restante das pessoas, tirando vc e a torcida do Corinthians e o Cohn, aceitam o PMBOK como um guia de melhores práticas para gestão de projetos. Melhores práticas disseminadas pelos melhores profissionais de gerência de projetos do mundo e que tem feito o sucesso dos projetos aumentarem nos últimos anos.
Mesmo não podendo pagar, vc faria a Ferrari para o cliente que só tem como pagar pelo UNO-1996? Assumiria estes riscos?
Eu não.
Quem assume este projeto nestas condições para mim é irresponsável.
Atc.
Rodrigo
Paulo Vasconcellos
Sérgio Cintra
Permitam-me uma observação, risco em latim significa ousar.
Ousar num projeto com custo, prazo e escopo definidos e fechados não faz sentido, a menos que queira rever a qualidade.
Um abraço, Sérgio
No virus found
in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.698 / Virus Database: 270.14.38/2467 - Release Date: 10/29/09
05:38:00
Jean Streleski
Um tinha motor de 450cv outro de 67cv. Se ambos funcionam, então, ambos tem qualidade.
São dois carros, cada um com seu escopo.
Agora eu me sentiria irresponsável ao me propor fazer um UNO que deveria ter 67CV e fazer ele ter uns 30CV só.
É isto que acredito que não possa ser variável.
Rodrigo
Então, é isso que eu quero dizer. Em função da qualidade melhor que é a Ferrari (escopo), vamos gastar mais. Por se ter um escopo menor (UNO) vamos gastar menos com qualidade.
O que não dá é exigir de um UNO a qualidade que se tem numa Ferrari e querer pagar somente pelo escopo do UNO!
Não dá para ter um escopo com muitos requisitos (Ferrari) e querer pagar somente pelo escopo do UNO!
Rodrigo
Paulo, vou pesquisar mais estes números.
Mas em clientes meus que gerenciam projetos baseados no PMBOK, houve aumento de mais de 70% de sucesso nos projetos que eles conduziram. Projetos de desenvolvimento de software.
Aqui na empresa implantamos uma metodologia de GP aliada a uma metodologia para desenvolvimento de software, que reduziu em 50% o número de erros em produção nos clientes.
Ronan Lucio
"Um cliente pode querer mais qualidade em um projeto e menos em outro."
Entendo e respeito a sua opinião, porém, penso da mesma forma que o Jean.
"Qualidade não deveria ser negociável."
[]s
Ronan
Jean Streleski
Se o cliente quer um UNO ele terá escopo de UNO e terá toda as qualidades de UNO (pobres proprietários de UNO ! hehe).
Ou seja, o escopo do UNO diz que não tem retrovisor elétrico mas tem um retrovisor manual. Legal! Mas o retrovisor manual não pode vir sem o espelho e o ajuste interno (Qualidade não variou).
O cliente pode pedir pra tirar o retrovisor do lado direito e esquerdo? Pode..vai variar o escopo.
A empresa que vende o UNO pode aceitar entregar um automóvel sem pelo menos o do lado esquerdo? NÃO. Deve indicar ao comprador que isto é essencial. E caso o cliente insista, NÃO vender o UNO mas sim uma bicicleta =)
Ronan Lucio
E mantendo a analogia.
Não vai dar bug por falta de testes.
Os botões de liga e desliga vão estar devidamente posicionados conforme o planejado, para um alcance rápido e prático (requisitos não-funcionais), embora o todo tenha menos recursos.
Isso é qualidade.
[]s
Ronan
Ricardo Daniel Agulhari
Pessoal,
Só dando um pitaco no assunto, acho que houve uma diferença na conceituação de “Qualidade” neste caso... Só para ver se estou entendendo os pontos de vista colocados na discussão:
Rodrigo, quando você fala de “Qualidade”, o que está se falando é que um sistema terá mais ou menos recursos que diferenciarão o produto. Só alterando um pouco sua analogia do Uno e da Ferrari, seria como se o usuário quisesse comprar um sistema A desenvolvido em SOA, com as últimas tecnologias de desenvolvimento de interfaces (AJAX, etc.) e todo o pacote do melhor banco de dados, mas só tem dinheiro prá comprar este sistema A desenvolvido em linguagens arcaicas com bancos de dados ultrapassados. Entendi direito?
Neste caso, acho que todos concordamos com sua afirmação (não dá prá cobrar o valor de um sistema na linguagem arcaica e entregar um SOA todo moderno), mas neste caso a sua “Qualidade” seria o escopo, como o Jean e o Paulo já comentaram.
A Qualidade, no caso, é garantir que um sistema saia com o mínimo de defeitos possível, passando por etapas de testes integrados, testes funcionais, etc.. Neste caso não é nem um pouco recomendado abrir mão da Qualidade. O mínimo que o cliente espera quando pede um sistema, não importando qual seja, é ter um produto com nenhuma falha (mas sabemos que não funciona assim). Acho que todos sabemos as consequências de entregar um sistema “bugado” para o cliente.
Espero ter contribuído de alguma forma.
Abraços,
Ricardo Agulhari
Rodrigo
Não deveria, mas é. Pelo menos comigo, eu negocio o nível de qualidade a todo momento. E deixo claro os riscos que as escolhas implicam e os custos que teremos. Juntamente com a mudança de escopo e prazo que serão necessários para atender aos requisitos de qualidade.
Teve projeto que o cliente pagou para NÃO testar o software gerado como produto do projeto. Segundo ele, não era necessário pois ele iria fazer os testes. Falei que não era a melhor escolha, que iria ficar mais caro...
Ele insistiu e depois que deu errado, na primeira entrega, ele solicitou a mudança no projeto quanto ao escopo e prazo para realização dos testes. Ele pagou mais por mais qualidade!
Atc.
Rodrigo
Rodrigo
É isto mesmo. Qualidade está ligada ao escopo sim. E também a prazos e custos do projeto. Posso contratar um estagiário para fazer os testes ou um engenheiro de testes sênior. Vai depender do prazo/escopo/custo/riscos do projeto!
Mas podemos ter no projeto pessoas com mais experiência para fazer os testes. Ou não. Vai depender do nível de qualidade que o cliente quer. Posso ter um campo de prova em Maranello para testar meu Uno. Certo? E isto custa muito caro, certo?
Ou simplesmente dar uma volta em torno da Fiat aqui em Betim-MG e pronto! Tá testado! E para uma amostra apenas. Não para todos os carros fabricados.
O que eu quero deixar claro é que temos sempre que balancear as cinco variáveis: ESCOPO/CUSTO/PRAZO/RISCO/QUALIDADE.
Muitas vezes o escopo é o mesmo. Uma geladeira por exemplo. Uma é Brastemp! Outra é xing-ling, feita por escravos na China. Ambas tem os mesmos itens de escopo e requisitos. Qual vc acha que tem melhor qualidade? A chnesa?
Atc.
Rodrigo
Tales Costa
(Escopo * Qualidade) / (Prazo * Recursos)= k
Um complicador comum é que muitas vezes os
conceitos/definições/entendimentos do que é Escopo .vs. o que é
Qualidade são diferentes e difusos entre os diversos stakeholders.
Como se pode observar nos posts aqui.
[ ]´s
Tales Costa
2009/10/29 Paulo Vasconcellos <pfvasco...@gmail.com>:
>> (Respondi antes de ver o link que o Paulo sugeriu).
>>
>> Reforça o que disse quando ele escreve:
>>
>> Quality is placed in the middle under the premise that we don’t mess with
>> quality.
>>
Gerson Dias
Não concordo com Prazo * Recursos nesta relação inversamente proporcional, já que muitas vezes o fato de colocar mais pessoas para fazer algo não quer dizer que aquilo será feito mais rápido, isso já disse nosso amigo Fred Brooks.
E tem aquela velha história que muitos gerentes teimam em não entender que colocar três mulheres juntas não fará com que o filho nasça em três meses!
De qualquer forma, meu pitaco é que Qualidade deve vir do profissionalismo da empresa e de cada profissional envolvido. Uma empresa não quer q eu teste o software que eu faço? ok, então não aceito o projeto. Se sou fornecedor de software, minha missão é "entregar software funcionando", ou é isso, ou não é nada. Deve haver essa ética nas relações. Sendo assim, sim, qualidade é inegociável!
Gustavo Tavares
O pessoal limita alguns conceitos em virtude do que está na moda e esquece de considerar o que acontece no dia-a-dia das empresas e das equipes. Neste tópico mesmo estamos vendo isto. Opiniões contraponto as práticas ágeis com o que é prescrito no PMBoK. Como se algum dia houvesse o mínimo conflito entre as duas abordagens.
[]'s
Gustavo Tavares
Lkdin: www.linkedin.com/in/gustavares
Via6: www.via6.com/gustavares
Ronan Lucio
Não concordo com Prazo * Recursos nesta relação inversamente proporcional, já que muitas vezes o fato de colocar mais pessoas para fazer algo não quer dizer que aquilo será feito mais rápido, isso já disse nosso amigo Fred Brooks.
@Gerson
Ou seja, quanto mais Requisitos, mair o prazo.
@Tales
Poderias ser mais claro na tua colocação?
Recursos = Recursos Humanos ou Recursos de Software / Requisitos?
[]s
Ronan
Ronan Lucio
Ronan,Como eu disse, a do Cohn é mais sofisticada e 'boazinha'. Mas acho que a minha pode representar um bom ponto de partida. Mais seguro, eu diria.
E o legal da ideia do Cohn é que dá pra fazer até em um guardanapo... haha
[]s
Ronan
Leandro Mendonça
Não vi esse PMBOK 2008, mas se eles aumentaram de 3 para 5 restrições,
aí é que eu não vou ler mesmo.
A definição de Qualidade é: entregar o que foi prometido. Não faz
sentido comparar Uno com Ferrari pois a "promessa" é completamente
diferente. A Qualidade do Uno é a qualidade do Uno e a da Ferrari é a
da Ferrari, como foi muito bem observado por alguns colegas.
Quando deixamos de entregar ou entregamos com defeito algo que foi
prometido, estamos atentando contra a Qualidade.
Quando informamos que o Uno não terá desembaçador traseiro estamos
renegociando escopo.
Quanto aos Riscos, que seriam a outra nova ponta desse pentagrama
(pentagrama do capeta!!), não faz sentido destacá-los pois eles também
não são objeto de negociação. Riscos são consequencia e não causa. Os
riscos permeiam todos os aspectos do projeto, e os principais riscos
de qualquer projeto estão relacionados às demais restrições: riscos de
escopo, riscos de prazo e riscos de custos.
Acho essa disciplina de Riscos extremamente importante na gestão de
projetos, mas considero um erro trazê-la para essa discussão sobre
negociação de variáveis.
Abraços,
Leandro
> 2009/10/29 Gerson Dias <gerson.dias....@gmail.com>
Shigueru
Qualidade é atender plenamente o escopo. Simples assim.
O cliente quer um carro rápido? Quão rápido? Como um Uno? Então não
pode ser como uma bicicleta. O carro deve se locomover (obviamente).
Não posso entregar um produto que eu nem sei se anda. Tenho que
testar. Se o cliente bater o pé que não precisa testar porque ele acha
que não é necessário, que procure outra montadora. O cliente vai andar
no trânsito caótico de São Paulo? Esse é o objetivo? A Ferrari aqui é
sinônimo de qualidade?
Qualidade deve ser inegociável.
[]s
Shigueru.
> 2009/10/29 Gerson Dias <gerson.dias....@gmail.com>
Tales Costa
Não entendi o que vc quis dizer com "Prazo * Recursos nesta relação
inversamente proporcional", me parece que estamos interpretando a
equação de formas diferentes.
O que essa equação mostra é que se aumentar Escopo OU Qualidade, então
o Prazo OU Recursos também irá/irão aumentar, pois o k é uma
constante. E Recursos deve ser entendido como custo, não apenas
pessoas.
[ ]´s
Tales Costa
2009/10/29 Gerson Dias <gerson....@gmail.com>:
>> >> (Respondi antes de ver o link que o Paulo sugeriu).
>> >>
>> >> Reforça o que disse quando ele escreve:
>> >>
>> >> Quality is placed in the middle under the premise that we don’t mess
>> >> with
>> >> quality.
>> >>
Tales Costa
Na equação Recursos representa o que é "consumido" pelo projeto para
atender determinados Escopo, Prazo e Qualidade. Em outras palavras, o
custo do projeto em pessoas, equipamentos, serviços, ...
[ ]´s
Tales Costa
2009/10/29 Ronan Lucio <ronan...@gmail.com>:
Ronan Lucio
Paulo Vasconcellos
Wow... o papo rendeu, hem? Agradeço a todos pelo alto nível do papo. Mas devo agradecer Ronan, Jean, Leandro e Shigueru por me mostrarem que não estou ficando maluco. Não que eu considere o outro lado doido, não é isso. Mas não seria a primeira vez que eu estaria 'sozinho' defendendo uma coisinha que me parece pra lá de fechada. Fico com o Leandro: se o PMBoK (cuja nova versão também desconheço) pretende complicar o mundo assim, vade retro!
Quanto ao papo PMBoK x Ágil me limitarei a dizer o seguinte: há muita incompatibilidade sim. Entre os 'mind sets' que eles criam. Me perdoem, mas o PMBoK é meio "velhinho" para projetos de software. Não é por isso que não seguirei considerando-o cartilha básica para todos os coordenadores de projetos. Espero ver, daqui alguns anos, a trilha inversa. Gente treinada em Scrum, por exemplo, estudando depois o PMBoK. Qual será a leitura e o choque?
Rodrigo, obrigado e parabéns pelos números alcançados. Invejáveis, eu diria.
Abraços,
Paulo
ps: Finalmente em SJC, depois de mais de 8 horas de estrada (Fernão Dias, Ayrton, Dutra... Ô vida!)
Gustavo Tavares
Não existe qualquer incompatibilidade entre PMBoK e metodologias ágeis. Primeiro que: sendo ágil ou não o desenvolvimento de software em 90% dos casos é um projeto. A incompatibilidade que existe é entre as metodologias waterfall, RUP e os modelos ágeis. Mas ambas as metodologias podem e são utilizadas em projetos. E um projeto, se quiser ser bem gerenciado, deve ser feito levando-se em conta algumas das considerações do PMBoK.
Como eu disse, as metodologias ágeis estão na moda. E agora são a bala de prata para resolver os problemas desenvolvimento de software. Quem sabe serão necessários mais alguns anos para os defensores xiitas da agilidade perceberem que não existe bala de prata; de novo. Mas até que isto aconteça eles vão continuar com o "mind-set" que você demonstrou: "não li e não gostei", ou melhor: "não entendi mas tenho certeza que não funciona".
Depois de passados estes anos, depois que as metodologias ágeis não conseguirem resolver todos os problemas do desenvolvimento de software, alguns destes defensores irão pular para o próximo modismo. Criar novos produtos para vender, criar novos treinamentos para ministrar. Outros irão começar a perceber que estas diversas metodologias são na verdade complementares. E que grande parte dos problemas que todas elas tentaram resolver no passado não são problemas a serem resolvidos com metodologias.
Atenciosamente,
Gustavo Tavares
Elaine
Gostaria de acrescentar que o conceito de qualidade pode ser muito
relativo. Em geral, o que pode ser qualidade para um pode não ser para
outro. Esta percepção varia de pessoa para pessoa, de cliente para
cliente.
QA é super importante, mas não é suficiente para entregar qualidade
para o cliente. Um cliente pode esperar defeito zero, outro um
atendimento mais cortês, outro um atendimento mais formal, um quer
sistema on-line com dash-boards para acompanhar o atendimento, outro
prazos extremamente agressivos, um quer contato diário, outro quer
apenas acompanhamento em marcos importantes etc.
Acho que esses são itens que devem ser considerados quando se fala de
qualidade, considerando que todos os esforços de qualidade são
voltados para o cliente.
[]s,
Elaine
> Gerson / Tales,
>
> 2009/10/29 Gerson Dias <gerson.dias....@gmail.com>
Shigueru
Sim, é relativo. Relativo ao escopo! Por isso "Qualidade é atender
plenamente o escopo".
[]s
Shigueru.
Rodrigo
custos do projeto. Posso contratar um estagiário para fazer os testes ou um
engenheiro de testes sênior. Vai depender do prazo/escopo/custo/riscos do
projeto!
Mas podemos ter no projeto pessoas com mais experiência para fazer os
testes. Ou não. Vai depender do nível de qualidade que o cliente quer. Posso
ter um campo de prova em Maranello para testar meu Uno. Certo? E isto custa
muito caro, certo?
Ou simplesmente dar uma volta em torno da Fiat aqui em Betim-MG e pronto! Tá
testado! E para uma amostra apenas. Não para todos os carros fabricados.
O que eu quero deixar claro é que temos sempre que balancear as cinco
variáveis: ESCOPO/CUSTO/PRAZO/RISCO/QUALIDADE.
Muitas vezes o escopo é o mesmo. Uma geladeira por exemplo. Uma é Brastemp!
Outra é xing-ling, feita por escravos na China. Ambas tem os mesmos itens de
escopo e requisitos. Qual vc acha que tem melhor qualidade? A chnesa?
Atc.
Rodrigo
From: an...@googlegroups.com [mailto:an...@googlegroups.com] On Behalf Of
Paulo Vasconcellos
32 horas depois, cá estou de volta ao Sul de Minas. Cansado pacas, mas cometi o erro de ligar o micro. Então vamos lá:
@Rodrigo,
Você pode fazer o upload de arquivos diretamente. Não precisa de minha intervenção, ok?
@Gustavo,
Vamos clarear alguns pontos? Ser chamado de 'agilista xiita', mesmo q indiretamente, era a última coisa que me faltava. Para alguns agilistas de carteirinha eu não passo de um 'cascateiro' ou algo do tipo. Provavelmente em todos os sentidos aplicáveis. Detesto dogmas e 'religiões', meu caro. Minha avaliação e impressão (sobre o PMBoK ou qq outra coisa) são frutos exclusivos das experiências que vivenciei ou testemunhei de alguma forma. Conheço versões anteriores do PMBoK o suficiente para ter minha própria opinião. A última versão, que está em questão, eu realmente não conheço. Fiquei sabendo que se meteram a falar sobre levantamento de requisitos e coisas do tipo. Acho indevido, mas não vem ao caso. Aliás, se for o caso de debater o PMBoK, acho conveniente que outra thread seja aberta. Esse papo começou a me lembrar de algo que já aconteceu em outros fóruns, particularmente no finado CMM-Br. Espero que a gente não caia no mesmo buraco negro. Respeito sua opinião e experiência. Minha visão sobre o PMBoK é um tanto diferente e ainda não vi razão para mudá-la.
Outro ponto: em nenhum momento, aqui no grupo ou em qualquer outro repositório, eu afirmei ou dei a entender que propostas ágeis configuram-se uma "bala de prata". Vinte e tantos anos de carreira em TI ensinam pelo menos uma coisa: a desconfiar. Como sou mineiro, imagine só o nível de desconfiança que deposito em tudo. Por isso sou muito lento. Falei sobre Scrum pela primeira vez lá nos idos de 2005. Comecei a sugerir sua adoção mais de 2 anos depois. Resumindo: modas não me pegam. Sou lento!
Espero que assim a gente consiga reposicionar o debate. Não tive a intenção de ofender ninguém que goste do PMBoK. Mas seguirei criticando-o sempre que achar necessário. E deixando meus argumentos com uma tag do tipo: pode descer o pau. Como já dizia o saudoso Vicente Matheus, "quem sai na chuva é pra se queimar".
Abraços,
Paulo
Giovanni Bassi
Não torço pro corinthians, e meu nome não é Paulo, ou Cohn. Ainda assim, compartilho a visão que o Paulo expressa no seu e-mail. E ele não disse que o PMBoK é uma carta do demônio, e que suas práticas não são válidas. É o conjunto da obra é que é ruim, e acabam levando para algo que já descobrimos que não funciona em desenvolvimento de software (ainda que os PMPs que estão por aí estejam desesperadamente querendo tirar leite de pedra e mostrar que até o PMBoK pode ser ágil - mas não vou entrar nessa questão). Ainda assim há práticas lá que são muito interessantes.
Agora.. o que me interessou mesmo foi essa frase:
Melhores práticas disseminadas pelos melhores profissionais de gerência de projetos do mundo e que tem feito o sucesso dos projetos aumentarem nos últimos anos.
Será que queremos tanto acreditar que aprendemos a fazer software que estamos acreditando nisso, ainda que constamente projetos conduzidos a la PMI falhem com frequência altíssima, conforme apresentado pelo Standish Group?
O interessante é que os critérios de sucesso aplicados no Chaos Report praticamente não se aplicam a projetos ágeis, já que alguns dos critérios de falha são projeto entregue fora do prazo, ou com escopo diferente do esperado, e em projetos ágeis todos entendem muito bem que estimativas não são contratos assinados com sangue, e que o escopo varia naturalmente.
[]'s
Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com
Caro Paulo, qualidade tem custo. E tem risco também.
Se eu sou cliente e quero uma Ferrari mas não tenho dinheiro para pagar, logo tenho duas opções:
1) Pagar pela Ferrari arrumando o dinheiro de alguma forma
2) Abrir mão da qualidade e ficar com o Uno-1996, que é o dinheiro que eu tenho para fazer o projeto.
Para fazer uma Ferrari terei mais riscos do que comprar um uno-1996. E para aceitar/evitar/mitigar os riscos da opção 1 terei mais custos do que na opção 2.
É simples assim. É uma questão de escolha. Se está no PMBOK é porque o restante das pessoas, tirando vc e a torcida do Corinthians e o Cohn, aceitam o PMBOK como um guia de melhores práticas para gestão de projetos. Melhores práticas disseminadas pelos melhores profissionais de gerência de projetos do mundo e que tem feito o sucesso dos projetos aumentarem nos últimos anos.
Mesmo não podendo pagar, vc faria a Ferrari para o cliente que só tem como pagar pelo UNO-1996? Assumiria estes riscos?
Eu não.
Quem assume este projeto nestas condições para mim é irresponsável.
Atc.
Rodrigo
From: an...@googlegroups.com [mailto:an...@googlegroups.com] On Behalf Of Paulo Vasconcellos
Sent: quinta-feira, 29 de outubro de 2009 12:25
Subject: [an.br :: 4479] Re: Prazo, Custo e Escopo
Olá Rodrigo,
Existem visões e visões, né? Não é por acaso ou birra que não gosto muito do PMBoK. Sigo com o Cohn (e a torcida do Corinthians) ao não negociar a *qualidade*. E não vejo como os riscos entram na equação. Riscos eu combato diariamente, para não ser derrubado por eles. Assumimos mais ou menos riscos dependendo da variável fixada, é certo. Mas o que negociamos, afinal?
Abraços,
Paulo
2009/10/29 Rodrigo <rodrigoalmei...@gmail.com>
Discordo.
Pelo PMBOK 2008, os projetos passam a ter 5 RESTRIÇÕES: Escopo, Prazo, Custo, Qualidade e Riscos. Cada uma delas podem ser alteradas em função de outras. Um projeto pode assumir mais riscos do que outro. Um cliente pode querer mais qualidade em um projeto e menos em outro. Assumir riscos e ter mais ou menos qualidade impacta diretamente em escopo, custo e prazo.
Ter menos orçamento impacta em diminuir o escopo ou diminuir prazo ou diminuir qualidade e diretamente pode aumentar os riscos do projeto.
Tudo deve ser avaliado e APROVADO pelo cliente!
Rodrigo Almeida de Oliveira, CBTS®
Gerente de Projetos/Gerente de Qualidade e Processos
Certificado em Testes de Software - CBTS
http://www.linkedin.com/in/raoliveira
From: an...@googlegroups.com [mailto:an...@googlegroups.com] On Behalf Of Paulo Vasconcellos
Sent: quinta-feira, 29 de outubro de 2009 12:04
To: an...@googlegroups.com
Subject: [an.br :: 4477] Re: Prazo, Custo e Escopo
Pois é, Jean
Qualidade não é ou não deveria ser uma variável nessa equação.
Abraços,
Paulo
Giovanni Bassi
Se você vai ao médico, e ele diz que precisa operá-lo, você tem autoridade para dizer se ele deve ou não lavar a mão antes de realizar a operação? Você pode dizer a ele que não deve lavar a mão ou esterlizar os instrumentos e como isso vai exigir menos tempo dele, então ele deve cobrar um pouco mais barato pela cirurgia?
É claro que não.
Ele é um profissional, e não abre mão das praticas que permitem que ele se intitule como tal - lavar as mãos antes de operar, por exemplo.
Seguindo a analogia do Uncle Bob, cabe a nós nos comportarmos profissionalmente, e não permitir projetar software sem testes (ou sem qualidade). É simples assim. Eu simplesmente não acho que essa decisão caiba ao seu cliente. Ou nem mesmo a você, como gerente de projetos, mas cabe aos seus engenheiros de software. O seu papel como gerente é compor uma equipe que entenda isso.
É muito comum ouvirmos a história de que o cliente exigiu e a gente fez. Isso pra mim é algo que não deveria ser aceito em hipótese alguma. É aquele tipo de comportamento passivo-agressivo que não ajuda em nada o projeto. Se você aceitou o título de gerente de projeto, você assumiu a responsabilidade pela entrega implícita que esse título traz. Entregar com problema no final e culpar o cliente não está condizente com esta responsabilidade. Se eu pago um gerente de projeto para "garantir o sucesso do projeto" e ele não faz isso, podia ter feito o projeto sem ele.
Por fim, eu acho que esse título não serve para a industria de software. Já percebemos que a atitude deve ser de colaboração, e não comando e controle, que é o que o nome "gerente de projetos" implica. Além disso, essa posição acaba sendo extremamente infeliz em software, já que é muito difícil entregar software desta forma. Não sei como os gerentes de projeto não percebem, falha após falha...
Não deveria, mas é. Pelo menos comigo, eu negocio o nível de qualidade a todo momento. E deixo claro os riscos que as escolhas implicam e os custos que teremos. Juntamente com a mudança de escopo e prazo que serão necessários para atender aos requisitos de qualidade.
Giovanni Bassi
Se isso não é incompatibilidade, não sei o que é...
Giovanni Bassi
Rodrigo
Acho que errei na minha afirmação sobre o sucesso dos projetos. Peço desculpas a todos.
Mas aqui na empresa após usarmos metodologia de GP baseada no PMI, passamos a ter sucessos no projetos, entregando no prazo, com o custo e escopo e nível de qualidade acordado com o cliente.
Atc.
Rodrigo
Rodrigo
Caro Giovanni. Estamos falando de projetos de desenvolvimento de algum produto.
Práticas médicas são processos definidos e não está em questão aqui processos e sim qualidade em projetos. Uma vez definidos os processos (muitas vezes são produtos de um projeto!!!) devem ser cumpridos. E mesmo assim existe o risco de ter contaminação. O nível de risco será maior ou menor a partir do que está definido como nível de qualidade do hospital . O hospital Souza Aguiar no Rio tem um nível de qualidade. O Albert Einstein em São Paulo tem outro muito maior. E um custo para o paciente muito maior também. Eu posso querer ser operado no Souza Aguiar, pois é pelo SUS e é mais barato. Eu sou o cliente. Eu escolho. E assumo os riscos. E assino um termo de responsabilidade ISENTANDO O MÉDICO de problemas que eu posso ter devido a contaminação hospitalar.
Sucesso em projetos também é atender bem o cliente, entregar o que ele quer e somente o que ele quer. O PMI diz isto. O Scrum faz isto na prática.
Clientes querem níveis de qualidade. E um nível maior ou menor implica em ter riscos. É disto que estou falando. O cliente tem que saber destes riscos e estar ciente dos impactos caso o risco aconteça.
Se um projeto tem um escopo, custo e prazo para cumprir , vc ficaria investindo em qualidade indefinidamente? Nos projetos que você trabalha, sempre tem os melhores profissionais existentes para a realização das atividades? Se não estiverem disponíveis vc os contrata mesmo que isto estoure os custos do projeto, sem precisar informar o cliente e ter o aval dele? Simplesmente manda a conta da projeto com o valor da qualidade QUE VOCÊ ACHA que é a melhor para o cliente ? E o seu cliente concorda em alterar o custo do projeto por estes motivos? E se não concordar? O que vc faz? Paga os custos do SEU BOLSO?
Atc.
Rodrigo
Gustavo Tavares
Em momento algum me senti ofendido por gostar de PMBoK. Não cabem desculpas relativas a isto até porque estamos em um debate de idéias e estamos dispostos a ter nossas opiniões questionadas. Certo? Mas continuando o debate: eu acredito que você seja um "agilista xiita" pela seguinte razão: Você deixou bastante claro que considera as metodologias ágeis incompatíveis com o PMBoK, mesmo tendo também deixado claro que não conhece bem o que prega o PMBoK. Você demonstrou a opinião: "não provei mas já sei que não gosto", "não conheço mais sei que agilidade é melhor". Isto para mim é uma atitude xiita. Isto para mim é ser dogmático.
Eu gostaria agora de tentar explicar o porque PMBoK não é incompatível com agilidade. Se estiver disposto a me escutar peço um pouco de paciência, pois meus argumentos serão um pouco detalhados.
Para começar acredito ser importante entendermos o quê em essência o PMBoK prega. Em um resumo bem grosseiro (e bota grosseiro nisto) basicamente o que o PMBoK diz é o seguinte: "Sempre que você for fazer algo, pense em como você vai fazer". Isto vale para todo tipo de coisa. Se você for pensar em construir um prédio, pense em como você vai construir. Se você vai criar um novo shampoo, pense em como você vai criar este novo shampoo. O mesmo vale para software. Se você vai desenvolver um software, pense em como você vai desenvolver. Isto é o que o PMBoK prega. Nada além. Qualquer edição do PMBoK pode ser grosseiramente resumida nesta idéia.
Agora considerando que o foco da discussão aqui sempre foi software, como o PMBoK se aplica nesta situação e como ele interage com as metodologias ágeis? Simples. Antes de você iniciar o desenvolvimento do software você olha as características gerais deste "projeto de software" e pergunta: Qual a metodologia mais adequada para produzir este tipo de software? RUP, Waterfall, Modified Waterfall ou Scrum? Olhando para o que você tem em mãos (a idéia do software) você escolhe qual a metodologia melhor se aplica a sua situação.
Isto quer dizer que você, Paulo Vasconcellos, quando reune uma equipe de desenvolvedores; define que vai criar um software utilizando Scrum; informa a sua equipe quem é o Product Owner; escolhe um Scrum Master e incentiva a auto organização você, basicamente, faz o planejamento de um projeto exatamente como prega o PMBoK. Se você quiser até melhorar um pouquinho você pode escrever um documento com a lista de pessoas na equipe, o nome do product owner e o nome do scrum master. Neste mesmo documento você escreve uma frase que diga algo semelhante a "este projeto obedecerá as diretrizes do scrum" e pronto. Você tem um plano de projeto exatamente como prega o PMBoK.
Seu plano de projeto, é lógico, não vai ter uma seção de gerenciamento de comunicação. Seu plano de projeto não vai ter uma seção de gerenciamento de riscos. Seu projeto sequer vai fazer o gerenciamento de aquisições. Mas isto não tem importância. Seu gerenciamento de comunicação vai ser feito de acordo com as diretrizes do Scrum. Seu projeto não vai se preocupar em gerenciar riscos por questões que você saberá responder melhor do que eu. Mas isto não te torna incompatível com o que prega o PMBoK. Afinal de contas, antes de começar você pensou em como iria desenvolver o software. E você chegou a conclusão que utilizar a metodologia Scrum seria a melhor opção.
Portanto, apesar de suas experiências anteriores e seus vinte e tantos anos de carreira em TI, você realiza os seus trabalhos de acordo com a essência do PMBoK. Você não concorda e até desmerece o PMBoK, mas sem saber segue exatamente a essência do que este corpo de conhecimento prega. Como um dogmático você apenas não está disposto a reconhecer. Faz o que é pregado mas se coloca em uma posição, supostamente, crítica ao que o PMBoK prega.
Agora a segunda parte da polêmica; e se me permite, mais uma grosseria: Você é um agilista xiita também por uma outra razão: a tal da bala de prata. Como eu disse anteriormente, toda vez que alguém vai iniciar o desenvolvimento de um software ele olha para as características do "projeto" e se pergunta: Qual a metodologia mais adequada para produzir este software? Por todos os seus e-mails eu cheguei a conclusão que você sempre vai responder "SCRUM". Se eu te perguntar porque você vai me dizer: Porque é uma metodologia que possibilita a auto organização da equipe, porque ela possibilita uma determinação dos requisitos de forma incremental, aumenta a proximidade dos desenvolvedores com os usuários, etc e etc. Você obviamente está correto. O Scrum te traz todas estas vantagens. Mas e o software que você vai desenvolver? Ele tem as características que possibilitam a aplicação da metodologia Scrum?
Vou te contar uma coisa que possivelmente vai fazer você cair da cadeira. Você e todos os agilistas xiitas. Nem todos os projetos de software possuem requisitos ainda não definidos. Nem todos os projetos de software possuem requisitos com alta volatividade. Nem todas as equipes possuem condições de se auto gerenciar. Nem todos os clientes de software estão disponíveis para negociar com a equipe de desenvolvimento. E vocês, agilistas xiitas, devem deixar de fingir que isto não acontece. Devem deixar de dizer: "mas as características do desenvolvimento de software são essas" e fazer birra quando alguém pede um prazo e um custo para o desenvolvimento de um software. Um bom responsável por desenvolver sofwares deve saber que, em algumas situações, ele deverá optar por RUP ao invés de Scrum. Em algumas situações ele deverá optar por (pasmén) waterfall ao invés do Scrum. E em outras situações ele deverá optar pelo Scrum. Responsáveis por desenvolvimento de software e consultores que acreditam que o Scrum é a melhor opção sempre são profissionais limitados e ineficientes. E, me desculpe, por todas as mensagens que você enviou para este fórum, eu considero você como um destes profissionais.
Quer provas do que falei no parágrafo anterior? Ok! Imagine um banco que tem que adaptar seus sistemas ao novo modelo de pagamento DDA (Débito Direto Autorizado). Com um bom método de rastreamento de componentes, os requisitos deste projeto estão muito bem definidos e delimitados antes do início do mesmo. Eles não mudam na medida em que o software é desenvolvido. Imagine agora um projeto que tenha equipes de desenvolvimento distribuídas em quatro países com línguas diferentes, tendo que atender o cliente localizado em sete países diferentes. Em algumas situações os desenvolvimentos atendem a um cliente, em outras atendem a mais de um e em terceiras situações os desenvolvimentos atendem todos. Eu trabalhei em um projeto com estas características em uma empresa de software Indiana que atendia a uma multinacional fabricante de pneus. Consegue imaginar esta equipe se auto gerenciando? Imagine agora o desenvolvimento de um sofware para atender uma norma de um órgão regulamentador (CVM, ANATEL, ANEEL, BACEN, etc). Cadê o cliente a disposição para negociar prazos e requisitos a serem desenvolvidos?
Enfim, PMBoK e Scrum não são nem um pouco incompatíveis. O PMBoK está apenas uma camada acima do Scrum. Não é melhor, não vem antes, nem nada disto. Só trata de assuntos diferentes. PMBoK trata de projetos que são iniciativas únicas para se produzir algo. Scrum trata de desenvolvimento de software. Os dois podem ser perfeitamente combinados. Um projeto com fases de acordo com o que determina o Scrum. É isto. Quem diz que as duas coisas são incompatíveis diz isto somente por desconhecimento.
suzandeise
em tão pouco tempo... Vou botar mais lenha na fogueira.
Concordo com o o Paulo e com os que reforçaram sua explicação de que
as pontas do triângulo são prazo, custo e escopo.
A análise de riscos gera decisões relacionadas a prazo, custo e escopo
(ex., e não lançarmos o produto até tal data, o concorrente sairá na
nossa frente).
O Shigeru explicou bem, “qualidade é atender plenamente o escopo”;
“qualidade deve inegociável”; e qualidade é relativa ao escopo. O post
do Mike Cohn mencionado pelo Paulo deixa claro no primeiro parágrafo
que qualidade fica no meio do triângulo (prazo, custo e escopo) e que
ele nem vai discutir qualidade pois parte da premissa que não devemos
mexer com ela.
Não vou entrar na discussão de se são 3 ou 5 restrições mencionadas no
PMBOK 4. Ainda preciso estudá-lo melhor pra poder discutir isso. Mas
já adianto que acho produtivo estudá-lo pra poder contribuir não só em
discussões como esta, mas também em discussões com o IIBA e com o
PMI. Confesso que sou idealista e sonhadora...
Pra quem não olhou ainda a quarta edição 4 do PMBOK, vou colocar meus
comentários num novo thread.
-Suzandeise
Paulo Vasconcellos
- Eu *conheço* o PMBoK desde 1997.
- Não estudei nem li a última versão porque dediquei meu tempo em coisas mais úteis.
- Um dos serviços que ofereço é a *engenharia de processos*. Não conseguiria fazê-lo e seria desonesto em apresentar tal proposta se não conhecesse uma gama razoável de métodos, processos ou metodologias (escolha o nome que quiser).
- Em uma thread colocada ontem eu tentei demonstrar o tanto que o PMI e, infelizmente, o IIBA, se baseiam em ideias "velhinhas".
- Sou da idade do PMI. Ou seja, também sou velhinho.
- Mas procuro manter minha cabeça aberta, porque aprendi que em desenvolvimento de software toda certeza é relativa ou deveras perigosa.
- Como 7 é conta de mentiroso, encerro aqui minha resposta para seus argumentos "pouco detalhados".
Paulo Vasconcellos
- O exemplo do banco e do DDA é muito bom. Didático!
Não utilizamos um ciclo de vida 'iterativo e incremental' só porque um negócio (ou seus requisitos) é instável. Adotamos este ciclo e este mind-set quando chegamos a conclusão de que: - Somos humanos; consequentemente
- Vamos errar.
- Tá aqui a beleza desse ponto de vista. Não importa que os requisitos estejam 100% estabilizados. O fato é que a realização deles é um processo de aprendizado. Vários projetos, particularmente aqueles para desenvolvimento de software, simplesmente não podem abrir mão desse aprendizado.
- Todas as propostas de processos (ou metodologias ou ...) surgidas na última década apresentam derivações desta forma de pensar (aka "mind-set").
- Quem acha que Scrum só se aplica a projetos para desenvolvimento de software:
- Não conhece a teoria básica do Scrum; e, o que é pior...
- ... nunca teve o prazer de ver o método aplicado na prática.
- Scrum serve para o desenvolvimento de *qualquer* tipo de produto.
- Scrum é "bala de prata"?
- Meldels... não há bala de prata para lobisomem nenhum, ok?
- Há mais coisas entre os requisitos e o software do que supõe nossa vã filosofia.
Leandro Mendonça
Apesar do feriado, tirei o final do dia (pós ressaca) pra estudar e
isso passa por dar uma sapeada aqui no grupo.
@Shigueru,
Vou retomar a defesa das 3 x 5 restrições a partir da sua afirmação,
que considero incompleta:
"
> Qualidade é atender plenamente o escopo. Simples assim.
"
Na verdade, qualidade é atender plenamente escopo, prazo e custo. Se
você entregar o escopo correto, mas fora do custo ou do prazo
combinados, o seu projeto teve perda de qualidade.
Uma equação seria: qualidade = entrega / promessa.
@Elaine,
Essa visão de que qualidade é um conceito subjetivo já foi superada. A
Qualidade é tão objetiva quanto a nossa capacidade de definir os
requisitos do projeto.
"
On 30 out, 11:30, Elaine <elaine.ven...@gmail.com> wrote:
> Pessoal,
>
> Gostaria de acrescentar que o conceito de qualidade pode ser muito
> relativo. Em geral, o que pode ser qualidade para um pode não ser para
> outro. Esta percepção varia de pessoa para pessoa, de cliente para
> cliente.
>
> QA é super importante, mas não é suficiente para entregar qualidade
> para o cliente. Um cliente pode esperar defeito zero, outro um
> atendimento mais cortês, outro um atendimento mais formal, um quer
> sistema on-line com dash-boards para acompanhar o atendimento, outro
> prazos extremamente agressivos, um quer contato diário, outro quer
> apenas acompanhamento em marcos importantes etc.
>
> Acho que esses são itens que devem ser considerados quando se fala de
> qualidade, considerando que todos os esforços de qualidade são
> voltados para o cliente.
"
aos requisitos do projeto, da forma mais objetiva possível, de modo
que possam ser verificados. Se eles não podem ser manifestados de
forma objetiva pelo cliente (quantitativamente, de preferência) eles
não podem ser prometidos pelo fornecedor, logo não entram na
equaçãozinha ali em cima.
Abraços,
Leandro Mendonça
Shigueru
Leandro,
Você tem razão. Me detive apenas na analogia da Ferrari e do Uno e
acabei dizendo sobre qualidade do produto e não da qualidade do
projeto.
[]s
Shigueru.
Paulo Vasconcellos
Preciso dizer,
@Leandro,
Fantásticas as suas observações. Parabéns! E obrigado.
Abraços,
Paulo