7 Desperdícios no Desenvolvimento Lean de Software e Como Preveni-los
Publicados: 2022-04-18O pensamento Lean Process prioriza a erradicação e redução da compilação de resíduos. Apesar da abordagem “enxuta” adotada por grandes empresas, algumas práticas padrão de “desperdício” persistem devido à sua “natureza óbvia”. A natureza profundamente gravada nas práticas humanas e organizacionais é teimosa até que seja adotada uma abordagem estrita.
O que é Resíduos?
Qualquer coisa que exija recursos/tempo ou esforço, mas não produz resultados relevantes no desempenho ou na geração de receita, é chamado de “desperdício”.
Em última análise, o procedimento de “redução de desperdícios” é desenhado e orientado para aumentar a produtividade e os resultados da equipe.
No entanto, agora que o desenvolvimento de software Lean é o precursor do ágil, podemos adotar esses sete princípios de redução de desperdício na engenharia e desenvolvimento de software para produzir produtos e serviços eficazes, reduzir custos e acelerar o tempo de lançamento do produto no mercado.
1. Trabalho Parcialmente Feito
Se o trabalho anterior nunca for reiniciado, esse esforço foi um desperdício.
Qualquer trabalho até ser finalizado/concluído não adiciona valor à proposta de valor do cliente; assim, ele desperdiça tempo e desafia a manutenção do código se for colocado em espera.
Um exemplo contemporâneo é quando um cliente requer modificação ou recursos extras em um produto. A empresa está empenhada em terminá-los com urgência; a equipe de desenvolvimento deve interromper o trabalho em andamento e agir de acordo com os requisitos. Na mesma página, se o trabalho anterior nunca for reiniciado, foi um desperdício de esforço.
ou
Documentação não codificada: Os requisitos são detalhados minuciosamente, mas nunca são implementados.
Como reduzir esse desperdício?
- O foco deve ser “terminar” e não apenas “começar” um projeto.
- Reduzir as posses de trabalho em andamento.
- Pare de esperar pela especificação detalhada de cada requisito até que a equipe esteja pronta para implementar os esforços (não será uma causa perdida então).
2. Processos Extras
Qualquer processo adicionado ou documentação não lida que não transmita valor prático e prolongue desnecessariamente o tempo ou a realização do mercado do produto é um desperdício.
No entanto, as políticas de negócios geralmente exigem esses documentos, com papelada considerável, mas nunca lidos. Esses esforços são extravagantes.
Exemplos típicos:
- Detalhamento desnecessário da documentação.
- Gestão ou planejamento adicional sem execução.
Como reduzi-lo?
As organizações podem diferenciar entre o que é uma causa/esforço perdido e o que traz valor para a mesa, o foco deve estar na produção de resultados significativos e canalizar esforços para fazer mais trabalho de “qualidade”, limitando o trabalho de “quantidade”.
3. Recursos extras
Qualquer recurso ou recursos de baixo valor adicionados para/pelo cliente, mas não solicitados/não contribuem para o aumento da receita, é um desperdício de esforço.
As empresas cometem esse erro de desenvolvimento quando adicionam recursos que não serão muito utilizados ou exercitados; esse novo recurso fica ocioso e aumenta a complexidade do aplicativo.
A regra Software 80/20 desempenha um papel significativo - 80% dos usuários utilizam apenas 20% de seus recursos. Portanto, o foco deve estar em tornar esses 20% de recursos de alto nível para reter os usuários existentes.

Códigos adicionais têm suas desvantagens:
- Aumenta a complexidade do aplicativo.
- Pode fazer um possível ponto de falha do aplicativo.
- Requer esforço posterior desnecessário no rastreamento e manutenção ao longo do ciclo de vida do produto.
Como reduzir esse desperdício?
Concentre-se no desenvolvimento iterativo - o que significa que, durante o lançamento inicial do produto, crie recursos primários robustos que definam a USP do seu aplicativo.
Concentre-se em torná-lo funcional e valide o aprendizado do avanço contínuo do produto. Além disso, continue criando recursos apropriados com base em sua análise de mercado, comportamento do consumidor e feedback.
4. Troca de Tarefas
Atribuir pessoas a várias tarefas quando elas não se sentem confortáveis com isso e dificulta o processo existente pode levar uma grande quantidade de dias. A maneira mais eficiente de terminar uma ou duas tarefas específicas é terminar uma de cada vez.
Ao alternar entre tarefas, há um pequeno custo de tempo para fechar a existente e obter impulso na outra, isso é chamado de troca de contexto e, se você espera uma transição constante de uma para outra, essas trocas de conteúdo se acumulam e atrasam o “resultado” ou “tempo de entrega”.
Como reduzi-lo?
Simples-Uma coisa de cada vez.
- Reduza a troca de conteúdo.
- Minimize interrupções ou distrações.
- Adie os sem importância.
- Aloque recursos como um projeto por vez.
5. Espera/Atrasos
As dependências de aprovação devem ser cronometradas principalmente durante o roteiro do produto; se um intervalo de tempo específico não for alocado, esteja pronto para respostas e comentários atrasados. Os atrasos também impedem o consumidor de perceber o valor real do produto. Mas, como desenvolvedores ou designers, você tem que esperar pela aprovação do trabalho feito; assim, você não pode evitar completamente o lapso de tempo.
O que você pode fazer para reduzir isso?
- Escolha/atribua algo enquanto aguarda o feedback existente.
- Aloque tempo para entrada e revisão.
- Considere chamadas rápidas, conversas cara a cara, em vez de enviar as alterações por e-mail.
- Feedbacks regulares.
6. Movimento
Se as equipes de desenvolvimento ou pesquisa foram espalhadas com informações adquiridas e não as marcaram/rotularam adequadamente, pode levar uma eternidade para dissipar a confusão e aparecer. Se a informação for extraviada toda vez que uma entrega for entregue; vai prejudicar drasticamente os resultados.
Como reduzi-lo?
- Identifique atribuições ou recursos adquiridos.
- Reduza os tempos de feedback.
- Colaborações presenciais.
7. Defeito
Quantidade de desperdício causado por defeito = (Impacto do defeito) x (Tempo que passa despercebido)
Devido à sua complexidade, o desenvolvimento de software gera defeitos inevitáveis, mas o problema surge quando eles se prolongam na execução e fixação ou o custo incorrido na fixação ou impacto de retrabalho. Além disso, os principais erros e bugs de código podem afetar e prejudicar todo o ciclo de vida do produto e deixá-lo vulnerável a ameaças de segurança, causando milhões de perdas de receita.
O que você pode fazer para reduzir isso?
- Testes imediatos.
- Integração constante.
- Teste do produto e lançado o mais rápido possível.
