7 Desperdícios no Desenvolvimento Lean de Software e Como Preveni-los

Publicados: 2022-04-18

O 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.