Lean management Quidgest

Lean Management

Vantagem competitiva

Fruto da muito maior procura do que oferta, o desenvolvimento de software de gestão empresarial beneficia de um estatuto particular. Não existiu pressão para a mudança que fosse suficiente para impor, neste setor, uma cultura da Qualidade Total, como se impôs, há mais de 50 anos, na produção industrial.

O Scrum é um conceito proveniente de ambientes industriais Lean[1]. Porém, a maior parte dos conceitos que provaram a sua eficácia na produção industrial (nomeadamente, no sistema Toyota de produção) não transitaram, nem foram acolhidos pela indústria do software.

E, claramente, deveriam ter sido considerados.

Aqueles que a produção de software deveria adotar, e não adotou, são demasiados para estas notas, mas deixamos aqui alguns conceitos para inspiração.

Gemba ou ir ao local. A mais grave de todas as faltas da qualidade, na produção tradicional de software, é o processo de verificação de erros. Na produção de software tradicional, a deteção de erros (bugs) é feita por testers[2] e no final do desenvolvimento. O que viola grosseiramente o terceiro dos 14 Pontos para a Gestão da Qualidade Total de Edward Deming[3]. É certo que controlo de qualidade só no final é melhor do que nenhum controlo da qualidade[4]. Mas a dependência de inspetores é fortemente desaconselhada. Os erros são detetados fora do contexto em que foram produzidos e, não se estando no local, é muito mais difícil perceber a sua causa e atuar sobre ela. É acrescentado trabalho (e equipamentos) a fases posteriores da produção, quando se podia ter detetado o problema logo quando ele foi introduzido no software. A responsabilidade é diluída e não se cria a cultura de a Qualidade ser uma tarefa de todos os que participam na produção de software.

Kaizen ou melhoria contínua. A fragilidade da produção de software tradicional, dependente de programadores e das suas habilidades específicas e, até, humores, reflete-se na forma como o software se vai construindo. O software tradicional não resulta de uma linha de produção que se vai afinando. Cada programador escreve uma parte do código, junta-o ao de outros programadores e dá a sua tarefa por concluída. Uma vez acabado o software, entrega-se. Não se continua a melhorar. Só será melhorado, se posteriormente se encontrar algum defeito. Se cumprir os mínimos (funcionar) não há nenhum esforço para o tornar mais eficiente, mais robusto ou mais adequado à utilização.

Jidoka ou automação inteligente. A produção de software tradicional não é automatizada. Mas, na Quidgest, a máquina (o computador) deteta automaticamente eventuais erros e a intervenção humana tem força para parar o processo de produção, reparar o problema e encontrar a causa, de forma a eliminar a hipótese de ocorrências posteriores. A produção não é retomada enquanto este ciclo não for executado.

Poka yoke, isto é, “à prova de erro” ou “prevenindo de erros inadvertidos”. É um conceito bem ilustrado e compreendido pela forma de uma bateria, de um cartão de memória ou de um microchip, forma essa que impede que estes objetos sejam colocados incorretamente.

De notar que, tal como as restantes dimensões debatidas na conferência Q-Day 2018, o Lean IT aplica-se a organizações de produção de software autónomas e descentralizadas e a redes de equipas colaborativas. Requer uma cultura própria, partilhada por todos os que participam na produção de valor, o que conduz novamente ao Gemba.

A contribuição da Quidgest

Na Quidgest, o software resulta de uma linha de produção automatizada, o Genio. A produção de software adota, assim e muito mais facilmente, a lógica de uma indústria. A identificação de padrões permite a utilização de máquinas em tarefas antes apenas desempenhadas por humanos. A sua reutilização cria uma massa crítica de casos e de contextos de aplicação que convidam a um aperfeiçoamento continuado.

O Genio, como uma linha de produção industrial automatizada, tem uma componente de modelação / conceção e uma componente de criação de código.

O modelo é um espaço adicional, que abre oportunidades excelentes para a implementação da Qualidade Total. Partindo dos conceitos Jidoka, Poka-yoke e Kaizen, a Quidgest integrou no Genio formas inovadoras de garantir a Qualidade não apenas dos produtos que fabrica, mas do processo de produção.

O já anteriormente referido Scaled Agile / SAFe [5]é uma corrente que agrega Agile e Lean IT e é, provavelmente, o movimento a que devemos estar mais atentos. Junte-se-lhe a modelação e geração automática de software e temos o ambiente de qualidade existente na Quidgest, que consideramos ideal.

Mas a Quidgest é, ainda, uma exceção. Não conhecemos nenhuma outra empresa de software, presente no mercado global (isto é, excluindo investigações de âmbito mais reduzido ao nível académico), em que o modelo defina inequivocamente a totalidade do sistema de informação. E, por isso, em que seja possível extrair qualquer sistema de informação (nomeadamente os mais complexos ERP) de um processo industrializado.

_________________
[1] The New New Product Development Game, Hirotaka Takeuchi e Ikujiro Nonaka, Harvard Business Review, January 1986
[2] Existe uma dinâmica Associação Portuguesa de Testes de Software https://www.pstqb.pt/. Do mesmo modo, há, nas comunidades meetup, inúmeros grupos focados em testes de software, espalhados por todo o mundo. E muitas ofertas de emprego como Test Engineers, mesmo em empresas consideradas Agile  https://jobs.jobvite.com/farfetch/job/oCSF3fwW
[3] http://asq.org/learn-about-quality/total-quality-management/overview/deming-points.html
[4] Joel Spolsky, uma voz reconhecida no desenvolvimento de software, representa bem a linha de raciocínio que prevaleceu, durante anos neste setor: https://www.joelonsoftware.com/2000/04/30/top-five-wrong-reasons-you-dont-have-testers/
[5] https://www.scaledagileframework.com/