archivo

Archivo de la etiqueta: product owner

De igual manera que el responsable técnico del proyecto tiene que encargarse de toda la parte “interna” del desarrollo de software: coordinar al equipo o equipos de programadores (que pueden ser incluso de diferentes proveedores), tratar con los responsables del proyecto por parte de los proveedores (si hubiera proveedores), coordinar a las personas que junto a ti gestionan el proyecto, tratar con el departamento de sistemas para preparar la infraestructura necesaria, tratar con el Centro de Atención a Usuarios para la recepción del sistema en sus procesos, etc…, el Product Owner se tiene que encargar de coordinar todo el área funcional.

¿En qué consiste esa tarea? El Product Owner es el responsable de definir la línea de desarrollo del producto y por tanto el máximo responsable de definir las prioridades y de aceptar las especificaciones. Debe ser el interlocutor único en cuanto a la toma de decisiones (independientemente de que tenga colaboradores). Esta persona sería la encargada de recabar consensos y segundas opiniones dentro del conjunto de usuarios y sería también responsable de la comunicación de los avances, desviaciones y contingencias del proyecto (en la comunicación se podría recabar el apoyo del área técnica si así fuera preciso).

En el área usuaria es el Product Owner quién debe tomar las decisiones y es el encargado de definir interlocutores para las tareas de especificación y de coordinar las citas que sean necesarias. Como máximo responsable de la línea de desarrollo del producto se requerirá su implicación en el proyecto de lo contrario no contará con la información suficiente como para que sus decisiones tengan una base sólida. Esto es una recomendación, ya que si se limita a dar el visto bueno a los que otros especifican es posible que apruebe soluciones que no son las adecuadas para la aplicación o que el sistema pierda consistencia (tratamiento de conceptos similares de diferente manera o falta de integración en información que debería tenerla).

Anuncios

Contra esta situación no hay metodología o estrategia que la resista, sin buenas especificaciones el producto final se encontrará lejos de las expectativas del usuario, sin colaboración efectiva de un responsable del producto por parte del área usuaria no habrá un buen feedback ni una buena priorización en la línea de desarrollo de la aplicación, sin un usuario que esté accesible se producirán fases de bloqueo en el proyecto que en muchos casos (la mayoría) solo se resolverán tirando hacia adelante.

Y no es que no puedas hacer un buen análisis, ni siquiera vas a poder hacer una buena definición de sprint. ¿Qué pasa al final? El presupuesto se ha esfumado y el producto está todavía a medias o no hace lo que el usuario quiere, esto es igual a mucho desgaste y a pérdidas de dinero por ambas partes.

Es cierto que los desarrolladores hemos hecho mucho daño al negocio del desarrollo de software pero las personas que se han designado como responsables del producto por parte de los clientes también.

Y este problema lo tenemos tanto en enfoques clásicos como en enfoques ágiles de desarrollo de software porque en ambos casos necesitamos al usuario.

Un proyecto de desarrollo de software requiere que los responsables del producto estén muy implicados y con una alta dedicación al mismo, si la persona designada no puede dedicar ese tiempo necesario lo mejor es que delegue el día a día en otra persona dándole autonomía para la toma de decisiones (independientemente de que determinadas cuestiones las deba consultar).

Si no es posible de ninguna forma asegurar esa dedicación habría que pensarse muy seriamente por ambas partes si merece la pena afrontar el trabajo y si por el motivo que fuera se tuviera que llevar a cabo habría que explicar muy claramente los riesgos y las consecuencias de esta incertidumbre y falta de implicación en los costes finales.

En potencia todo, salvo el papel en blanco (y seguro que conocemos casos donde se han realizado estimaciones con un nivel de conocimiento del trabajo a realizar que se aproxima muy mucho a ese papel en blanco), es estimable, sin embargo, lo que queremos son estimaciones que se ajusten lo máximo posible a la realidad y para ello se requiere que cada historia de usuario esté lo suficientemente desarrollada como para conseguirlo.

Vuelvo a insistir en lo que comenté en el artículo de ayer, suficientemente desarrollada no es lo mismo que absolutamente detallada y/o llena de formalismos, sino que se adapte a lo que el proyecto (y su contexto actual) necesite.

Otra cosa es que nos equivoquemos en la estimación, cosa que sucederá sobre todo en los primeros sprints y/o hasta que se tenga dominada la tecnología y entorno sobre el que se va a desarrollar.

¿Para que sirven entonces las reuniones de planificación de sprint? Para terminar de perfilar el sprint. ¿No se hacen todas las actividades necesarias para poder estimar? La base son las historias de usuario y aunque puedas invitar al product owner a participar y aclarar dudas con él, cuando el proyecto se encuentra en una fase inicial o se incorporan funcionalidades con una cierta complejidad, no da tiempo en una reunión de planificación de sprint a tener lo suficientemente claro el alcance de la tarea por lo que la estimación corre más riesgos a lo que hay que sumar las consultas que de forma más que probable habrá que hacerle al product owner durante el sprint y que podrían bloquear determinados trabajos si no se han resuelto antes de que esas tareas se lleven a cabo.

Aplicando prácticas de Scrum y si me apuráis, por puro sentido común, tenemos que tener como objetivo que el resultado de cada sprint sea una versión entregable y por tanto, que se pueda pasar a producción.

Es muy importante desarrollar con intención para reducir el número de iteraciones (o dicho de otra forma para ganar en cantidad de trabajo efectivo por unidad de tiempo o lo que es lo mismo para ganar en productividad), para ello debemos minimizar (siendo el objetivo máximo eliminar), el número de componentes (funcionalidades) defectuosas que llegan al final del sprint (y por extensión a producción).

