Desarrollo de software. ¿Existe el control del proyecto? III

Aunque resulte paradójico, la agenda es una de las principales causantes de la pérdida de control del proyecto porque en el momento en que se rompen sus premisas: estabilidad de las especificaciones, del contexto y acierto en las predicciones de coste y plazos y no se trata esta situación de manera natural ajustando la misma a la nueva realidad, estaremos trabajando en una condiciones fundamentadas en unas hipótesis erróneas y de esa situación no se puede esperar nada bueno.

La crisis del software se asoció al no cumplimiento de las agendas porque efectivamente los proyectos no cumplían objetivos de costes, plazos, alcance y calidad y a partir de ahí se constituyó la gestión predictiva de proyectos generando con las experiencias pasadas y con el paso del tiempo todo un cuerpo de conocimiento.

Precisamente este problema es el que sufren los desarrollos que siguen el enfoque clásico pero perfectamente son extrapolables a enfoques pretendidamente ágiles si los mismos están condicionados por agendas rígidas (digo pretendidamente porque agenda rígida y agilidad son conceptos contrapuestos).

Como es lógico, se mejoraron los resultados del pasado porque hay que tener en cuenta que se pasó del caos a un cierto orden, pero seguían sin ser satisfactorios a lo que había que sumar el desgaste que tiene este tipo de gestión entre todas las partes implicadas en el proyecto.

El culto a la agenda no es la solución porque pretende estabilidad y predicción en un contexto de incertidumbre que es inherente al desarrollo de software. Por eso, el centro no debe ser el triángulo de hierro sino el valor del producto de manera que costes, plazos y alcances supongan referencias y no límites.

Desarrollo de software. ¿Existe el control del proyecto? II

La gestión de la capacidad, velocidad o carga de trabajo del equipo resulta esencial. Uno de los factores que más influyen en la pérdida de control es precisamente el intento de cumplir agendas imposibles.

Con mucho esfuerzo, siempre y cuando, exista posibilidad material de cumplir unos plazos, se pueden llegar a ofrecer unos resultados, pero, ¿a costa de qué?, ¿a costa de quién? Del producto y del equipo, ya que probablemente el sistema resultante tenga funcionalidades que no estén bien rematadas, tenga incorrecciones funcionales, numerosos bugs y la factura técnica sea francamente mejorable, a lo que hay que añadir el desgaste de las personas debido a la presión y al overtime.

Esto impacta en la entrega pero también en lo que queda de proyecto porque será necesario dedicar esfuerzo a «barrer» o «pulir» lo que fue mal mientras se está trabajando en lo nuevo.

Si no se ha reajustado la capacidad de trabajo asumible por el equipo, seguirá desbordado y lo más probable es que no cumpla con la mayoría de los compromisos y los que cumpla presenten deficiencias similares a los de la anterior entrega y se sigan acumulando flecos pendientes. Como una bola de nieve esto irá a más y más durante el transcurso del proyecto y si además se acumulan modificaciones funcionales serias sobre elementos ya desarrollados o hay cambios sensibles en el contexto del proyecto, se volverá absolutamente inmanejable.

Incluso con la intención de ajustar el trabajo a la capacidad del equipo podemos caer en la situación descrita si nos equivocamos a la hora de hacer ese ajuste, si bien, es posible a corto/medio plazo volver a una situación más equilibrada ya que gracias a este enfoque tendremos en cuenta ese esfuerzo de más que vamos a necesitar en cada iteración para lograr ese objetivo.

La ilusión del cumplimiento de plazos

Hay proyectos donde el plazo de tiempo realmente importa porque cada día que se llegue tarde implica pérdida de mercado o de dinero.

Sin embargo lo que es realmente trascendente es el resultado final del producto y esto es así en todos los casos porque da igual si llegas a tiempo pero no consigues satisfacer a tu audiencia potencial.

Lo que quiero decir es que los plazos tienen una importancia relativa que dependerá de cada proyecto por lo que la política a aplicar respecto a los mismos no puede ser igual en todos los casos.

Lo que pasa es que como el cumplimiento de plazos es fácil de medir se tiende a evaluar el grado de evolución de un producto o del proyecto en base a los mismos y aunque puede resultar muy interesante para detectar desviaciones y tomar decisiones de interés, tiene menos relevancia que el valor que vaya ganando el producto.

Al final, el cliente no va a recordar (o al menos no lo va a tener en primer plano) si te has retrasado una semana, un mes o varios, lo que sí va a tener presente es si el producto que se ha desarrollado le resulta satisfactorio.

No se trata de trabajar sin plazos porque los mismos siempre establecen una referencia sino de relativizar su importancia en aquellos casos en los que sea posible.

Por otro lado los retrasos deben gestionarse de manera adecuada entre las partes porque de lo contrario se está jugando con algo muy peligroso como son las expectativas, es decir, todos deben ser conscientes de que no se van a cumplir los plazos estimados, deben llegar a un acuerdo de cuáles serán los nuevos y tener comprendidos los motivos que han llevado a ellos.

La agilidad y el alcance II

¿Quién expone más con esta estrategia?, ¿el cliente?, ¿el proveedor? De entrada podría pensarse que el cliente porque no cierra un alcance definido, solo lo esboza y puede darse el caso de que se acabe con el presupuesto y no se consigan los objetivos generales que se han marcado.

Es posible que esto suceda, como también es posible que suceda con una visión opuesta, la de la llave en mano, en donde se pretende mantener fijo el alcance, ya que en el momento en que las cuentas no cuadran para el proveedor y supera el umbral de las pérdidas admisibles, querrá empezar a querer recortar ese alcance y/o solicitar más dinero, todo eso en un contexto de desgaste en el que además, la productividad y calidad de los trabajos se verá afectada, impactando a su vez en los costes. Esto que cuento no es ciencia ficción, quiénes hayáis trabajado en este tipo de contratos sabéis de lo que estoy hablando.

La clave está en definir unas condiciones contractuales en las que ambas partes compartan el riesgo, pero para llegar a eso es importante que en el cliente se entienda que con la incertidumbre que es inherente a todo proyecto de desarrollo de software, cualquier estimación inicial terminará siendo papel mojado conforme vayan avanzando los trabajos y que lo realmente importante es ir trabajando de la mano del proveedor (y el proveedor de la mano del cliente) para ir incrementando el valor del producto en cada iteración, de manera coherente a la inversión que se está realizando.

La agilidad y el alcance I

El triángulo de hierro: alcance, coste y plazos, determina unas condiciones de partida para el proyecto basadas en la mayoría de los casos en hipótesis realizadas con un gran desconocimiento sobre el sistema que se va a realizar, estando además, condicionadas por el hecho de que el área usuaria va a tratar de que se abarque el mayor alcance, con el menor coste posible.

Después el proyecto evoluciona y nos iremos dando cuenta de cómo la estimación inicial ha fallado (y por mucho) y el alcance varía porque conforme el usuario vea materializada sus ideas, le surgirán otras nuevas, se dará cuenta de que determinadas funcionalidades ya implementadas son mejorables y que también se ha equivocado en otras, provocando que se tengan que modificar sensiblemente o reconstruirlas.

Y no solo eso, habrá riesgos que impacten y que supongan una resistencia al desarrollo, cambios de rumbo en el proyecto, etc… y todos ellos provocarán que sea necesario modificar alguno de los vertices del triángulo de hierro porque seguir creyendo en su foto inicial es engañarnos.

¿Cómo poder actuar contra esto? Trabajando sobre el alcance y gestionando las expectativas. Estas dos variables se tienen que modular a la realidad del proyecto y subordinarse al estado económico real en cada momento (costes) y a los plazos que se definan.

De esta forma podemos trabajar sobre unas condiciones de partida de tiempo y presupuesto y haciendo una estimación del alcance que se pretende.

¿Es tan importante cumplir los plazos?

No es posible dar una respuesta generalista ya que depende realmente de lo que impliquen esos plazos.

Si existe una imposición legal, la necesidad de informatizar o cambiar determinados aspectos de un proceso ya informatizado para poder responder o adelantarse a la competencia sí que tiene una gran relevancia los plazos, en caso contrario, los plazos, incluso siendo importantes deberían modularse también a las necesidades del producto (¿conviene, tal vez, esperar algo más de tiempo y poner en marcha un producto más maduro?) y a las contingencias que hayan podido ocurrir en el proyecto.

