U de Usuaria

Todo software tiene al menos una usuaria a la que servir. Por tanto, diseñamos y construimos software para servir a esas usuarias, pero no solo para ellas. No siempre coinciden las figuras de usuarias y clientes, aunque es frecuente utilizarlas de forma indistinta. Simplificando mucho, diríamos que cliente es quien paga por nuestro producto o servicio. A veces, cliente y usuaria son las mismas personas, a veces son diferentes.

Así, por ejemplo, hay ocasiones en las que la persona usuaria de nuestro software no es nuestra cliente. Imagina que la aplicación en la que trabajas es usada por el departamento de atención telefónica de la empresa. O bien nuestro cliente puede ser una compañía, y las usuarias son sus empleadas. O, por descontado, puede que nuestro producto sea utilizado por nuestras clientes directamente. Se pueden dar muchas combinaciones.

Pero en realidad, en todos estos casos, hay más grupos que son clientes de nuestro equipo en mayor o menor grado. En ocasiones abarcamos todos estos grupos con el término stakeholders, palabra que viene a denominar a toda persona que tiene algún interés en nuestro producto y que puede tener algo que decir sobre él, lo que nos incluye. Claro que cada una de ellas tiene un interés diferente que se manifiesta en distinto grado.

Este es un aspecto que, a veces, se olvida. Es decir, el equipo de desarrollo tiene que atender distintas demandas que no siempre están perfectamente alineadas.

Las usuarias del producto estarán especialmente interesadas en que funcione bien, que sea fácil de entender y utilizar, que les permita realizar sus objetivos con la mayor eficacia posible. Son las que van a lidiar con ese diseño de interfaz, o con el tiempo que tarda en ejecutarse alguna acción, o con un defecto que genera resultados inadecuados.

Si clientes y usuarias no son las mismas personas entran otras consideraciones en juego. La decisión de optar por nuestro producto la realizan personas diferentes a las que lo van a utilizar, con otras prioridades. Las clientes pueden estar más preocupadas por el precio, la posibilidad de recibir soporte o la política de actualizaciones. ¿Y si son distintos clientes con distintas demandas?

Además de clientes y usuarias como destinatarias del software, tenemos que atender intereses internos a nuestra empresa. Si desde el punto de vista del agilismo lo que buscamos es una entrega de valor sostenible, podemos encontramos con limitaciones derivadas de los intereses y estrategias de la empresa. Creo que nos hacemos una idea de la complejidad que esto supone, no tanto de implementación, como de toma de decisiones: la forma en que introduzcamos una prestación beneficiosa para las usuarias puede depender de la forma en que la explotaremos comercialmente.

Atendiendo a la arquitectura de nuestros sistemas, también podemos tener que dar soporte a clientes internos por razones más técnicas. En entornos de micro servicios, es frecuente que un equipo deje de ostentar el ownership completo de un producto, siendo responsable de una parte exponiendo servicios a otras, o bien consumiendo.

Todo esto conlleva una complejidad en la toma de decisiones. Debemos atender muchos intereses diversos, no necesariamente contrapuestos, para lo cual tendremos que saber encontrar un equilibrio. Esto supone, como desarrolladoras, aspirar a tener una visión de conjunto. No podemos limitarnos al contexto reducido de nuestro producto o equipo, sino entender muy bien su rol y posición dentro de la estrategia general del negocio.

Como recalcamos en otras partes de este libro: como desarrolladoras, la parte técnica es solo un elemento más de nuestro trabajo, que debemos poner al servicio de todas nuestras clientes.