archivo

Archivo de la etiqueta: product owner

Siempre comento que la importancia del valor del producto resultante es mayor que la del presupuesto, siempre y cuando estén compensado o exista una descompensación a favor del valor (cuánto más virada esté la balanza en esta dirección, mucho mejor).

De ahí la importancia de tener un buen product owner, con criterio y que también sepa dejarse aconsejar por otros usuarios y por el equipo de desarrollo.

El valor muchas veces se encuentra limitado por las especificaciones contractuales, cuando éstas marcan una serie de objetivos, que lo mismo resultaban interesantes en el momento en que se redactó el contrato, pero que tal vez, durante la ejecución del proyecto dejen de serlo, o al menos, pierdan peso respecto a otras necesidades sobrevenidas o que aparecen como consecuencia de la utilización de la aplicación.

Cuando nos encontramos en circunstancias así, llegará el momento donde el contrato, salvo que se hagan (si se puede) modificaciones sobre el mismo, predominará sobre la posibilidad de conseguir un mayor valor.

El contrato es un elemento estático, el mundo no lo es y, en consecuencia, los proyectos de desarrollo de software tampoco lo son. Lo mejor es establecer especificaciones contractuales más abiertas, que permitan una mayor flexibilidad y margen de maniobra.

Eso no es lo mismo que firmar un cheque en blanco, sino de saber leer mejor el contexto y expresarlo en un contrato.

Como siempre, no hay soluciones absolutas, lo mismo puede ser conveniente en desarrollos concretos, ser extremadamente meticuloso con especificaciones y alcance (sobre todo en desarrollos llave en mano).

Partamos de una base cierta, cuanto más próximo se corrija un defecto desde el punto en que se originó menor será su impacto y menos costosa será su corrección.

Ante eso, podríamos tomar la decisión de que todo defecto se corrija en el momento en que se detecte y hacerla extensiva a todo el conjunto de desarrolladores.

De hecho esa práctica es acertada, si bien, habrá veces donde tocará decidir.

Supongamos que se detectan una serie de defectos en el proceso de paso a producción de un producto y que las vueltas a atrás son costosas, en tiempo y en esfuerzo, ¿decidimos siempre dar marcha a atrás?, pues depende, tocará evaluar el impacto del defecto y el coste que tiene volver a hacer una nueva entrega (que nadie garantiza que sea limpia y que no lleve consigo nuevos defectos), de esta forma, habrá veces que convenga seguir hacia adelante (lo cual no significa ignorar los defectos detectados) y otras en donde la versión no alcance el mínimo necesario para llegar a producción.

La decisión de si el defecto se debe corregir o no debe quedar en manos del responsable de definir la línea de desarrollo del producto que no es otro que el Product Owner, el cual debe asesorarse por personal técnico con el objeto de obtener información suficiente para tomar la decisión que mejor convenga al producto.

Se pueden enumerar decenas y decenas de posibles situaciones que se pueden producir en un proyecto y que se podrían considerar riesgos, pero hay una que casi podríamos considerarla unánimemente cómo el principal factor de riesgo en un proyecto y es la falta de implicación del área usuaria.

Sin ellos no hay visión de las expectativas de producto por más que el equipo de proyecto cuente con personas con visión y experiencia sobre el negocio, porque una cosa es el proceso de negocio que se quiere informatizar y otra es cómo le gustaría al usuario verla ejecutada. Es posible que se acierte sin el usuario pero es más mucho más probable que se falle.

¿Y por qué el usuario no se implica?

– Se ha designado un responsable funcional o product owner que no quiere asumir sus responsabilidades o el trabajo que implica el mismo y la dirección del área usuaria no hace nada por arreglar esta situación.

– Puede darse el caso de que quiera hacer ese trabajo pero no se le han dado instrucciones precisas sobre qué tareas de las que tiene que atender son más prioritarias, por lo que tenderá a hacer las propias de su trabajo ordinario.

– También puede producirse el hecho de que sean sus propios jefes los que les obliguen a atender otras prioridades.

– Al área usuaria o al departamento TIC se les vendió un proyecto que pretendía cubrir una necesidad no existente y como tal, llegado el momento, se prefiere atender otras necesidades o trabajos más urgentes.

– El área usuaria apostó por el desarrollo ya que era una apuesta personal por parte de la dirección del área afectada y en un momento dado se produce un relevo en la misma que considera que existen otras prioridades.

– El área usuario y/o el responsable funcional se desaniman al no desarrollarse el proyecto según sus expectativas. Esto no quiere decir que se estén haciendo las cosas mal (que es posible) sino que no se han sabido gestionar sus expectativas,.

Causas puede haber muchas, pero el camino siempre debería ser el mismo en el caso de que se produzca esta situación y es que si no se consigue enderezar, lo mejor para todos es que se llegue a un acuerdo para dar por finalizado el proyecto y resolver el contrato (cuando proceda).

Niklaus With dijo (traducción libre): “Uno de los principales motivos de la complejidad es que los proveedores de software adopten sin crítica casi cualquier característica que los usuarios desean”.

Se puede adaptar la postura cómoda, que no quiere decir que sea sencilla, de limitarnos a recoger las especificaciones de los usuarios sin expresar una visión crítica.

Esto implica que nos guardaremos la opinión sobre la complejidad o simplicidad de la solución planteada, sobre la conveniencia de priorizar determinadas tareas sobre otras, en definitiva, no ponemos a disposición del product owner o del responsable funcional nuestro conocimiento y experiencia.

