archivo

Archivos diarios: octubre 4, 2011

Lo ideal es que responsables técnicos del cliente, usuarios y equipo de desarrollo formen un equipo, cada uno con sus roles, pero un equipo, sin embargo en la mayoría de las ocasiones no se dan las circunstancias para hacer eso posible, de manera que por lo menos hay que intentar conseguir que cada grupo funcione como un equipo, que persigan un objetivo general común (obtener un sistema de información que satisfaga las expectativas del usuario, pero no a cualquier coste, sino al presupuestado y con los plazos fijados, siempre y cuando, claro está, ambos estén adecuadamente dimensionados a la naturaleza del proyecto) y existir unos mecanismos adecuados de comunicación y colaboración entre los mismos.

En el momento en que los objetivos individuales de las personas o de estos equipos se impone al objetivo general se produce la ruptura de la unidad, afectando primero a la comunicación y más adelante a la confianza.

Cada grupo puede tener sus propios intereses, pero se tiene que intentar que los mismos estén siempre detrás de los objetivos generales. Si hay problemas se deben exponer al grupo por si fuera necesario hacer algún ajuste en esos objetivos generales.

Lo cierto es que por regla general, cada uno de los grupos de personas de un proyecto de desarrollo de software suelen funcionar poniendo sus objetivos individuales a la altura de los objetivos generales (o por encima) y esa es una de las causas que provoca un incremento de la complejidad en los proyectos.

Lo peor de todo es que se sabe que ese funcionamiento es nocivo para los intereses generales del trabajo a ejecutar pero se prefiere que cada uno desempeñe su rol en el proyecto y que la comunicación solo se realice en momentos puntuales (sobre todo en fase de análisis en proyectos con ciclo de vida clásico o en cascada o cuando en modelos iterativos e incrementales se definen entregas con un tiempo de desarrollo amplio).

En un proyecto de desarrollo de software, sobre todo aquellos que son de larga duración, se producen situaciones donde cliente y proveedor negocian y llegan a acuerdos.

Romper esos acuerdos es aniquilar la confianza. Un acuerdo, un pacto, puede ser bueno, malo o regular, para una parte o para los dos, pero es el resultado de un proceso de negociación, es algo que se ha construido juntos, como el software que se está desarrollando.

Siempre se puede renegociar, pero sobre unas bases que lo justifiquen y si la otra parte está de acuerdo (si hay confianza, por regla general no habrá problemas en sentarse, por lo menos, a escuchar y si lo que se pide es coherente, es probable que se llegue a un nuevo acuerdo).

Romper acuerdos unilateralmente y tomar como base esa situación para forzar una negociación, destruirán o dejarán muy mermadas las relaciones de cara a un futuro.