Sin Usuarios (Proxies de Usuario)

El ideal y la realidad

Idealmente, cuando se pretende desarrollar un software, debemos conversar con uno o más usuarios reales que forman parte del equipo de un cliente. Pero, la realidad tiene la mala costumbre de golpearnos a nostros y a Dilbert justo en la nariz y continuamente nos podemos encontrar en una de dos situaciones:

1. Tenemos como contactos primarios a personas que pretenden adivinar cómo un usuario final quiere que se comporte el software, cuando solo un usuario real lo sabe, y aun así tenemos acceso limitado a ellos o ningún acceso a ellos.
2. El producto es muy innovador y no tenemos un usuario real existente de antemano.

Desafortunadamente, a menudo es difícil obtener los usuarios que necesitamos. Por ejemplo, podríamos estar desarrollando un producto con usuarios en todo el país, pero no podemos traer uno (o más) de ellos con nosotros para escribir requerimientos o historias de usuario (user stories). O podríamos escribir software que se utilizará dentro de nuestra empresa, pero alguien nos dice que no podemos hablar con los usuarios.

Cuando no podemos obtener tantos usuarios como desearíamos para representar las diferentes perspectivas del producto, tenemos que recurrir a personas o recursos intermediarios, también conocidos como proxies de los usuarios o user proxies, que pueden no ser usuarios, pero que debemos incluir en el proyecto para ayudar a representar a los usuarios y así lidiar con las dos situaciones mencionadas.

Advertencia

Lo que diré a continuación en el resto de esta entrada puede ser polémico y está sujeto a mi experiencia personal pero también en base a publicaciones (que siempre pongo al final). En esta ocasión me enfocaré en aquello que caracteriza a cada tipo de proxy de usuario.

La selección de proxies de usuario puede ser crítica para lograr el éxito de un proyecto. La experiencia, motivos y posible agenda de los proxies de usuario debe considerarse. Un proxy de usuario involucrado en ventas tendrá una perspectiva completamente diferente a la de un experto de dominio. Es importante estar al tanto de estas diferencias, por lo que trataré de proporcionar una síntesis de lo que caracteriza a algunos.

Proxies:

Supervisores de usuarios finales

Cuando se intentan crear aplicaciones de uso interno es común que los mandos medios se muestren reacios a dar un acceso completo a los usuarios finales por una variedad de razones, por lo que es muy probable que usted como ingeniero de requerimientos, analista de negocios, product owner, etc., termine lidiando con supervisores o gerentes de los usuarios de su interés.

Hay que tener mucho cuidado cuando debemos tratar con estos proxies sobre todo en instituciones públicas muy burocratizadas, porque estas tienden a caer en malas prácticas que intentan minimizar, disimular u ocultar durante sus procesos y operación.

En otras ocasiones los supervisores de usuario interceden y quieren representar el rol de usuario porque creen que saben más que los usuarios reales.  Pero usualmente los gerentes o supervisores tienen patrones de uso diferentes a los usuarios. Usted deberá ser lo suficientemente hábil para “dar la vuelta” a este proxy y llegar tanto como sea posible a los usuarios finales sin ofender al supervisor. En la sección ¿Que hacer sin usuarios (o casi)? puede ver que hacer casos así.

Gerentes de desarrollo, supervisor de desarrollo, directores de desarrollo, líderes de desarrollo y similares

Este tipo de proxy es uno de las peores opciones, a menos que usted esté escribiendo software específicamente para este tipo de usuario. Incluso cuando las intenciones de este tipo de proxy a veces sean buenas, lo más probable es que este tipo de líder tenga sus propios intereses y priorice de manera diferente, los requerimientos o historias de usuario, a como lo haría un usuario final.

Esto sucede porque este rol tiende a querer acelerar la introducción de nuevas tecnologías, o en el peor de los casos, cuando se tiene mucha deuda técnica o una operación desorganizada, tratará de disminuir su carga de trabajo a la menor oportunidad.

Finalmente, los encargados de desarrollo no suelen tener experiencia como usuarios finales de la solución que se está construyendo y no son expertos del dominio de interés. Si un encargado de desarrollo es realmente un usuario final entonces considérelo un experto de dominio apropiado, de lo contrario le aconsejo evitar en lo posible usarlo como proxy.

Involucrados en ventas

El peligro de utilizar a personas involucradas en ventas como proxies, está en que estas usualmente tienden a querer cerrar una venta rápido y a como dé lugar, lo cual lleva a una visión distorsionada acerca de cómo un producto debe ser construido.

Si la persona en ventas, perdió la última venta por la carencia de una característica específica tenga por seguro que esa personas de ventas incluirá instantáneamente como requerimiento de alta prioridad a esa característica o funcionalidad. Otra situación común es que las persona en ventas, de acuerdo a la utilidad y comisión potencial de una venta específica, tienden a prometer demasiado incluso con poco conocimiento de otros dominios, con una visión de beneficio a corto plazo.

Una compañía que pone demasiado énfasis en ventas perdidas o por beneficios a corto plazo puede perder la pista de su visión y estrategias de largo plazo.

Sin embargo, las personas en ventas, pueden ser un gran conducto para llegar a usuarios finales y hay que usarlos de esa manera. Pídales que lo presenten con los clientes, acompáñelos a visitas de venta, a los shows y ferias de promoción, aprenda acerca de cómo se exhiben los productos o servicios de su organización y entonces hable con los usuarios.

Expertos de dominio

Los expertos de dominio, son aquellos que nos dan lo que llamamos la opinión de expertos, y pueden ser sumamente importantes debido al conocimiento que poseen en el área de nuestra aplicación. Desde luego algunos dominios son más complejos que otros.

Los expertos de dominio pueden ser grandes recursos, pero su utilidad es muy dependiente de si son usuarios actuales o antiguos usuarios del tipo de solución que estamos creando. Sabiendo esto hay que estar conscientes que este tipo de proxies nos pueden hacer crear aplicaciones dirigidas a su nivel de dominio, y si no se tiene cuidado podríamos caer en crear un software demasiado complejo para el nivel de nuestros usuarios reales.

Grupos de mercadeos (marketing)

Las personas o grupos enfocadas al mercadeo tienden a concentrarse más en el mercado o en nichos en si, más que en usuarios individuales, por lo que el resultado es que se concentran más en cantidades de funcionalidades que en la calidad de las mismas.

Pero no descartemos a nuestros amigos de marketing, en muchos casos nos pueden proveer de valiosa información de alto nivel que nos puede ayudar sobre todo a establecer prioridades relativas, pero no esperemos una visión detallada para nuestros requerimientos o historias de usuario.

Antiguos usuarios

Un antiguo usuario puede ser un gran proxy si su experiencia es reciente. Sin embargo, como sucede con otros proxies, hay que tener cuidado y considerar que los objetivos e incentivos de nuestro proxy se alineen con los del usuario final.

Clientes

Los clientes son los que toman la decisión de compra; ellos no son necesariamente usuarios finales del software. Es importante considerar los deseos de sus clientes porque ellos, no sus usuarios, son los que firman el cheque para comprar la solución, a menos que por supuesto, los usuarios finales y los clientes sean las mismas personas.

Las características de un producto como este deben ser suficientes para que los usuarios finales no griten demasiado fuerte; pero también deben ser aquellas que atraen al cliente que toma la decisión de compra.

Capacitadores y soporte técnico

Los capacitadores y el personal de soporte técnico pueden parecer opciones lógicas para utilizar como proxies de usuario. Pasan sus días hablando con verdaderos usuarios, por lo que seguramente deben saber lo que quieren los usuarios mismos ¿correcto?. Bueno, desafortunadamente si usa un capacitador como su proxy de usuario, terminará con un sistema, eso es sí, fácil de capacitar.

Del mismo modo, si utiliza a alguien de soporte técnico, terminará con un sistema que es muy compatible y fácil de soportar. Por ejemplo, alguien de soporte técnico puede dar baja prioridad a las funciones avanzadas que él anticipa que aumentarán el trabajo de  soporte.

Si bien la facilidad de capacitación y la compatibilidad son buenos objetivos, lo más probable es que no sean lo que un usuario final verdadero priorizaría.

Analistas de sistemas y analistas de negocio

Muchos analistas de negocios y sistemas hacen buenos proxies de usuario porque tienen un pie en el mundo de la tecnología y un pie en el dominio de los procesos y la operación. Un analista que puede equilibrar estos antecedentes y que se esfuerza en hablar con los usuarios reales suele ser un excelente usuario proxy.

Un problema que presenta algunos analistas es que prefieren pensar en un problema detectado en lugar de investigarlo para solucionarlo. Otro problema que he encontrado ocasionalmente es que tienden a pasar demasiado tiempo en las actividades de antemano de un proyecto.

¿Que hacer sin usuarios (o casi)?

Si el acceso a los usuarios es limitado

Cuando es necesario que el equipo trabaje con un proxy es importante ser muy rápido y establecer con los patrocinadores, el proxy y gerencia con suficiente autoridad, el hecho de que se requiere establecer un grupo pequeño “de avanzada” formado por usuarios reales, con el fin de evaluar cualquier iniciativas, teorías o suposiciones, y lograr conocimiento validado los más pronto posible.

Sea eficiente y transparente programando reuniones constantes de duración máxima establecida y a ritmo constante para facilitar las reuniones y minimizar los obstáculos externos, dejando muy claro desde el inicio que el objetivo es identificar, escribir y priorizar historias de usuario y requerimientos.

Si realmente no hay usuarios disponibles

Cuando realmente no hay un usuario disponible y debe recurrir a un proxy de usuario, una técnica valiosa es usar más de un proxy de usuario. Esto ayuda a reducir la probabilidad de construir un sistema que satisfaga solamente las necesidades de una persona. Cuando use más de un proxy de usuario, asegúrese de usar diferentes tipos de proxy. Por ejemplo, combine un experto de dominio con alguien de marketing en lugar de usar dos expertos de dominio.

Si está desarrollando un software que compita con otros productos comerciales, puede usar los productos de la competencia como fuente de algunas historias de usuario o requerimientos. ¿Qué características de los productos de la competencia se mencionan en las reseñas? ¿Qué características se discuten en los grupos de noticias en línea? ¿Se discuten las características porque son demasiado complejas de usar o porque son muy útiles?

Otra técnica que puede usar cuando trabaja con un proxy de usuario en lugar de usuarios reales, es lanzar el producto lo antes posible. Incluso si la versión se llama preliminar, beta, temprana, etc., trate de ponerla en manos de los usuarios lo más pronto posible e identificar inconsistencias entre lo pensando por su proxy de usuario y sus usuarios reales, así también obtendrá conocimiento validado. Incluso mejor, una vez que el software está en manos de uno o más de los primeros usuarios, usted ahora tiene una ruta de comunicación para esos usuarios reales y puede usar eso para hablar con ellos sobre las próximas funciones.

¿Puede hacerlo usted mismo?

Cuando no puede encontrar o acceder a un usuario real, evite caer en la trampa de pensar que conoce las mentes de sus usuarios y no necesita o puede ignorar a un proxy de usuario. Si bien cada tipo de proxy de usuario tiene algún tipo de inconveniente que lo hace menos deseable que un usuario real, la mayoría de los desarrolladores presentan aún más deficiencias para pretender ser un usuario real.

En general, los desarrolladores no tienen conocimiento de marketing que les permita comprender el valor relativo de las características, no tienen la misma cantidad de contacto con el cliente que los vendedores, no son expertos en el dominio, etc.

¿Conoce otro tipo de usuario?¿Tiene una opinión diferente de los proxies que se presentaron aquí?

Otros enlaces de interés:

El Origen Y Los Valores De Agile
El Enfoque del Equipo Agile
Planeación, Cono de Incertidumbre y Estimaciones en IT

Si quire saber más estos son algunos libros recomendables: