Manifiesto ágil. Un manifiesto a favor del desarrollo de software IV

Tras la revisión del primer y segundo principio o valor del manifiesto ágil, le toca el turno en este artículo al siguiente:

Principio 3: Valorar la colaboración con el cliente, por encima de la negociación contractual.

Quien me conoce sabe que para mi este principio es primordial. Los dos primeros hablan sobre la importancia de las personas que participan en el proyecto y su interacción/comunicación y sobre la importancia de que el software funcione por encima de otros factores, en este caso se trata de dos valores que considero esenciales que no son otros que la colaboración y la confianza.

A lo largo del tiempo que llevo escribiendo en el blog habréis podido comprobar una cierta evolución en mi manera de ver ciertos aspectos del desarrollo de software, pero si hay algo que no ha cambiado ha sido precisamente esto, es decir, la necesidad de que exista colaboración y confianza para que un proyecto de desarrollo de software salga hacia adelante.

Es necesario romper la barrera que separa a clientes y proveedores. Cuando se trabaja en un proyecto es necesario considerar a todas las partes que intervienen como un equipo, en el que todos deben sumar. Si se consigue eso se logrará uno de los objetivos más importantes del trabajo en equipo que no es otro que el hecho de que la suma del bloque sea superior que la suma de las distintas partes individuales.

Por tanto, el equipo de proyecto debe ser uno, en el cual cada uno tiene su rol y tiene que ser respetado. Es lógico que el proveedor defienda determinados intereses (como por ejemplo que el proyecto le sea rentable y/o le sirva de lanzadera para conseguir más negocio) y el cliente los suyos (ha realizado una inversión y quiere obtener resultados), pero siempre dentro del marco de la confianza.

Si se destruye la confianza, se rompe buena parte del espíritu de colaboración y se rompe la unicidad del equipo, cada parte se hará más radical en la defensa de sus intereses y las palabras y la propia negociación del día a día del proyecto serán sustituidas por el contrato que existe entre las partes.

Esto supone un problema para el proyecto, ya que los contratos son objetos predictivos y el desarrollo de software es adaptativo. Cuando se negocia sobre el contrato el proyecto siempre pierde. Pero no es el único, el proveedor también lo hará, ya que difícilmente un contrato será tan cerrado para que no de lugar a interpretaciones y cuando se trata de eso, tiene todas las cartas a su favor el cliente ya que al fin y al cabo es el que tiene la llave de paso del pago de los trabajos.

El cliente también sufre. Si el proyecto pierde en el sentido de que haya funcionalidades que no se implementen y/o de que la calidad se resienta, también pierde el cliente, a lo que hay que sumar el desgaste que individualmente tienen las distintas partes que participan en proyectos de estas características y también en el desgaste de las relaciones centre las partes que pueden dar lugar a que unos u otros terminen buscando otras alternativas.

Continuemos con el análisis de los principios del manifiesto ágil.

5 comentarios
  1. Francisco dijo:

    Que podes comentar algo acerca de como adaptar una técnica ágil a un entorno como la administración publica, en donde muchas de la consignas no pueden ser planteadas porque están en contra de los procedimientos de contratación.

    Por otro lado, la valoración de un proyecto es a mi entender compleja y surge “el quien lo paga” que por lo general es distinto del interlocutor….. (espero que refutes esto para poder abrir mi horizonte)

    • jummp dijo:

      No es sencillo aplicar técnicas ágiles en un entorno como la administración publica, ya que su propia dinámica de funcionamiento lo complica.

      Como cualquier cambio de hábito se requiere tiempo para poder llevar a cabo cambios, desde mi punto de vista el primer paso es cambiar cómo se enfocan los proyectos y hacerlo desde una perspectiva ágil. Es un cambio de mentalidad y eso está por encima de cualquier metodología.

      Respecto a lo de valorar la colaboración con el cliente por encima de la negociación contractual, es totalmente compatible con un marco de contratación tan estricto como el que tiene la administración pública.

      Un pliego de prescripciones técnicas establece unas directrices y puede estar hecho con más o menos detalle. Determina una finalidad (compuesta por diferentes objetivos o tareas) que se tiene que conseguir con la ejecución del proyecto. No se trata de un manual de instrucciones, sino que hay que adaptarse a lo que el proyecto depara y esto pasa incluso con las metodologías clásicas.

      Siempre y cuando no se desvirtúe el objeto del contrato y se cumpla la finalidad del proyecto existe suficiente espacio para poder aplicar principios ágiles.

      Como es lógico, si el responsable del proyecto de la administración no quiere que se trabaje con planteamientos ágiles poco puede hacer el proveedor.

      Como bien comentas, en los proyectos de la administración no siempre paga el departamento TIC, sino que puede pagar un servicio o centro directivo distinto.

      Pero este problema también se produce con metodologías clásicas, surgen problemas en el proyecto, una de las más habituales son cambios en los requisitos en diferentes momentos del proyecto, que el proveedor quiera reducir el alcance del proyecto una vez que se da cuenta de que es mucho más de lo que dedujo del pliego (o que con el presupuesto ofertado no llegan), que el cliente empiece a pedir más de lo acordado, etc… cuando esto sucede todas las partes implicadas tienen que llegar a un acuerdo que podrá ser más o menos consensuado o provocar más o menos desgaste.

      Como comentaba al principio, no es nada fácil aplicar los valores ágiles en los proyectos con la administración y habrá casos en que no será posible. En cualquier caso pienso que si se dan las circunstancias adecuadas sí que se pueden ejecutar proyectos de esta manera y en cualquier caso siempre es posible afrontar las distintas tareas que se presentan en un proyecto y la toma de decisiones desde un enfoque ágil.

      • Francisco dijo:

        Muy buen comentario. Pienso que probablemente vengo usando de manera “no metodológica” técnicas ágiles ya hace muchos años, sin embargo, creo que los grandes proveedores aun no están preparados por muchas razones, entre ellas el aplicar métodos de gestión ajenos al diseño de software.

        Saludos

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: