Archivo

Archivo de la etiqueta: incertidumbre

Cuando se falla en las estimaciones estamos golpeando en la línea de flotación del proyecto y también contra nosotros mismos. Se falla muy a menudo y después toca sufrir las consecuencias porque se adquieren compromisos que costarán muchísimo esfuerzo ser respetados.

¿Por qué nos equivocamos en las estimaciones? Son muchos los factores que pueden influir:

- La incertidumbre inherente que tienen los proyectos de desarrollo de software. Si aplicamos un enfoque iterativo incremental con sprints cortos tiene una menor o nula influencia dentro de ese segmento de trabajo, pero si consideramos el proyecto en su totalidad sí que la tiene cuando hay cambios significativos ya sea sobre las condiciones iniciales o sobre el producto que se lleva desarrollado.

- Se tiende a estimar considerando situaciones ideales y después sabemos que hay problemas.

- Se estima en muchos casos sin conocer suficiente detalle sobre el trabajo a realizar.

- Se estima en muchos casos sin conocer suficientemente las restricciones de la tecnología o del entorno de trabajo.

- No estima quien va a realizar el trabajo.

- La presión del cliente por tener plazos más cortos (y a menor coste).

Estoy seguro de que se os ocurren otro montón de causas que provocan que no se acierte con las estimaciones. Ahora bien, una cosa es que sea difícil estimar y otra que no se intente acertar en lo posible con las mismas porque no queda otra, por ese motivo es importante tomar el control de todos aquellos factores que estén en nuestra mano y que puedan afectar a la calidad de la estimación, esto dependerá como no podría ser de otra forma del proyecto en sí y de su contexto.

Como sabemos los problemas que hay con las estimaciones y que es necesario dar la importancia que se merece al feedback sería recomendable que el cliente pensase más en términos de valor que de agenda, si bien, no resulta sencillo conseguir esas condiciones ya que se mostrarán, por términos generales, reacios a considerar que el presupuesto inicial puede variar después …

Los presupuestos fijos en los proyectos sobre una base de funcionalidades que hay que desarrollar (y que son o pueden ser innegociables) dan lugar a fuertes desviaciones en las previsiones iniciales que se pueden ver reducidas o acentuadas en función del conocimiento del negocio, tecnología y de las personas (componentes de los stakeholders) que van a participar en el proyecto y de la materialización o no de los riesgos previstos e imprevistos.

Cuanto mayor sea la incertidumbre más probabilidad hay de que las estimaciones sean erróneas. Por tanto, cuanto más cerca estemos del inicio del proyecto, más probabilidad de error habrá.

Mike Cohn lo cuantifica de la siguiente manera (traducción libre): “Durante la fase de estimación de la viabilidad de un proyecto la estimación realizada se sitúa entre el 60% y el 160%”.

Sobre esa afirmación se podría pensar que todos los proyectos están abocados al desastre. Tal vez quien piense eso no anda muy mal descaminado, sobre todo si el proyecto se realiza en un contexto de inflexibilidad en el que las distintas partes no se centran en el problema: que es desarrollar un producto software de la mayor calidad posible teniendo en cuenta los recursos disponibles.

¿Qué es ese contexto de inflexibilidad? Este es el presupuesto y esto es lo que hay que hacer, no hay posibilidad de negociación ni voluntad de analizar las causas que han dado lugar a esa situación.

Es importante que tengamos en cuenta lo que nos dice el Manifiesto Ágil al respecto: “Se valora la colaboración con el cliente, por encima de la negociación contractual”, a lo que habría que añadir también que “Se valora la colaboración con el proveedor, por encima de la negociación contractual”.

Y es que las causas hay que analizarlas con el objeto de determinar cuál o cuáles han sido los orígenes de esta situación porque en base a eso hay que dialogar y negociar. Generalmente los problemas de ese diálogo o de esa negociación lo tenemos también como consecuencia de una situación de inflexibilidad y la negativa a reconocer errores por parte del cliente y del proveedor.

Dado que el desarrollo de software es evolutivo soy de la opinión de que el presupuesto en un proyecto debe evolucionar de la misma manera que lo hace el software teniendo siempre presente el cliente y el proveedor el coste de cada actuación. Sobre esta materia recomiendo leer la serie de artículos sobre Contratación ágil que escribí hace un tiempo.

El tamaño y la incertidumbre importan. Para un proyecto donde se prevé el desarrollo de un nuevo sistema de información de medio o gran tamaño o un mantenimiento evolutivo importante del mismo resulta muy complicado acertar, es más, soy de la opinión de que si se acierta es por casualidad.

Un gran desarrollo tiene incertidumbre inherente porque es sabido que en la mayoría (aplastante) de los casos, los usuarios no saben realmente lo que quieren hasta que se va avanzando en la construcción del producto y esto sucede independientemente del enfoque de desarrollo que se le quiera dar. Si a eso le sumas otros factores como la inestabilidad de los procesos de la organización cliente, de la propia organización, el mercado, etc…, todo se hace mucho más complicado.

Por ese motivo es importante que todas las partes sean conscientes de lo complicado que resulta acertar en un contexto como ese. Desgraciadamente en muchos casos, los usuarios y los clientes no atienden a razones y dan lugar a una gestión orientada a la agenda (a intentar mantener un equilibrio en el triángulo de hierro) en la que se sufrirá mucho si la desviación entre lo estimado y la realidad es sensible y que fracasará seguro si se superan los umbrales del Death March Project.

¿Por qué es importante tener en cuenta que estimar en esas condiciones es una batalla perdida? Pues precisamente para considerar la estimación como una referencia pero no como una losa que llevar a la espalda durante todo el proyecto, es decir, no se debe malgastar el presupuesto pero se debería ser flexible en su gestión y tener la mente abierta a la necesidad de contar con más presupuesto en el caso de que sea necesario.

Las estimaciones irán mejorando conforme se vaya avanzando en el conocimiento del producto y el equipo de trabajo se vaya familiarizando con el entorno tecnológico y el negocio. También se reducirá el margen de error si las historias de usuario o funcionalidades a desarrollar no son de gran tamaño.

Aún así se seguirá fallando y será necesario gestionar esas desviaciones, sobre todo en lo que al cumplimiento de los compromisos de la iteración se refiere, ya que en este caso, al estar más acotada la estimación y ser mayor el conocimiento que existe, las desviaciones a nivel de esfuerzo serán poco significativas (lo suficiente para fastidiarte o ponerte muy difícil cumplir con los objetivos del sprint) pero con escaso impacto a nivel presupuestario,.

Cuando se trata de evolucionar un producto sin consolidar ese avance tenemos que plantearnos si efectivamente se trata de tierra ganada.

Una cosa es la experimentación, otra el desarrollo iterativo incremental o la incertidumbre y otras bien distinta es dar pasos rápidos que lo que van dejando atŕas es tierra quemada.

Experimentar es necesario, es una de las bases del desarrollo de software, realmente es lo que se hace cuando se implementa lo que creemos que hemos entendido de lo que cree que quiere el usuario. Esa diferencia se va paliando a través del feedback, salvo que se piense que se va a acertar a la primera, algo poco probable por muy buena voluntad que pongan las partes.

El desarrollo iterativo incremental refleja esa evolución del producto, tratando de consolidar lo ya realizado a la par de que se van incluyendo nuevas funcionalidades. No es tan importante el concepto como la aplicación de un enfoque adecuado, siendo recomendable pensar en pasar de estados más simples a otros más complejos.

La incertidumbre es lo que rodea al desarrollo de software y también a los negocios. Se está sometido a tantos factores que el contexto puede cambiar de manera lo suficientemente sensible como para que impacte en el proyecto. No se trata de huir de la incertidumbre sino de entenderla como algo inherente, por lo que se trata siempre de estar adaptado al cambio.

Dar pasos rápidos con el objeto de obtener un feedback necesario para obtener una orientación del producto es una buena estrategia. El problema es cuando se confunde ir rápido con la toma de atajos. A veces viene bien cogerlos pero cuando dejan de ser una excepción tenemos en un problema porque probablemente estemos sacrificando estabilidad y deuda técnica (capacidad, a fin de cuentas de adaptación al cambio) por más funcionalidad, que por otro lado hay que ver si es necesaria y que nos restará capacidad de maniobra en el caso de que sea necesario cambiar de enfoque.

Por todo eso, resulta necesario analizar si efectivamente los pasos que se van dando en el proyecto dejan tierra ganada.

