archivo

Archivo de la etiqueta: presupuesto

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

Anuncios

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.

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,

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.

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

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

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.