La posición del Product Owner no siempre está clara dentro del equipo. Si tienes este rol, es posible que surjan situaciones en las dudas sobre cuál es tu papel. Pues bien, tenemos dos buenas noticias.
La primera es que tus dudas son normales: el papel del Product Owner es manejar en equilibrio varias tendencias contradictorias; adoptar un enfoque relativamente técnico, pero no excesivo; tener madera de líder, pero sin caer en la tiranía; establecer buenas prácticas, pero dejando que elScrum Master haga su trabajo.
La otra buena noticia es que con este artículo evitarás algunas de las trampas que puedan influir en el ejercicio de tus funciones. Nos referimos, sobre todo, a situaciones en las que te verás tentado de asumir el papel de tus colegas, como cuando el Scrum Master es inexistente, los desarrolladores no inspiran confianza o un Project Manager no encaja contigo... Ten cuidado y trata de evitar lo siguiente.
Motivos que llevan a cambiar la posición de un Product Owner e intervenir
En esta lista detallada, pero no exhaustiva, describimos varias situaciones en las que te podrías sentir tentado de ejercer ciertas funciones que van más allá del puesto de Product Owner.
Te planteas reemplazar al Scrum Master
- Por una serie de motivos, peores o mejores, has dejado de confiar en el Scrum Master.
- El Scrum Master de tu equipo desempeña otra función en el equipo o es la empresa que le impide dedicar suficiente tiempo a las obligaciones de su rol.
- No tienes un Scrum Master.
- Acabas de obtener la certificación como Product Owner y tienes unas ideas muy claras sobre qué debería aportar un Scrum Master al equipo.
- Ya has sido Scrum Master en otro equipo y te cuesta aceptar que otra persona pueda desempeñar esa función de una forma distinta a la tuya.
- Te atrae el papel de coach, así como los aspectos organizativos o de «proceso» de un equipo, así que te apetece involucrarte en las tareas relacionadas.
Cuando hay que gestionar los problemas de tu equipo
- Notas que el equipo no está tan motivado y que falta coherencia y disciplina.
- La empresa está pasando por la tercera reorganización del trimestre y tu equipo se ve afectado por la inestabilidad reinante.
- El Project Manager de tu equipo acaba de dejar su puesto y su sucesor no se incorpora hasta dentro de 4 meses.
- Tus sponsors te han comentado que esperaban más entregas y más rápidas; el año llega a su fin y la hoja de ruta se ha desviado mucho.
- Crees que el equipo podría trabajar más rápido.
- Tus desarrolladores tienen horarios de trabajo inadmisibles y se pasan las horas muertas en el ordenador jugando al 2048.
- Al fin y al cabo, eres el capitán de tu propio equipo: lo normal es que te salga el líder que llevas dentro y que tengas muchas ideas para mejorar el equipo.
- El año que viene te ves liderando el equipo de Producto; quieres demostrar a tus superiores (o a ti mismo) que sabes cómo llevar a tu equipo a la victoria sin sudar la camiseta.
Estás muy interesado en asumir el liderazgo técnico
- Tu equipo valora tu capacidad para resolver problemas técnicos, pues la comunicación es más fluida. Esta sensación te gusta y te insta a estar cada vez más presente en las decisiones técnicas.
- Tienes experiencia previa como desarrollador y echas de menos la parte creativa del código.
- Calculas tu deuda técnica (lo cual está bien) y notas que esta ha ido en aumento en los últimos 3 sprints. Ya no confías tanto en tus desarrolladores.
- Acabas de asumir el papel de Product Owner en un equipo ya existente. Heredas un backlog, pero también muchos errores, además de una arquitectura y unos frameworks obsoletos. Crees que hay que tomar medidas para mejorar esta situación.
- Te gusta tener todo bajo control y eso te lleva a interferir en las decisiones técnicas de tus desarrolladores.
- Tu equipo está experimentando con nuevos frameworks o métodos de trabajo; te tienta intervenir para acelerar la curva de aprendizaje de los desarrolladores.
Hazte con los básicos de un Product Owner descargando el Product Ownership Starter Toolkit
Hacer el trabajo de otros conlleva ciertos riesgos
Si caes en este tipo de intervención, te arriesgas a introducir mecanismos perjudiciales para la dinámica colectiva.
De hecho, al asumir un papel que va más allá de tus responsabilidades, harás que tus compañeros de equipo adopten ciertas posturas que pueden afectar negativamente a los distintos factores de éxito colectivo: la organización, las relaciones entre los compañeros del equipo y, en resumen, el trabajo del equipo.
Descargar de responsabilidad al equipo
Si asumes demasiadas responsabilidades en el equipo, una de las posibles reacciones de tus colegas será la de aceptar la situación y cederte terreno. Veamos el ejemplo del Product Owner - Product Manager.
Al asumir tanto el rol de líder como el de manager, proyectarás una imagen «de superioridad» respecto a tu equipo, y eso puede afectar al carácter proactivo de los desarrolladores: su capacidad de iniciativa, la solidez de sus propuestas e incluso su motivación pueden verse ensombrecidas por el papel dominante que desempeñas.
Al final, se crea un círculo vicioso: el equipo cada vez te cede más espacio y tú lo ocupas; a la larga, puede resultar agotador dirigir cada uno de los movimientos del equipo, y la falta de voluntad que ahora reina puede llegar a frustrarte.
Sembrar la desconfianza en el grupo
Si asumes el papel de un compañero porque no confías en sus capacidades, lo normal es que él también adopte una actitud de desconfianza. Tu postura puede interpretarse como una amenaza para su puesto y los motivos para estar en el equipo, y desencadenar una reacción de oposición o incluso de hostilidad por su parte.
El efecto espejo también puede hacer que tus compañeros acaben reprochándote algunas de tus acciones como Product Owner. El impacto se hace notar a diario: comunicaciones infructuosas, cuestionamiento excesivo de las decisiones y opiniones expresadas, conflictos, falta general de apoyo a la visión que propones, deterioro gradual del espíritu de equipo.
Este tipo de interacciones también pueden extenderse a todo el equipo e incluso llevar a la creación de grupos internos. Esta espiral se irá reforzando a medida que las situaciones de conflicto empujen a los participantes a mantenerse firmes en sus posiciones y cerrarse al diálogo.
Las consecuencias se aprecian especialmente en los puestos de Scrum Master o desarrollador, pues son parte del propio equipo y afectan al trabajo de Producto de forma muy directa, así como a las relaciones entre los compañeros del equipo.
El infierno está empedrado de buenas intenciones
Por todos esos motivos, crees que se te daría mejor desempeñar un trabajo que se supone que no es el tuyo, pero no nos engañemos: nada más lejos de la realidad.
Esto que decimos puede parecer obvio, pero es importante ser consciente de ello. Si resulta que eres un mal Scrum Master, un desarrollador incompetente o un pésimo Product Manager, acabarás empeorando el problema inicial. Es una pena, porque has dedicado una gran cantidad de tiempo y energía a solucionar los problemas.
Sin embargo, por el camino has minado la confianza que el equipo tenía en ti, y ser el Product Owner de un equipo donde uno no es valorado puede acabar resultando un calvario.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Nuestros consejos para garantizar el buen funcionamiento de un equipo
Las situaciones descritas anteriormente pueden discutirse con el responsable de QA, el especialista en UX o cualquier interlocutor que necesites para contribuir a la construcción del producto.
Las causas y consecuencias comentadas aquí no se ciñen a la más estricta realidad y se han descrito de forma caricaturesca de manera intencionada. Ahora bien, no es descabellado que te hayas topado con alguna de ellas.
Ahora se acabaron las excusas: puedes identificar estas situaciones e incluso evitarlas o ponerles remedio gracias a estos principios:
Sé humilde
En general, no hay que olvidar que los demás esperan que hagas el trabajo para el que se te ha contratado, y no el de tus compañeros. Y en ese puesto es en el que seguramente seas más útil. Lo mismo se aplica para tus empleados.
La humildad es una de las virtudes más importantes y necesarias para la agilidad, porque para lograr una mejora continua, hay que saber detectar y aceptar lo que hay que mejorar.
No eches más leña al fuego
Si intentamos hacer el trabajo de un compañero, lo más probable es que descuidemos nuestro propio cometido, lo cual puede empeorar los problemas.
Hagamos una analogía futbolística: imagínate un equipo de fútbol con jugadores muy buenos, pero que no confían los unos en los otros; todos intentarán jugar en la posición de los otros. El resultado será una defensa llena de agujeros y un ataque desorganizado.
Confía en tus compañeros
Este sencillo consejo se deriva de los dos anteriores. Debería ayudarnos a confiar en las capacidades de nuestros compañeros el aceptar las propias limitaciones y entender que el buen funcionamiento del equipo siempre se debe a un esfuerzo colectivo para mejorar.
Si dudas de las habilidades de tu compañero de equipo, concéntrate en su capacidad para mejorarlas y moviliza a tu equipo para que ocurra. La confianza es el cimiento de cualquier grupo que da fuerza a la gente. Además, evita que nos salgan más canas y nos hace mejores personas.
¡Comunicarse, comunicarse y… comunicarse!
Así es. Uno de los grandes clásicos para mejorar tanto individual como colectivamente es ser transparente, prestar atención y promover el diálogo en todo momento.
Este consejo supera cualquier cosa dicha antes en este artículo, así que no hay mucho más que añadir. Se han dicho muchas cosas sobre este tema. Aprovecha las retrospectivas para sacar a relucir los puntos débiles que realmente dificultan la vida de tu equipo.
Concentrarse en las cualidades que definen a un buen Product Owner
Tu posición como Product Owner es esencial para que un producto avance adecuadamente.
Si te afectan los problemas que están fuera de tu campo de acción, concéntrate en las cualidades unificadoras que puedes aportar como Product Owner al equipo.
La legitimidad de tu intención y tu visión, tu capacidad de decisión y tu disponibilidad son herramientas importantes para unir fuerzas y, por lo tanto, establecer una relación sana con sus desarrolladores.
Al hacer bien tu trabajo, las posibles deficiencias del equipo pueden identificarse con más facilidad, lo cual puede dar un ejemplo positivo que motive a todo el mundo.
Por último, no olvidemos que respetar el papel de los compañeros no tiene por qué impedir que nosotros mismos tomemos la iniciativa para realizar propuestas en ámbitos que consideremos relevantes, aunque se desvíen un poco de nuestra actividad principal como Product Owner. Si tienes experiencia y conocimientos personales, ¡compártelos con tu equipo!
Para saber más: descarga nuestro libro Las Claves del Product Management
Foto por Jason Goodman en Unsplash
