Manejar las expectativas del usuario que no quiere hacer pruebas finales del usuario
Tengo un usuario, de un departamento interno, que solicita muchos cambios o señala errores en el sitio web de nuestra empresa. Tenemos vínculos muy estrechos y fuertes, pero recientemente se han molestado por tener que probar estos cambios. Los consideran una pérdida de tiempo. Un correo electrónico reciente que recibí incluso tenía esta pequeña línea:
Cuando lleva un automóvil a un garaje para que lo reparen, no se le pide que lo pruebe para asegurarse de que el automóvil esté funcionando
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 que el usuario pruebe / confirme antes de poder publicar el cambio o la corrección de errores.
¿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?
Respuestas
No existe una respuesta universal. Digamos que el usuario informa un error ortográfico en una página web. "Dice teh donde debería decir el ". No retrasaría la implementación de esta única solución esperando que el usuario acepte que corrigió el error tipográfico.
Ahora, digamos que el usuario pidió (como lo hizo uno de los míos) que un botón sea "dos tonos más claro de azul". Tiene sentido pedirles que confirmen que ha adivinado correctamente lo que eso significa. Sin embargo, la redacción es clave aquí: "por favor, pruebe la solución y apruebe" implica que no está seguro de haberlo hecho bien, y puede sonar un poco "si algo sale mal más tarde, depende de usted". Un mensaje más amigable "¿puede avisarme si le gusta el nuevo color?" O "asegúrese de que sea lo que quería" o incluso "asegúrese de que mi desarrollador lo haya entendido 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 comprenda que prueba su trabajo y que ha codificado lo que pretendía codificar. Lo que el cliente está probando es que entendiste la solicitud. Entonces te piden que agregues una columna a un informe y te olvidas de preguntar dónde lo querían: cuando lo entregas, dices "Lo agregué al final" o "Lo agregué junto a la fecha del pedido" y luego les pides que confirmen. Es correcto.
Seguro, todo esto es "prueba". Míralo y asegúrate de que te guste. Para usar su analogía, si tomara su auto para que lo pintaran de azul, no se iría en un auto rojo brillante sin decir nada. Entonces, para todo, excepto las emergencias absolutas, usted hace la reparación o agrega las cosas nuevas, lo pone en escena para que lo vean y confirmen que es bueno, luego lo pone en vivo. El uso de la frase " confirme que es bueno " hace mucho de lo que está buscando:
- contiene la suposición de que ha hecho lo correcto. "Buscar errores" contiene la suposición de que hay errores
- no usa un verbo que el cliente te paga por hacer como "prueba"
- no utiliza un verbo que ponga nervioso al cliente al asumir responsabilidades, 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 tuvieran que tomar ustedes mismos porque no estaba especificada, y por alguna razón no preguntó antes de hacerlo, dígales eso y pídales que confirmen. Cualquier cosa que sea ambigua y que no haya aclarado antes de codificar, indíquelo ahora.
¿Cuál es la mejor forma de gestionar las expectativas de este usuario?
Comprenda completamente el problema antes de solucionarlo y luego pruébelo profesionalmente.
No debe confiar en un usuario final para la prueba, debe realizarla 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 que el usuario realice pruebas para confirmar que el cambio / error está funcionando como el usuario espera", "no podemos publicar en vivo sin la validación del usuario"). No es de extrañar que el cliente sienta que está haciendo un trabajo para usted. Esto, después (en su mente) de que no pudiste abordar 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 beneficia a ellos . ¡Imagínese lo peor que sería si lanzara una "solución" y aún no estuviera arreglada, o funcionara de la manera que ellos querían! ¡Imagínese si lo hubiera empeorado accidentalmente !
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 habría lanzado algo que era ... perfecto. Encontraron un error. Eso significa que cualquier proceso que tenga para que soliciten una función y usted la proporcione, se perdió algo. No es sensato asumir que el proceso para informar el error y solucionarlo no puede perderse algo también. Lo sensato es volver a verificar: "creemos que lo hemos hecho como usted quería, ¿es correcto?".
Esto es especialmente cierto si están pagando por alguno de estos cambios o correcciones. Esta es una oportunidad para que se aseguren de que están obteniendo el valor de su dinero. Si libera algo y aún no es lo que quieren, tendrá que pasar por todo el proceso nuevamente y cargarlos nuevamente. ¿No sería mejor para ellos confirmar la solución antes del lanzamiento, para que solo paguen una vez?
En cualquier caso, se les debe explicar como una oportunidad positiva para que tengan su aporte, no como un drenaje 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 llevo mi auto para arreglar una llanta pinchada, le echaría un vistazo a la llanta antes de arrancar, para asegurarme de que realmente parece haber sido reparada. De lo contrario, si comencé a conducir y noté que estaba desinflado en el camino, el taller 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 reparen, no se le pide que lo pruebe para asegurarse de que el automóvil esté funcionando
Ah, gracioso. Cuando llevo un automóvil a una REPARACIÓN (y los cambios en el sitio web no son servicio), lo que puede incluir cosas que se encuentran en el servicio, como que los rodamientos de bolas de una llanta no sean totalmente redondos ...
... cada vez que eso sucedía cuando recogía el auto, en realidad me pedían que hiciera una prueba de manejo con un representante del mecánico (representante como: trabajador de primera línea, ya que no hay pequeños disparos que separan a los mecánicos 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 la variedad de que no se realiza ninguna prueba de manejo en esos casos es rotundamente errónea o indica el uso de un taller de mecánica de gama baja, en mi experiencia.
Debería 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 de "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 han solicitado que usted o su empresa eligieron implementar, a menos que no pueda recrear el error en tu fin por la razón que sea.
Cuando te informan de un error, primero debes recrear el error antes de implementar una solución, para que sepas que realmente corrigiste el error ... Luego, cuando se implemente esa corrección de errores, puedes 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 se lleve a cabo cualquier trabajo para implementar la función. No adivinar ciegamente lo que quieren, implementarlo y luego pedirles que lo prueben por usted.
Tu dijiste:
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 que el usuario pruebe / confirme antes de poder 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, ponga un temporizador en el paso de verificación de las partes interesadas y si la parte interesada no ha verificado una solución (que usted ha probado) en 2 semanas, cierre el problema / elemento de trabajo como "completar".
Si la idea es delegar las pruebas a las partes interesadas, bueno, 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 desea que hagan.
Si, en general, cree que está en sintonía con los informantes de problemas en cuanto a los problemas que están informando, la estrategia de tiempo de espera parece ser el camino a seguir.