Sigo la cadena con @sbastn para que tanto él en su podcast como yo en mi blog consigamos adquirir la costumbre de publicar cada semana.
Estaba esta semana acompañando a Ángel Díaz-Maroto (@adiazmaroto) en un curso para Dueños de Producto. Uno de los grupos se atascó en una historia de usuario y al comentarla entre nosotros surgió una pequeña discrepancia. Os cuento primero el escenario y luego las conclusiones a las que llegamos.
El problema
Pensad en un proceso de negocio tipo “solicitud de un duplicado de una tarjeta de crédito”. La primera historia de usuario que nos puede salir típicamente podría ser algo así como:
HU-1
Como cliente con tarjeta de crédito
Quiero un duplicado de la misma
Para sustituir la que acabo de perder
Lógicamente se trata de una épica, es decir, de una historia de usuario demasiado grande para ser abordada en una sola iteración por un equipo; por lo que no nos queda más remedio que buscar maneras de hacerla más pequeña. El grupo en cuestión decidió centrarse en una parte de ese gran proceso que va desde la solicitud hasta la llegada de la tarjeta al cliente. La historia que les salía era algo como:
HU-2
Como ¿¿¿????
Quiero que una solicitud de tarjeta duplicada inserte un registro en el fichero XYZ con el valor ABC
Para que el proceso batch de estampación incluya la tarjeta solicitada
Efectivamente, una historia con detalles muy técnicos y alejados de la necesidad original del cliente. Tan alejada del cliente que ni tan siquiera eran capaces de verlo como beneficiario de la misma. El grupo sabía que no estaba en la buena dirección y solicitó ayuda.
Mi consejo
Les sugerí pensar en la posibilidad de ofrecer valor a algún usuario responsable de controlar el proceso, en su totalidad o al menos en parte. Yo estaba pensando en algo muy parecido a esto:
HU-3
Como Responsable del Proceso de Duplicado de Tarjetas
Quiero conocer cada paso en el proceso de tratamiento de una solicitud de tarjeta duplicada
Para responder al cliente sobre el estado de su solicitud en cualquier momento
De esta manera el equipo que desarrollara esta historia tendría la obligación de garantizar que el proceso es auditable. También se podría así testear el proceso en su totalidad mediante la composición de pasos independientes y con diferentes grados de acabado. Incluso sería posible habilitar una migración hacia un proceso nuevo desde otro ya existente. Así, trabajando un poco la anterior (HU-3) podríamos llegar a una historia más concreta como la siguiente:
HU-4
Como Responsable del Proceso de Duplicado de Tarjetas
Quiero que se estampe la tarjeta solicitada
Para que pueda llegar hasta el domicilio del cliente que la ha solicitado
Lógicamente, en el criterio de aceptación de esta historia aparecerían detalles técnicos referidos a aquel proceso batch y posiblemente también al fichero XYZ al que se refería la HU-2, pero no son relevantes a efectos de la especificación sino a efectos de la implementación.
Customer centricity
Mi sugerencia provocó una conversación muy interesante con Ángel. Él defiende un enfoque plenamente centrado en el cliente, pero no ese “customer centricity” de Big Data, NFC, Responsive Design o Community Management, sino un enfoque menos orientado a vender glamour y más comprometido con el concepto, que exige a todos y cada uno de los departamentos y sus actividades que se centren en aportar valor al cliente. Esto deriva inmediatamente en que todas y cada una de las historias de usuario que escribamos deberían aportar valor al cliente. En este contexto, mi consejo no estaría colaborando con el planteamiento de Ángel para este curso interno sino más bien provocando el efecto contrario, es decir, que las historias tendieran a centrarse en los típicos usuarios internos y olvidarse del cliente. Sin embargo, fijaos que la diferencia entre un usuario interno centrado en sí mismo y otro centrado en el cliente es el Para.
Supongamos que en vez de la historia HU-3 hubieramos escrito algo como:
HU-5
Como Responsable del Proceso de Duplicado de Tarjetas
Quiero conocer cada paso en el proceso de tratamiento de una solicitud de tarjeta duplicada
Para saber si crecen o decrecen las solicitudes a lo largo del año
Espero que podáis apreciar cómo el cambio en el propósito de la historia (el Para) provoca que el sistema que vamos a construir será muy diferente porque tenderá a olvidarse del cliente. De hecho, en HU-5 ya ni siquiera aparece la palabra cliente.
Epílogo
Lo mejor de todo es que esta conversación nos duró a Ángel y a mí algo así como un minuto. No más. Lo juro. Para mí fue un aprendizaje muy interesante y además creo que viene a demostrar que entre agilistas es muy fácil alinearse. Eso sí, la conversación la extendimos, lógicamente, al resto de los asistentes al final de ese ejercicio. Y la discusión fue aún más interesante para mí porque sacó a la luz la educación taylorista que la mayoría hemos sufrido y de la que es tan difícil desprenderse. Esta educación nos lleva a la paradoja de pensar que las personas más adecuadas para tomar decisiones relacionadas con los clientes son aquellas que más lejos están de los mismos, por ejemplo, los Directores Generales. 🙂
Uno de los alumnos, empleado y emprendedor a partes iguales y reciente converso de las metodologías prescriptivas al agilismo, ponía un excelente ejemplo de este enfoque “customer centric” para escribir historias de usuario con una similar a ésta:
HU-6
Como cliente con problemas de liquidez
Quiero que el banco me rechaze la petición de mi crédito de 50000 euros
Para evitar tener problemas de impago
Este acercamiento al “rechazo de un crédito a un cliente de riesgo” me removió por dentro y reconozco que la palabra cinismo vino a mi mente por un momento, pero si eliminamos esa parte emocional, creo que este enfoque de escribir historias de usuario radicalmente centradas en el cliente me parece muy potente y merece la pena profundizar en él porque, sin duda, ayuda a alinear los productos y servicios con los clientes y con la gente que hace posible que los unos lleguen a los otros.