En el artículo ‘The Team Journey’ os contaba cómo visualizaba la evolución de un equipo que apenas entregaba incremento de producto a final de sus iteraciones. Ahora quiero compartir con vosotros las principales áreas que trabajé con ellos cuando empecé a formar parte del día a día del equipo. La primera para mi es conocer el producto.

VanesaTejada_ConoceTuProducto.jpg

Conocer el producto

Creo que un equipo que no conoce su producto no entiende por qué hace las cosas y es incapaz de plantear cómo resolver los problemas de los clientes, lo que se traduce a un ‘dime lo que tengo que hacer’ y si me apuras a un ‘ dime cómo lo hago’.

Un equipo que no conoce su producto no puede desarrollar un buen producto.

Cuando trabajo en equipos de desarrollo hago mucho hincapié en que se entienda el negocio, porque es de lo que se trata: nosotros ofrecemos unos servicios a personas que tienen unas necesidades.

  • Cuando los servicios son buenos, las personas pagan por ellos y así podemos seguir invirtiendo en el mantenimiento, mejora e innovación de dichos servicios. Fácil, el intercambio ha producido valor a ambas partes.
  • Cuando los servicios no son buenos, las personas no satisfacen sus necesidades y no pagan por ellos, si no entra dinero entonces la empresa dejará de invertir en sus recursos físicos y personas.

Una de las preguntas que hago al equipo para abrir este tema es: ¿por qué haces lo que haces?. Lo que pretendo conseguir con sus respuestas, posteriores preguntas y el debate que surja, es que el equipo como un todo sea capaz de responder a estas preguntas:

  • ¿Qué es lo que hacemos? – una tienda de ropa online
  • ¿Para quién lo hacemos?- hombres, mujeres, adultos o adolescentes…
  • ¿Por qué lo hacemos? – permitirles comprar sin desplazarse a la tienda física…
  • ¿Cómo sabemos si lo estamos haciendo bien? – informe de beneficios…

He escuchado en más de un ocasión a equipos Scrum decir que el responsable del producto es sólo el Product Owner. Mi opinión es que no, no es el único. El producto es de todos sólo que cada uno tenemos un rol alrededor de él y eso nos hace trabajar en el producto con diferentes perspectivas y prestar atención a diferentes actividades que hay que llevar a cabo para desarrollarlo. Creo que un equipo de desarrollo de producto debe tener unos conocimientos del mismo básicos y muy claros, aunque luego cada rol tenga más experiencia en unos aspectos u otros.

Ventajas de conocer tu producto

La primera ventaja que veo en los equipos que conocen su producto es su implicación. Cuando era Product Owner me encantaba que los desarrolladores me llevaran la contraria en mis ideas, me encantaba que se llevaran la contraria entre ellos, porque sabía que lo que saliera de esa conversación iba a ser la mejor opción elaborada entre todos.

La implicación de un equipo con su producto genera valor. No, no puedo demostrarlo científicamente, pero esto hace que la mayor parte de las conversaciones, sean sobre la creación de producto, sobre cómo resolver problemas y no solo sobre la resolución de errores.

Cuando un equipo está implicado, genera valor y su producto tiene pocos errores, se ganan la confianza de otros roles alrededor del producto y la organización. De hecho esto fue una de las ventajas que permitió a un equipo del que fui Product Owner dejar de estimar.

El hecho de que un equipo conozca su producto se puede involucrar en otros foros. Por ejemplo, una de mis principales responsabilidades a día de hoy es asegurar que roles de management, stakeholders y equipos de producto trabajan en la misma dirección y alineados. Para ello facilito unos eventos de revisión del roadmap cada cuatrimestre y entre los asistentes hay desarrolladores. Estos desarrolladores están ahí en varias sesiones porque son capaces de entender conversaciones de negocio, hablar su lenguaje y ofrecer su punto de vista más técnico cuando se requiere.

Finalmente, siempre he percibido mayor satisfacción personal y grupal en equipos que conocen su producto, hay otro ambiente, clima, se respira de otra manera, y creo que es gracias a saber lo que hacen y el impacto que tiene.

 

 

2 thoughts

  1. Completamente de acuerdo, Vanesa. Es fundamental el “para qué” y no solo el “cómo”.
    En general, a lo desarrolladores nos cuesta cambiar a la perspectiva de negocio, pero ese es el camino. Nuestro valor no es solo saber cómo usar las herramientas sino saber para qué sirve cada una y dónde aplicarlas mejor. Para ello debemos conocer las necesidades del usuario. De esta forma podremos proponer diferentes alternativas al requerimiento.

    Mucha gracias por el artículo.

    Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s