Vamos falar sobre Lean e os sete tipos de desperdícios. Neste post vamos nos focar ao desperdício da produção.
“Desperdício é tudo aquilo que não agrega valor ao cliente” -- Taiichi Ohno
Uma definição para a manufatura nas empresas
Sobre-produção
Produzir mais que o necessário, mais rápido que o necessário e antes que necessário
Conseqüências
* Consumo desnecessário de matérias primas
* Ocupação dos meios de armazenamento
* Ocupação dos meios de transporte
* Stock elevado e a mão-obra para o controlar
É considerado o maior desperdício das empresas
Uma definição para a área de desenvolvimento de software
Elimine o desperdício
Os três maiores desperdícios no desenvolvimento de software são:
Funcionalidades a mais (Extra Features)
Precisamos de um processo que nos permita desenvolver apenas os 20% das características necessárias que produzem os 80% do valor do sistema.
Reclamações (Churn)
Se você tem reclamações sobre os requisitos, você esta especificando muito cedo. Se você tem teste e ciclos de correções de erros, você esta testando tarde de mais.
Removendo Hierarquias (Crossing Boundaries)
Estruturas organizacionais hierárquicas tipicamente aumentam os custos em mais de 25%, criando um buffer que retarda o tempo de resposta e interfere na comunicação
Existe um livro chamado caindo na real (Getting Real) que mostra bem como o desperdício em desenvolvimento de software funciona. Eu sempre bato na tecla nos projetos, desenvolva menos, cada vez mais menos, pois a cada nova funcionalidade passamos a ter mais instruções de maquina para nos preocuparmos.
O desenvolvimento deve ser focado no que realmente agrega valor ao cliente, nos temos o habito de sempre adicionarmos mais funcionalidades ao sistema, eu sempre costumo dizer que em cada ciclo do desenvolvimento do software, cada caixa do processo agrega funcionalidades que se acredita ser importante ao sistema e que necessariamente não esta agregando valos nenhum ao cliente.
Desta maneira o analista de sistemas, desenvolvedor, DBA, analista de testes, etc sempre estão adicionando funcionalidades que eles acreditam ser importantes ao software.
O Principio de Pareto:
A lei baseia-se na verdade no Princípio 80/20, descoberto em 1897 pelo economista italiano Vilfredo Pareto (1848-1923), segundo o qual 80% do que uma pessoa realiza no trabalho vêm de 20% do tempo gasto nesta realização. Logo, 80% do esforço consumido para todas as finalidades práticas são irrelevantes. Uma constatação surpreendente!
Uma maneira de mantermos o foco nas funcionalidades que são importantes no desenvolvimento de software é o desenvolvimento direcionado a testes, onde um requisito tem agregado ao seu entendimento os testes comportamentais que ele deve possuir e desta maneira a equipe passa a utilizar requisitos mais testes como escopo da funcionalidade.
É uma técnica que permite com que todos os envolvidos no desenvolvimento do software passem a ter um alinhamento comum sobre o entendimento do requisito e quais funcionalidades o requisito possui.
Remover hierarquias permite uma comunicação mais rápida e a eliminação de tempo de espera por retornos de tarefas que devem ser executados por outros profissionais num quadro de responsabilidade hierárquico. Projetos que possuem a características de um gerente de projetos forte, onde a empresa trabalha com características profetizadas tem esta eficiência. Este sem duvida nenhuma é um dos itens mais difíceis de ser implantado em uma organização, pois não depende das equipes de trabalho e sim de uma mudança coorporativa.
Devemos sempre nos adaptar ao meio que estamos inseridos e não ficarmos reclamando que a nossa corporação não possui características A, B ou C.
A nossa criatividade faz com que este item passe a ser trabalhando de maneira diferente do idealizado pelos princípios de Lean, para que possamos alcançar resultados pelo menos semelhantes ao que o principio define.
Este foi um post de bate papo.
Abraços a todos,
Abu
Bibliografia
http://www.scribd.com/doc/3487699/Lean-Manufacturing-2Os-7-Tipos-de-Desperdicio
http://www.poppendieck.com/index.htm
http://gettingreal.37signals.com/GR_por.php
http://www.editoras.com/rocco/022345.htm
Um comentário:
E o chaos report comprova isso:
- 45% das funcionalides de um sistema tipico NUNCA são usadas;
- 19% raramente são usadas;
- 16% as vezes são usadas;
Somando os 80% que não agregam valor ao cliente.
Só para completar, os outros 20% das funcionalidades vem de:
- 13% frequentemente são usadas;
- 7% sempre são usadas;
Postar um comentário