archivo

Archivo de la etiqueta: desperdicio

Para Peter Drucker: “No hay nada tan inútil como hacer eficientemente algo que no debería haberse hecho”.

El desperdicio de esfuerzo, en muchas ocasiones, tal vez la mayoría, realizado con la mejor de la intenciones, hace mucho daño a los proyectos de desarrollo de software.

Querer avanzar demasiado deprisa, desarrollando nuevas funcionalidades cuando hay otras que todavía no están maduras y que dependen entre sí, querer abarcar más de lo que se puede, trabajar con demasiadas hipótesis no validadas. Todo ello es susceptible y, de manera muy probable, de generar desperdicio.

Y no se trata de falta de interés, esfuerzo o competencia, sino de no saber administrar adecuadamente los tiempos, de no priorizar bien y de no saber decir que no.

Un enfoque iterativo incremental de ciclos cortos y el feedback que se obtiene a partir de ellos permite probar la efectividad de los enfoques de los usuarios (que inicialmente no son más que hipótesis sobre lo que quieren) y realizar ajustes que nos van acercando progresivamente a una solución que realmente satisface las expectativas del usuario.

En los enfoques clásicos las hipótesis no se compruebas hasta etapas finales del desarrollo en donde los presupuestos están casi agotados y en donde el tamaño del producto dificulta la realización de modificaciones. Menos dinero, más envergadura del producto, más deuda técnica, menos margen de maniobra.

Todos los que hemos trabajado con ciclos de vida en cascada y/o con contratos llave en mano hemos sufrido esa situación. Da igual lo bien que trates de hacer el análisis que siempre habrá funcionalidades que no se han definido correctamente, que ni siquiera se han definido o que son mejorables y, además, siempre existirán circunstancias a lo largo de la ejecución del proyecto que impliquen cambios de prioridades.

El conocimiento real del producto se va obteniendo conforme se va desarrollando, ¿por qué? pues porque se contrastan las hipótesis y con ello se va mejorando y adquiriendo nuevo conocimiento.

Está bien tener una visión de lo que se quiere pero el detalle se debe trabajar poco a poco, lo demás es correr un riesgo importante de desperdiciar esfuerzo y no nos podemos permitir ese lujo porque en el propio devenir del proyecto y del desarrollo del producto habrá esfuerzo que no proporcione un valor directo, ya que a veces la solución elegida para una determinada funcionalidad deberá cambiar de orientación o ser perfilada en diferentes iteraciones, algo que es normal en cualquier proyecto y que, por tanto, debe contar con suficiente respaldo presupuestario que, como no andará sobrado, es conveniente cuidarlo desde un principio.

Realmente podemos llevarnos horas, días, semanas, meses, discutiendo sobre si la aplicación de una determinada estrategia, enfoque o práctica es adecuada, pero solo se tratará de especulación, muchas hipótesis e ideas.

¿Es humo? Para mi el humo tiene mucho más que ver con hipótesis que solo han tenido en cuenta aspectos teóricos u opiniones personales que no se han contrastado, al menos, con la realidad del contexto en el que se quieren aplicar. Si, por lo menos, las ideas se sustentan en un análisis objetivo, yo no lo llamaría humo, pero no dejan de ser hipótesis sin validar.

Lo queramos llamar humo o no, se trata de mucho tiempo invertido en establecer un conjunto de ideas que lo mismo la realidad se encarga de demostrar que son equivocadas.

Ese tiempo invertido puede suponer dinero (siempre lo es aunque no te suponga un gasto directo), pérdida de oportunidad y/o dificultad de adaptación al cambio si has desarrollado un producto prácticamente finalista.

No solo se trata del síndrome de la última versión sino que también nos lo encontramos en cualquier evolución del software (o en un desarrollo desde cero) cuando desde un principio se quiere tener una primera versión operativa del producto con demasiadas funcionalidades (digo demasiadas y no todas).

En mi opinión, la primera versión operativa debe tender hacia el menor número de funcionalidades necesarias, buscar el pragmatismo y la simplicidad aún a costa de tener una versión que tal vez no termine de satisfacer completamente al usuario (hay que tener en cuenta que, en cualquier caso, la decisión sobre la línea de desarrollo del producto recae en el usuario y de él dependerá hasta que punto se deja asesorar y qué considera como mínimo imprescindible).

A partir de esa versión toca iterar y seguir evolucionando el producto, siempre con la simplicidad como referencia.

¿Por qué lo simple como referencia? Porque es más sencillo llegar así hacia una solución más compleja, gracias al feedback obtenido por los usuarios y por el aprendizaje que se va obteniendo a todos los niveles mientras se desarrolla el producto y también porque en el caso de descubrir que el enfoque no es adecuado se ha desperdiciado menos esfuerzo en tareas que se podían haber evitado.

La idea que tienen los product owners o los responsables funcionales del software que quieren no es más que algo abstracto, es más, hasta que el producto empiece a materializarse y cobrar una cierta entidad es más acertado decir que su idea inicial es lo que creen que quieren porque hasta que no se empiece a experimentar no saldrán a la superficie comportamientos y funcionalidades deseados pero que estaban ocultos o el caso contrario, comportamientos y funcionalidades que se creían efectivos y útiles y que no son ninguna de esas dos cosas.

De ahí la conveniencia de aplicar desarrollo iterativo incremental y con más razón en aquellos casos donde el sistema se prevea complejo y/o los responsables funcionales no terminen de verlo claro.

Pero desarrollo iterativo incremental es una idea muy general, si definimos ciclos largos hemos fraccionado algo el problema pero probablemente será insuficiente y será mayor la cantidad de desperdicio generado.

También es cuestión de enfoque, mejor siempre partir de soluciones simples consolidadas y validadas para a partir de ahí crecer hacia otras más complejas.

¿Se trata de obtener una versión rápida a toda costa? Versión rápida a toda costa es algo demasiado general, sí que resulta interesante cuanto antes obtener un feedback del usuario pero también que el desperdicio generado sea el menor posible (por lo que los ciclos de desarrollo deben hacerse con intención, de no hacerse así estaremos haciendo desarrollo por permutación y eso tiene un coste importante) y que no perdamos de vista que para seguir generando nuevas versiones es necesario que las modificaciones a realizar sobre el producto se puedan hacer en unos plazos razonables, por lo que en el momento en el que la deuda técnica supere unos determinados umbrales perderemos esa capacidad de respuesta rápida o por lo menos no tan rápida, efectiva y económica como sería deseable.

Tal vez al principio consideres que lo más importante es desarrollar una versión aunque sea prototípica para verificar si el producto va por el camino deseado y que determinados factores como la calidad del código son secundarios. Al final es algo que tendrás que valorar tú en base al contexto en el que estás desarrollando.