Gestão por Processos

Lendo o livro de David Anderson (2010 - Kanban), percebi um detalhe interessante que estava passando desapercebido por mim.

Ele diz que descobriu e ficou curioso sobre teoria das restrições, e aprendeu os conceitos iniciais desta técnica. São cinco passos para melhorar o desempenho do sistema a partir da identificação do elo mais fraco da corrente. Muito simples, muito interessante, dizem que roubado dos japoneses que não tinha tradição de publicar nada, mas já praticavam a maioria das técnicas propostas por Goldratt sem ter documentado no Sistema Toyota de Produção.

Ocorre que no trabalho em manufatura tais conceitos são claramente úteis, mas na administração de serviços administradores, gerentes de projeto, executivos mais tradicionais não percebem como ou onde aplicar tais técnicas. A administração contemporânea de serviços segue uma linha de princípios e técnicas separada da manufatura industrial.

Entretanto David Anderson explica que ao perceber os conceitos da indústria de manufatura, instintivamente percebeu como aplicá-los para o gerenciamento do desenvolvimento de software.

Ele percebeu que poderia olhar para o problema de desenvolvimento de software como um trabalho em fluxo. Desta forma a otimização do fluxo poderia utilizar a técnica de TOC (Theory of Constraints) de Goldratt, com a qual ele estava encantado.

Ele aplicou em seu trabalho como gerente de projetos na M$ e obtever resultados muito bons.

Na verdade, muitos dizem que TOC é um sistema produtivo, mas eu o considero na verdade uma filosofia para otimização de processos. Deverá existir um processo especificado para a produção que será otimizado pelos princípios da TOC.

Da mesma forma, existem outras metodologias de otimização de processo como o Pensamento enxuto com seus 5 passos, as ferramentas do STP, Six-Sigma, Sense and Respond, Sistema da Volvo, entre outros.

Ele deu continuidade em seus estudos e percebeu a amplitude de conhecimento sobre processos no Sistema Toyota de Produção e no Lean Thinking. Melhorou ainda mais os resultados para desenvolvimento de software.

Ao publicar estes resultados causou polêmica na academia, pois de fato as áreas de manufatura e serviços ainda usam princípios e teorias separadas.

Ocorre que qualquer ambiente administrativo "gerenciado" por administradores "convencionais" pode ser transformado em um processo, e como tal, irá apresentar sob este novo ponto de vista um fluxo, com lead-time, cycle-time, variação, anormalidades, sigmas, etc.

Isto se chama Gerenciamento por Processos. Pode-se manter todos os conceitos da "ciência administrativa", e seus caminhos, paradigmas e tal, porém observando o sistema delimitando-o geograficamente como um processo, limitado pelas fronteiras, entradas e saídas, e possibilitando assim trazer a cultura de processos da indústria para o ambiente de serviços.

Assim, torna-se possível melhorar 5 a 10 vezes o desempenho de qualquer departamento administrativo. As melhorias de qualidade na produção chegam a taxas superiores 90% em departamentos mal "administrados". Diminuição de erros, utilizando por exemplo six-sigma são imensas.

Ao ler o livro Lean Office, que é um dos poucos sobre Lean para Serviços, percebi que na verdade existe uma Lacuna gigantesca neste tema. A Engenharia de Produção domina perfeitamente os conceitos de administração de fluxo, conceitos sobre processos, enquanto áreas originalmente de serviços estão tateando para começar a entender sobre o assunto.

A Engenharia de Software por exemplo, ao tratar de Processos, como no CMMI, não faz idéia sobre o que significa otimização, em seu nível 5.

As referência bibliográficas utilizadas no CMMI são baseadas na década de 90 e antes. Eles descobriram Deming mas ainda usam Ford e Taylor, enquanto na Engenharia de Produção já se estuda Sistemas que Aprendem, Chaordics, e muito mais.

A distância entre a Engenharia de Software e a Engenharia de Produção pode ser medida diante das datas das referência bibliográficas sobre processo utilizadas nas últimas publicações.

FATO: ao identificar informações sobre processos e gerenciamento de processos da engenharia de software estará identificando referências ingênuas, ultrapassadas e que já tiveram sua contribuição em outra realidade que não a nossa.

CMM e CMMI não são antigos, mas pecam ao não perceberem o mundo que existe por traz do gerenciamento de processos, que não se limita a Taylor, Fordismo, e às primeiras contribuições de Deming.

Por volta de 2004 a SEI começou, timidamente a avaliar Six-Sigma, que tem muito a contribuir, mas parece não ser ainda considerada por eles uma ferramenta padrão para seu processo.

Acredito sinceramente em six-sigma e em controle estatístico de processos, porém entendo que o conjunto da obra do Sistema Toyota de Produção e o Pensamento Enxuto é muito, mas muito mais apropriado para lidar com desenvolvimento de software.

Não se trata de eliminar a variabilidade do processo, mas sim de ser reativo a variação.

Na indústria, variações como anormalidades devem ser suprimidas.
Na Engenharia de Software ainda não se percebeu que o mundo está mudando rapidamente, e que esta mudança é adaptativa. Empresas precisam se adaptar rapidamente. Fechar o escopo neste contexto, ou eliminar este tipo de variação não é o que a indústria precisa.

Existe uma diferença GRANDE entre eliminar o desvio do erro, de eliminar a variabilidade decorrente da demanda. Se a demanda for verdadeira deve haver resposta ágil do sistema.

Penso.

Variabilidade X Anormalidade

Muito tem sido dito sobre diminuição da variação no processo de desenvolvimento de software.

Infelizmente existe uma confusão de terminologia que não deve ser aceitar/mantider, sob pena de estarmos nos direcionando novamente no paradigma Fordista e ainda atual da Engenharia de Software.

Quando Ford produzia seus carros em 1904, a demanda era muito superior a sua produção, os mercados eram ávidos por seus produtos, portanto, segundo Ford: Henry Ford: "O carro é disponível em qualquer cor, contanto que seja preto..".

Isso se chama variabilidade na indústria.

Outro fenômeno paralelo é que, desde a manufatura artesanal, ocorria que as peças apresentavam imprecisões, por baixa padronização ou por erro de produção, que são consideradas anormalidades da produção.

Tais anormalidades são medidas, e em controle estatístico de processos, são identificadas como variações de medida dentro do processo.

Diz-se, matematicamente, que o desvio entre o esperado e o obtido é uma variação.
Existe ainda a propriedade estatística que define que a soma dos desvios será sempre zero.
Portanto para descobrirmos um desvio médio (erro médio) não se pode tirar a média dos desvios (erros), faz-se a média dos desvios quadrados, a que chamamos variância.

O desvio padrão, ou média dos desvios, é a raiz quadrada da variância.

Busca-se matematicamente diminuir esta variação com o objetivo de eliminar as anormalidades ou erros do processo.

Entretanto, não se busca diminuir a variação, porque a variação é inerente a demanda.
Variação significa evolução, de conceitos, de valores, da sociedade e da indústria.

Busca-se eliminar os erros e seu desvio do objetivo inicial.

Vários autores em desenvolvimento de software pregam eliminar a variação, o que é incorreto.

Devemos sim trazer o processo para a eliminação de erros, e para uma estabilidade tal que possamos conhecer e estimar o desempenho, qualidade e capacidade do processo.

É interessante dizer que existem técnicas de controle estatístico de processos que existem com esta finalidade, entretanto existem outras técnicas como o Six Sigma, que buscam otimizar processos sob a ótica do controle estatístico.

Entretanto, existe um perigo intrínseco e antigo em otimizações.

Ford, na década de 20, atingiu através da padronização das peças que utilizava o auge da velocidade de produção, quando tem início de fato a era da "Produção em Massa". O sistema então chamado Fordista, consegue diminuir drasticamente os erros e tempos de produção.

Ford atingiu o que na Toyota se chama de fluxo de produção, com a diferença que Ford levava as máquinas e pessoas ao estresse extremo, tirando a última gota de sua capacidade de produção.

A velocidade que a Toyota propõe é na verdade baseada na eliminação de desperdícios, esperas, operações ineficientes e desnecessárias. Entretanto, mesmo as paradas totais da fábrica são apoiadas e necessárias, com vistas ao trabalho consciente e a melhoria da qualidade do trabalho.

Outra dúvida/erro muito comum é achar que na Toyota tudo tem que ser feito rápido, isso é uma afirmativa errada. Não pode haver demoras e esperas, isso sim. Mas os funcionários devem poder realizar o trabalho em um rítmo sustentável e calmo para poder observar e pensar sobre o que estão fazendo, e sobre como podem mudar para atingir a resultados melhores.

Entretanto, na Ford a otimização unicamente do desempenho estava direcionada para a produção de estoques. Com este objetivo, unicamente velocidade, pode-se monitorar as estatísticas e produzir mais rápido, gerando estoques cada vez maiores e mais cheios.

De forma semelhante, o desenvolvimento de software pode ser acelerado usando técnicas estatísticas, mas será este um caminho para o processo ideal?

Por este mesmo motivo, atualmente é difícil encontrar casos de processos otimizados unicamente por SixSigma. Na verdade utiliza-se mais de uma forma de otimização associadas, como por exemplo Lean + SixSigma, ou Lean + TOC.

O Lean ( ou Pensamento Enxuto) possibilita mudar qualitativamente o processo, dando rítimo sustentável para o processo de trabalho, o que significa LEVE ou LIVRE de esperas, demoras, e outras formas de desperdício, e somente por isso mais rápido, como consequência.

A Engenharia de Software, na busca de um processo Otimizado, no CMMI em seu nível mais alto, já ouviu falar do SixSigma, e recentemente começou a ouvir falar de Lean.

Talvez, daqui a pouco tempo estejamos percebendo a Engenharia de Software se livrar dos paradígmas de processo Fordistas e da Produção em Massa.