Manejar las expectativas del usuario que no quiere hacer pruebas finales del usuario

No hay una respuesta universal. Digamos que el usuario reporta un error ortográfico en una página web. "Dice teh donde debería decir el ". No detendría la implementación de esta solución única esperando que el usuario acepte que corrigió el error tipográfico.

Ahora, supongamos que el usuario pidió (como lo hizo uno de los míos una vez) que un botón fuera "dos tonos más claro de azul". Tiene sentido pedirles que confirmen que has adivinado correctamente qué diablos significa eso. Sin embargo, la redacción es clave aquí: "pruebe la corrección y apruébela" implica que no está seguro de haberlo hecho bien, y puede sonar un poco "depende de usted si algo sale mal más adelante". Un "puede decirme si le gusta el nuevo color" o "asegúrese de que eso es lo que quería" o incluso "asegúrese de que mi desarrollador lo entendió correctamente" no solo es más preciso, sino que contiene la explicación de por qué los desarrolladores preguntan para el trabajo de un cliente.

También debe asegurarse de que el cliente entienda que usted prueba su trabajo y que ha codificado lo que quería codificar. Lo que el cliente está probando es que entendiste la petición. Entonces te piden que agregues una columna a un informe y te olvidas de preguntar dónde la querían: cuando entregas dices "La agregué al final" o "La agregué al lado de la fecha del pedido" y luego les pides que confirmen Es correcto.

Claro, todo esto es "probar". Míralo y asegúrate de que te gusta. Para usar su analogía, si tomaste tu auto para que estuviera pintado de azul, no te irías en un auto rojo brillante sin decir nada. Entonces, para todo, excepto para emergencias absolutas, arreglas o agregas cosas nuevas, lo pones en escena para que lo vean y confirmen que está bien, luego lo pones en vivo. El uso de la frase " confirme que es bueno " hace mucho de lo que está buscando:

• contiene la suposición de que has hecho lo correcto. "Buscar errores" contiene la suposición de que hay errores
• no usa un verbo por el que el cliente le está pagando como "probar"
• no usa un verbo que ponga nervioso al cliente acerca de asumir la responsabilidad, como "aceptación"

A menudo agregamos detalles específicos a nuestras solicitudes de prueba. Confirme que el formato de la nueva columna es el que deseaba. Confirme que el desarrollador tomó la decisión correcta sobre el tamaño de fuente. Básicamente, cualquier decisión que tuvisteis que tomar vosotros mismos porque no se especificó, y por alguna razón no preguntasteis antes de hacerlo, díselo y pídeles que lo confirmen. Cualquier cosa que haya sido ambigua y no haya aclarado antes de codificar, indíquelo ahora.

¿Cuál es la mejor manera de gestionar las expectativas de este usuario?

Comprenda completamente el problema antes de solucionarlo y luego realice una prueba profesional.

No debe confiar en un usuario final para la prueba, debe ser realizada por un profesional que tenga un interés personal en asegurarse de que esté libre de errores antes del lanzamiento.

Debe presentar el paso de aceptación del usuario como algo que beneficia al cliente, no a usted.

Ha estado hablando de los beneficios para su empresa ("requerimos pruebas de usuario para confirmar que el cambio/error está funcionando como el usuario espera", "no podemos lanzar en vivo sin la validación del usuario"). No es sorprendente que el cliente sienta que está trabajando para usted. Esto, después de que (en su mente) no lograste satisfacer sus necesidades en primer lugar, ¡al lanzar algo que no era lo que querían!

Puede comenzar explicando que esta es una parte clave del proceso que los beneficia . ¡Imagínese cuánto peor sería si lanzara un "arreglo" y aún no estuviera arreglado, o funcionando de la manera que ellos querían! ¡Imagínate si accidentalmente lo hubieras empeorado !

Claramente hubo una falla en la comunicación que causó los errores en primer lugar. Si hubiera entendido perfectamente lo que querían, usted mismo habría probado perfectamente esas expectativas y lanzado algo que era... perfecto. Encontraron un error. Eso significa que cualquier proceso que tenga para que ellos soliciten una función y usted la proporcione, se perdió algo. No es sensato suponer que el proceso para informar el error y corregirlo no puede pasar por alto algo también. Lo más sensato es volver a comprobar: "creemos que ahora lo hemos hecho como querías, ¿es así?".

Esto es especialmente cierto si están pagando por alguno de estos cambios o correcciones. Esta es una oportunidad para que ellos se aseguren de que están obteniendo el valor de su dinero. Si liberas algo y aún no es lo que ellos quieren, tendrás que pasar por todo el proceso nuevamente y cargarlos nuevamente. ¿No sería mejor para ellos confirmar la solución antes de lanzarla, de modo que solo paguen una vez?

En cualquier caso, debe explicárseles como una oportunidad positiva para que tengan su opinión, no como una pérdida y una demanda de su tiempo sin ningún beneficio.

FWIW, creo que es una mala idea argumentar por analogía, como lo hacen otras respuestas, porque terminas hablando de algo que en realidad no es el problema del que deberías estar hablando. Aun así, si llevara mi automóvil para arreglar una llanta ponchada, echaría un vistazo a la llanta antes de partir, para asegurarme de que realmente parecía haber sido reparada. De lo contrario, si comencé a conducir y noté que estaba desinflado en el camino, el garaje podría decir que hicieron bien su trabajo y que la llanta nueva debe haberse desinflado después de que me fui.

Cuando lleva un automóvil a un garaje para que lo revisen, no se le pide que realice una prueba para asegurarse de que el automóvil esté funcionando.

Gracioso. Cuando llevo un automóvil a REPARACIÓN (y los cambios en el sitio web no son de servicio), que pueden incluir cosas que se encuentran en el servicio, como que los cojinetes de bolas de un neumático no son totalmente redondos...

...cada vez que eso sucedía cuando recogía el auto, en realidad me invitaban a una prueba de manejo con un representante del mecánico (representante como: trabajador de primera línea, ya que no hay tiros muy pequeños que separen al mecánico del cliente).

Su cliente parece pensar que los cambios en el sitio web están funcionando. Este no es el caso. El servicio sería parchear bibliotecas. Los cambios son similares a las reparaciones o actualizaciones de un automóvil. Y el surtido de que no se realiza una prueba de manejo en esos casos es rotundamente incorrecto o indica el uso de un taller mecánico de gama baja, en mi experiencia.

Deberías hablar con el cliente sobre eso. También sobre el hecho de que las actualizaciones al flujo de la interfaz de usuario de un sitio web pueden no funcionar de la manera que el cliente esperaba. No es que cometa un error, pero no puedo contar la cantidad de veces que una solicitud de cambio fue seguida por "ah, eso no funciona como esperaba", aunque el cambio fue exactamente lo que se ordenó. Detectar esto temprano es parte de un flujo de trabajo.

Te sugiero que hables con ellos y les expliques que su comparación es una falacia que apunta más hacia el uso de un taller de mecánica de gama baja ;)

Soy de la opinión de que no debería decirle al usuario que pruebe los errores que le señalaron, o las funciones que solicitó que usted o su empresa eligieron implementar, a menos que no pueda recrear el error en tu final por cualquier razón.

Cuando le informan un error, primero debe volver a crear el error antes de ir e implementar una solución, para que sepa que realmente solucionó el error ... Luego, cuando se implementa la corrección de errores, puede comunicarle al usuario que se ha implementado una solución.

Si solicitan una nueva función, usted o su empresa deben obtener todos los requisitos / expectativas por adelantado antes de que cualquier trabajo se dirija a la implementación real de la función. No adivinar a ciegas lo que quieren, implementarlo y luego pedirles que lo prueben por ti.

Usted dijo:

El problema es que seguimos un modelo que, a menos que un cambio/corrección de errores sea una emergencia o utilice procedimientos escritos estándar (por ejemplo, un cambio de parámetro estandarizado), requerimos pruebas/confirmaciones del usuario antes de que podamos publicar el cambio o la corrección de errores.

¿Por qué sigues ese modelo? ¿Qué requisitos/objetivos pretende alcanzar este modelo? ¿Quién lo instituyó?

Si la idea es brindar una oportunidad para que las partes interesadas verifiquen la solución, coloque un temporizador en el paso de verificación de partes interesadas y, si la parte interesada no ha verificado una solución (que usted haya probado) en 2 semanas, cierre el problema/elemento de trabajo como "completo".

Si la idea es delegar las pruebas a las partes interesadas, bueno, me imagino que necesitaría escalar esto en el organigrama ya que esta parte interesada en particular no parece creer que sus deberes laborales incluyen realizar las pruebas que usted quiere que hagan.

Si generalmente cree que está en la misma página que los reporteros de problemas en cuanto a los problemas que están informando, la estrategia de tiempo de espera parece ser el camino a seguir.

Cuando corrige un error (arregla el automóvil), debe verificar si la corrección se realizó correctamente. Por lo tanto, debe replicar el problema señalado por el cliente antes de comprometerse a solucionarlo.

Simple: las notas del cliente "Escucho un ruido adherido del motor", la solución del mecánico "Se agregó más aislamiento acústico para que el cliente no escuche nada del compartimiento del motor" es una mala solución. Si el mecánico replica cuándo y cómo el cliente escucha el ruido, puede identificar qué se debe cambiar/arreglar y confirmar que la solución eliminó el problema. Luego puede documentar la solución y evitar más acusaciones de los clientes si cambió el aceite y 3 días después el aire acondicionado dejó de funcionar.

Cuando un mecánico MODIFICA (cambia) el automóvil del cliente, el taller debe asegurarse de que el cliente sepa lo que hacen las modificaciones y cómo afectan la experiencia de conducción. Luego, antes de devolver el automóvil, deben asegurarse de que el automóvil funcione según lo previsto (no tiene sentido agregar turbo si quita la línea de combustible). Si el cambio interfiere con la arquitectura existente, el cliente debe saberlo antes de que el taller comience a trabajar: "Oye, el único turbo que encaja necesita un agujero en el capó, ¿quieres que lo hagamos?"

El cliente espera un "paquete". y confianza Entonces, cuando van a un servicio, no esperan que necesiten verificar si se cambió el aceite. O si las ruedas están equilibradas después del cambio de neumáticos. El taller podría decirle que necesita una alineación.

Trate la corrección de un error como un retiro. El cliente entra y espera que cambie una parte comprometida por una que funcione según lo previsto. Para no descubrir que cambiaste el brazo de control que desgasta los casquillos antes de tiempo pero no los casquillos.

¿Cuál es la mejor manera de administrar las expectativas de este usuario y aún así obtener las pruebas completadas o confirmadas por ellos?

Debe establecer las expectativas correctas para sus usuarios. Si la política de la empresa es como usted indicó:

requerimos la prueba/confirmación del usuario antes de que podamos publicar el cambio o corregir el error.

Luego, debe dejar en claro al usuario que su prueba es un requisito antes de comenzar a trabajar en su problema. Si hay alguna documentación que indique esta política, debe presentársela al usuario para que no piense que está siendo vago y no quiere probarse a sí mismo.

El problema fundamental parece estar relacionado con la política. Hablaría con su gerente, o con quien tenga la autoridad adecuada, para que esta política pueda reevaluarse y mejorarse para abordar mejor las correcciones de errores/cambios.

Cuando lleva un automóvil a un garaje para que lo revisen, no se le pide que realice una prueba para asegurarse de que el automóvil esté funcionando.

Eso es realmente cierto, un cliente puede tomar su software y decir que es bueno y ponerlo en producción, y después del tiempo de garantía, si lo hay, tendrá que pagar por todo lo que no haya verificado en las pruebas. Y es lo mismo con un garaje o un televisor. Si tiene un problema con él y no lo probó cuando lo recibió o dentro de los términos de la garantía, lo pagará.

No le digo que le responda así a su cliente, pero podría hacerle recordar los términos de su contrato, con la esperanza de que usted (o su equipo) no haya estropeado el contrato de mantenimiento.