Desarrollo de software. Antipatrón. Síndrome de la última versión

Afecta sobre todo a los usuarios pero también a los desarrolladores y nos lo encontramos tanto en enfoques clásicos como ágiles.

Cuando nos aproximamos a al definición de la primera entrega que va a producción (en el caso de un enfoque iterativo incremental se han podido liberar previamente versiones parciales que no han llegado a producción), el usuario empezará a querer incorporar funcionalidades que considera necesarias aún sabiendo que no son imprescindibles (los desarrolladores que en esto no deberían intervenir, pero que ya conocen el negocio, se convierten incluso en cómplices), sin tener en cuenta que tras esta versión, vendrán otras en las que podrán ir incorporando estas funcionalidades según las prioridades que establezcan.

Si este antipatrón se materializa presenta como inconveniente que se asuma una mayor capacidad de trabajo que la que el equipo puede soportar, lo que provocará, además del correspondiente overtime, una versión del producto con un peor acabado: más errores y más deuda técnica, y que no se cumplan los compromisos adquiridos ya que probablemente alguna funcionalidad no de tiempo a tenerla lista (esto último puede parecer menos importante pero no lo es, ya que la confianza está muy ligada al cumplimiento de los compromisos).

Es un ejemplo claro de que más es menos cuando se toman decisiones que no son compatibles con las posibilidades del equipo de proyecto.

Desarrollo de software. ¿Ser más duro con el proveedor?

Son muchos proyectos en los que he tenido la oportunidad de trabajar con equipos de proyectos distintos de diferentes proveedores. En esos proyectos ha pasado y me he encontrado de todo.

He participado en proyectos con mucho desgaste en las relaciones con el proveedor en los que durante meses ha existido tormenta y casi ningún día de calma.

La mayoría de vosotros, independientemente del “bando” en el que se encontréis: cliente o proveedor, habréis vivido situaciones similares.

No hace mucho un amigo me comentó que desde su punto de vista se era demasiado permisivo con los proveedores y que a su juicio se debería aplicar sobre los mismos “mano dura”.

Con respecto a la aplicación de “mano dura” es importante que tengáis en cuenta en primer lugar cuál es vuestro rol en la organización a la que pertenecéis. Probablemente tengáis como jefes a una infinidad de personas en diferentes niveles por lo que vuestra “mano dura” se puede quedar en nada si los que están por encima tuya no te respaldan y/o llegado el momento no se quieren mojar. ¿Qué quiero decir esto? Si amenazas con no pagar, con penalizar o con rescindir el contrato o decides pasar de la amenaza a los hechos, el asunto se termina escalando tanto en cliente como en el proveedor y se llega a una instancia donde se toma la decisión final y en la que pintarás bien poco.

Al final si no te dan la razón te encontrarás con respecto al proveedor en una situación peor que la que existía antes de comenzar este proceso.

Cuando no se tiene una visión del día a día del proyecto los criterios para respaldarte o no en tu postura son absolutamente distinto a los tuyos y lo normal es que la gente no se complique la vida.

La “mano dura” no sirve en el día a día de un proyecto. Creo más en la firmeza, en el respeto y en la comunicación. Es cierto que a veces no hay ni respeto ni comunicación y que eso al final da lugar a un desastre. Tu puedes querer calidad en los trabajos pero si el proveedor no entiende eso como necesario (solo le interesa imputar más y más horas) da igual como te pongas y da igual las veces que lo discutas (te podrán hacer caso a corto plazo pero a la larga volverán a las andadas). ¿Qué hacer en ese caso? Si la situación no se reconduce se debe escalar, una vez que se hayan apurado las vías de diálogo y hacer las recomendaciones oportunas a tus superiores, después que ellos actúen (esa responsabilidad está en su nómina) y por supuesto tener muy en cuenta lo que ha pasado de cara a un futuro. En cualquier caso hay que tratar de darle la salida más digna posible al proyecto.