Comenta Roy Miller (consultor y autor experto en metodologías ágiles) que: “Todo lo que necesitamos saber es el primer paso que tenemos que dar para dirigirnos hacia donde pensamos que queremos dirigirnos en ese momento”.

Este tipo de reflexiones se realizan principalmente para llamar la atención sobre un aspecto concreto y en este caso lo que trata probablemente de hacer Roy Miller es que dediquemos unos minutos a pensar por un lado en la incertidumbre característica de todo proyecto de desarrollo de software y por otro en su enfoque evolutivo en el cual vamos construyendo poco a poco el producto objetivo que lo mismo difiere de manera sensible de la idea que del mismo tenían inicialmente los usuarios y el propio equipo de desarrollo.

Siguiendo un enfoque evolutivo sí que resulta relevante cuál es el siguiente paso que tenemos que dar ya que nos permitirá llegar a la siguiente etapa y allí ya veremos pero no por ello, y estoy seguro que Roy Miller piensa de manera parecida, debemos obviar otro tipo de información que puede resultar de utilidad como por ejemplo los riesgos del proyecto y su situación (que llevamos hecho, qué tareas estarían pendientes de realizar, cuál es el presupuesto restante, qué problemas nos estamos encontrando en el proyecto, cuáles están originando resistencia al desarrollo, etc…).

No se trata de control sino de ser consciente de cómo estamos algo importante para evolucionar porque el siguiente paso importa pero también desde dónde se da.

El cono de incertidumbre de Steve McConnell viene a expresar algo que ya sabemos y es que efectivamente se acierta más cuanto más conocimiento tenemos del proyecto, su contexto, sus problemas, de las personas que participan, etc…

Ese conocimiento se adquiere conforme se va desarrollando el proyecto, con el proceso de definición de las historias de usuario, su construcción, el feedback y las retrospectivas. Cualquier otra actividad de carácter teórico puede producir mejores estimaciones, de base no lo niego, pero siempre limitada y siempre menor que la que se adquiere con la experiencia.

Entonces, ¿de qué valen las estimaciones que se realizan en la definición del proyecto y que tienen como objeto asignarle un presupuesto? Para definir un punto de partida e interesa que el mismo no esté muy equivocado, si bien lo realmente importante es la actitud que cliente (sobre todo el cliente) y el proveedor tienen sobre esas condiciones de partida. Si la orientación es al contrato, a su lectura literal, procura acertar (al cliente porque la satisfacción de sus expectativas respecto al producto final dependerá del acierto y al proveedor porque tendrá que prepararse a sufrir y perder mucho dinero).

En cualquier caso es conveniente dedicar tiempo a hacer la mejor estimación posible con la materia prima disponible, teniendo en cuenta que hay que saber cuándo parar porque si se pretende llegar a un conocimiento muy detallado, además del tiempo que se requiere para ello, se estará suponiendo que después la línea de desarrollo va a ir en esa dirección y lo mismo (lo más probable) se van produciendo cambios conforme el usuario vaya teniendo más claro qué es lo que quiere.

Las estimaciones iniciales no van a ser buenas, las finales estarán más ajustadas y no solo es cuestión de conocimiento técnico y funcional, sino que nos habremos dado cuenta de varios errores que se cometen sistemáticamente con las estimaciones (y que no sería de extrañar que los volvamos a repetir en el siguiente proyecto): considerar condiciones ideales, dejarse llevar por el optimismo, ser demasiado permeable a las presiones externas para admitir más capacidad o para producir estimaciones sin un conocimiento más en detalle de la historia de usuario o del requisito, exceso de ambición, etc…

Volviendo al cono de incertidumbre, hay que tener en cuenta que Steve McConnell lo planteó sobre una secuencia de fases que bien podrían ajustarse a un ciclo de vida clásico o en cascada, si bien podría ser extrapolable, al menos conceptualmente a otros enfoques de desarrollo de software.

McConnell señala que las estimaciones iniciales con un conocimiento insuficiente sobre la visión del producto (visión abstracta del sistema a desarrollar) se suelen desviar hasta cuatro veces por encima o por debajo de lo que viene a ser el esfuerzo real. En el momento en que se avanza más en la definición de la visión del producto, la desviación se ajusta hasta dos veces por encima o por debajo. Vuelve a bajar en la definición de requisitos (un 50%) y así sucesivamente hasta la entrega.

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.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.198 seguidores