Desarrollo de software. La responsabilidad del 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).

Desarrollo de software. Sin implicación del cliente o área usuaria no hay nada que hacer

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.

Desarrollo de software. Las historias de usuario deben ser estimables

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.

Desarrollo de software. Las historias de usuario deben ser verificables

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.

Cuando el product owner siente el producto como suyo

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.

Iterativo, incremental, enfoque evolutivo

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. Desarrollo con intención

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.

Valor, proyectos y especificaciones contractuales

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).

Llegado el momento, ¿quién decide que se corrija un defecto?

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.

Desarrollo de software. Cuando el usuario no está implicado

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).