Skip to main content

¿Son los proyectos a precio fijo realmente Agile?

February 18, 2022

Es tentador imaginar un mundo en el que todos los proyectos a precio fijo se inicien sin plazos y continúen hasta que las partes interesadas decidan que se ha entregado suficiente valor. 

En algunas organizaciones esta es la realidad, dicen que hacen Agile así. 

Pero en otras organizaciones del mundo real, los equipos a menudo deben lidiar con:

  • Proyectos de fecha fija en los que se debe entregar un producto nuevo o mejorado en un plazo definido.
  • Proyectos de alcance fijo en los que se requiere un conjunto de características y funcionalidades antes de que se pueda entregar el producto.
  • Proyectos de todo fijo (alcance, precio y tiempo), que bloquean tanto la fecha de entrega como las funciones que se entregarán en esa fecha.
pira
La piramide de acero donde analizamos tiempo, presupuesto y alcance

Agile es dependiente del contexto

¿Es posible ser ágil cuando los elementos cruciales están fuera de tu alcance? 

En mi opinión, no lo es. Los equipos difícilmente pueden ser ágiles cuando la fecha, el alcance y presupuesto o todos son fijos.

Ser ágil depende del contexto y de la cultura.

Por ejemplo, un equipo pequeño que trabaja en una aplicación móvil puede ser más igual de ágil que un gran equipo distribuido que construye hardware regulado médicamente.

Esto se debe a sus contextos.

Este último proyecto médico sin duda requerirá producir más documentación; controlar más rigurosamente, o al menos documentar, el cambio; y hacer otras cosas que se tienen que ir revisitando de manera iterativa e incremental de manera más constante que en otras maneras de trabajar. 

Ser ágil cubre una amplia gama de actividades, al igual que ser saludable. Recuerda que engloba mindset, valores y prácticas.

Un equipo puede ser más o menos ágil de la misma forma que tú puedes ser más o menos saludable.

El contexto no puede ser impuesto por aquellos fuera del equipo

El contexto para algunos equipos es que los jefes, clientes o clientes les dicen que se necesita cierta cantidad de funcionalidad para una fecha determinada, posiblemente incluso por un precio fijo.

Estos proyectos se ven precocinados por una serie de factores y no se perciben tan ágiles como podrían ser. Pero aún pueden ser ágiles dentro de ese contexto.

¿Los equipos que trabajan en estos proyectos tendrían más éxito y serían más capaces de superar las expectativas de los clientes sin contratos que garanticen una fecha de entrega, un alcance o ambos? Depende.
Pero ese no es su contexto. No podemos simplemente desear que la realidad en que vivimos desaparezca.

Proyectos a precio fijo y el Manifiesto Ágil

Veamos cómo los proyectos de precio fijo se alinean con los valores del Manifiesto Ágil. Si, esa web 1.0 que aún sigue en pie y vigente.

web
Evolución de la web respecto a la evolución del Manifiesto Ágil

Individuos e interacciones sobre procesos y herramientas

Primero: individuos e interacciones sobre procesos y herramientas. Nada de bloquear el alcance, la fecha de entrega o ambos de un proyecto significa restar importancia a la importancia que otorga Agile a las personas y las interacciones.

Los grandes productos seguirán siendo construidos por grandes equipos que se comunican bien y sobretodo que colaboran entre ellos.
Parte de esa comunicación puede estar prescrita por un contrato. Pero no hay nada que diga que un equipo no puede comunicarse de manera más efectiva o con más frecuencia de lo que exige el contrato por ejemplo.

Software de trabajo sobre documentación exhaustiva

Personalmente, prefiero actualizar este valor por “Soluciones funcionando sobre documentación exhaustiva”. Es casi seguro que los proyectos de desarrollo de contratos tendrán más documentación que sus contrapartes sin contrato.

Sin embargo, un rasgo común entre los proyectos de alcance fijo y fecha fija bien ejecutados es que el equipo entregando con frecuencia demostrará y liberará una solución funcional a las partes interesadas.

Colaboración con el cliente sobre la negociación de contratos

La colaboración con el cliente sobre la negociación de contratos podría ser el valor ágil que suena más en desacuerdo con los proyectos de fecha fija y alcance fijo. Pero no es necesario que lo sea. Incluso con un contrato que define la relación con el cliente y el proveedor, un equipo aún puede colaborar con su cliente. Si has leído bien, puede darse.

Incluso en el contrato escrito más detallado, habrá lagunas: lagunas en lo que está escrito, lagunas en lo que realmente se necesita y lagunas en cómo se interpreta el contrato. 

Por eso, debemos llenar estos vacíos con una mentalidad colaborativa y comunicativa.

Responder al cambio sobre seguir un plan

El último valor del Manifiesto, que responde al cambio por encima de seguir un plan, describe un lugar donde la colaboración es vital.

La forma en que un equipo y sus partes interesadas manejan el descubrimiento del cambio, o lo que no se sabía al principio, suele ser un factor diferencial para que un proyecto se considere exitoso o fallido. Queremos construir y seguir una manera de trabajar la gestión del cambio; es tan fundamental para la agilidad como lo es para el éxito con proyectos de fecha fija y alcance fijo.

iceberg
Modelo del iceberg para ver que implica la agilidad de negocio

Mi conclusión

Viendo la realidad de muchas organizaciones se ve claro que podemos hacerlo mejor. Y a veces hacerlo mejor empieza en nosotros mismos. En dar ese pasito para ver en nuestro metro cuadrado como podemos empezar a cambiar nuestra manera de trabajar para irnos a ese mundo de la agilidad de negocio empezando en honorar los valores de Agile.


What did you think about this post?