martes, 3 de junio de 2008

El costo del cambio (parte II)

La primera parte (que recomiendo leer antes de seguir) de este artículo, comenzaba el comentario del libro de Kent Beck, Extreme Programming Explained presentando la curva de "costo del cambio" a través del tiempo, y finalizaba proponiéndonos imaginar cómo afectaría al desarrollo de un proyecto el pensar en una curva aplanada o asintótica. ¿Cómo desarrollaríamos? ¿qué factores tendríamos en cuenta en nuestras decisiones? ¿cómo diseñaríamos?

Decir que esa curva es aplanada, implica que el software puede modificarse indefinidamente sin perjudicar su calidad. El costo aumenta ya que -siguiendo las teorías "tradicionales"- cada modificación introduce errores, cierta incoherencia y complejidad al sistema, lo torna cada vez más difícil de entender, aumentando las horas/hombre necesarias para llevarla a cabo. Por otro lado están los costos de modificar un sistema en producción, y sobre todo los riesgos que ello implica. Bien, todos esos terrores desaparecen en nuestro nuevo mundo. Lo mismo me cuesta modificar el sistema hoy que hacerlo mañana.

Aclaremos antes de seguir que utilizamos "cambio" en un sentido amplio, que implica no sólo cambios en el software, sino en la planificación, en el diseño y en la conformación del equipo de trabajo. Ahora sí, ¿cómo nos afectaría esta nueva curva?

En primer lugar, diseñaríamos y planificaríamos "para hoy", ya que no tiene caso adelantarse en el horizonte, gastando más en planificar hoy lo que, de ser necesario, podremos planificar mañana al mismo costo. Y de esta manera no enfrentaríamos el riesgo de que cambios en el negocio o en las tecnologías tiren nuestra planificación y diseño por la borda.

Entregaríamos cada funcionalidad completa en su forma más minimalista, y trabajaríamos sobre los comentarios y propuestas del usuario, que mientras tanto podrá utilizarlo tal cual está, ya que si bien es probable que tenga mayores costos por modificar el sistema en producción, éstos no irán creciendo, y no superarán el riesgo de desarrollar a espaldas de la supervisión del cliente.

Eso en cuanto a nosotros. ¿Y al cliente, cómo lo afecta esta nueva perspectiva?

El punto más interesante es que desde este nuevo punto de vista los cambios en el negocio que afecten al sistema en desarrollo ya no son amenazas sino oportunidades. Cada cambio en la dirección del viento provoca movimientos que el cliente puede aprovechar para incorporar al sistema y adaptarse más rápido que sus competidores. El cliente tiene un sistema funcionando -porque hemos entregado temprano y mínimo-, y un equipo de desarrollo en marcha y dispuesto a cualquier giro brusco, ya que no tiene demasiado invertido en costosos planes para el futuro.

Cualquiera que haya trabajado en una PyME reconocerá en todo o parte esta forma de trabajar o de ver las cosas, más o menos explícita. Talvez intuya en los párrafos anteriores los clásicos requerimientos sorpresa de una semana a otra que hacen que de repente todo el mundo esté trabajando "en otra cosa". De hecho esta es la clásica ventaja competitiva de la PyME frente a, por ejemplo, las grandes consultoras para las cuales cada proyecto implica el movimiento de un ejército de analistas, diseñadores, programadores, etc., y en general una abultada factura.

En este planteo estas prácticas no son automáticamente tildadas de poco profesionales y desorganizadas. Si estos conceptos se han "pegado" es porque manejar el nivel de cambio del que hablamos es terriblemente más difícil que vivir en un ambiente calmo y estático creado por requerimientos inamovibles y diseños absolutistas... El problema es que esos ambientes son imaginarios, y tienden a explotar dejándonos frente a la cruda realidad: el negocio cambió y los requerimientos son diferentes, las nuevas tecnologías han vuelto obsoleto al diseño, y la realidad ha ridiculizado las planificaciiones.

La dificultad para mantener la organización en medio del cambio continuo puede hacer que la rueda gire fuera de control rápidamente y la curva del costo abandone su reciente placidez buscando de nuevo el techo del gráfico. Cuanto más rápido cambiemos más rápido puede desbocarse el proyecto, si no llevamos al mismo tiempo un estricto control sobre las formas de implementar esos cambios.

Volvemos a las PyMEs. ¿Control y organización para el cambio? Bueno, eso sí suena como una utopía. Pero recordemos la primera parte de este artículo: las herramientas han mejorado enormemente, nuestra comprensión de los procesos de cambio ha mejorado, y no es imposible para una empresa pequeña contar con la tecnología y sabiduría necesarias para llevarlo a cabo.

De todas maneras, ¿existe realmente otra posibilidad? No creo que estemos hablando de una opción. Una consultora puede perder un cliente, un proyecto. Puede darse el lujo ocasional -si bien doloroso- de salirse del presupuesto para enfrentar el costo de un cambio no previsto. Y así y todo son mayoría las consultoras -si no todas a este punto- que han adoptado algún tipo de metodología ágil para muchos de sus proyectos. Es decir, el manejo del cambio ya no es siquiera, como hasta hace algunos años, una ventaja competitiva, sino una característica necesaria para sobrevivir.

En la tercera parte repasaremos brevemente el cómo según Kent Beck (pero no demasiado, ya que él lo hace mejor que yo) y buscaremos un punto intermedio entre los cambios radicales que propone y las "metodologías tradicionales".

No hay comentarios.: