archivo

Archivo de la etiqueta: estimaciones

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

Tenemos los extremos:

– En los contratos llave en mano el riesgo lo asume el proveedor: “Estas son los objetivos, las condiciones y el dinero… ¡suerte!”.

– En los contratos por horas el riesgo lo asume el cliente: La baja productividad y esas horas que se pierden en el limbo de las horas de los proyectos de desarrollo de software (que debe de ser, por cierto, muy grande, para dar cabida a tantas).

Ambos extremos, en frío, sin matices, deben ser evitados y sin embargo con muy pocos matices son los que se utilizan de manera mayoritaria y ambas partes: clientes y proveedores tratan de arrimar el ascua a su sardina, muchas veces sin tener en cuenta que lo que a priori parecen ventajas se puede convertir después en inconvenientes.

La llave en mano es demoledora cuando se falla en las estimaciones y ten seguro que será así, estadísticamente se suele ser demasiado optimista con las mismas y más optimista será si el cliente es el que se ha encargado de hacerlas. Y no es cuestión solo de pesimismo o de optimismo, la clave está en que no se dispone de información suficiente para poder hacer una estimación medianamente realista y el problema lo tenemos en que ese conocimiento se obtiene conforme vamos avanzando en el proyecto.

Cuando el error es sensible nos encontramos en una situación de Death March Project, en la que será necesario replantear el triángulo de hierro o el proyecto fracasará sin remedio y con gran desgaste entre las partes.

Y el problema no es solo fallar más o menos con las estimaciones sino también en la definición de los objetivos por un lado porque a lo largo del contrato pueden cambiar, pero sobre todo por la interpretación de cuál es el nivel de acabado que tienen que tener los mismos para darse por satisfechos: para el cliente pocas veces será suficiente para el proveedor será justo lo contrario.

Las bolsas de horas ofrecen una flexibilidad extrema pero soy de la opinión de que para optar por esta opción el cliente debe confiar muchísimo en el proveedor y más que en el proveedor en las personas que van a intervenir en el proyecto.

Incluso en las condiciones más favorables para aplicar esa estrategia es beneficioso para ambas partes la definición de objetivos como podría ser por ejemplo facturar por iteración.

Como veis es difícil encontrar una fórmula en la que se consiga el equilibrio pero tal vez sea más sencillo encontrar soluciones en las que el riesgo se comparta.

En la serie de artículos sobre Contratación Ágil podéis ver algunas posibles soluciones a aplicar, teniendo siempre en cuenta que independientemente de la fórmula utilizada, si las personas se quieren entender se entienden (y al contrario), pero dado que nadie puede garantizar a priori que quiénes toman las decisiones van a estar durante todo el proyecto (las personas vienen y van), es conveniente que exista un marco de referencia:

Contratación ágil I.
Contratación ágil II.
Contratación ágil III.
Contratación ágil IV.
Contratación ágil V.

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.

Cuando tenemos que pagar, casi siempre nos parecerá demasiado caro lo que nos ofrecen. Por otro lado, el proveedor tratará de no pillarse los dedos y realizará estimaciones con el objeto de minimizar riesgos.

La situación no es sencilla de resolver, de hecho, casi nunca nadie estará satisfecho, teniendo en cuenta de que el proveedor casi siempre termina equivocándose en sus estimaciones y de forma desfavorable para él (otra cuestión es analizar si el motivo del error ha sido el exceso de optimismo, la baja productividad o una información insuficiente y/o inexacta).

Un primer antídoto lo tenemos en el cumplimiento de las expectativas del cliente, ya que éste se quedará con el valor real que le proporciona el producto, por encima de lo que se ha gastado (siempre, como es lógico, dentro de unos márgenes razonables).

Otro antídoto lo tenemos en la confianza, sin confianza, da igual lo que te apliques estimando que la otra parte terminará pensando que te estás cubriendo las espaldas. La confianza en estos casos se obtiene a través de la transparencia y de la capacidad de asumir errores, porque para el proveedor todo se simplifica, todo es muy sencillo, si es el cliente el que siempre termina pagando sus fallos. Lo mismo pasa al revés, cuando el cliente trata de repercutir en el proveedor su indefinición, sus errores en las especificaciones, su falta de colaboración, etc…