La gran ventaja que ofrecen las metodologías ágiles es que en cada iteración ofrecen una nueva versión del producto susceptible, en potencia, de pasarse a producción si así se decidiese. Hay que tener en cuenta que en determinados productos, se pueden tardar varias iteraciones en tener un núcleo mínimo que pueda ser totalmente funcional para ser utilizado en un entorno real, lo cual no quita que, ya sea en un entorno de demostración o incluso en producción, se pueda trabajar o prácticar sobre la versión con el objeto de obtener feedback lo más pronto posible.

Al plazo general del proyecto, se suman los plazos individuales de las iteraciones. Con el objeto de tener un ritmo sostenido de desarrollo, es fundamental que los sprints terminen en la fecha indicada, aunque haya algún compromiso que no se haya podido terminar por completo.

El problema de los plazos generales del proyecto lo tenemos en lo complicado que resulta alinearlo con la expectativa de lo que se pretende tener en el mismo y eso trasciende al hecho o no de tener versiones funcionales cada cierto tiempo, es decir, puede darse el caso de que no te sirva de mucho poner en marcha una versión dentro del plazo si la misma no se corresponde con las expectativas que había para ese momento del tiempo.

Pero tampoco se pueden pedir imposibles y si realmente los quieres, sufrirá la calidad del producto porque velocidades de desarrollo sostenidas en el tiempo muy por encima de lo que se puede producen ese efecto.

Cuando se trabajan con ese tipo de plazos es fundamental gestionar de manera adecuada las expectativas del área usuaria, ya que es muy posible que tenga que haber modificaciones del alcance y en más de una ocasión.

Es mucho mejor esa situación que el hecho de que el usuario o nosotros nos mintamos, mucho mejor entregar unos mínimos con calidad que un producto inestable, mucho mejor tratar de cumplir esos plazos que retrasarnos.

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. La flexibilidad del Product Owner condiciona la flexibilidad del equipo de desarrollo

Soy partidario de no retrasar las entregas que se fijan. Es cierto que no siempre he pensado he pensado así y tampoco os puedo asegurar que mañana no cambie de opinión ya que independientemente de que uno tenga un background el presente condiciona, y mucho.

Si no se va a llegar y el incremento de la capacidad del equipo no es suficiente o incluso empeora la situación, la solución pasa por renegociar con el Product Owner, con el área usuaria o el cliente (en general) el alcance de la entrega.

Esto no es fácil, nada fácil. El usuario lo querrá todo (y más allá) y por supuesto, en plazos, independientemente de todo lo que haya ocurrido desde que se inició el proyecto, incluso siendo consciente de que el retraso no es imputable al equipo de desarrollo.

Si el usuario no quiere reducir el alcance o no lo hace de manera suficiente sí que hay que plantear un retraso en la entrega. No creo en el overtime impuesto directa o indirectamente en los desarrolladores, sí creo en la responsabilidad de los mismos y en su capacidad de administrarse el tiempo (son muchos los desarrolladores que no funcionan bien así y como digo siempre, mejor trabajar con personas que se adaptan a tu forma de entender el trabajo), por ese motivo no puedo ser partidario de soluciones que supongan overtime. Sí es admisible un pico de trabajo, pero por supuesto compensado de alguna forma (siempre equivalente a los resultados y esfuerzo realizado) y no puede ser prolongado en el tiempo.

¿Qué tampoco puede haber retraso? No hemos nacido para hacer imposibles y mi recomendación es que si se sabe de manera cierta que no se va a llegar, se escale el problema. Mejor ahora que dar sorpresas desagradables más adelante.

Ahora bien, si existen posibilidades de llegar en plazos hay que intentarlo, advirtiendo siempre al Product Owner de lo ajustado que vamos a estar y levantando la mano en el momento en que veamos que no vamos a llegar. Si el Product Owner no ha sido flexible a la hora de acotar el alcance, tampoco debemos serlo nosotros a la hora de realizar cambios que supongan una desviación sensible de los objetivos.

Reconozco que eso es antiágil y anti todo lo que entiendo que debe ser el desarrollo de software pero no puedo borrar la realidad y el contexto del proyecto es ese. El contexto manda, se será ágil en lo que se pueda, pero esas son las condiciones, esas son las variables que manejamos.

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.