Para ello cada historia de usuario debe estar completamente terminada. ¿Qué es eso? Desde luego no es programar las tareas en que se descompone la historia y hacer cuatro pruebas, sino de tener la certeza de que efectivamente funciona, lo que implica una buena batería de testing y la verificación de que efectivamente cumple con las expectativas del usuario.

Una primera aproximación a esto último son las medidas para verificar la misma que aparecen en la historia de usuario, en las cuales tenemos que minimizar las ambigüedades para poder dar por bueno o rechazar la misma, ya que no debería haber medias tintas.

Estas medidas pueden estar implícitas en la propia descripción de la historia o separadas en un apartado diferente de la misma.

Otra cosa es que después, el product owner o por extensión los usuarios, se den cuenta de que la especificación realizada no satisface sus expectativas, en este caso el problema está en la especificación y para solucionarlo se requerirá evolucionar (modificar) esa funcionalidad en uno de los siguientes sprints.

En estas circunstancias es cuando se tiene buena parte del camino andado para que el proyecto tenga éxito. Y no es fácil conseguirlo.

Un product owner puede tener voluntad en hacer su trabajo de la mejor manera posible, sin embargo, la milla extra que separa un proyecto aceptable de otro con éxito se encuentra, en muchas ocasiones, en el hecho de que el product owner considere y sienta el proyecto como suyo.

El product owner es fundamental para el proyecto y así lo deben entender los desarrolladores, de manera que no lo consideren como alguien ajeno al equipo sino como una persona más dentro de él.

Para ello el product owner también tiene que poner de su parte, no obstante, si nos encontramos con dueños del producto que no tienen experiencia, tenemos que poner más del lado de los desarrolladores para conseguir ese ambiente de trabajo que favorecerá la colaboración entre todos.

Cuando el product owner se sienta parte del proyecto, defenderá el producto, lo que hará más llevadero un proceso tan complicado como es el de la implantación del sistema, en el que muchos usuarios se mostrarán contrarios a su utilización, queriendo preservar sus métodos, herramientas y procesos de trabajo.

La implantación se asocia a la puesta en producción de la primera o mínima versión viable del producto, sin embargo es un proceso que comienza antes y no me refiero a formación que haya que realizar con carácter previo, sino a todo un trabajo que comienza en las etapas iniciales del proyecto y que se extiende a lo largo de sus diferentes iteraciones.

Tanto a los products owners como a los desarrolladores nos encantaría poder hacer y acertar a la primera la funcionalidad completa de un determinado objetivo o módulo que se quiera implementar en una aplicación, pero pocas veces sucede esa circunstancia, ya que resulta muy complicado dar con una solución en la que se haya “traducido” perfectamente una idea abstracta y compleja que el product owner tiene en mente (y además, y por lo general, de manera incompleta y/o que no cuenta con todos los detalles), teniendo en cuenta, además, que, en algunos casos, estas funcionalidades tendrán la suficiente complejidad y/o tamaño como para que no quepan en un sprint.

Tratar de acertar a la primera tiene un riesgo importante, ya que puede dar lugar a que buena parte del esfuerzo invertido quede desaprovechado y a que tengamos un producto con una mayor deuda técnica y, por tanto, más complejo de mantener.

¿Que puede resultar más aconsejable? Tratar de acercarnos a una solución que cumpla las expectativas (no hablo de soluciones ideales) mediante aproximaciones sucesivas.

De esta forma el margen de error es más pequeño y ofrece la posibilidad de realizar ajustes que parten de una base concreta, lo que va a permitir que el feedback sea más efectivo.

Trabajar de esta manera requiere paciencia porque tal vez se tarde más de lo deseable en conseguir una solución completa pero a cambio el resultado obtenido tendrá más probabilidades de adecuarse a las expectativas de los usuarios siempre y claro, el product owner haya acertado en sus decisiones y los desarrolladores hayan construido una solución adecuada teniendo en cuenta también aspectos no funcionales.

Por otro lado, es muy probable que también se desperdicie esfuerzo de esta forma (el feedback dará lugar a modificaciones) pero por regla general será inferior al que se perdería tratando de trabajar sobre la solución completa de manera iterativa o realizando parches que muy probablemente no terminen de satisfacer las expectativas de los usuarios y que terminan siendo muy costosos en comparación con los resultados obtenidos.

Mary Poppendieck realiza la siguiente reflexión: “No tome decisiones irreversibles demasiado pronto, retrasa las decisiones de diseño todo lo que sea posible, de manera que cuando las tengas que tomar, lo hagas con la mejor información disponible para hacerlas correctamente”.

Tiene razón, pero lo que pide es difícil. Requiere que el Product Owner tenga una visión sólida del producto, conozca bien el negocio y tenga el apoyo por parte del equipo de desarrollo sobre qué funcionalidades una vez construidas son más costosas de modificar.

Poppendieck, lo que recomienda es que se desarrolle con intención, sabiendo lo que se hace, para de esta forma reducir el número de iteraciones. Aún así, la especulación a veces es inevitable porque el responsable funcional no tendrá claro siempre si la solución que propone es la mejor o qué reacción va a tener el conjunto de usuarios ante las mismas.

El objetivo es conseguir cada vez un mayor valor para el producto con una inversión ajustada a ese incremento. A veces tendremos más éxito que otras, porque equivocar nos equivocaremos ya que el desarrollo del producto es evolutivo y en él nos daremos cuenta no solo de nuevas funcionalidades que son necesarias, sino de algunas ya implementadas que son mejorables.

Por ello, siguiendo las recomendaciones de Poppendieck, el desarrollo debería comenzar por lo más prioritario y dentro de ello por lo que se tenga más claro en ese momento, si se tienen dudas sobre una funcionalidad y se prevé un coste de modificación alto (por sí misma o por su impacto sobre terceros desarrollos), mejor esperar, si se puede, un poco más.