Estamos en tiempos disruptivos, los cambios saltan y avanzan por doquier, las innovaciones, el cambio climático, la inteligencia artificial, el Internet de las cosas, los virus (escribo esto cuando el COVID-19 está conquistando el mundo – por si lo lees en un futuro cercano o lejano –), la economía, la política entre otras cosas, se han vuelto impredecibles, bien etiquetaba el Ejército de los Estados Unidos esta era como VUCA (1), tiempos en los que el más rápido le quita el mercado al más lento.
Dado este contexto, la forma como hemos venido haciendo las cosas, aunque nos trajo hasta donde estamos hoy, no es muy útil para este presente ni para la supervivencia en el futuro, pues necesitas generar en tu organización la capacidad de adaptarte rápido a los cambios o de ser el causante del de ellos, es allí donde es necesario un liderazgo Lean-Agile: Lean (2) desde el enfoque de generación de flujo continuo de valor y eliminación del desperdicio, como Agile(3) desde su enfoque en la adaptación, mejora continua, generación de valor y colaboración.
Es desde la óptica Lean y su guerra sin cuartel contra el desperdicio, que quiero poner foco en este artículo, ya que desde TI y de las Áreas de Negocio “hoy en día” no podemos darnos el lujo de tener desperdicios a granel y no hacernos cargo de ellos, permitiéndole a la competencia ganar donde nosotros estamos perdiendo, ergo cualquier desperdicio tarde o temprano será valor que se dejó de generar, energía que dejamos ir y no podremos recuperar.
Los Ocho Desperdicios de Lean en Desarrollo y Mantenimiento de Productos de Software
Lean tiene identificado ocho desperdicios:
· Sobreproducción
· Inventario
· Sobreprocesamiento
· Defectos
· Movimientos
· Transporte
· Esperas
· Creatividad de los empleados no utilizada
Las áreas de TI no son ajeas a estos desperdicios. Seguramente han o has tenido que lidiar con algunos de los que enumero a continuación:
Sobreproducción: hacer más producto del que es requerido
| ||
Síntoma
|
Consecuencias
|
Sugerencias y Comentarios
|
Hacer más software o producto del que es requerido
|
· Pérdida de dinero
· Pérdida de tiempo invertido en hacer definiciones que no son requeridas
· Pérdida de tiempo y dinero probando funcionalidades que no serán usadas
· Pérdida de tiempo haciéndole mantenimiento a software que nadie usa
· En el futuro, migrar a otros sistemas funcionalidades innecesarias
· Software innecesario siendo causa de posibles errores y ocupando espacio en los servidores
|
· Aplicar un enfoque ágil para el desarrollo de productos software
· Construir MVP (Productos Mínimos Viables) (4) y validar hipótesis de valor lo antes posible
· Comenzar a migrar a un paradigma enfocado en Valor y no en el Alcance. No se trata de hacer mucho, se trata de trabajar de forma inteligente
· Priorizar los desarrollos de iniciativas, mantenimientos evolutivos y correctivos por valor, no le diga a todas las áreas ¡sí!
|
Inventario: almacenamiento de producto que no está siendo usado
| ||
Síntoma
|
Consecuencias
|
Sugerencias y Comentarios
|
Versiones o actualizaciones de software que se encuentran desarrolladas y probadas, pero “NADA” que pasan a producción, “NINGÚN” área de negocio las reclama, estan en los servidores de staging esperando que alguien se acuerde de ellas para pasar a producción
|
· Costos y tiempos de actualización de versiones (ej: he visto pagar ingenieros por más de un año actualizando versiones que no salen a producción)
· Costos y tiempos de pruebas de versiones que no están siendo usadas
|
· Borre de su servidor las versiones que no han sido puestas en producción hace más de 4 meses, si nadie las reclama, es que nadie las necesita.
· Priorice las versiones por valor (nuevamente no diga a todo sí, recuerde, no hay tiempo para construir desperdicio)
|
Software subutilizado o no utilizado
|
· Millones de dólares en tiempo y dinero que no están siendo usados.
|
· Identifique si el pareto (20%) de las funcionalidades le genera un 80% de impacto en el negocio.
· Haga programas de gestión del cambio que le permita usar al menos el 20% de lo que compró.
|
Movimientos innecesarios: movimientos innecesarios por parte del equipo de trabajo
| ||
Síntoma
|
Consecuencias
|
Sugerencias y Comentarios
|
Demasiados procesos manuales de parte de su equipo
|
· Emerge un gran número de errores durante los procesos debido a esos procesos manuales
|
· Reemplace y priorice toda tarea repetitiva en su equipo por otra automatizada, de manera que tenga foco en la generación de valor, no tiene sentido que un desarrollador de software esté haciendo trabajo manual en pleno siglo 21.
· Adopte una mentalidad y cultura de DevOps en su equipo, “automatice todo lo automatizable”
· Genere pipelines de CI, CD
· Cree macros que ayuden a poblar datos
· Automatice las pruebas (de todo tipo)
· Use bots
· Tenga herramientas que le den tracking de todo su ciclo de desarrollo de software
|
Sobreprocesamiento: se está volviendo a realizar un proceso sobre un componente de forma innecesaria.
| ||
Síntoma
|
Consecuencias
|
Sugerencias y Comentarios
|
Las versiones no salen oportunamente debido a cambios en el entorno
|
· Las versiones deben ser construidas de nuevo.
· Pérdida de tiempo y dinero de todos los involucrados.
|
· Ver las sugerencias de “desperdicios por inventario”
|
Se especificaron requisitos o historias de usuario que ya no son necesarias porque el negocio cambió, y es necesario volver a hacer definiciones
|
· Pérdida de tiempo y dinero de todos los involucrados
|
· Abandone la idea de tener en productos de software “todo” definido a priori, avance hacia realizar una definición progresiva de las funcionalidades, en vez, de una definición “completa” desde el inicio.
|
Refactor por componentes mal desarrollados (deuda técnica)
|
· Pérdida de tiempo, dinero y performance del producto
|
· Monitoreé y reduzca la deuda técnica, la Agilidad dependerá de ello.
· Exija excelencia técnica tanto de sus colaboradores como de proveedores
|
Rediseño por componentes mal concebidos
|
· Pérdida de tiempo, dinero y performance del producto.
|
· Aplique principios de Arquitectura Evolutiva y Arquitectura Ágil que le permita ser resiliente a los cambios
|
Espera: tiempos muertos mientras se espera el próximo paso del proceso
| ||
Síntoma
|
Consecuencias
|
Sugerencias y Comentarios
|
Controles de cambio demasiado lentos
|
· Pérdida de tiempo y dinero de los involucrados
· Falta de generación oportuna de valor
|
· Automatice su proceso de control de cambios, si es necesario ponga puntos de control, pero que no dependan de un comité, sino de un experto, y que este experto pueda aprobar sobre la herramienta directamente
|
Procesos de aprobación de paso entre plataformas demasiado lentos
|
· Ibídem
|
· Ibídem
|
Al cliente le llega el producto cuando:
· no lo necesita
· la competencia le quito la porción de valor que esperaba ganar
· ya no es necesaria la solución
|
· Íbidem
|
· Adopte una forma de pensar ágil en su organización
· Aprenda a salir a producción con MVP lo más temprano posible (ojala al segundo mes ya tenga software funcionando en manos del cliente)
|
Defectos: defectos visibles e invisibles de los productos
| ||
Síntoma
|
Consecuencias
|
Sugerencias y Comentarios
|
Deuda técnica (defectos invisibles)
|
· Pérdida de tiempo y dinero de los involucrados en la corrección
· Impacto en el negocio por mal desempeño del producto
|
· Monitorée y reduzca la deuda técnica, la Agilidad dependerá de ello.
· Exija excelencia técnica tanto de sus colaboradores como de proveedores
|
Defectos en el producto (defectos visibles)
|
· Íbidem
|
· Exija excelencia técnica tanto de sus colaboradores como de proveedores
· Es una buena estrategia que el equipo que desarrolla el producto sea el mismo que le da mantenimiento en producción, esto genera responsabilidad con lo construido.
· Adopte DevSecOps, o el concepto de ShiftLeft y rete constantemente a su equipo de operaciones y desarrollo. |
Movimientos innecesarios de los productos: el producto es movido a una fase anterior o a un punto innecesario
| ||
Síntoma
|
Consecuencias
|
Sugerencias y Comentarios
|
El producto se devuelve a la fase previa por mala calidad o problema en los requisitos.
|
· Pérdida de tiempo y dinero de los involucrados
Falta de generación oportuna de valor |
· Exija excelencia técnica tanto de sus colaboradores como de proveedores
· Tenga una aproximación ágil en la construcción de productos, haciendo definición progresiva de los mismos.
|
El producto debe ser “bajado” de producción porque la versión salió defectuosa
|
· Pérdida de tiempo y dinero de los involucrados
· Mal impacto ante el cliente
|
· Use estrategias de DevOps como: “Canary Releases” (5), “Dark launches” (6) , “Feature Toogles”(7).
· Desacople Release (Liberación) de Despliegue (8), le dará más maniobrabilidad
|
No emplear el talento de las personas
| ||
Síntoma
|
Consecuencias
|
Sugerencias y Comentarios
|
Solo su voz es la que importa y usted es el dueño de la estrategia
|
· Está perdiendo la oportunidad de recoger recomendaciones importantes de su equipo de trabajo
|
· Reúnase una vez al mes con su equipo y encuentren 2 a 3 cosas a mejorar para el siguiente mes.
|
Estamos demasiado ocupados para sentarnos a conversar y mejorar
|
· Íbidem
|
· Rompa el círculo vicioso y frenético de: “no mejoramos porque no tenemos tiempo, no tenemos tiempo porque no mejoramos”
· Reúnase una vez al mes con su equipo y encuentren 2 a 3 cosas a mejorar para el siguiente mes y en efecto mejórelas (sino esta reunión tambien será desperdicio)
|
Llamado a la acción
Si desde TI o las Áreas de negocio vamos a generar desperdicios, que estos sean experimentos controlados de productos rápidos y baratos, que nos permitan capturar aprendizaje y nos den pistas sobre cómo avanzar en este terreno de volatilidad, incertidumbre, complejidad y ambigüedad, pero que no sean pérdidas de energía que terminen dando oportunidad a la competencia.
Si como CIO, o parte del Equipo del Top Management de TI has identificado al menos uno de estos síntomas, priorízalo, haz de la mejora continua la costumbre de tu equipo, toma métricas y comienza tu camino hacia la excelencia operativa y de negocios de una forma decidida y constante.
Como siempre, bienvenida la retroalimentación
Saludos Ágiles
Jorge Abad.
Notas, Aclaraciones, Comentarios, Referencias y Observaciones.
1. VUCA es un acrónimo utilizado para describir o reflejar la volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad de condiciones y situaciones. Más información en https://es.wikipedia.org/wiki/VUCA
2. Lean es la forma como Jame Womack acuño la esencia del Toyota Production System. Más información en https://en.wikipedia.org/wiki/Lean_thinking
3. Agile es la forma como es conocido el Agile Software Development, comprende varios enfoques para el desarrollo de software bajo los cuales los requisitos y las soluciones evolucionan a través del esfuerzo colaborativo de equipos autoorganizados y multifuncionales y sus clientes / usuarios finales, es representado condensado en cuatro valores y doce principios. Ver más en https://en.wikipedia.org/wiki/Agile_software_development.
4. Un Producto Mínimo viable (MVP – Minimum Viable Product por sus siglas en Inglés ) es una versión de un producto con características suficientes para satisfacer a los primeros clientes y proporcionar comentarios para el desarrollo futuro del producto. Ver más en https://en.wikipedia.org/wiki/Minimum_viable_product.
5. Canary releases: Técnica que proporciona un mecanismo para lanzar la solución a producción a un segmento de Cliente específico y medir los resultados, antes de expandirse y lanzar a más clientes. Ver más en https://www.scaledagileframework.com/release-on-demand/.
6. Dark Launches: Esta técnica proporciona la capacidad de desplear en un entorno de producción de forma “apagada” sin liberar la funcionalidad a los usuarios finales.
7. Feature Toogles: Esta es una técnica para facilitar los “Dark launches” mediante la implementación de conmutadores en el código, que permite cambiar entre funcionalidad antigua y nueva. Ver más en https://www.scaledagileframework.com/release-on-demand/.
8. Desacople el Release del Despliegue, estrategia de DevOps que permite poner código constantemente en producción y habilitarlo cuando este vaya a ser usado, reduciendo el impacton impacto la estabilidad del sistema por cambios realizdos. Ver más en https://www.scaledagileframework.com/release-on-demand/.
9. Gracias a mis amigos Lucho Salazar- https://www.linkedin.com/in/luchosalazar/ - y Ricardo Cruz - https://www.linkedin.com/in/ricardocruzmartinez/ - por sus aportes y correcciones.
No hay comentarios.:
Publicar un comentario