archivo

Archivo de la etiqueta: flexibilidad

No se trata de improvisar, sino de ser flexible. Muchas veces los problemas en las arquitecturas y en el desarrollo de software son difíciles de resolver en tiempo de definición. No es cuestión de programar mediante prueba y error, de programar por permutación, siempre es conveniente reflexionar sobre la solución a aplicar tratando de reducir el nivel de abstracción con el que inicialmente se enfoca la solución.

Me parece muy interesante la siguiente reflexión de Christopher Alexander, Sara Ishikawa y Murray Silverstein en su libro “A Pattern Language”: “Todas esas decisiones de diseño detallado que nunca pueden ser resueltas con antelación en el papel, se pueden hacer durante el proceso de construcción”.

Esta cita está por encima de las metodologías o marcos de trabajo, es una forma de entender el desarrollo de software, de tratar de ser flexible y ser consciente de que no todo puede o debe ser predecible.

Hay una cosa cierta, de cada proyecto en el que trabajamos, si tenemos la intención, aprendemos más y por tanto, tenemos la posibilidad de adaptar mejor nuestra forma de trabajar a las circunstancias que se presenten y de poder hacer uso de esa experiencia para tratar de acertar más en nuestras decisiones.

Por ese motivo me parece muy interesante la reflexión de Lowell Lindstrom que si bien está centrada en la programación extrema es perfectamente extensible a cualquier otro esquema de trabajo (traducción libre): “XP no es el final del viaje, es sólo el pozo de agua corriente que es especialmente sabroso para muchos. Vamos a aprender más con cada proyecto que hacemos”.

Cada proyecto es diferente e incluso dentro de cada uno hay circunstancias que implican cambios más o menos sensibles en el enfoque, por ese motivo si nos limitamos exclusivamente a aplicar las mismas ideas, prácticas y métodos de trabajo probablemente estamos restringiendo nuestra capacidad de poder aplicar determinadas soluciones que pueden resultar más aconsejables al contexto del proyecto.

Ojalá todo fuera tan fácil en el desarrollo de software como seguir unas guías, de hecho si así fuera la mayoría de los proyectos tendrían éxito y el concepto de crisis del software estaría erradicado.

¿Tienen éxito la mayoría de los proyectos? Lo mismo tu respuesta es que precisamente no tienen éxito por no aplicar en ellos marcos de trabajo o metodologías. No quiero decir que no se hagan uso de ellas, sino de que sea excesivamente rígido con la forma en que se aplican y de que no se tenga en cuenta de que nuestro conocimiento y las técnicas que tenemos a nuestra disposición son herramientas que tenemos la posibilidad de aplicar o no en función de las necesidades del proyecto.

Los procesos y las metodologías delimitan un camino y eso de por sí restringe las posibilidades de actuación. Esto no es ni bueno ni malo de por sí, depende realmente de hasta dónde llegan esas restricciones y de las posibilidades que tenemos de hacer excepciones cuando el proyecto lo requiera.

Cuando un proceso o una metodología entran en un nivel de detalle alto nuestro margen de maniobra se reduce, si quien controla (en el caso de que haya alguien) el cumplimiento de la misma no permite excepciones nuestra frontera empieza y termina allí, esto podría ser interesante cuando tienes la mayor parte de los detalles de un proyecto bajo control pero sabemos que esas condiciones, prácticamente ideales, son complicadas de conseguir.

No se trata de elegir entre extremos sino de ser flexible ya que no siempre es problema de la rigidez de quién especifica los procesos, también es importante que nosotros seamos flexibles y entendamos que la organización también necesita gestionarse y que por ese motivo, a veces, se establecen ciertas premisas que aunque puedan no gustarnos los gestores entienden que son necesarias (aunque no por ello tienen que ser acertadas siempre).

Al final es cuestión de que todas las partes sean sensatas y no se posicionen en esquemas de funcionamiento que no se adapten a un contexto y a las necesidades del proyecto.

