archivo

Archivos diarios: febrero 9, 2013

Cuando un proyecto entra en una espiral en la que el equipo de proyecto tiene que enfrentarse continuamente a una horda de problemas que dificulta, sin duda, su avance y el cumplimiento en los compromisos en las diferentes iteraciones es que algo se ha hecho mal o que la situación de partida no era buena o, tal vez, ambas cosas.

También es cierto que si el equipo no se deja vencer por esta situación, va respondiendo, va ganando la batalla aunque parezca que nunca termina y se cumplen buena parte de los compromisos, es que algo se está haciendo bien.

La verdadera naturaleza de un equipo de proyecto, como en la vida, sale en los momentos malos, ahí es donde no solo vale la capacidad técnica o los conocimientos, sino la intención y las ganas de luchar por tratar de cumplir unos objetivos. Cuando el desgaste, la presión y los nervios te van haciendo más pequeño, solo te quedan dos opciones, dejarte vencer o tratar de enfrentarte a la situación, ahí es donde te haces grande y en donde demostrarás que no solo puedes ganar cuando el viento sopla a favor.

Si los problemas no dejan de aparecer, llegado el momento adecuado (porque una solución aplicada en mal momento por muy buena intención que lleve, puede empeorarlo), es necesario actuar.

Muchos de esos problemas (más de lo que se piensan) son el resultado de someter a los equipos a una carga de trabajo superior a la que pueden admitir, lo que provoca que cualquier contingencia se convierta prácticamente en un obstáculo insalvable. Si a eso le sumamos otros riesgos como un entorno tecnológico inestable, un código con mala deuda técnica, la participación de diferentes equipos que tienen que sincronizar desarrollos, etc…, la aparición de problemas, uno tras otro, será inevitable, mientras pasan los días y es necesario cumplir lo pactado.

Hablo de solución y debería hacerlo en plural porque generalmente e independientemente de que haya algún problema principal hay otros secundarios que por si mismos o por alimentar a terceros, también deben ser tratados.

En un proyecto de desarrollo de software lo que cuenta es que al final hayamos desarrollado una solución de calidad que satisfaga las expectativas del usuario.

No vale llegar de cualquier manera, hay un presupuesto que respetar (pero el mismo deberá ser acorde a los objetivos reales del proyecto y es necesario estar abierto a realizar ajustes si es necesario) y unos plazos en donde tenemos que tener el producto en funcionamiento.

Pero más allá de todo eso se encuentra todo el conjunto de actuaciones que se han tenido que realizar para conseguir ese resultado. En las mismas es donde se sustenta el éxito del proyecto pero también las miserias y otros posibles éxitos en el futuro (nuestra carrera no termina en un proyecto concreto, tras este vendrá otro y la actitud que hayas mantenido en el mismo en el trato con tus compañeros y con los usuarios tendrá repercusiones en el futuro para bien o para mal, en función de lo que has hecho y cómo lo has llevado a cabo).

Al principio se tienen unas ideas generales de lo que se quiere. Conforme vayamos avanzado nos iremos aproximando a las expectativas reales que se tienen en el producto. Nos llevará un tiempo adquirir ese conocimiento y el usuario tardará tiempo en sacar a la luz lo que realmente quiere, todo eso en un contexto que puede cambiar. Esto quiere decir que la meta no es algo que está fijo y que se ve con claridad sino que se trata de algo que sabemos que existe.

Lo importante es que en cada paso estemos más cerca de ella y a veces y de forma paradójica para estar más cerca sea necesario alejarse de un camino elegido aunque ello suponga una mayor distancia de la misma (si hay que deshacer camino andado habrá que hacerlo con tal de encontrar de nuevo la dirección adecuada).

En un proyecto estamos continuamente adaptando nuestra trayectoria para tratar de llegar con éxito a la meta.

Con respecto a esto me parece muy interesante la reflexión de Michael White y David Epston: “No es el tamaño de los pasos de una persona lo que cuenta pero sí su dirección”.

¿Qué es la certificación de aplicaciones?, ¿asegurarte de que la versión entregada no tiene defectos y hace lo que el usuario espera?, ¿debe tener también en cuenta aspectos técnicos relacionados con la mantenibilidad del sistema?.

Es posible que sea la suma de esos y más factores, pero, ¿quién posee el conocimiento suficiente para certificar?, ¿el equipo de proyecto?, ¿los usuarios?, ¿ambos?. En cualquier caso deben ser personas que han participado en el proyecto y que saben todo lo que ha pasado en él, porque es la única forma de conocer cuáles son las expectativas reales de los usuarios y de conocer por qué y dónde está la diferencia entre una solución teórica perfecta y la que se ha logrado conseguir.

Puedo entender que equipos externos den soporte a ciertos aspectos como el testing del sistema, no solo en la ejecución sino también en el asesoramiento de los mismos, también que garanticen que lo que se entrega es lo que efectivamente se encuentra en nuestro sistema de gestión de versiones y en nuestro repositorio de artefactos, pero no puedo entender, porque no es algo real, que se pueda certificar un producto basado en un plan de pruebas que ha realizado quién lo ha construido y que todos sabemos que presenta imperfecciones porque desgraciamente no se le suele prestar mucho cariño a invertir tiempo en eso, por mucho testing exploratorio adicional que se haga.

Por todo esto, considero que es necesario ser muy prudente cuando se dice que este o tal equipo van a certificar los desarrollos que se realizan para una organización porque probablemente de lugar a expectativas que se encuentren lejos de convertirse en realidad.