Si se encuentra un error en un producto, ¿cuánto tiene la culpa del gerente de producto?

Seguramente no es una pregunta para la definición de un error, pero para dar una respuesta tengo que ejemplificar.

Consideremos que hay una necesidad de usuario (historia) de la siguiente manera:

“El usuario quiere hacer clic en un botón para ver una cuenta regresiva en la pantalla de 10 a 5 (opcionalmente con un motivo adicional 🙂 solo porque el usuario disfruta viendo números entre 10 y 5”.

Aquí, si hacer clic en el botón finaliza con una cuenta regresiva de 9 a 5 … o si el usuario hizo clic en el botón, la cuenta regresiva comenzó desde 10 pero se bloqueó a las 7 … entonces estos son desajustes de funcionalidad y error …
Aquí, no hay absolutamente nada que culpar al Gerente de Producto
El desarrollador debe trabajar duro para crear un botón simple en cualquier lugar de la pantalla y una cuenta regresiva después de hacer clic en él, nuevamente sin nada especial, excepto números del 10 al 5 de la manera estándar: un paso a la vez.

No se puede culpar al Gerente de Producto aquí porque su responsabilidad es (si los problemas de análisis y diseño están en los hombros del PM como en las startups comunes) comprender / prever por qué y qué necesita el cliente aquí.
(S) tiene que indicar lo que se necesita para una cuenta regresiva, desde qué (10) hasta qué (5) y por qué. ¿Qué más se debe incluir en el flujo del proceso? es decir. ¿Hay algo necesario después de hacer clic en el primer botón y antes de que comience la cuenta regresiva? ¿Es posible que el cliente necesite otra cuenta regresiva en el futuro, o la necesitará una cuenta regresiva hasta 0 ..?

Se puede culpar al gerente de producto por no ser tan visionario en la definición de requisitos / características, se puede culpar por la falta de suficiente conocimiento de dominio, se puede culpar por no definir los requisitos tan bien (color de botón, tamaño de botón, tamaño de paso de cuenta regresiva, posición del módulo en la pantalla, etc.).

Pero no se debe culpar por un error.

Si el cliente dice “no está contando desde 10”.
Culpa al desarrollador.
Si el cliente dice “está haciendo una cuenta regresiva de 10 a 5 paso a paso, pero mientras hablamos odio los números impares (9,7,5) entre ellos”.
Culpa al gerente de producto.

Sin embargo, ser de corazón cálido es lo mejor … así que trata de no culpar a nadie 🙂

No consideraría los errores como una cuestión de culpar. El software solo tiene errores y nada es perfecto. Mirarlo desde una perspectiva de evolución y darse cuenta de que no es perfecto es un paso importante para mejorar el software.

No puedo decirte la cantidad de veces que hemos tenido errores en nuestro software en Sqwiggle. Es algo con lo que tienes que lidiar. La clave aquí es tratarlo de manera efectiva y brindarle al cliente una gran experiencia en el proceso. Pida disculpas por el error y dígale al cliente que debido a que lo enviaron, solucionaremos el problema lo más rápido posible. Darle al cliente la satisfacción de haber tenido influencia en el software es una excelente manera de construir relaciones con el cliente. Si lo planifica correctamente, los errores se pueden usar como un activo porque cuando el cliente vea que usted solucionó el error exacto que tenían, elogiará su servicio al cliente.

Los errores están en todas partes, solo aprende a aplastarlos lo más rápido posible.