Nuestro objetivo y el del cliente debe ser tratar de conseguir el mayor valor posible para el producto, lo cual requiere que se haga un uso racional de la inversión ya que de esta forma tendremos la posibilidad de obtener un mayor rendimiento de las iteraciones.

Para eso es muy importante desarrollar con intención, lo que requiere una alta implicación de todos los stakeholders del proyecto, sobre todo del responsable funcional, de las personas que colaboran con él y del equipo de desarrollo.

Sin embargo, la falta de intención no es el único factor que puede hacer que no se extraiga el mayor aprovechamiento posible de la inversión, hay otro muy importante que son las actividades de proceso o metodología, ya sea incluidas por el propio equipo de desarrollo o por la organización, que generan entregables que no aportan un valor real al producto y al proyecto.

Este mal es muy común en organizaciones que entienden que la singularidad de los proyectos es algo secundario y que todos deben tener un cuerpo de procesos común. Esto es lo mismo que pretender que una misma talla de ropa sirva para todos los componentes de una familia.

Parto de la base de que la organización necesita armonizar determinadas actividades de los proyectos, requiere recibir unos inputs necesarios para su gestión y para mantener un cuerpo de conocimiento. Soy de la opinión de que la base deben ser unos mínimos, comunes a todos los proyectos, con la mentalidad abierta a crear excepciones si fuera necesario (teniendo en cuenta que la excepción no se debe convertir en la norma) y que a partir de ahí, sea el proyecto quien mande, alcanzándose acuerdos para ampliar esa base de procesos si todas las partes entienden que aporta valor.

El problema lo tenemos cuando no se parte de mínimos y cuando se intenta encorsetar el desarrollo con actividades, sean pocas o muchas, que no solo restan flexibilidad al proyecto sino que originan costes en tareas y entregables cuyos coste de realización (y mantenimiento) son superiores al valor que proporcionan al producto y a la organización.

La palabra proceso nos crea la imagen mental de burocracia y esto es así no porque nos hayamos levantado de esa manera una mañana sino porque la mayoría de nosotros ha sufrido procesos de desarrollo de software que daban lugar a un mayor coste que a un beneficio real y que estaba lleno de hitos y entregables que se convertían en un obstáculo más que solventar en el ya de por sí complejo camino que son los proyectos de desarrollo de software.

Sin embargo, por mucho que no soportemos los procesos, muy probablemente aplicamos determinadas metodologías, estrategias o prácticas que en esencia también son procesos, lo que pasa es que como muchas de ellas para nosotros son automatismos o confiamos en sus resultados, no las vemos de esa forma.

¿Qué quiero decir con esto? Pues que tal vez el problema no se encuentra en el concepto sino en su definición e implementación, en la falta de una visión orientada a su mejora continua (si un proceso no sufre ajustes algo está pasando) y a la falta de flexibilidad que se ofrece a la hora de adaptarse a las particularidades concretas de cada proyecto.

Un proceso debe aportar, no restar. Si nos pone límites ficticios que dificultan nuestro margen de maniobra quiere decir que nuestros resultados en el proyecto estarán condicionados por impedimentos que perfectamente podrían haberse eliminado, ¿no es absurdo en estos casos abogar por la ortodoxia en lugar de la solución que más conviene?.

En los proyectos de desarrollo de software intervienen infinidad de variables y es el resultado de la colaboración de una serie de personas y no hay nada más impredecible que un ser humano, por ese motivo la definición de los procesos debe tener en cuenta esa circunstancia.

No se trata de acertar a la primera sino de tener capacidad de ir adaptándolo y mejorándolo con la experiencia y de dotar a su aplicación de la flexibilidad suficiente (incluyendo excepciones) para adaptarse lo máximo posible a las necesidades concretas que requiere el proyecto.

Lo importante realmente en la predisposición a modificar la agenda, ahí es donde está la clave de todo esto. Esa predisposición supone haber entendido la incertidumbre del desarrollo de software y la necesidad de adaptarse al cambio y a los nuevos contextos que surjan durante su ejecución.

Sin embargo, son muchos años aplicando la filosofía de la llave en mano, de la gestión de agendas, de ciclo de vida clásico, de pensar que un proyecto de desarrollo de software es solo proceso y que no tiene por qué verse afectado por su contexto. Respeto ese cuerpo de conocimiento ya que supuso el primer intento de crear un orden dentro del caos y tuvieron un cierto éxito en comparación con el estado del arte anterior en el que sencillamente los proyectos, por regla general, no se gestionaban.

Pero tampoco supusieron la solución definitiva, solo un primer avance, sin embargo muchas organizaciones, muchos profesionales de reconocido prestigio creyeron ver ahí la solución a la ejecución de los proyectos software. El tiempo vino a demostrar que no, como tal vez el tiempo venga a demostrar que los enfoques ágiles tampoco lo son, sino una siguiente aproximación a otro modelo que permita obtener mejores resultados.

En cualquier caso y sea cual sea el enfoque a aplicar, lo realmente importante es el valor del producto y considerar la agenda como algo inamovible es atentar precisamente contra ese principio.

Recomiendo la lectura, si no lo habéis hecho ya a esta serie de artículos que si bien están orientados a los enfoques iterativos incrementales tratan, en esencia, de este mismo problema:

La (difícil) convivencia entre el enfoque iterativo incremental y el cumplimiento de agendas: Parte I, Parte II y Parte III.

La gestión de una agenda con falta de flexibilidad en sus parámetros supone no la gestión del proyecto en sí, sino la gestión del desgaste en las relaciones entre los diversos participantes, las cuales se irán deteriorando conforme vaya avanzando el proyecto porque no se terminarán de llegar a acuerdos que sean satisfactorios para ambas partes. La gestión del desgaste tratará de buscar puntos de equilibrio en ese caos en el que se habrá convertido la situación, con el objetivo de intentar exprimir al máximo un fruto al que prácticamente no le queda jugo.

Planificar a largo plazo puede ser esfuerzo invertido en vano. Sí que me parece interesante tener marcados objetivos e hitos, pero no me lo parece tanto, tener un nivel de detalle importante más allá de lo que se considere el corto/medio plazo (que sea uno u otro dependerá del nivel de incertidumbre que exista).

Es importante saber y poder reaccionar ante el cambio y no cerrarnos en un guión preestablecido ya que la película es otra.

Para Peter Drucker: “Tratar de predecir el futuro es como intentar conducir de noche por un camino rural con las luces apagadas mientras miras por la ventana de atrás”.

Una planificación detallada a largo plazo pretende dar una sensación de control: “si doy todos estos pasos conseguiré los objetivos”, pero en realidad es una falsa sensación de control porque para empezar no sabes si tu plan es bueno o no (por mucho que confíes en él) y tampoco si se van a mantener constantes en el tiempo el contexto o condiciones en las que se ha realizado el mismo (pero es importante tener en cuenta que el problema no suele ser fallar en la planificación, sino como dije antes, ser poco flexible a los cambios cuando resulta necesario).

Precisamente por eso los enfoques predictivos o clásicos en el desarrollo de software no suelen dar buenos resultados porque se especula con una solución basada en un conocimiento limitado de los usuarios del producto que quieren (el conocimiento real se obtiene con el tiempo conforme ellos vayan viendo materializadas sus ideas a lo largo del proceso de desarrollo), dado que estas estrategias prevén estabilidad en las especificaciones, todo empieza a desmoronarse cuando se rompe ese requisito y es demasiado tarde para que los cambios en las especificaciones tengan un impacto leve en el esfuerzo disponible del proyecto.

Llegado a ese punto solo se podrá salvar la situación si cliente y proveedor entienden el problema y tratan de buscar una solución flexibilizando el objeto del contrato, intercambiando tareas y aportando más presupuesto por parte del cliente en el caso de que sea necesario.