El desarrollo de software debe ser colaborativo porque las perspectivas, habilidades, conocimientos y experiencias del conjunto suman siempre más que cada una de ellas por separado.

¿Por qué adoptar esa posición? A veces, en función de la naturaleza del product owner, la confrontación de las opiniones puede originar desgaste y en cualquier caso siempre vas a trabajar más ante la necesidad de argumentar tus opiniones y de consensuar soluciones.

Sin embargo, en muchas ocasiones, la elección de esa postura es el resultado de arrojar la toalla como consecuencia de que el usuario ni quiere ni se deja asesorar.

El product owner debe definir la línea de desarrollo del producto, es su responsabilidad, pero también debe tener la capacidad de escuchar las recomendaciones de todo el conjunto de personas que colaboran en el proyecto, si deja esto de lado, probablemente la obtención de valor será más lenta y el producto resultante en cada iteración tendrá un nivel de complejidad mayor al necesario.

Los desarrolladores deben aportar, no solo su capacidad para desarrollar el software, sino también poner en valor su perspectiva y experiencias.

Esto del desarrollo de software se debe basar en condiciones de equilibrio. Bastante complejo resulta hacer este trabajo como para tener que estar constantemente a contracorriente.

En un proyecto de desarrollo de software son tantas las variables que intervienen que resulta muy complicado mantener ese equilibrio y será necesario el esfuerzo y voluntad de muchas personas para tratar de crear un contexto en el que por término medio se consiga.

Precisamente hay un factor que afecta en gran medida a ese equilibrio y es que las partes implicadas asuman de verdad el rol que tienen que desempeñar en el proyecto. En muchas ocasiones nos encontramos con responsables funcionales que huyen de su responsabilidad, en otras en donde tratan de imponer un criterio sin escuchar las recomendaciones o consejos de terceros y en otras en donde determinadas personas del equipo de desarrollo son las que tratan de que el producto vaya en la dirección y sentido que ellos estiman más conveniente.

Todas esas situaciones darán lugar, muy probablemente, a malos resultados. Seguro que se os ocurren ejemplos que hayáis vivido en primera persona lo que os estoy contando.

El responsable funcional es quien debe definir las prioridades y la línea de desarrollo del producto pero no debe prescindir del asesoramiento del equipo de desarrollo, entre otras cosas porque independientemente de que puedan conocer mejor o peor el negocio, saben de desarrollo de software.

Por otro lado, tampoco resulta razonable que sea el equipo de desarrollo el que defina el sistema porque no hay que olvidar que el producto no es para ellos y que hacer un producto de esta forma tiene todas las papeletas de que no se aproxime a lo que realmente los usuarios esperan y necesitan.

Realizar una correcta gestión de las expectativas es fundamental en todo proyecto de desarrollo de software. Hay que ser muy constante en este aspecto porque aunque se piense que las expectativas están bajo control, las mismas van a variar con el tiempo, ya sea por la propia evolución del proyecto o por presiones que se reciban desde el exterior.

Los responsables funcionales te van a apretar porque tienden a exigirte un mayor alcance y en un menor tiempo de lo pactado. Tienen que comprender (y tener una cierta experiencia) cómo funciona un proyecto con prácticas de Scrum para que sean más moderados en sus peticiones de modificación del sprint, sin embargo, cuando ellos mismos están recibiendo presiones, les resulta complicado no traspasarte, aunque sea, parte de ellas.

Precisamente por este motivo se agiliza en muchos casos las prácticas de Scrum con Kanban, pero esto simplemente trata de definir determinadas reglas del juego, la complejidad realmente se encuentra en mantener un equilibrio entre lo que el usuario desea y lo que realmente se puede hacer (o lo que realmente se considera práctico realizar), porque está claro que el usuario manda, pero también debe ser consciente, y para eso estamos nosotros, de la complejidad que tiene la realización de una determinada solución.

Es importante poner las cartas sobre la mesa y a partir de ahí que decida. No vale con ser simplemente ejecutores de historias de usuario, también tenemos que proporcionar ese valor a los product owners porque se trata de aprovechar de la mejor manera posible la inversión, de manera que consigamos ganar el mayor valor posible con el menor esfuerzo y de no complicar de manera innecesaria el producto.

Cuando se está trabajando en el refinamiento de la pila de producto (en paralelo al desarrollo de un sprint), una herramienta muy útil para definir con más detalle una historia de usuario es la utilización de maquetas o prototipos estáticos o dinámicos que permitan a los desarrolladores comprender mejor una determinada funcionalidad y a los responsables funcionales o product owners ver materializadas (de manera más o menos simplistas) esas ideas abstractas que tienen en la cabeza.

Sin embargo, llegados a un punto, continuar trabajando con esos prototipos para seguir perfilando una funcionalidad puede llegar a convertirse en esfuerzo invertido en vano, ya que el feedback que se obtiene deja de resultar significativo.

¿Cuándo se llega a ese punto? Cuando prácticamente no se obtiene un feedback de lo funcional y sí del diseño pero ya en aspectos poco significativos (de aquellos que hoy te dicen una cosa, mañana otra y pasado todo lo contrario).

En ese momento es fundamental, que el siguiente feedback se obtenga sobre la funcionalidad ya implementada sobre una versión del producto en el sprint en que se decida llevarla a cabo.

Feedback, sí, siempre que se pueda, pero con intención y fundamento.