¿Deben los Product Managers hacer QA?
Implicación del Product Manager en la validación de la calidad. ¿Qué es hacer QA? La calidad como responsabilidad de todo el equipo.
Durante la semana pasada lancé un par de encuestas en Twitter y LinkedIn acerca de si los Product Managers deberían hacer QA. Los resultados estuvieron parejos en ambas plataformas, con un resultado aproximado de 60/40 a favor de que sí hagan QA.
Tres quintas partes no es una mayoría aplastante. La comunidad de producto parece dividida en este aspecto. Pero, ¿es realmente así?
¿Qué es hacer QA?
Parte del problema puede ser porque dejé la pregunta de la encuesta intencionalmente abierta. Porque, ¿qué es hacer QA? ¿Hablamos del trabajo de creación de casos de tests y automatización de los mismos? ¿O hablamos de verificar que el producto que vayamos a entregar tenga la calidad adecuada?
La primera parte, es claramente responsabilidad de un QA, o del equipo en caso de que este no lo tenga. La duda surge sobre la segunda, porque ahí podemos apreciar cierto solapamiento. Desde mi perspectiva, garantizar que el producto cumpla las expectativas de nuestros clientes, es tanto responsabilidad de QA como del Product Manager.
Moisés Vilar apuntaba en un comentario algo con lo que en general estoy bastante de acuerdo, y es que los Product Managers se deben centrar en el espacio del problema, y el equipo en el espacio de la solución. Bajo este paradigma, podría parecer que los Product Managers una vez definen el problema, ya no tienen nada que decir de la solución, pero nada más lejos de la realidad en mi opinión.
El Product Manager es el primer interesado en que el producto tenga éxito. Y solo puede tener éxito si este funciona de la forma adecuada, no ya libre de fallos, sino también de forma fluida y usable.
No me imagino un Product Manager lanzando un producto o funcionalidad al mercado sin haberlo probado mínimamente, así que creo que parte del problema residía principalmente en definir correctamente que se entendía por hacer QA. Otro comentario de Julio César Pérez ahondaba en ello.
La disciplina del QA es amplia, y aborda distintos niveles representados en la famosa pirámide del testing.
El ingeniero de QA puede trabajar en todas las capas, mientras que el testeo que realiza un Product Manager se centra en la cúspide de la pirámide, lo que se llamaría exploratorio, y principalmente centrado en las happy paths de los usuarios.
El objetivo del Product Manager con este testeo no es encontrar fallos en casos extremos, si no simplemente asegurarse de que el producto cumplirá las expectativas de los usuarios, como acertadamente apunta Julio César.
La calidad es responsabilidad de todo el equipo
Rizando más el rizo, la realidad es que la calidad no es ni mucho menos responsabilidad exclusiva del QA y del Product Manager. El entorno ideal, es aquel en que todo el equipo se responsabiliza de la calidad del producto que está desarrollando. Lo apuntaba Miguel Echávarri en Twitter:
Es lo que sucede en equipos con verdaderos ingenieros de producto. El primer responsable de la calidad es el ingeniero, y también debe ser el primero en validar que su desarrollo tiene la calidad adecuada. De esta forma, cuando llega al QA, este se puede dedicar a los casos excepcionales en lugar de perder el tiempo levantando fallos evidentes.
Esto es especialmente importante por acortar los tiempos de retroalimentación. Si un ingeniero deja en ready to test algo con fallos evidentes y se pone a hacer otra tarea, para cuando el QA lo revisa y los levanta, el ingeniero ya ha cambiado de contexto. Este toma y daca entre ingeniería y QA, el tiempo que se pierde entre revisiones, destruye la cadencia de cualquier equipo.
Esta es precisamente una de las mayores ventajas por las que creo interesante que Product Managers participen en esa fase exploratoria: para acelerar los ciclos de retroalimentación con el equipo de ingeniería. Si el QA se encuentra ocupado, y el PM puede pasar para descartar fallos evidentes, es tiempo que se ganará a la hora de poner el producto en manos de los usuarios.
Y quién dice Product Manager, también puede decir, Product Designer. Porque recordemos, la calidad es responsabilidad de todo el equipo.
En definitiva no creo que la comunidad de producto esté tan dividida como los resultados de la encuesta declaran. Probablemente todos convenimos en que el Product Manager, como parte del equipo, debe garantizar que el producto que vaya a poner en manos de sus clientes tendrá la calidad adecuada. Si bien eso tiene cierto solapamiento con las responsabilidades de un ingeniero de QA, estas son mucho más amplias y totalmente fuera del día a día de un Product Manager.
¿Podemos decir que hace QA entonces? Lo dejo a vuestra elección. Con que entendamos que debe participar de la misma, como cualquier otro miembro del equipo, me doy por satisfecho 🙂.
Muy interesante el artículo y el enfoque. Voy a generar un poco de debate en base a cómo he trabajado con equipos de QA.
Cuando se habla de QA creo que es importante diferenciar entre QA que bloquea el proceso de despliegue de nuevas funcionalidades, o un equipo de QA que mejora la calidad del producto (identificando y mejorando areas).
Por lo que no, un PM no tiene que hacer el QA de su producto.
Pero si que tiene que probar las funcionalidades, ¿no?
Si. Un PM tiene que probar la aplicación pero no con un enfoque de validación, si no con un enfoque de autoaprendizaje. Las pruebas deben ir con la pregunta ¿qué puedo hacer para mejorar el producto? no ¿está esto listo para desplegarse a producción?
Si el paso a producción recae sobre el PM, ¿qué accountability tiene el equipo de ingeniería?