archivo

Archivo de la etiqueta: incertidumbre

Jim Highsmith en su libro “Adaptive Software Development” realiza la siguiente reflexión: “El aprendizaje rápido requiere iteraciones: intentar, revisar, repetir”.

Aprender sobre hechos y no trabajar indefinidamente sobre hipótesis es para mi la esencia de la iteración.

Es cierto que la hipótesis dura (para bien, para mal o para regular) hasta que tenemos el resultado definitivo del proyecto en producción ya que hasta que de manera completa no se utiliza en un contexto real no podemos medir con precisión la satisfacción con el producto pero también lo es que la niebla se despeja poco a poco conforme el usuario va probando versiones parciales del mismo (en producción real preferiblemente) y va proporcionando su feedback.

En este proceso no solo aprende el desarrollador sino que también aprende el usuario porque de lo que cree que quiere (que no deja de ser una idea abstracta y a gran escala) a la solución que realmente le satisfaría, hay un largo trecho.

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.

Comenta Stephen Hawking que: “La inteligencia es la habilidad de adaptarse a los cambios”. Y es así, si no lo haces, estás abocado a no evolucionar, a esperar sentado a que otros (personas y circunstancias) decidan tu suerte.

Adaptarse al cambio requiere tener mentalidad abierta, no estar atado a prejuicios y contemplar más posibilidades que las que nos pueden parecer, a priori, más válidas.

En los proyectos de desarrollo de software trabajamos en un entorno de incertidumbre, en el que las condiciones cambian, en donde se pasan de situaciones supuestamente bajo control a otras que se nos escapan de las manos, en donde las que eran las mejores decisiones la semana pasada requieren ser revisadas.

Adaptarse al cambio no es improvisación sino entender la propia naturaleza del desarrollo de software. Ahora bien, la línea que la separa ambos conceptos es muy delgada, de ahí que sea una habilidad la adaptación al cambio, primero por la detección de la necesidad (y la inteligencia y el valor para darnos cuenta de que tenemos que actuar en consecuencia) y en segundo lugar porque todo se debe tratar de hacer con intención, no vale cualquier respuesta, la que tomemos, pese a estar equivocada, no debe basarse en un prueba y error, salvo que no seamos capaces de detectar que una de las opciones sea la mejor.

No se puede entender el desarrollo de software sin cooperación y sin el elemento imprescindible para que sea efectiva: la comunicación.

Cuantos más distancia (no me estoy refiriendo a distancia física) haya entre las personas y los equipos y más muros (o fosos) se pongan en medio más complicado será que el proyecto vaya a algún sitio.

La creatividad también es importante si no se pierde el control sobre la misma ya que no poseemos un recetario que ofrezca soluciones a todos los problemas.

Comenta Alistair Cockburn que: “El desarrollo de software es un juego cooperativo de invención y comunicación” y estoy totalmente de acuerdo con esa apreciación: si no sabes o no quieres jugar el trabajo se resiente.

Reducir distancias, eliminar fronteras y agilizar las relaciones requiere de mucho esfuerzo y habilidad pero sobre todo depende de que creamos que realmente es así como hay que trabajar. No basta con que lo leamos o que nos lo digan, hay que creer en ello porque mantener el equilibrio no es nada sencillo debido a que las propias contingencias de un proyecto desestabilizan y porque detrás de todo estamos las personas y no hay nada menos estable que nuestro comportamiento.

Los dos principales motivos que hacen que los presupuestos de partida y las planificaciones (incluso a muy alto nivel) no se ajusten posteriormente a la realidad son:

– La incertidumbre. Sabes que va a haber contingencias en el transcurso del proyecto y que las mismas afectarán al presupuesto y los plazos. Puedes aplicar un colchón de seguridad en función de las variables que conozcas del proyecto: tecnología, complejidad, cliente, etc…, pero incluso contemplando ese factor las posibilidades de error siguen siendo importantes porque prevés un comportamiento de esas variables en base a la experiencia anterior (en el presente el contexto puede ser diferente y, por tanto, el comportamiento también) y porque hay variables que sencillamente no controlas.

– El desconocimiento. Muchas veces se presupuesta y planifica sin conocer las expectativas del área usuaria y la complejidad funcional real que va a tener el sistema. Se tienen ideas generales y sobre eso se construye una hoja de ruta, acertar en base a esto es casi un milagro.

Al final, el presupuesto y los plazos serán restricciones que condicionarán el proyecto y que si están lejos de la realidad (en muchos casos es así) condicionarán a la calidad del producto final.

Sé que trabajar con un presupuesto fijo da tranquilidad: “Tengo la previsión de gastarme X para obtener Y”, pero en el desarrollo de software para obtener Y te tienes que gastar Z que puede ser menor, igual o mayor (casi siempre) que X.

No se trata de tener barra libre. El presupuesto tiene que ser bien gestionado e invertido pero es importante tener presente que si el objetivo real es tener un sistema de información acorde a las expectativas que se tenían en él (tanto a nivel funcional como no funcional) no podemos estar atados a la inflexibilidad de un presupuesto fijo e inamovible.

Comentan Mary y Tom Poppendieck que: “El rápido desarrollo tiene muchas ventajas. Sin velocidad, no se puede retrasar las decisiones. Sin velocidad, no tenemos información fiable. En el proceso de desarrollo, el ciclo de descubrimiento es fundamental para el aprendizaje: diseñar, implementar, feedback, mejorar”.

Me parece muy interesante que cita como ventajas, inconvenientes o deficiencias propias de otras estrategias de desarrollo: como atrasar casi indefinidamente decisiones que hay que tomar (gusten o no) y que las hipótesis formuladas queden sin ser demostradas durante demasiado tiempo.

Lo que está claro es que un enfoque clásico donde hay que esperar al final del proyecto a que se levante el teĺón para ver si el resultado es el adecuado es un riesgo absolutamente innecesario y que no se ajusta a la naturaleza del contexto del desarrollo de software: incertidumbre y cambio.

Si la solución no es acertada hay que esperar hasta el final, si hay que mejorar cosas (no solo del producto sino también del funcionamiento de las personas implicadas en el proyecto) también hay que esperar al final (es cierto que se pueden corregir deficiencias en ese funcionamiento sobre la marcha pero se escaparán muchas de ellas debido a que no se tendrá conciencia del impacto real que están teniendo en el desarrollo del producto).