archivo

Archivos diarios: agosto 23, 2013

Es muy importante saber dónde se encuentra cada uno y cuál es su rol. Pero partiendo de esa base, los proyectos funcionan mejor cuanto menos muros existen entre los diferentes stakeholders en el proyecto (en el título del artículo he puesto unos cuantos, en la medida en que sean más los que decidan aplicar esta filosofía, las cosas funcionarán mucho mejor).

Venimos de una cultura formalista, en la que los mecanismos de comunicación se centraban en el intercambio de papel. Una cultura en la que todas las partes trataban de cubrirse las espaldas, para que cuando hubiera problemas, que los había, por mucho papel que hubiera por medio, todos tuvieran argumentos de defensa o de ataque.

El problema no era que quedasen cosas registradas en papel, en sí no es malo siempre y cuando no se abuse de él, sino la orientación que se le dio. En lugar de crear espacios comunes se creaban muros de defensa para lo que después podría venir.

Y es que al final nadie solía quedar satisfecho. La crisis del software (totalmente vigente hoy día) daba como resultado productos que no satisfacían las necesidades del cliente y encima el proveedor obtenía, en el mejor de los casos, beneficios muy escasos. Además, generalmente cuando más satisfecha quedaba una parte, menos quedaba la otra.

Eso necesariamente no lo arregla un simple cambio de mentalidad, porque en un proyecto siempre hay muchos intereses en juego e intervienen personas ajenas a los mismos pero que tienen influencia directa sobre los equipos (los responsables de los departamentos implicados o de las propias organizaciones).

Para que esto termine calando dentro de una determinada organización o departamento se requiere su tiempo, pero alguien tiene que dar el primer paso, y verás como te alegras de ser tú el que lo ha dado.

Querer controlar el estado de un proyecto exclusivamente a través de los valores cuantitativos que te ofrecen las desviaciones es un error. Los números son números y aunque puedan hacer soltar determinadas alarmas, se necesita conocer realmente los motivos que han dado lugar a la aparición de esas desviaciones.

Que un proyecto presente desviaciones no quiere decir que vaya mal ya que lo mismo ha sido necesario aplazar determinados hitos del proyecto con el objetivo de hacer una entrega de mayor calidad o lo mismo nos estamos yendo en precio pero a costa de un producto que se adapte en mejor medida a las necesidades de los usuarios y de la organización.

No debemos olvidar que las desviaciones son respecto a unas condiciones iniciales y evolución que se pensaron que se iban a mantener a lo largo del desarrollo y que, como todos sabemos por nuestra propia experiencia, varían, a veces poco y otras de manera absolutamente radical.

Tampoco quiere decir que un proyecto sin desviaciones vaya bien, lo mismo se está siendo inflexible con una planificación que podría dar lugar a un producto de una calidad discutible y alejado de lo que el usuario requiere para realizar su trabajo, en funcionalidad, en usabilidad y/o en combinación con cualquier otro factor que marque la satisfacción del cliente.

No se trata de que no se informen de las desviaciones, antes al contrario, resulta un indicador muy interesante, sin embargo, el análisis no se debe quedar ahí, sino que debe llegar al detalle para conocer realmente el estado del proyecto.

Es razonable definir plazos. De hecho si aplicamos sprints, éstos tienen una fecha de finalización.

La metodología definida en una organización puede exigir la entrega de determinada documentación asociada al proyect sea o no documentación que resulte necesaria para el trabajo a diario en el proyecto.

Puede ser deseable que los ítems necesarios para el proyecto puedan cubrir las necesidades de la organización pero en cualquier caso, quien se encarga de definir los procedimientos de trabajo es el que tiene que valorar el coste de exigir determinada documentación que se puede considerar adicional a lo que se está necesitando.

Lo que veo todavía más discutible es el hecho de exigir plazos a una documentación dentro de un sprint. Sí que puedo entender que se fijen fechas tope y que el equipo de proyecto pueda jugar con ellas, pero exigir fechas concretas para cada uno de ellos dentro del sprint me parece excesivo y contraproducente.

Hay que entender a la organización y sus procesos, pero no debemos olvidar que el fin último de cada proyecto es entregar un software de calidad y la documentación no es condición necesaria ni suficiente para ello.