¿Qué distancia te separa de tu usuario?

Hace tiempo me contaron la siguiente historia:

Érase una consultora que residía en Barcelona, y que decidió abrir oficina en Berlín para poder atender a un cliente. Este cliente contrató a la consultora para el desarrollo de un software. La consultora, para reducir costes, dispuso en Berlín solo de personas de negocio, realizando el desarrollo desde Barcelona. En Barcelona, suelen colaborar con una factoría de Sevilla que, a su vez, se apoya en una factoría chilena. Cada vez que los alemanes se comunicaban, los emails iban siendo redirigidos entre cada equipo hasta que un chileno los recibía. La distancia en la cadena de comunicación era tal que influyó en que el proyecto acabara siendo un desastre, lo que derivó en una demanda por parte del cliente. 

Este ejemplo es el más exagerado de los que he conocido en cuanto a deslocalización, y cómo sobre el papel parece que soporta un modelo, y el servicio real que se presta acaba siendo muy malo. 

¿Dónde está nuestro usuario?

En otras empresas, las áreas de negocio o marketing sí que tienen presente al usuario final y al mercado. Tratan de medirlo y tratan de proponer ideas que lleven a generar negocio (testAB, propuestas, escucha activa de cliente o formularios de satisfacción). Sin embargo, los desarrolladores muchas veces no tienen ese contacto ni ese conocimiento. Ellos son los encargados de generar ese valor, ¿de verdad podemos ayudar a usuarios sin conocerlos? 

Una vez estuve acompañando a un par de equipos en una organización semipública que se encargaba de hacer herramientas digitales para un colectivo. Lo curioso es que había personas de esa organización que llevaban más de diez años en ella, y nunca habían tratado con personas de ese colectivo. ¡Jamás! Por tanto, no sabían si su trabajo tenía sentido, si estaban haciendo un software que de verdad les fuera útil y que de verdad les ayuda. ¿Estamos maximizando valor cuando no podemos tratar con nuestros usuarios?

Un buen profesional del software no se debería dedicar a desarrollar software, debería solucionar problemas creando software. Por eso, el objetivo de Scrum no es hacer software (o lo que corresponda para contextos que no sean de software), es entregar valor. Y el valor debe ser para ese usuario receptor del software. Debemos descartar el alegrarnos por hacer componentes software que no use nadie, al igual que un arquitecto no se debe alegrar de hacer un puente muy bonito por el que no pase ningún coche. Jeff Sutherland llegaba incluso a afirmar que el desperdicio debería ser delito, el hacer cosas que nadie quiere.  

He estado trabajando en multitud de consultoras. En ellas, muchas veces es difícil tener ese contacto con el usuario por el contexto. Algunas situaciones que he vivido: te contratan áreas de tecnologías que no conocen a ese usuario, las áreas de negocio no conocen tampoco a ese usuario, o bien estamos deslocalizados… Estos son sólo algunos ejemplos. 

En esos casos, nos comunicamos a base de documentos y requisitos, y no medimos el valor entregado, solo velocidad y funcionalidades entregadas, sin saber el valor que estas generan. Estoy generalizando, lo se, pero parece que medir todo ese valor no es parte del Scrum Team sino del área de negocio. 

Quizás, por eso cuando se creó el manifiesto por el desarrollo ágil, se promovió que negocio y tecnología trabajaran juntos. Seguramente vieron una deficiencia entre las personas que creaban en valor y los receptores del mismo. 

Mentalidad de Producto

En el último año, he acompañado a dos equipos de producto digitales. El primero de ellos, ayudaba a entidades financieras en la recuperación de deuda. A pesar de ser un producto propio, el modelo de negocio se basaba en implantaciones cerradas en fecha y sin medición continua de valor. Es decir, el día X te entrego la implantación, a partir de ahí, es cosa vuestra. Una vez más, entraban en el paradigma de entregar un alcance cerrado en una fecha cerrada. ¿Qué nos aporta la agilidad aquí?

Sin embargo, en el segundo producto la cosa es diferente. Este producto genera los ingresos de toda la compañía, es esencial que funcionen porque de ello depende la supervivencia de la organización. Además, el modelo de negocio que utilizan me parece muy adecuado, si mi tecnología ayuda a mis clientes a ganar más, yo ganaré más. Por tanto, es vital entender al usuario para poder darle un buen servicio. En este contexto, la agilidad tiene mucho más sentido para mí, nos permite fallar pronto para pivotar cuánto ante en búsqueda de soluciones por las que paguen los clientes. 

De hecho, hemos visto que cierta parte de la organización quizás aún no asume que su papel es dar servicio y no hacer software. Parte del reto de la Transformación Agile es eso: reducir esa distancia y crear un entorno de customer centric real donde toda la organización gire en torno al usuario. 

Escribir historias de usuario versus entender al usuario

Una de las prácticas más extendidas en el mundo del desarrollo ágil son las Historias de Usuario. Las Historias de Usuario son una manera diferente (cultural) de trabajar con nuestros usuarios. Sin embargo, para equipos pocos maduros en agilidad, en ocasiones se utilizan las Historias de Usuario como una manera nueva de escribir los requisitos de usuario de siempre. Es más, acaban por utilizar el análisis funcional tradicional escrito en “formato historias” simplemente porque alguien les dijo que así serían más ágiles. 

Sin embargo, es mucho más que eso, es empatizar con el usuario, entenderlo, ponerse en sus zapatos y entender el problema y la necesidad que hay detrás. Cualquier experto en Historias de Usuario te dirá que parte del debate a la hora de escribir una historia, es estudiar cómo hace hoy ese trabajo el usuario. Es necesario entender su situación actual para entender cómo aportar valor con lo que le vamos a entregar. 

La cadena de comunicación, midamos la distancia 

Vamos a poner un ejemplo “completo” desde un cliente final, que se comunica con un usuario que utiliza nuestro software, hasta las personas que desarrollan el software. Imaginemos que estamos desarrollando un software para un alquiler de vehículos. Tenemos a nuestros clientes que interactúan con operarios que son los usuarios del software. Pintemos una cadena ejemplo que se da en algunas empresas: 

Imaginemos un cliente (A) que quiere alquilar un coche, por lo que se va a un mostrador y habla con un operario (B). Ese software no funciona bien y confunde las reservas, lo que provoca muchas quejas de los usuarios (B) porque afecta a los clientes (A). 

Tras muchas quejas, el responsable de reservas (C) traslada el problema al responsable de negocio (D). El responsable de negocio decide invertir en un proyecto para rehacer ese software de reservas, para lo que habla con la responsable de tecnología (E). La responsable firma un acuerdo con un proveedor, a través del responsable de ventas (F). Ese responsable traslada al Jefe de Proyectos (G) lo que se ha vendido. 

Este, a su vez, envía al Analista (H) a tomar requisitos y para ello, se reunirá con el responsable de negocio (D) ya que quiere ser él el que defina el nuevo software al ser parte de la estrategia de la compañía. Por último, el analista le cuenta al equipo (I) lo que tienen que hacer, y estos se apoyan en una factoría en otra ciudad (J) con la que tendrán que colaborar para sacar adelante este software. 

En total, tenemos 9 saltos de información. Las opciones de que el equipo que desarrolla el software entienda bien las necesidades son escasas; además, los tiempos de respuesta son muy lentos, seguramente optemos por desarrollar algo durante meses para ponerlo en producción sin garantizar qué es lo que nuestros usuarios necesitan y cómo afecta a los clientes. 

Mejorando con un equipo Scrum

Una vez introducido Scrum, cambiamos los equipos tradicionales por un Scrum Team. Si lo hacemos mal, el antiguo Jefe de Proyecto (G) será el Product Owner y el analista pasará a ser Product Owner Proxy (H) por lo que, en la práctica, estaremos en las mismas. 

Si queremos un cambio real, tendremos que introducir Scrum. Sin embargo, hay organizaciones que, a pesar de introducir Scrum, siguen estando muy lejos del usuario final. 

Imaginemos que hacemos Scrum, y que renunciamos a usar factorías para fomentar el cara-a-cara y evitar la comunicación por videoconferencia, etc. La nueva situación podría ser esta: 

A partir del cambio, ahora tendremos que el Product Owner (G) tratará con los comerciales (F) y trasladará toda la información que tenga al Development Team (H) y al Scrum Master (I).

Este tipo de situaciones siguen dejando muy lejos a las personas que generan el valor (Scrum Team G-H-I) del usuario(B) y del cliente(A). En total, sigue habiendo 6 saltos. Por tanto, aunque hemos mejorado nuestra capacidad de hacer software, no hemos mejorado nuestra capacidad de entregar valor, ya que no sabremos si es valor al no recibir el feedback directamente. Sólo con feedback de la persona que nos contrata (E) no es suficiente, podrá estar contenta, pero no sabemos si los usuarios ven utilidad en nuestro software. 

Lo curioso es que este modelo puede funcionar (al menos tentativamente). Una vez acompañé a un equipo que desarrolló un software para un banco durante dos años. El banco estaba contento porque se cumplieron plazos, el Product Owner (del banco) obtuvo el software y le permitió “destacar” dentro del banco, la consultora estaba feliz porque había obtenido un buen margen… ¡el problema vino porque el software no lo usaba nadie! Apenas tenía usuarios y uso, con métricas de valor se tendría que ver como un desastre, pero sin embargo todos lo percibían como un éxito. 

Reduciendo más aún la distancia

Si queremos abordar una transformación cultural para incorporar el desarrollo ágil, deberíamos acabar en un modelo parecido al siguiente: 

En este modelo, hemos suprimimos la externalización para reducir el tiempo de arranque y de comunicación. Podríamos haber puesto a la consultora a trabajar con el cliente (B) y con el usuario (A) directamente pero, desde luego, tendríamos que tener en cuenta el tiempo que tardamos entre que buscamos al proveedor, nos da precio, hacen análisis… ¡Las organizaciones ágiles intentan cambiar esto! Por tanto, decidimos que el equipo sea de la compañía que necesita el software y no lo externalizamos. 

El Scrum Team directamente colabora con el usuario (B) y, tiene cierta interacción con el cliente (C). De esta manera, la entrega de valor es más probable que ocurra al entender mejor el problema. Al ir entregando software, podríamos ver el impacto del mismo, y tomar decisiones con lo aprendido. 

Por último, el resto de la jerarquía de la organización pasarán a ser líderes servidores del Scrum Team. Podemos hablar de modelos sin managers, aunque, como mínimo, debe haber una madurez hacia un modelo de liderazgo basado en servir por encima del ordeno-y-mando. 

Conclusiones

En este modelo, cuando escribimos las Historias de Usuario sí que tendremos las necesidades más presentes sobre la mesa y podremos negociarlas. Podremos involucrar a los expertos en desarrollo (Dev Team) para que propongan soluciones a los problemas de los usuarios y no ser unos meros implementadores de lo que alguien escribió en Jira o en un Word. 

En total, solo hay un salto entre el usuario real y las personas que hacen el trabajo, hemos reducido enormemente la distancia con nuestros usuarios. 

Os animamos a hacer este ejercicio en vuestro equipo para saber si estáis tratando o no con el usuario y si estáis entendiendo o no al mismo. 

Y en tu organización…¿qué distancia te separa de tu usuario?