Los problemas de ser un tomador de pedidos en un contexto Ágil

Siendo Product Owner en Garage Labs he tenido que enfrentarme a diferentes tipos de clientes, diferentes desarrollos de software y diferentes equipos de trabajo. Y uno de los mayores desafíos es no ser sólo un tomador de pedidos.

¿Cómo detectar cuando una idea o “requerimiento” del cliente aportará verdaderamente valor al producto o es un simple capricho?

En este artículo hablaré de cuáles son los problemas de ser un tomador de pedidos, y posibles soluciones o técnicas que a mi me han funcionado.

‍

1. Casarnos con el cliente: Decir que SÍ a todo

Aquí es necesario que el equipo se pregunte si tal función aportará al desarrollo del software y por consecuencia al modelo de negocio o al flujo operacional de la empresa.

Entonces, para no casarnos con los clientes, se debe interpelar, hacer dudar al cliente o a los usuarios finales. La técnica de los 5 ¿por qué? es clave, esto te ayudará a determinar la causa, raíz, dolor de un problema… si es que lo es.

Otra técnica o una buena costumbre es especificar objetivos. Definir junto con los Stakeholders los objetivos, el QUÉ y POR QUÉ, es lo que hacen los Product Owners, dejando el CÓMO al equipo de desarrollo y de diseño.

‍

2. ¿Empleados, Proveedores o Partners?

Antes de decir que SÍ a todo es importante entender el problema o dolor de los usuarios y clientes. Una vez hayamos empatizado, seremos capaces de proponer.

Otro error es permitir a los clientes que nos traigan la solución de todo y luego complementar como Product Owners con ciertas acotaciones ¿Y si la solución ya existe en el mercado?¿Y si en realidad quiere sólo reinventar la rueda? ¿Y si tomando una solución del mercado solucionan todos sus problemas? Debes ser capaz de proponer soluciones factibles y reales, incluso antes que los Stakeholders proponga qué hacer, eso hace un Product Owner. Con esto no quiero decir que los Stakeholders no puedan aportar soluciones, al contrario esto es clave ya que sólo ellos conocen mejor que nada su negocio (o eso es lo que debería ocurrir).

Pero si proponemos, le damos vuelta al asunto, se analizan los referentes, se realizan Wireframes, Customers Journeys, o incluso se evalúan 2 posibles soluciones y posteriormente el testeo de estas, entonces sentirán que los estás acompañando y que no somos sólo Product Owners que tomamos pedidos o sus empleados, sino que somos sus partners. Así además, sentirán que los apoyas y que no les estás entregando más trabajo para que desarrollen solos. En conclusión, matas dos pájaros de un tiro: propones y fortaleces la relación con el cliente siendo un partner.

‍

3. Invertir tiempo y recursos

¿Cuál es el resultado de haber dicho que SÍ a todo? Tener que invertir más tiempo y recursos en excavar dentro de la cabeza de los clientes y usuarios. Por consecuencia, tener más reuniones, más emails, más llamadas telefónicas, ¿Abrumante no? Al final terminarás escondiéndote del cliente en la oficina, tu casa o en un arbusto.

Para esto debes tener en claro que es mucho más productivo trabajar individualmente en equipo. Esto puedo sonar un poco contraproducente, pero si haces el trabajo, analizas, escribes historias de usuarios, conversas con los usuarios finales y luego te juntas con el cliente a revisar los pendientes, resulta mucho más fructífero que conversar tema por tema en reuniones infinitas o en mini llamadas que terminan quitándote todo el día.

Sé ejecutivo y autómata.

‍

4. Infactibilidad de desarrollar un MVP

Como consecuencia de haber dicho que SÍ a todo, tendrás un Backlog gigante y luego de haberte comprometido con los clientes, llegarás al último Sprint y te darás cuenta que no fueron capaz de conseguir un MVP en los tiempos establecidos.

Malos Product Owners pondrán excusas del tipo “No había suficiente presupuesto”, “El área comercial estimó mal la inversión”, “Los desarrolladores son muy lentos”, entre otras. Pero en verdad fue él quien no pudo tomar la iniciativa y responsabilidad de idear y ejecutar una estrategia ganadora sin excusas para alcanzar un MVP.

Finalmente terminarás con un MVP a medias, enojado con el cliente y tu equipo y querrás destrozar todo a tu alrededor.

Yo, con mi primer desarrollo, cometí el error (gran error y de principiante) de no visualizar el Scope del producto, ¿Consecuencia de eso? Tuvimos que financiar un Sprint por parte nuestra al cliente para cumplir con el MVP.

Para que no te pase lo que a mí, puedes apoyarte en diferentes herramientas, tales como Roadmaps o User Story Maps (esta última es la que más ocupo yo). Con ellas podrás visualizar el Scope, con las Historias de Usuarios, Épicas, su estimación de esfuerzo y estableciendo objetivos. Con esta herramienta, podrás jugar con las Historias de Usuarios, moviéndolas de acuerdo a los Story Points, de acuerdo a los objetivos y tiempos establecidos, así tú y el equipo entero sabrán si alcanzarán un MVP.

‍

5. Soluciones a problemas inexistentes

Si eres capaz de detectar un problema y de brindar una solución ya tienes un gran trecho recorrido. Sin embargo, y en base a mi experiencia, es más difícil decir que “no” a un capricho del cliente.

Debes darle más énfasis a detectar problemas reales que se quiere y debe solucionar, antes que solucionar caprichos del cliente. Esto puede llevar a que el producto final sólo responderá a sus caprichos o necesidades, o incluso solucionar problemas inexistentes, tales como reinventar el martillo, cuando todos sabemos que un martillo por sí solo cumple su función ¿o no?.

‍

6. Resultado: Un producto poco o nada funcional

Puede que llegues al final de los Sprints y obtengas un producto poco o nada funcional. Podría tener funciones que no aportan en el flujo operacional de la empresa, podría solucionar problemas inexistentes o incluso no cumplir con las expectativas de los clientes.

Si bien los Stakeholders conocen su flujo operacional, y entienden qué es lo que necesitan para su empresa, puede que no sea lo que necesiten los usuarios finales, tales como sus mismos trabajadores o compradores. Para esto, es importante ir testeando durante cada iteración el producto a nivel funcional y su usabilidad, así, si es que tienes que mejorar o incluir nuevas funciones, o cambiar de dirección, podrás hacerlo en las iteraciones siguientes.

Concluyendo, debes ser capaz de interpelar, proponer, trabajar individualmente en equipo, visualizar tu scope y testear todo el tiempo. Obviamente hay un montón de otros tips, técnicas o metodologías que te ayudarán a ser un Buen Product Owner y a tener una buena relación con el cliente.

Para Garage Labs es importante las buenas relaciones interpersonales, es por esto que trabajamos teniendo nuestros valores presentes.

No olvides dejar tus comentarios o contactarnos en Garage Labs si necesitas ayuda.