CMMI e a Apropriação dos meios de produção

Não deixe de Ler.

Resumindo: é a apropriação dos meios de produção que justifica os lucros no sistema capitalista, garantindo que a qualidade do produto não dependa de quem o produz.

http://zensistemas.blogspot.com/2007/07/cmmi-e-apropriao-dos-meios-de-produo.html

JavaEvangelist Membro desde: 07/07/2006 12:28:12 Mensagens: 393 Offline

RodrigoSol wrote:
Não deixe de Ler.

Resumindo: é a apropriação dos meios de produção que justifica os lucros no sistema capitalista, garantindo que a qualidade do produto não dependa de quem o produz.

http://zensistemas.blogspot.com/2007/07/cmmi-e-apropriao-dos-meios-de-produo.html

Muito bom o texto!!!

yeap ...
pena que não funciona para software

[editado]Ops, ótimo o texto, eu não tinha lido ainda

[/editado]

Não funciona até inventarem um CNC para softwares. Enfia UML de um lado, sai um ERP do outro.
A área de TI é muito parecida com a área financista nesse ponto. Apesar de existir conceitos que guiam e auxiliam uma análise, elas não são regras imutáveis, na qual a aplicação é certa. Depende muito do "sentimento" e da análise conjunta do economista com o mercado.
Pintar ainda não virou mecânico, então software vai demorar um pouco para sê-lo.

Até!

JavaChild Membro desde: 15/06/2003 00:00:31 Mensagens: 132 Offline

O CMMI é algo que pode tirar as empresas do caos porque as pessoas passam, mas a empresa fica.

Faça o seguinte exercício: Pare, por um momento, de pensar como programador e pense como o gerente da área de informática de uma empresa, ou seja, pare de pensar como empregado e pense como patrão.

Agora, pense em um sistema muito importante para a sua empresa, como um sistema de ponto ou um sistema de gestão financeira, por exemplo.

Neste cenário, você gostaria que todas as regras do negócio estivessem exclusivamente na cabeça de um programador, e que nada estivesse documentado, isso em função da inexistência de um processo de desenvolvimento bem definido?

É claro que não gostaria, pois assim você, e toda a sua empresa, ficaria refém do "Salvador da Pátria". O que você, gerente da área de informática, faria se este funcionário resolvesse, de uma hora para outra, que merece trabalhar apenas duas horas por dia?

Agora, volte a pensar como programador, e suponha que você tenha sido contratado para a vaga deste outro programador que fora demitido por motivos óbvios. Como você se sentiria chegando para trabalhar e descobrindo que, além de todas as variáveis do sistema serem nomeadas com o nome das ex-namoradas do antigo programador e o código não estar endentado, não existe documentação, processo de desenvolvimento bem definido, padrões nem nada que possa te ajudar a fazer o seu trabalho, que tem que ser bem feito porque você largou o seu emprego anterior para se dedicar a este?

Por já ter visto esta situação acontecer várias vezes, e já ter passado por isso, sou defensor do CMMI, RUP, padrões de programação e tudo mais que costumam chamar de burocracia (eu chamo de formalidade)

O CMMI e o RUP podem até ter os seu problemas, mas são uma luz no fim do túnel para quem tem que se preocupar com a sustentabilidade da área de informática de uma empresa a médio e longo prazo.

Além disso, o que várias pessoas não entendem, é que não se pode tentar implementar, de uma só vez, um padrão de desenvolvimento do nível da fábrica de software da IBM em uma software-house de 4 pessoas que não tem a cultura da padronização.

Achei o texto falacioso, pois o autor tenta direcionar o entendimento das pessoas para conclusões equivocadas, como as seguintes:

"Quanto mais eficiente a empresa for em apropriar os meios de produção menos importante o empregado vai ser. Por que valorizar um tipo de trabalho que pode ser executado por qualquer pessoa"

A importância do empregado independe da eficiência da empresa em se aprorpiar dos meios de produção. Poderia dar vários exemplos, mas vou citar apenas 2. Na fábrica da Wolks em São Paulo, algum de vocês, trabalhadores da área de informática que estão lendo este texto, se habilitaria a assumir a posição do engenheiro de segurança do trabalho? Notem que estamos falando de uma fábrica de carros, o exemplo mais comum quando se fala de alienação. E no caso de um centro cirúrgico de alta complexidade, algum de vocês se habilitaria a tomar o lugar do médico que, do Brasil, faz cirurgias na Alemanha? O médico não é o dono dos meios de produção - câmeras, mesa de cirurgia e demais equipamentos - mas não pode ser substituído por nenhum de nós e dificilmente o será por outro médico. No caso do desenvolvimento de software acontece a mesma coisa, nenhum profissional DE QUALIDADE pode ser substituído como se substitui um parafuso.

