7 desperdicios en el desarrollo de software Lean y cómo prevenirlos

El pensamiento Lean Process prioriza la erradicación y reducción de la acumulación de residuos. A pesar del enfoque "ajustado" adoptado por las principales empresas, persisten algunas prácticas estándar de "desperdicio" debido a su "naturaleza obvia". La naturaleza que está profundamente grabada en las prácticas humanas y organizacionales es obstinada hasta que se toma un enfoque estricto.

¿Qué es Residuos?

Cualquier cosa que requiera recursos/tiempo o esfuerzo, pero que no produzca resultados relevantes en el rendimiento o la generación de ingresos, se denomina “Desperdicio”.

En última instancia, el procedimiento de "reducción de desperdicios" está diseñado y orientado para aumentar la productividad y los resultados del equipo.

Sin embargo, ahora que el desarrollo de software Lean es el antepasado de Agile, podemos adoptar estos siete principios de reducción de desperdicios en ingeniería y desarrollo de software para generar productos y servicios efectivos, reducir costos y acelerar el tiempo de comercialización del producto.

1. Trabajo parcialmente terminado

Si el trabajo anterior nunca se reinicia, ese esfuerzo fue un desperdicio.

Cualquier trabajo hasta que esté terminado/completado no se suma a la propuesta de valor del cliente; por lo tanto, pierde tiempo y desafía el mantenimiento del código si se pone en espera.

Un ejemplo contemporáneo es cuando un cliente requiere modificaciones o características adicionales en un producto. El negocio se compromete a terminarlos con urgencia; el equipo de desarrollo debe detener el trabajo en curso y actuar según los requisitos. En la misma página, si el trabajo anterior nunca se reinicia, ha sido una pérdida de esfuerzo.

o

Documentación no codificada: los requisitos se detallan minuciosamente pero nunca se implementan.

¿Cómo reducir este desperdicio?

• El enfoque debe estar en "terminar" y no solo "comenzar" un proyecto.
• Reducir las tenencias de obras en curso.
• Deje de esperar la especificación detallada de cada requisito hasta que el equipo esté listo para implementar los esfuerzos (entonces no será una causa perdida).

2. Procesos adicionales

Cualquier proceso agregado o documentación no leída que no transmita un valor práctico y prolongue innecesariamente el tiempo o el logro del mercado del producto es un desperdicio.

Sin embargo, las políticas comerciales a menudo exigen dichos documentos, con un papeleo considerable que nunca se lee. Esos esfuerzos son extravagantes.

Ejemplos típicos:

• Detalles innecesarios de la documentación.
• Gestión adicional o planificación sin ejecución.

¿Cómo reducirlo?

Las organizaciones pueden diferenciar entre lo que es una causa/esfuerzo perdido y lo que aporta valor a la mesa, el enfoque debe estar en producir resultados significativos y canalizar los esfuerzos para hacer más trabajo de "calidad" al limitar la "cantidad" de trabajo.

3. Funciones adicionales

Cualquier característica o características de bajo valor que se agregan para/por el cliente pero que no se solicitan/no contribuyen al aumento de los ingresos es una pérdida de esfuerzo.

Las empresas cometen este error de desarrollo cuando agregan características que no se utilizarán o ejercitarán mucho; esta nueva función, de hecho, permanece inactiva y aumenta la complejidad de la aplicación.

La regla del software 80/20 juega un papel importante: el 80 % de los usuarios solo utiliza el 20 % de sus funciones. Por lo tanto, el enfoque debe estar en hacer que ese 20% de funciones sean de primera categoría para retener a los usuarios existentes.

Los códigos adicionales tienen sus desventajas:

• Aumenta la complejidad de la aplicación.
• Puede crear un posible punto de bloqueo de la aplicación.
• Requiere un esfuerzo posterior innecesario en el seguimiento y mantenimiento a lo largo del ciclo de vida del producto.

¿Cómo reducir este desperdicio?
Concéntrese en el desarrollo iterativo, lo que significa que, durante el lanzamiento inicial del producto, construya características principales sólidas que definan la USP de su aplicación.

Concéntrese en hacerlo funcional y valide el aprendizaje del avance continuo del producto. Además, siga creando funciones adecuadas en función de su análisis de mercado, el comportamiento del consumidor y los comentarios.

4. Cambio de tareas

Asignar personas a múltiples tareas cuando no se sienten cómodos con ello y dificulta su proceso existente puede tomar una gran cantidad de sus días. La forma más eficiente de terminar una o dos tareas específicas es terminar una a la vez.

Al cambiar entre tareas, hay un pequeño costo de tiempo para cerrar la existente y obtener impulso en la otra, esto se denomina cambio de contexto, y si espera una transición constante de una a otra, estos cambios de contenido se acumulan, lo que retrasa la “resultado” o “tiempo de entrega”.

¿Cómo reducirlo?

Simple: una cosa a la vez.

• Reducir el cambio de contenido.
• Minimice las interrupciones o distracciones.
• Posponer los que no son importantes.
• Asignar recursos como un proyecto a la vez.

5. Espera/Retrasos

Las dependencias de aprobación deben programarse principalmente durante la hoja de ruta del producto; si no se asigna un intervalo de tiempo específico, prepárese para recibir respuestas y comentarios retrasados. Los retrasos también evitan que el consumidor se dé cuenta del valor real del producto. Pero, como desarrolladores o diseñadores, debe esperar la aprobación del trabajo realizado; por lo tanto, no puede evitar el lapso de tiempo por completo.

¿Qué puedes hacer para reducir esto?

• Elija/asigne algo mientras espera los comentarios existentes.
• Asigne tiempo para ingresar y revisar.
• Considere llamadas rápidas, conversaciones cara a cara en lugar de enviar los cambios por correo electrónico.
• Retroalimentación periódica.

6. Movimiento

Si los equipos de desarrollo o investigación se han dispersado con la información adquirida y no la marcaron/etiquetaron adecuadamente, puede tomar una eternidad eliminar la confusión y entrar. Si la información se extravía cada vez que se entrega un entregable; obstaculizará los resultados drásticamente.

¿Cómo reducirlo?

• Asignaciones de etiquetas o recursos adquiridos.
• Reducir los tiempos de retroalimentación.
• Colaboraciones presenciales.

7. Defecto

Cantidad de desperdicio causado por defecto = (Impacto del defecto) x (Tiempo que pasa desapercibido)

Debido a su complejidad, el desarrollo de software tiene defectos inevitables, pero el problema surge cuando se prolongan en la ejecución y reparación o el costo incurrido en reparación o reelaboración impacta. Además, los errores y errores de código importantes pueden afectar y obstaculizar potencialmente todo el ciclo de vida del producto y dejarlo vulnerable a las amenazas de seguridad, lo que genera una pérdida de ingresos millonaria.

¿Qué puedes hacer para reducir esto?

• Pruebas inmediatas.
• Integración constante.
• Pruebas de productos y lanzamiento lo antes posible.