Soy partidario del reparto de riesgos, por eso ni creo en la facturación por horas ejecutadas, ni tampoco en la llave en mano, ambos sistemas son injustos.

Soy partidario de definir objetivos globales, crear una visión inicial del producto que se quiere obtener y a partir de ahí, realizar estimaciones basadas en iteraciones de corta duración (se reduce el margen de error) en las que cliente y proveedor, repartan riesgos, y en las que (muy importante) sea el equipo de desarrollo el que estime (ese espacio debe respetarlo el cliente o en su extensión, el área usuaria o el responsable funcional).

Si hacer estimaciones es complicado y si equivocarse en las estimaciones puede condicionar gravemente un proyecto, quiere decir que es una actividad que no debe tomarse a la ligera.

A alto nivel las estimaciones en un proyecto deberían ser referencias porque todos conocemos el grado de incertidumbre que existe sobre todo si se trata de un sistema nuevo o de una evolución importante de uno ya existente. Considerarlas más allá de eso, supondrá una gestión maś rígida del triángulo de hierro (alcance, plazos y costes) y la existencia de una serie de limitaciones que dificultan la agilidad en los desarrollos.

Desgraciadamente las estimaciones a alto nivel se toman demasiado en serio. Entendedme bien, no digo que no sean serias, no digo que se deban ignorar, sino que es necesario que se tengan en cuenta las circunstancias del proyecto y no se ignore que cuando se realizó la estimación se pensó en un alcance del que se disponía realmente de poca información y en unas condiciones que probablemente van a cambiar.

Las estimaciones suelen ser optimistas porque se suele pensar en condiciones ideales. También tiene mucho que ver la presión que puede venir por parte de los usuarios o del cliente, que desean que cuanto antes y por el menor coste posible se tenga el producto en producción.

Ese optimismo se convierte en temeridad (todavía más), cuando las estimaciones se realizan en momentos de euforia, generalmente poco tiempo después de realizar una demo del producto con éxito, haber recibido felicitaciones por el trabajo bien hecho, haber superado una crisis complicada, etc… Es recomendable tratar de evitar la realización de estimaciones en esas condiciones (o por lo menos tratar de diferirlas lo que sea posible) porque incluso las personas más frías pueden verse afectadas por esa situación.

Es curioso, pero cuando nos preguntan tendemos a dar un grado de avance superior al real y no siempre se hace con la intención de dar una imagen optimista del proceso de desarrollo que no se ajusta con la realidad sino porque los que nos dedicamos a esto somos optimistas por naturaleza, por mucho que seamos conscientes de la problemática de cada proyecto concreto y de la incertidumbre que rodea al desarrollo de software.

Como somos de esta forma, corregirnos es difícil, por mucho que nos hayamos comprometidos en infinidad de ocasiones con plazos realmente temerarios. En cualquier caso, no está de más, tomarnos un tiempo y consultar con el equipo el estado real de los trabajos antes de apresurarnos a decir nada.

Sin embargo, el verdadero problema no es dejarse llevar por el optimismo o por nuestras ganas (van de la mano) sino dar estimaciones con ánimo de engañar. Aunque pueda parecer que el resultado en los dos casos es el mismo, no es así, y la comprensión por parte de terceras partes cuando las cosas se hacen con buena fe es mucho mayor que cuando la misma brilla por su ausencia (aunque la tercera parte no sepa realmente si los has hecho queriendo o sin querer) y es que resulta mucho más fácil explicar las cosas desde la verdad que desde la mentira.

Otro problema de las estimaciones, es el remate de los sistemas de información, donde si no se analiza, llegado a cierto punto, lo que cuesta implementar determinadas funcionalidades que no son fundamentales en el sistema, no se termina nunca de darle vueltas al sistema porque tras el desarrollo de una vendrá otra, intercalándose con tareas de mantenimiento evolutivo que sí resultan necesarias.

Ese remate resulta todavía más lento (o interminable), si la calidad integral del desarrollo (hacia fuera y hacia dentro) no ha sido buena.

Hay una cita de Terry Baker que resume en pocas palabras el contenido de este artículo: “Un programa nunca está menos del 90% completo y nunca más del 95% completo”.