"Aí entra o CMMI, ele é a grande justificativa destas fábricas de software. O que ele vende é que com a definição de um modelo de maturidade de processos a qualidade vai passar a ser propriedade das empresas e não dos seus funcionários"

O CMMI não vende que a qualidade vai ser propriedade das empresas, mas que os processos bem definidos contribuirão, caso seja necessário, para que a substituição de uma pessoa por outra seja feita com o mínimo de prejuízo para a empresa, que não deve ficar refém de "estrelas". Além disso, todos sabemos que esta substituição, apesar dos processos maduros e bem definidos, não é feita com base no "se vira nos trinta" nem entre pessoas com QUALIFICAÇÕES diferentes, pois pode-se substituir um arquiteto de software por outro, mas não por um programador estagiário.

"O que não está sendo levado em conta na adoção deste modelo são os problemas que a sua implantação gera. Alguns já são problemas clássicos da produção industrial tradicional e outros são decorrentes da sua aplicação na produção de software. Dentre os problemas clássicos podemos destacar a alienação do trabalho e dentre os específicos da informática a perda de qualidade."

A adoção do modelo em nada se relaciona com a perda de qualidade, pois conhecemos ambientes que não adotaram este modelo no qual também há falta de qualidade. Além disso, o CMMI não se presta a ser uma garantia de qualidade, mas de processos bem definidos, o que pode (em alguns cenários) ser considerado como um componente da qualidade. De nada adianta um processo bem definido se o sistema entregue não atende os requisitos do usuário. O processo não garante a qualidade, mas, em projetos de médio e grande porte, é um de seus componentes.

"Por isto quando trabalhamos no modelo industrial no qual o nosso trabalho é dividido, nós perdemos a visão do todo e passamos a ter a impressão de que o nosso trabalho não transforma nada, não serve para nada! O reflexo disto é um altíssimo nível de insatisfação e consequentemente alta rotatividade."

Se o autor está achando ruim a divisão do trabalho, sugiro que se dedique a fazer sandálias de couro e ir vender nas feiras de artesanato de sua cidade, ou então, caso queira continuar na área de informática, que dedique-se a sistemas mono-usuário para bancas de revista ou locadoras.

"Apesar da alienação no trabalho a produção industrial é muito eficaz porque, mesmo com a insatisfação dos trabalhadores, a apropriação dos meios de produção garante a qualidade."

Já vimos que a apropriação dos meios de produção - a alienação no trabalho - não garante a qualidade. O que garante a qualidade é um conjunto de fatores, que variam de acordo com o objetivo do sistema. Para projetos de médio e grande porte, dois destes fatores são as PESSOAS e o PROCESSO.

Em reumo: O autor mostra ser uma pessoa inexperiente, imediatista e egocêntrica, pois só pensa no seu mundinho de programador de "programinhas"

Leandro BSB wrote:
Para projetos de médio e grande porte, dois destes fatores são as PESSOAS e o PROCESSO.

Caso seja curioso, leia o artigo sobre qualidade de software da WikiPedia em Português e depois a versão em Inglês. Note que nós associamos qualidade de software a processos e não a melhores praticas que teoricamente seria o correto.

O que acho que está acontecendo aqui e que as empresas acreditam que bastam ter processos bem definidos para ser ter qualidade de software.

Qualidade do processo não garante boa qualidade de código, por exemplo.

Não acho que os processos devem ser banidos da humanidade, eles são importantes para guiar a produção de software, seja ele burocrático(RUP) ou ágil(XP) , mas acredito que qualidade de software se garante principalmente por PESSOAS e não por PROCESSO.

Independente de processos, acho que o processo que está falho é o do
RH de contratação.

Contrate programadores bons! Sei que é foda, mas muitas vezes vejo as empresas
'conhece java? então pode vir...'
Que não tenham medo de entender/refatorar e melhorar/testar código de outros,
que escrevam javadocs úteis, codificam nos padrões da empresa, etc.
Coisas básicas que um programdor deve fazer.

Leandro BSB wrote:O CMMI é algo que pode tirar as empresas do caos porque as pessoas passam, mas a empresa fica.

O CMMI é uma maneira pobre de se fazer isto, pelo menos como ele é aplicado ...
E considerando que (numero chutado) 90% das implantações são terriveis, acho que o problema é com o CMMI.

Leandro BSB wrote:
Faça o seguinte exercício: Pare, por um momento, de pensar como programador e pense como o gerente da área de informática de uma empresa, ou seja, pare de pensar como empregado e pense como patrão.

Agora, pense em um sistema muito importante para a sua empresa, como um sistema de ponto ou um sistema de gestão financeira, por exemplo.

