Desarrollo de software. ¿Son las estimaciones una guerra perdida?

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,.

Ciclo de vida iterativo incremental de ciclos cortos, conocimiento más real

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.

Desarrollo de software. Se acaba el presupuesto y funcionalidades por hacer

El proyecto se queda sin presupuesto, al menos, a corto y medio plazo y los responsables funcionales entienden que existen funcionalidades que son necesarias para que el producto sea de utilidad o para que la productividad en el uso del mismo sea aceptable.

¿El problema? No hay dinero para hacer todo lo que necesitan, ¿cuál es la primera consecuencia? Desgaste, incluso en situaciones donde el desarrollo haya sido fluído. A los usuarios les entra el síndrome de la última versión y el proveedor de servicios de desarrollo por muy flexible que sea tendrá que mirar por los resultados económicos del proyecto.

Gestionar bien esa circunstancia tanto por parte del cliente como del proveedor es esencial ya que se puede tirar por tierra todo el esfuerzo de meses de trabajo. No es sencillo porque todos sabemos lo complicado que resulta cerrar un proyecto.

No existen fórmulas mágicas, solo el sentido común, la búsqueda del beneficio mutuo y un autoanálisis crítico del trabajo que se ha realizado en el proyecto con el objeto de asumir responsabilidades (si existen). Si ambas partes quieren se puede alcanzar un acuerdo satisfactorio, si una de ellas se resiste probablemente terminen perdiendo ambas.

Además de lo anterior, la solución ideal pasaría por dotar al proyecto del presupuesto adicional necesario para terminar de manera adecuada los trabajos, si bien pueden existir circunstancias que lo impidan o, al menos, que lo impidan temporalmente.

Recordemos que lo realmente importante es el valor del proyecto y su relación adecuada con la inversión realizada y no acertar con una estimación inicial que todos sabemos (cliente y proveedor) cómo está hecha. Si tu objetivo es hacer que la estimación sea acertada tal vez te lleves ese logro pero tal vez, también, el proyecto se quede a medias o se entregue un producto deficiente,

El overhead de no tener presupuesto

Cuando se quieren hacer más tareas que presupuesto en un proyecto se empieza a incrementar de manera desorbitada el tiempo dedicado a la gestión, el cual tiene un efecto paradójico, ya que se trata de gestionar para minimizar conflictos, modular expectativas, buscar soluciones a través de reducción de alcance, simplificación de soluciones, etc…, el cual suele tener un coste superior al beneficio que produce.

No digo que no se deban hacer, pero en muchos casos no van a solucionar el problema de fondo y finalmente lo que se obtendrá es un producto que no suele dejar satisfecho a nadie, en primer lugar a los usuarios/cliente que verán recortado el alcance esperado, con más defectos y con un código de peor calidad y en segundo lugar el proveedor que no solo verá desgastada su imagen con respecto al cliente (que tal vez pierda) sino que tendrá unos resultados económicos en el proyecto peores de lo esperado.

La solución pasa por alcanzar un nuevo acuerdo presupuestario sin que ello suponga que se deje de lado el análisis de por qué se ha llegado a esta situación: podría ir desde una estimación inicial incorrecta, mayor complejidad de la esperada, nuevos requerimientos, menos productividad de la deseable y la suma de algunos de estos factores junto a otros.

Desarrollo de software. Las expectativas importan

Gestionar las expectativas es fundamental en nuestra profesión y es algo que no solemos hacer bien y que es causa de pérdidas de confianza, desgaste y de minusvaloración del trabajo realizado (nosotros mismos lo hacemos pequeño cuando intentamos «vender» algo más grande de lo que realmente es).

¿Por qué fallamos en esto? Los motivos pueden ser muy diferentes: no terminamos de ver (o no queremos ver) el problema y por lo tanto no lo transmitimos o lo hacemos demasiado tarde, tenemos miedo de la reacción de la otra parte o simplemente no le damos importancia a las expectativas que pueda tener el usuario (algo muy peligroso porque un proyecto surge de unas necesidades y de la expectativa de darles una solución).

No es sencillo transmitir al área usuaria que no se va a poder cumplir lo que se tenía pensado inicialmente y lo que hasta este momento parecía que se iba a poder conseguir, ¿por qué no es sencillo? pues porque se pedirán explicaciones (y es natural que así sea porque le estamos cambiando la imagen mental que tenían del proyecto) y las mismas no siempre se van a entender, seas sincero o no (mejor sincero).

¿Qué hacer? Lo importante es explicar qué ha llevado a esta modificación en las expectativas y qué ventajas supone hacer un ajuste a las mismas, ¿ventajas? perseguir quimeras en el proyecto no solo supone engañarnos a nosotros mismos sino que además supone inflingirnos un castigo en forma de esfuerzo desbocado que se traducirá probablemente en unos resultados deficientes.

Esto no es un alegato al incumplimiento de las planificaciones sino de intentar exponer mi punto de vista sobre una realidad: es muy complicado acertar en los plazos y presupuestos del proyecto para el alcance que se defina, es posible que ese alcance cambie o que funcionalidades que se esperan más simples sean más complejas y, además, a lo largo del proyecto pueden ocurrir infinidad de circunstancias que impidan un desarrollo lineal del mismo.

Teniendo en cuenta esa realidad gestionar las expectativas de manera adecuada resulta fundamental para alcanzar los objetivos marcados en el proyecto. ¿Cómo cumplir objetivos si se ajustan las expectativas? Generalmente las expectativas incluyen funcionalidades no imprescindibles o con mayor complejidad de la necesaria, ahí es donde podemos trabajar para seguir manteniendo el pulso al cumplimiento de objetivos.

A veces el ajuste no será suficiente y se requiere un mayor aporte presupuestario y/o un mayor plazo para la ejecución del proyecto. ¿Qué pasa cuándo no se puede o cuándo no se llega a un acuerdo? Problemas para todos (cliente y proveedor), mi recomendación es que lo mejor es intentar llegar a un acuerdo satisfactorio y eso pasará también porque las partes asuman su responsabilidad en que se haya llegado a esa situación (que no necesariamente tiene que deberse a un mal desempeño en el proyecto sino que puede darse el caso de que el problema partiera con la estimación inicial de presupuesto (principalmente) y plazos).

Desarrollo de software. Maleabilidad

Siempre es posible desarrollar un software aplicando las mismas técnicas de gestión que para construir un puente, sin embargo estaríamos prescindiendo de una de sus principales características, su maleabilidad, lo que le permite adaptarse al cambio y modificar criterios con un coste asumible (siempre y cuando se tenga la deuda técnica bajo control).

Cuando tienes un puente a medio construir, tomar la decisión de poner un carril más en cada dirección puede ser prácticamente imposible o requerir una inversión muy superior a la que hubiera sido necesaria si se hubiera tenido en cuenta desde el principio.

En el desarrollo de software no es así. Es cierto que el cambio tiene un coste pero no es equiparable al de las construcciones físicas.

Renunciamos a la maleabilidad del software cuando lo importante es el cumplimiento de una agenda, es decir, se prioriza mantener previsiones de costes y plazos sobre la posibilidad de entregar un producto con mayor valor. Hay que analizar cada circunstancia y es posible que no haya otra alternativa que cumplir con la agenda: no es posible dedicar mayor presupuesto al proyecto y/o modificar los plazos, siempre y cuando se entienda que no es posible la cuadratura del círculo: cumplir agendas y tener al producto sometido a continuos cambios de criterio.

Mi apuesta es incrementar el valor del producto que se pone en producción y eso requiere un enfoque iterativo incremental para aprovechar el feedback del usuario. Esto tiene implicaciones presupuestarias que se solucionarían bien teniendo abierto el presupuesto del proyecto o si está cerrado centrarse en que las funcionalidades prioritarias vayan bien (esto último siempre y cuando no nos encontremos en una situación de Death March Project en la cual todo será mucho más complicado).

Desarrollo de software. Modelos predictivos o cómo gestionar el desgaste IV

El segundo escenario suele ser el más habitual y es la base para el fracaso de muchos proyectos de desarrollo de software, independientemente del enfoque a utilizar, si bien los enfoques evolutivos ofrecen la posibilidad de desarrollar el software por incrementos y si el área usuaria se muestra flexible (y la agenda da alguna oportunidad) es posible conseguir una solución razonable con el presupuesto y plazos definidos.

¿Qué agenda se puede gestionar si las condiciones iniciales son imaginarias? Solo es posible hacer algo en el caso de que el cliente entienda esta situación y no se cierre en banda al llave en mano. Si lo hace perderá el proveedor, pero también el cliente, porque pocos proyectos alcanzan un éxito real en esas condiciones.

También podría ser, porque también pasa, que las condiciones iniciales estén muy por encima de lo que requiera el proyecto, este escenario es más favorable que el anterior (por no decir que un chollo para el proveedor si te toca trabajar en estas condiciones), pero no arregla el problema de fondo, tal vez el proyecto sea muy rentable y el cliente quede satisfecho, pero el desarrollo de software es algo lo suficientemente serio como para esperar a ver si la moneda cae cara o cruz.

Recuerdo de artículos míos recomendando que el presupuesto fuera holgado, teniendo en cuenta esta situación de incertidumbre inicial, sin embargo, la solución no pasa por ahí, sino que pasa por la definición de presupuestos objetivos y por la predisposición a modificarlos si las circunstancias del proyecto lo aconsejan.

Cuando hablo de presupuesto objetivo lo hago desde la perspectiva de que se base al menos en una visión sólida del producto, para lo cual no es necesario hacer un análisis completo y en detalle del sistema de información, teniendo en cuenta que ese presupuesto objetivo obedece a una visión inicial (aunque sólida) del producto y que después habrá cambios que afectarán a las condiciones de la agenda.

Desarrollo de software. Agendas (presupuestos y plazos)

Es posible que esté transmitiendo en mis artículos que las agendas resultan negativas para los proyectos de desarrollo de software. Si lo hago es porque entiendo que es más importante incrementar el valor del producto.

No es incompatible aumentar ese valor con las restricciones de la agenda pero llegará un punto donde habrá que decantarse por un camino o por otro o lo que es lo mismo, cuando se pongan en conflicto los límites de la agenda con tareas que permitirían evolucionar el producto tocará elegir. Generalmente se intentará que todo quepa dentro de esos límites pero eso dará lugar a falsas expectativas y también, de forma más que probable, el incremento de valor no sea el esperado, al no poder dedicarse el esfuerzo necesario, se verá mermada la calidad del producto y se incumplirá la agenda.

En cualquier caso valoro la importancia que pueden tener las agendas en determinados proyectos y es que hay situaciones en las que no es posible disponer de más presupuesto del que se parte y tampoco es posible jugar con otros plazos.

Siendo objetivo, incluso partiendo de la base de que lo importante es el valor del producto, no podemos ser tan ilusos como para pensar que el presupuesto y los plazos son infinitos. Esto nos lleva a que el desarrollo se haga con intención, es decir, con la idea de que cada incremento proporcione un valor real al producto acorde al esfuerzo invertido, priorizando las funcionalidades principales del sistema, determinando el mínimo de las mismas que se requerirían para tener la aplicación funcionando en producción y enfocando el desarrollo a una estrategia iterativa incremental.

Conocer los límites puede resultar interesante, el problema está cuando los mismos son irreales con la naturaleza del trabajo a realizar y con las múltiples contingencias que se producen en el proceso de desarrollo y eso, desgraciadamente, lo que suele suceder.

Desarrollo de software. Antipatrón. Desarrollo a la primera

Este antipatrón surge cuando se asigna un presupuesto para el desarrollo de un producto y no se tiene en cuenta que tras la construcción del mismo va a ser necesario continuar con su evolución ya sea ampliando funcionalidades o realizando modificaciones sobre las ya existentes.

Esto lo podemos encontrar tanto en enfoques clásicos como en los iterativos incrementales. Es muy frecuente sobre todo en los primeros, ya que suelen tener un enfoque de contrato cerrado: «esto es lo que hay que hacer y este es el dinero que te voy a pagar», no obstante los segundos también se ven afectados en el momento en que se agota el presupuesto y se detecta que es necesario seguir trabajando sobre el sistema.

Pensar que se va a desarrollar el producto a la primera es una quimera tan grande como pensar que incluso consiguiéndolo no se van a dar circunstancias que hagan necesario realizar una mantenimiento.

Lo mismo piensas: «Bueno, si hace falta más dinero, se pone y ya está». Eso no es tan fácil, ya que dependerá de la holgura que permita el presupuesto de la organización. En el caso de proyectos con la Administración resulta todavía más complejo porque los procesos de contratación requieren su tiempo y porque existe menos flexibilidad presupuestaria.

Desarrollo de software. Antipatrón. El culto a la agenda

El enfoque clásico, predictivo o en cascada del desarrollo de software tiene como objetivo final el cumplimiento de a la agenda: «Estas son las condiciones contratadas y esto es lo que hay: alcance, coste y plazos».

La premisa es que las condiciones de partida no van a cambiar y que la información existente para realizar las estimaciones era suficiente para que la desviación en lo vértices el triángulo de hierro no afecte a la calidad final de los trabajos.

Puedo no estar de acuerdo con esta estrategia de desarrollo de software, teniendo en cuenta que mi apuesta es por los enfoques iterativos incrementales siguiendo prácticas ágiles, pero no por ello es una estrategia descartable ya que puede ser válida o la solución más óptima en determinados tipos de contextos.

Además, a priori, suena bien eso de cumplir la agenda, porque de ello se desprende tranquilidad y predecibilidad (sé lo que me gasto, sé lo que voy a obtener y cuándo) y es cierto, en teoría parece que no presente grietas.

Pero solo en teoría, el castillo de naipes se desmorona en el momento en que las condiciones de partida cambian (es posible que incluso se desmorone antes, si la estimación ha sido deficiente) y eso es algo que se producirá con una probabilidad muy alta, causas puede haber muchas, como por ejemplo que cambie el proceso que se quiere informatizar, que la implicación de una de las partes sea menor que la esperada, que la complejidad sea superior a la prevista, etc… pero lo más frecuente es que el propio usuario se de cuenta en el proceso de desarrollo de ciertas mejoras o cambios que permitan dar al producto un mayor valor.

¿Dónde comienza el antipatrón? Cuando se pasa de velar por el cumplimiento de la agenda a una situación de culto por la agenda, de manera que no se trata de buscar una solución mediante la flexibilización de alguna de las variables: coste, plazos, alcance y calidad, sino que se pretende conseguir la cuadratura del círculo de manera que se asuman los cambios sin variar las condiciones de partida.

Y esto no suele traer buenos resultados, para empezar se producirá un desgaste en las relaciones entre los diferentes equipos implicados que hará todavía más complicada la consecución de los objetivos, dará lugar a un sobreesfuerzo por parte de muchas personas con el objeto de compensar esa desviación lo que terminará pasando factura en la calidad y en la productividad y por último el producto final será el reflejo de todos estos problemas y situaciones.