Sumario

Debate iniciado en el grupo de discusión TESTING & QA, comunidad de testers dentro de la red LinkedIn, para discutir la forma más adecuada de comunicarse con el usuario final. Título del Debate: Adoptar el lenguaje del usuario final.

Usuario Final

El siguiente es un debate publicado desde el grupo de discusión TESTING & QA de la red LinkedIn, te invito a que te unas para participar no solo de los diferentes debates que se encuentran activos, sino además de encuestas, estadísticas, promociones, ofertas laborales y encuentros virtuales.

Muchas veces imagino que alguno de nosotros nos hemos preguntado cuando se ha entregado el desarrollo de un evolutivo o una modificación sobre la anomalía detectada testeada por nosotros y conforme de acuerdo con las especificaciones que nos fueran entregadas inicialmente, si los usuarios finales se sienten satisfechos, ya que en definitiva será la persona (o grupo de personas claves y que entienden del negocio) que comprobará que los errores que ellos encontraron, ya no están más (o por lo menos, la mayor cantidad se ha solucionado)

Creo que muchas veces varios de nosotros perdermos la dimensión del impacto que tiene nuestra tarea al estar tan enfocados en la parte técnica.

Ahora bien, también pueden presentarse ciertas situaciones que hacen que nos hagamos algunas de las siguientes preguntas (¿o me van a decir que lo han vivido?):

-¿Cómo es posible que el usuario final me envíe este email?
-¿Acaso el entregable no responde a sus expectativas?
-¿Me pregunta cosas que debería saberlas mejor que yo?
-La pantalla y la navegación por ella es como la pidió, ¿Porqué pregunta cosas que están en la especificación?
-Esta levantando bugs que no son críticos ni cancelatorios, ¿Acaso no se da cuenta de ello?
-¿No se da cuenta que esta probando mal la solución entregada? Ese flujo no estaba contemplado dentro de esta entrega
-¿Porqué pusieron a ese usuario a probar si no conoce la aplicación?
-Me esta haciendo preguntas que están contenidas en el manual que le envié, esta más que claro!
-No tengo tiempo para atender al usuario, lo que le escribí es más que suficiente y se entiende perfectamente!!

Definitivamente, muchas de estas situaciones se remediarían si fuéramos capaces de ‘hablar el mismo idioma que nuestros usuarios finales’, es más, hasta incluso podríamos sacar provecho de ello y ganarlos como aliados, eso podría estar influyendo positivamente sobre el proyecto ya que la comunicación mejoraría y por ende, también la calidad de nuestras entregas.

En muchas ocasiones hasta me he puesto a pensar que deberíamos evitar hablar y/o mandar emails con palabras muy técnicas porque de lo contrario no obtendremos la respuesta que estamos esperando de nuestros usuarios finales.

Si bien hoy en día, los usuarios finales se están capacitando mucho, no quita que tratemos de acercar nuestro lenguaje al de ellos.

El usuario final no tiene porqué saber de los aspectos técnicos del proyecto, eso lo deberíamos dejar para el área técnica del usuario final.

No hay que olvidar que el usuario final es el que tiene que convivir con el día a día del aplicativo y la atención sobre sus respectivos usuarios finales, que le estarán generando otra problemática similar a la nuestra.

Por supuesto que tendríamos que hallar las formas de acceder al usuario final de la mejor manera posible y con todo el arsenal posible de herramientas para que entienda y sea capacitado rápidamente en función a sus tiempos y necesidades.

Todos estos comentarios surgen a partir de haber leído desde el blog jummp, el artículo “Desarrollo de software. La valoración del usuario de la calidad del software”, aquí les dejo una parte del mismo con la intención de que si les interesa, puedan acceder a él para leer el resto.

“… El usuario va a evaluar si sus expectativas se encuentran satisfechas: que la aplicación cumpla su propósito y que su experiencia en el uso de la misma sea buena (en términos de manejo, productividad de uso y que el número y naturaleza de errores que se encuentre es reducido (o inexistente) y que no le bloquea o afecta al trabajo).

Resulta complicado que el usuario entienda, por ejemplo, que el software que has desarrollado tiene una deuda técnica baja o que el framework en el que has basado los trabajos sea el más adecuado a la naturaleza del producto que se implementado.

Como he comentado en repetidas ocasiones en el blog, si quieres que te entiendan y que tu mensaje llegue al destinatario hay que adaptar el lenguaje al interlocutor. …”

Fuente: Blog Jummp. Desarrollo de software. La valoración del usuario de la calidad del software

Comentario 1
Asi es. Una de las habilidades que debe tener el Analista es comunicarse en el idioma en que hablan sus interlocutores, sea el Usuario o el Equipo de Desarrollo.

Comentario 2
Es verdad, deben usar el mismo lenguaje del negocio que están analizando. Saludos cordiales

Comentario 3
La comunicación es fundamental para establecer buenas relaciones con los usuarios finales, sin embargo, esta se ve afectada ya requiere del entendimiento mutuo.

La comunicación es eficaz solo cuando el usuario entiende el mensaje que queremos darle, en los términos en que hemos querido dar el mensaje. Atentan contra una buena comunicación factores tales como, diferencias culturales, métodos de comunicación, lenguaje y diferencias de percepciones de cada persona.

Se logra una comunicación verdadera si estamos interesados e interiorisados en el lenguaje de los usuarios, de tal forma que este se puede expresar libre y sinceramente, si escuchamos atentamente y observamos con conciencia y somos capaces de ponernos en el lugar del otro. Solo entonces estaremos estableciendo las bases de una buena comunicación.

Yo lo simplificaria diciendo que mientras más contacto, participación y relación tengamos con los usuarios obtendremos no solo mayor eficiencia en nuestro trabajo sino que el producto final sera acorde a las espectativas. El ida y vuelta con el usuario enriquece al analista y su tarea.

Comentario 4
Gustavo y demás colegas,

Por supuesto, la comunicación efectiva entre dos o más personas o grupos de personas ocurre cuando el receptor interpreta el mensaje en el sentido que pretende el emisor. Para ello es importante que el emisor, en este caso, el Analista del Sistema, tenga ciertas habilidades entre las que se cuentan: ser buen entrevistador, ser buen escritor (técnico), saber realizar procesos de abstracción y, en general, ser buen comunicador. Algunas de estas artes son potenciadas por la comunicación social y por la ingeniería del conocimiento, otras simplemente se adquieren con la praxis.

Conocer el lenguaje y la palabra, materia prima de todo escritor y nutriente de la gramática y el estilo, reduce los problemas de comunicación en cualquier entorno. Así como es imprescindible para cualquier Ingeniero de Software conocer al detalle lenguajes de modelado como UML o lenguajes de programación como C#, Java o PHP, es fundamental tener un buen conocimiento del idioma español para transmitir mejor las ideas y los artefactos que elaboramos durante el ciclo de vida del software.

De eso se trata un manual de redacción que estoy escribiendo y cuyo primer capítulo lo encuentran, haciendo clic AQUI

Salud@s,