[Artigo] Fracasso 2.0
Paulo Vasconcellos
Rodrigo Almeida de Oliveira
Paulo, tudo bom? Muito bom o seu artigo!
Paulo, já tivemos aqui uma discussão boa e extensa sobre a qualidade ser ou não um item negociável de um projeto.
Neste seu artigo, você mostra um novo triangulo com duas vértices focadas em qualidade (interna e externa). Como balancear isto se para muitos neste grupo qualidade não é negociável? O que você acha?
E você diz também que o plano para o PMBOK é uma camisa de força. Não é. Nunca foi. Nunca será. Ele diz que se precisar mudar algum requisito do projeto, o plano DEVERÁ ser mudado e aprovado por todos os stakeholders do projeto ou por um comitê de mudança. Simples. Ações corretivas são para ajustar desvios em relação ao planejado. Se um escopo/prazo/custo/qualidade foi acertado com o cliente, espera-se que se entregue o que ele pediu. Até no Scrum é assim. Entregar valor!
Rodrigo Almeida de Oliveira, PMP, CBTS®
Gerente de Projetos/Gerente de Qualidade e Processos
Project Manager Professional - PMP
Certificado em Testes de Software - CBTS
--
Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com
Para cancelar sua participação, mande um email para:
an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
Este grupo é administrado e patrocinado pelo finito: pfvasconcellos.com
Paulo Vasconcellos
E você diz também que o plano para o PMBOK é uma camisa de força.
Me parece inevitável uma revisão da definição de fracasso pelo Standish Group. Assim como espero um PMBoK mais orientado para a adaptação do que para ações corretivas (que visam a colocação do trabalho nos “trilhos” de um plano). Como insiste Jim Highsmith em mais de um trecho do livro,“planos (e arquiteturas) devem funcionar como guias e não como camisas-de-força”.
Rodrigo Almeida de Oliveira
Eu não revi porque acho que não está errado.
Peço desculpas por ter escrito o que eu escrevi. Deveria ter escrito que você citou o autor Jim Highsmith.
Porém, fiquei sem saber se você concorda com o que você escreveu e sustenta no artigo, que teremos que balancear o novo triangulo.
Atc.
Rodrigo
Paulo Vasconcellos
Flavio Clesio
A qualidade é independente do escopo, logo, independentemente daquilo que esteja sendo proposto ou feito.
Exemplo utilizando metafóricamente o caso do Uno e da Ferrari.
No conceito proposto pelo o Rodrigo, a qualidade é intrinsecamente ligada ao escopo, pois ele afirma, segundo palavras do Paulo "[...]mudança de um Uno (ou algo parecido) para uma Ferrari representava mudança da qualidade.[...]" .
Ou seja, o fato de ser um carro Ferrari, será de melhor qualidade independente de análise de seus processos de fabricação?
Vejamos...
Se uma Ferrari tiver falhas e necessite de um Recall de Freios e diferencial; e o Uno Mille, fabricado na mesma época não necessite desse Recall é correto ainda afirmar que a Ferrari TEM MAIS QUALIDADE?
A qualidade é ligada quase que por osmose com a EXCELÊNCIA TOTAL em todas as etapas do processo, independentemente do escopo principal; se pegarmos o modelo japonês de administração que foi o primeiro de fato a introduzir o termo Qualidade de forma abrangente, fica claro que a QUALIDADE é muito mais perfecionismo e a excelência dos processos do que Design.
Trazendo a discussão para o campo das metáforas:
Caro Rodrigo, dentro do seu paradigma de qualidade; o que você prefiriria?
a) Uma Ferrari no qual não foi atingida a Excelência Total em TODOS os seus processos de fabricação, mas que ainda sim é uma FERRARI...
Ou...
b) Um Uno Mille referência em excelência de todos os seus processos de fabricação, desde a colocação de um parafuso de careganem, até os dispositivos de segurança como Cinto de Segurança, Santo Antônio, Barras de Proteção Lateral e afins?
Não sou nenhum Gerente de Projetos, nem um Scrum Master nem nada relacionado, sou apenas mais um estudante querendo um lugar ao sol e todo dia aprendo um pouco aqui; mas acho que para se nortear uma discussão de processo de qualidade, devemos não apenas nos importar com Design e Renome; mas sim excelência em todos os aspectos.
--
Flavio Clesio - Bacharelando do Curso de Sistemas de Informação das Faculdades Integradas Rio Branco e Acadêmico do Curso de Análise e Desenvolvimento de Sistemas da Faculdade de Tecnologia (FATEC) São
Caetano do Sul
Tel: 8359-3989
Esporte Social - O esporte tratado de forma lúdica de sociabilização e saúde. - www.esportesocial.com
Paulo Vasconcellos
Rodrigo Almeida de Oliveira
Flavio, na minha opinião qualidade tem haver com escopo sim.
Mas vamos a um outro exemplo.
Duas geladeiras feitas com os mesmos insumos, tendo as mesmas funcionalidades. Uma é Brastemp. Outra é feita na China. Qual você compraria?
No seu exemplo, eu ainda prefiro a Ferrari, que tem um processo artesanal de fabricação e é feita quase que sob medida e que é testada unidade por unidade (cada Ferrari). Obviamente se eu puder pagar por uma Ferrari.
Um Uno ainda que muito bem feito e sem defeito algum, possui componentes de sua fabricação, por exemplo o freio, feito de de materiais inferiores ao de uma Ferrari.
Atc.
Rodrigo
De: an...@googlegroups.com [mailto:an...@googlegroups.com] Em nome de Flavio Clesio
Enviada em: sábado, 19 de dezembro de 2009 19:03
Para: an...@googlegroups.com
Flavio Clesio
muito me surpreende você como um Gerente de Projetos e Gerente de Qualidade por assim dizer pensar dessa forma, mesmo sendo um profissional certificado como descrito na sua assinatura.
Não sei se você já administrou empresas, mais necessariamente administração de produção; mas uma visão de qualidade, até mesmo nas literaturas correlatas você vai SEMPRE encontrar que a Qualidade é relacionada diretamente a EFICIÊNCIA e EFICÁCIA sob qualquer ótica.
Isso eu te falo com conhecimento de causa, pois em produção não tem essa de ser a empresa X ou Y e sim tem haver em aspectos técnicos.
Desculpa, mas EU ACHO que isso é um dogma em acreditar que qualidade se faz por nome e marca, quando na verdade isso se dá de forma pura e simplesmente técnica. E acho que e de técnica que estamos falando aqui...
Mas o tema é grande e vejo que há uma relação quase que dogmática quanto a utilização desse conceito; mas se você acha que uma Ferrari toda frouxa e com peças em não conformidade é melhor e mais seguro que um "Uninho" revisado em toda a sua cadeia de produção, continue assim.
PS I: Você citou o exemplo da China né? Acontece, que se você souber como é o processo produtivo lá (isso é amplamente divulgado em um bom curso de Econ ou Eng. da Produção) vai saber que lá eles não tem políticas de controle de qualidade e o porque deles não adotarem essa política.
PS II - Sobre o exemplo mais uma vez você utilizou de elementos subjetivos; pois quem te garante a diferença dos processos envolvidos na fabricação do freio da Ferrari e do Uno? Quem tem garante que o processo de metalurgia utilizado na fabricação dos freios da Ferrari se não houver o que eu descrevi, vai prejudicar ou não o desempenho do freio?
PS III - E se processo artesanal fosse melhor que os preceitos de avaliação técnica, não precisariamos de Analistas nem engenheiros de software; era só colocar uns 2 javeiros lá e tava udo certo não acha !?
2009/12/19 Rodrigo Almeida de Oliveira <rodrigoalmei...@gmail.com>
Camilo Almendra
Com que intuito o cidadão vai usar o carro?
Se ele quer ir apenas visitar a avó dele do outro lado da cidade, o Uno resolve e a Ferrari é GOLD PLATING. Se o Uno pifar depois de 10.000 km indo e vindo visitar a avó, não tem qualidade. Se só precisou fazer uma revisão mais completa com 30.000 km, então o Uno possui qualidade.
Agora, se ele quer impressionar gatinhas no verão de Floripa, a Ferrari resolve e o Uno não atende as metas de negócio. Se a Ferrari funcionar durante todo o verão, tem qualidade. Se ela pifar no meio do verão, e tiver que ser puxada de reboque, não atendou as metas de negócio (impressionar as gatas).
Sobre a questão da Geladeira Chinesa e Brasileira, é uma questão de percepção de valor do usuário final. A indústria chinesa possui qualidade também, não se deve tomar toda a indústria da China pelos cacarecos e "bregueços" que são vendidos na 25 de março.
Abraços.
--
Camilo Almendra
twitter.com/ccalmendra
Flavio Clesio
Rodrigo Almeida de Oliveira
Flavio, eu sou muito pragmático, focado em resultados. E todo dia eu tenho que negociar com clientes e equipe interna o nível de qualidade que vamos entregar. Muitas vezes o escopo não permite investir mais em qualidade. Muitas vezes é o tempo/prazo que é curto. Outras tantas é custo que é limitador. Por estas restrições é que eu acho que a qualidade é negociável. E o artigo do Paulo dá a entender isto.
No PMBOK quarta edição, na página 190, tem os seguintes conceitos: “Qualidade e grau não são a mesma coisa. Qualidade é grau com que um conjunto de características
inerentes atende aos requisitos. Grau e uma categoria atribuída aos produtos ou serviços que tem a mesma utilidade funcional, mas diferentes características técnicas . Embora um nível de qualidade que não cumpra os requisitos de qualidade seja sempre um problema, um grau baixo pode não ser. Por exemplo, um produto de software pode ter alta qualidade (sem defeitos óbvios, manual de fácil leitura) e um grau baixo (numero limitado de funcionalidades), ou ter baixa qualidade (muitos defeitos, documentação do usuário mal organizada) e um grau alto (varias funcionalidades). O gerente do projeto e a equipe de gerenciamento do projeto são responsáveis por gerenciar as compensações envolvidas para entregar os níveis necessários de qualidade e grau.”
Acho que estes conceitos são bem claros e expressam o que eu entendo sobre qualidade.
Eu sei na prática e concordo com o que você falou, mas para tudo tem um preço. E qualidade para mim está ligada diretamente ao escopo do produto e do projeto que se está fazendo. E também ligada a processos e principalmente pessoas. É este conjunto de fatores que se funcionar harmonicamente, irá gerar valor para o cliente.
Shigueru
Bom dia pessoal,
Rodrigo, agora eu fiquei intrigado. Como você negocia a qualidade? É
dito ao cliente que um produto pode vir a falhar em algumas tarefas?
Ou que determinadas evoluções possam ser custosas (em virtude de um
teste de regressão manual)? Ou que pelo orçamento será possível contar
apenas com um time júnior?
Baseio essas perguntas também na discussão anterior:
http://groups.google.com/group/an-br/browse_thread/thread/7f381be46f18eed7/7806fab88bc82384
[]s
Shigueru
On Dec 21, 8:52 am, "Rodrigo Almeida de Oliveira"
> 2009/12/19 Rodrigo Almeida de Oliveira <rodrigoalmeidadeolive...@gmail.com>
> 2009/12/18 Paulo Vasconcellos <pfvasconcel...@gmail.com>
>
> Olá Rodrigo, tudo bem. E contigo?
>
> Meu caro, não tenho boas lembranças daquele debate não. E temo que este vá
> pelo mesmo caminho.
>
> Se bem me lembro, naquele papo você disse que a mudança de um Uno (ou algo
> parecido) para uma Ferrari representava mudança da qualidade. Eu e outros
> colegas afirmamos que se trata de uma mudança de escopo, não de qualidade.
> Para discutir o tema, preciso saber se você reviu seu entendimento sobre
> *Qualidade*.
>
> Outra coisa que me desagrada demais é ver minhas palavras totalmente
> distorcidas. Você escreveu:
>
> E você diz também que o plano para o PMBOK é uma camisa de força.
>
> Lá no meu artigo está escrito assim:
>
> Me parece inevitável uma revisão da definição de fracasso pelo Standish
> Group. Assim como espero um PMBoK mais orientado para a adaptação do que
> para ações corretivas (que visam a colocação do trabalho nos “trilhos” de um
> plano). Como insiste Jim Highsmith em mais de um trecho do livro,“planos (e
> arquiteturas) devem funcionar como guias e não como camisas-de-força”.
>
> Por essas e outras, e se for para seguir neste rumo, não creio na
> produtividade e utilidade do debate para ninguém.
>
> Contando com sua compreensão agradeço.
>
> Abraços,
>
> Paulo Vasconcellos
>
> 2009/12/18 Rodrigo Almeida de Oliveira <rodrigoalmeidadeolive...@gmail.com>
> Paulo...
>
> read more »
Rodrigo Almeida de Oliveira
comunicando ao cliente que outras funcionalidades não críticas podem ter
erros.
Posso ter uma equipe experiente (sênior) que custa muito caro e produz mais
e melhor.
Ou ter uma equipe júnior, menos experiente, custa barato e que produz menos
e com menor qualidade.
Tudo isto é ao meu ver, negociável com o cliente.
Atc.
Rodrigo
-----Mensagem original-----
De: an...@googlegroups.com [mailto:an...@googlegroups.com] Em nome de
Shigueru
Enviada em: segunda-feira, 21 de dezembro de 2009 10:51
Para: Análise de Negócios . br
Assunto: Re: RES: [an.br :: 4833] [Artigo] Fracasso 2.0
Bom dia pessoal,
[]s
Shigueru
--
Paulo Vasconcellos
Flavio Clesio
ALBERTO LOBAO CAZARIN
>>> Flavio Clesio <flavio...@gmail.com> 12/21/2009 12:48 pm >>>
Olá,Eu não gostaria de conhecer e muito menos negociar com um cliente que diga: "ah, então forma uma equipe com 'moleques' e me entrega um sistema meia-boca. Assim ganho um descontinho de 40%, certo?".Confirmo também, pela citação do Rodrigo, que o PMBoK segue confuso. Agora, além de qualidade, pintou ali um "grau". Sempre vi "grau" associada a outra coisa qualquer. Graus célsios, por exemplo. Sei lá a razão daquela confusão, mas prefiro não mexer mais nela.Highsmith é muito didático ao falar de Qualidade Externa e Interna. A externa é imediatamente percebida pelo cliente ou usuário. Refere-se a apresentação da aplicação como um todo (telas, manuais etc), performance, escalabilidade etc etc. Cada tipo de aplicação requer um balanceamento próprio de todos os atributos de qualidade. Não faz sentido, por exemplo, que o cliente exija a capacidade de atender milhões de usuários simultâneos se ele está comprando uma intranet para sua empresa de 100 funcionários.A qualidade interna é percebida durante todo o ciclo de vida de um produto. Se sua manutenção é cara, diz-se que sua qualidade interna é ruim. Se o cliente está comprando um tipo de 'hot site' que irá para o lixo depois de uma curta vida (uma promoção, por exemplo), então a qualidade interna não exigirá muita atenção.Negociam-se tais atributos e características, mas nunca a possibilidade de entrega de um produto inferior. Não no mundo onde vivo.Agora, sobre a confusão com escopo. O exemplo do Camilo é legal - com grandes requisitos indicando o produto mais adequado. Faltou a conclusão, né Camilo? Você concorda que os grandes requisitos definiram o escopo do projeto (produto), certo?Abraços,Paulo
Camilo Almendra
Agora, sobre a confusão com escopo. O exemplo do Camilo é legal - com grandes requisitos indicando o produto mais adequado. Faltou a conclusão, né Camilo? Você concorda que os grandes requisitos definiram o escopo do projeto (produto), certo?
Flávio foi exato ao ressaltar que analogias dependem de contexto, e minha analogia foi focada na confusão sobre escopo.
Eu não gostaria de conhecer e muito menos negociar com um cliente que diga: "ah, então forma uma equipe com 'moleques' e me entrega um sistema meia-boca. Assim ganho um descontinho de 40%, certo?".
Fazendo analogia (de novo!) com o Net Negative Producing Programmer , isso seria o Net Negative Client. É um cliente que deseja custo mínimo, não se importa com qualidade, e tende a não ser rentável a longo prazo.
Abraços,
--
Camilo Almendra
twitter.com/ccalmendra