archivo

Archivo de la etiqueta: plazos

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.

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.

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.

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

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.

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.

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