Existen multitud de variables que pueden echar al traste un proyecto. Una de ellas, tal vez una de las más importantes, es la falta de implicación por parte de la persona designada por el área usuaria para realizar este trabajo.
A veces, no falla la implicación y sí la actitud, cuando el responsable funcional entra en una espiral de ordeno y mando, en la que no se deja aconsejar.
El problema se hace más grande cuando, además de lo anterior, el responsable funcional no asume sus errores de manera que explícita o implícitamente hace que los mismos recaigan sobre el equipo de desarrollo.
Innumerables proyectos han fracasado por estos motivos.
Lo mejor es que desde un principio quede claro cuál es el rol del responsable funcional: definir la línea de desarrollo del producto, estableciendo prioridades y seleccionando las tareas que se hacen en cada momento, es el responsable de coordinar el área usuaria para obtener información adicional en el caso de que sea necesario (que lo será en muchos casos) y es el interfaz de comunicación entre esos usuarios y el equipo de desarrollo (lo cual no quiere decir que los usuarios sean un elemento aislado y que los desarrolladores no puedan comprobar directamente cuáles son sus sensaciones).
Teniendo muy claro que sus decisiones producen un impacto en el proyecto, es decir, si se equivoca a la hora de definir una historia de usuario o si se equivoca en las prioridades, hay repercusiones, en el sentido de que el proyecto tiene un presupuesto limitado y en cada iteración va menguando.
No se trata de que no se pueda equivocar, ya que para eso está el enfoque iterativo incremental y el feedback, sino de que las decisiones que tome las haga con intención, disminuyendo las tentativas orientadas al prueba y error.
Desde un principio hay que definir las reglas del juego y es muy probable, sobre todo para responsables funcionales sin experiencia en la participación en proyectos de desarrollo de software, que haya que ir realizando recordatorios puntuales de las mismas.
Una cosa es que desde un principio queden claras las reglas y otra que el responsable funcional las quiera cumplir. Si pasa de ellas y no se consigue normalizar la situación, no quedará otra que escalar el problema porque de lo contrario el proyecto y el producto serán los principales perjudicados.
Con el objeto de mantener un equilibrio en el proyecto es fundamental gestionar las expectativas, de manera que el responsable funcional no se lleve sorpresas. También, por nuestra parte, es importante que no nos intercambiemos los papeles, es decir, él responsable funcional debe elegir los objetivos de nuestra iteración y él no debe meterse (salvo que requiera alguna aclaración) en el esfuerzo estimado para cada una.
Es muy complicado ambas cosas, que el desarrollador no se meta a product owner y que el product owner no discuta la duración seleccionada para cada tarea, en su afán de tratar de que se asuma la mayor cantidad de trabajo posible, olvidando o ignorando que el cumplimiento de los compromisos se ve muy perjudicado cuando la capacidad del equipo de proyecto está sobresaturada.
Lo primero se resuelve aceptando cuál es el verdadero rol del equipo de desarrollo (una cosa es aconsejar y otra definir la línea de desarrollo) y la segunda con mucho diálogo y con la consolidación de una relación de confianza.
Es más difícil solucionar lo segundo que lo primero, de hecho, será complicado que con relativa frecuencia no se nos pidan explicaciones por tal o cual estimación, aceptemos que esto será así, dando las explicaciones que sean oportunas.
Vía: jummp.wordpress.com
StackPointerBlog 