Neste cenário, você gostaria que todas as regras do negócio estivessem exclusivamente na cabeça de um programador, e que nada estivesse documentado, isso em função da inexistência de um processo de desenvolvimento bem definido?

Ninguem disse para não documentar, uma coisa não tem anda a ver com a outra ...

Leandro BSB wrote:
Por já ter visto esta situação acontecer várias vezes, e já ter passado por isso, sou defensor do CMMI, RUP, padrões de programação e tudo mais que costumam chamar de burocracia (eu chamo de formalidade)

O CMMI e o RUP podem até ter os seu problemas, mas são uma luz no fim do túnel para quem tem que se preocupar com a sustentabilidade da área de informática de uma empresa a médio e longo prazo.

Eu acho que são um Tiro no pé.
tudo bem, CMMI pode ser bem implantado, e até ser muito pouco burocratico ...
agora colocando o RUP no meio da salada tu deu um tiro no pé, até os criadores do RUP dizem que ele não funciona direito (pelo menos um deles

).

Outra coisa, CMMI e RUP não tem nada a ver um com o outro, é bem possivel utilizar CMMI e Scrum por exemplo ...

Acho que tu ta comparando coisas que não tem nada a ver uma com a outra.

Leandro BSB wrote:
"Quanto mais eficiente a empresa for em apropriar os meios de produção menos importante o empregado vai ser. Por que valorizar um tipo de trabalho que pode ser executado por qualquer pessoa"

A importância do empregado independe da eficiência da empresa em se aprorpiar dos meios de produção. Poderia dar vários exemplos, mas vou citar apenas 2. Na fábrica da Wolks em São Paulo, algum de vocês, trabalhadores da área de informática que estão lendo este texto, se habilitaria a assumir a posição do engenheiro de segurança do trabalho? Notem que estamos falando de uma fábrica de carros, o exemplo mais comum quando se fala de alienação. E no caso de um centro cirúrgico de alta complexidade, algum de vocês se habilitaria a tomar o lugar do médico que, do Brasil, faz cirurgias na Alemanha? O médico não é o dono dos meios de produção - câmeras, mesa de cirurgia e demais equipamentos - mas não pode ser substituído por nenhum de nós e dificilmente o será por outro médico. No caso do desenvolvimento de software acontece a mesma coisa, nenhum profissional DE QUALIDADE pode ser substituído como se substitui um parafuso.

Novamente comparando maçãs com bananas ...
Primeiro medicina não é um trabalho mecanico ...
engenharia de segurança no trabalho também não ...
tu ta comparando as coisas erradas, o trabalho que esta automatizado na fabrica da Wolks é o de montagem dos carros, e sim, qualquer um deste forum poderia com um treinamento de no máximo 1 dia, ocupar uma posição na linha de montagem de carros na fabrica da Wolks.

e é este tipo de coisa que as "Fábricas de software" tentam fazer com os desenvolvedores.
eles estão com o mesmo pensamento errado que tu ...
estão comparando operário com médico ...
os tipos de trabalho são totalmente diferentes ...

Leandro BSB wrote:
"Aí entra o CMMI, ele é a grande justificativa destas fábricas de software. O que ele vende é que com a definição de um modelo de maturidade de processos a qualidade vai passar a ser propriedade das empresas e não dos seus funcionários"

O CMMI não vende que a qualidade vai ser propriedade das empresas, mas que os processos bem definidos contribuirão, caso seja necessário, para que a substituição de uma pessoa por outra seja feita com o mínimo de prejuízo para a empresa, que não deve ficar refém de "estrelas". Além disso, todos sabemos que esta substituição, apesar dos processos maduros e bem definidos, não é feita com base no "se vira nos trinta" nem entre pessoas com QUALIFICAÇÕES diferentes, pois pode-se substituir um arquiteto de software por outro, mas não por um programador estagiário.

Se o CMMI não diz isto, é assim que ele é vendido pelo menos ...

Leandro BSB wrote:
Em reumo: O autor mostra ser uma pessoa inexperiente, imediatista e egocêntrica, pois só pensa no seu mundinho de programador de "programinhas"

E tu na minha opinião, se mostra querendo defender o teu ponto de vista, mas cometendo o erro de comparar coisas diferentes como sendo a mesma, o que faz tu perder a linha de raciocinio e fazer comparações sem sentido ...

mas como eu disse, é só a minha opinião

Li esse tópico e jurei nao entrar nele...mas nao resisti!

Só uma colocação: CMMI e RUP tem pontos de vista diferentes por assim dizer....o CMMI foca mais em práticas a serem adotadas eo RUP de fato tras algo mais "baixo nível" no sentido de chegar ao ponto de propor templates, ou o "faça assim, e faça desta forma...utilizando este documento, etc"...o CMMI diz o que fazer, e não como, ou seja, é um modelo mais "alto nível" no sentido de que atendendo aquela pratica vc está obtendo maturidade em seu processo...o RUP já vai mais a fundo..mas ambas são metodologias interessantes...e no meio ponto de vista não vejo "confiltos" entre as duas metodologias...se analisarmos legal veremos que pode não haver uma "complementação de uma para a outra" mas as duas podem conviver entre sí tranquilamente...bom, eu entendo mais ou menos assim os 2 modelos.

ate mais...

JavaChild Membro desde: 10/01/2007 00:54:33 Mensagens: 120 Offline

A importância do empregado independe da eficiência da empresa em se aprorpiar dos meios de produção. Poderia dar vários exemplos, mas vou citar apenas 2. Na fábrica da Wolks em São Paulo, algum de vocês, trabalhadores da área de informática que estão lendo este texto, se habilitaria a assumir a posição do engenheiro de segurança do trabalho? Notem que estamos falando de uma fábrica de carros, o exemplo mais comum quando se fala de alienação. E no caso de um centro cirúrgico de alta complexidade, algum de vocês se habilitaria a tomar o lugar do médico que, do Brasil, faz cirurgias na Alemanha? O médico não é o dono dos meios de produção - câmeras, mesa de cirurgia e demais equipamentos - mas não pode ser substituído por nenhum de nós e dificilmente o será por outro médico. No caso do desenvolvimento de software acontece a mesma coisa, nenhum profissional DE QUALIDADE pode ser substituído como se substitui um parafuso.

Aí vc forçou a barra...Eu não sou engenheira da segurança..se fosse eu me habilitaria sim....
Como disse um colega acima, vc tá misturando bananas com maças.
A idéia principal quando vc tem processos definidos dessa forma é a sua empresa ter funcionários descartáveis. No sentido que: se alguém sair e su só preciso de outra pessoa com os mesmos conhecimentos. O que é bem diferente de uma empresa depender de um cidadão..
Um professor meu dizia: a empresa que depende de um único funcionário não presta...

Nenhuma empresa pode depender de um funcionário...já que o mesmo é um capital intelectual volatil...pode ficar 10 anos ou 1 semana.

ate mais...

Curto e grosso: Um selo de CMMi ou MPSBR ou o que quer que seja garante que durante a avaliação a empresa fez oq eu o selo exige. Eu já trabalhei em empresa com certificados do tipo e já comprei delas (comprei mesmo, como gestor) e a qualidade do software é péssima.

1 - Se o software tem péssima qualidade de que vale o certificado? De que vale o processo cumprir as exigências?

2 - Como eu garanto que quando o appraiser virar de costas o processo vai ser mantido? (por experiência eu sei que não é na maioria dos lugares)

3 - Regras de negócio documentadas estão rpesentes em qualquer processo de desenvolvimento que não seja um caos completo, dada a pergunta no item (1) qual a vantagem em comprar de uma empresa que tenha selinho?

4 - A Wolks perde dinheiro, como as outras montadoras, há anos. A Toyota aplica lean, que é raiz das metodogias ágeis, e é a única lucrativa. E não tem selinho.

5 - Desde os anos 70 sabemos por dados estatísticos (vide Fred Brooks) que uma equipe boa produz várias ordens de grandeza mais que equipes medíocres como as que geralmente habitam empresas de 3 letrinhas, que sao as grandes certificadas

6 -

Se o autor está achando ruim a divisão do trabalho, sugiro que se dedique a fazer sandálias de couro e ir vender nas feiras de artesanato de sua cidade, ou então, caso queira continuar na área de informática, que dedique-se a sistemas mono-usuário para bancas de revista ou locadoras.

Eu sugiro que você leia os livros clássicos de gerenciamento de pessoas tanto de tecnologia (Peopleware para começar) quanto de empresas em geral ("The New Product Development Game" é obrigatório neste debate). Cuidado com o senso comum, software é indústria do conhecimento e esta indústria não usa fábricas, por mais que as 3 letrinhas insistam.

Mas ok, ter CMMi ou MPS.BR não quer dizer que a empresa seja boa ou ruim quer dizer... nada. Só isso.

Fora que na hora que o prazo aperta esquecam os processos o que vale é entregar. Ja vi algumas vezes essa cena no mercado infelizmente.

]['s

urubatan wrote:yeap ...
pena que não funciona para software

[editado]Ops, ótimo o texto, eu não tinha lido ainda [/editado]

Uau, um diretor de fabrica de software ao avesso!

hehehehehe

Notícias, artigos e o maior fórum brasileiro sobre Java