Oficina de historias de Usuario: meme instrumental

INTRODUCCIÓN

‘Oficina de Historias de Usuario’. Este es el tema del que partirá mi ponencia del próximo 8 de junio en ItSMF, un foro en el que se discutirá sobre Tecnología, DevOps, Agilismo y Servicios. Os recomiendo asistir a este evento no sólo por los destacados conferenciantes que tendrán protagonismo en la jornada, sino también por las interesantes sinergias entre responsables de tecnología que tendrán lugar. Además, tengo un par de sorpresas bajo la manga para aquellos que se acerquen a mi charla. Si te interesa te pongo en antecedentes. ¿De qué trata esto de ‘Oficina de Historias de Usuario’?

EL RETO

Las organizaciones se han dado cuenta de que no pueden trabajar como lo hacían. Empiezan a abandonarse las prácticas donde un proyecto se definía mal (por incapacidad o incluso voluntariamente para obtener más por menos de los proveedores), donde luego se dedicaban semanas a una negociación contractual a los proveedores más grandes (y cada vez más lejos) y posteriormente se descuidaba la ejecución (cual presentación de servicio) para descubrir meses después que no se cumplen las expectativas de funcionalidad o calidad: poco contacto con el usuario de negocio, poco acceso al código y pocas prácticas XP / DevOps.

Esto podría valer en tecnologías y negocios consolidados, pero “amigo” ahora han llegado las fintech, las startups, y los todopoderosos modelos de Spotify, Google, Amazon, etc. demostrando que sus sistemas dejan atrás a todos los que no cambian.

Entregar pronto, en ciclos de 2/3 semanas, hace que los equipos técnicos tengan que estar más alineados con las necesidades de negocio. También requiere que estén más cerca, físicamente incluso.

Pero cambiar es complicado y hay que ponérselo fácil a las personas y organizaciones.

Imaginad que se desea empezar a trabajar ágilmente, lo primero que tenemos que hacer es definir los proyectos más pequeños y empezar a construir lo antes posible para enseñárselo a los usuarios y obtener feedback temprano. Incluso para darnos cuenta que es una mala inversión y dejarla: falla rápido/falla barato.

Por tanto, hay que formar a las áreas de negocio y de tecnología para trabajar de otro modo. Es más, todos sabemos que el aprovechamiento de un curso es muy limitado, más aún cuando la gente tiene la mente en otro lugar, por la cantidad de tareas pendientes. En grupos pequeños o en áreas donde hay un héroe que se echa el problema a las espaldas (se forma y empuja) el problema es menor. Pero vamos a ponernos en un modo “normal” donde en las empresas hay de todo y tenemos que conseguir avanzar.

A ver si somos inteligentes facilitando el estado transitorio entendiendo donde estamos, empatizando con las personas y sus problemas y dándolas alternativas razonables para abordar el cambio.

EL ESTADO

Si empatizamos con un responsable de producto de una organización es una persona que ya tiene un modelo de trabajo, muchos productos en curso y su vida gobernada por una incesable agenda de reuniones. ¿ahora pretendemos que de un día para otro aprenda a?

• Definir un proyecto en base a historias.
• Dar cabida a otras áreas en la definición.
• Poner al cliente en el centro de la necesidad.
• Podar para hacer los proyectos más pequeños.
• Concretar a un nivel al que no está acostumbrado.
• Estar disponible para cuando la tecnología les requiera para dar una respuesta rápida.
• Aprobar acciones sin (la falsa) estimación total del coste.

Parece bastante complicado que puedan dedicar tiempo, aprender y aceptar del modelo.

Pero ahora vamos a ponernos en la perspectiva de tecnología. En muchas organizaciones el rol de jefe de proyecto de tecnología consiste en hacer de puente, a partir de un pliego escrito por negocio (en el que no han participado), como declaración de intenciones, con los proveedores que tienen casi todo el conocimiento y control de las plataformas. Se produce un ciclo: pliego mal definido, petición de oferta a proveedores, estimación cara, rebote a negocio para reducir ámbito, reducción del precio objetivo y asignación. Además, hay una tendencia a condicionar a negocio con lo que “se puede hacer”.

Tecnología propia no toca apenas código/sistemas y ha perdido habilidades técnicas, como todo lo que no se usa.

Ahora, si se desea que tecnología se integre con negocio y empiece a identificar y abordar chores (labores técnicas que se pueden anticipar), proponer alternativas menos costosas al mismo problema y empezar a construir de un modo temprano, sin que haya un pliego detallado sino un conjunto de historias a ejecutar por orden ¿tiene capacidad para poder hacer esta ejecución temprana o labores de investigación técnica?. Posiblemente no tenga ni los recursos (reducidos al mínimo internamente y sin un proveedor por no tener asignado el proyecto todavía) ni las capacidades.

Además, si te acostumbras a que los proveedores te hagan las tareas, hacerlas personalmente luego cuesta.

EL MODELO DE CAMBIO

Entonces ¿cómo hacemos para que la organización cambie de un modo gradual? Necesitamos que se adquiera el conocimiento y la práctica. Y sobre todo, necesitamos que nos den presupuesto para que alguien ayude a que esta transición no sea dolorosa.

Pues se me ha ocurrido un MEME instrumental que es fácil de vender a las organizaciones (dentro del modelo mental) y que puede ser una muy buena solución para resolver estos problemas: LA OFICINA DE HISTORIAS DE USUARIO.

Cada vez que se desee iniciar un nuevo proyecto estratégico, se le asigna una persona de la oficina de historias de usuario (perfil de coach agile) que está para encaminar el trabajo, es decir, no para solo «coachear», formar, recopilar información o reportar sino para hacer el primer trabajo de campo y resolver el problema de folio en blanco: manchándose la manos en resolver el proyecto.

A: Montar el equipo multidisciplinar y definir las responsabilidades: Se constituye en equipo para un nuevo proyecto: normalmente, con representantes de negocio (el PO), de operaciones, soporte, tecnología, un jefe de proyecto de toda la iniciativa y un responsable del proyecto desde tecnología. Posiblemente alguien más invitado en base al proyecto. Pero recordar, mucha gente es mucho gasto y muchas opiniones. El PO siempre tiene que tener un peso mayor. El jefe de proyecto luego tiene que ponerlo en marcha y tecnología es el único que puede estimar.

Podemos decir que aquí ya puede haber un problema, que la abuela fuma, ¿quién de toda esta gente tiene la responsabilidad de escribir las historias de usuario? Porque el product-owner es el responsable de priorizar y dar sentido al product-backlog pero ¿tiene que escribirlo todo? Te va a mandar cerca…

Además, sin práctica a la hora de hacerlo cuesta, se confunden historias con tareas y “da pereza”. Negocio percibe que no es su responsabilidad bajar a tanto detalle. También falta tiempo para detallar sistemáticamente.

Pues el representante de la oficina de historias (ROHU) se integra con ellos y hace el “primer trabajo sucio”. Después de dinamizar las reuniones se encargará de generar el esqueleto. Cuando ya hay una carcasa será relativamente fácil completar el trabajo (veremos cómo).

Una práctica que utilizamos es forzar a los miembros de la nueva iniciativa a imaginar que el sistema ya está construido y que nos explique como funcionaría. De este modo, nosotros vamos pintando en la pizarra un diagrama de procesos. De este modo, al no tener contexto profundo del negocio se ven obligados a explicarnos a muy alto nivel todos los pasos. Os sorprendería ver como cuando esto se hace, en la mente de todos los asistentes se fija este diagrama como referencia. ¡Por primera vez todos manejan la misma abstracción física!

B: Definir proyectos de futuro sin contaminarse pero avanzando. Pero además puede existir otro problema, en muchas organizaciones puede no desearse contaminar con el estado actual de una solución (as-is) el estado futuro al que se quiere ir (to-be) por lo que no se quiere que el equipo asignado al proyecto estudie la solución actual detalladamente para no ser continuista con el modelo. Aquí aparecen modelos como Design Thinking u otros.

Entonces, hasta que no se ha avanzado la conceptualización del nuevo proyecto no se estudia la solución actual. Esto crea un problema de eficiencia ¿tengo que esperar unas semanas para luego aterrizar la solución?

Pero ¿realmente son los proyectos tan sumamente disruptivos? Normalmente, y siguiendo la teoría de Kano (elementos imprescindibles, de valor linear o que sorprenden) diría que el 80 % de las nuevas funcionalidades pueden ser variaciones sobre lo que hay.

El ROHU puede hacer desde el primer día reingeniería del proyecto actual haciendo un User Story Mapping de la solución existente, de los componentes. Una iniciativa nueva claramente afectará a historias de usuario existentes y aportará algunas nuevas.

Sin afectar al proceso creativo del equipo asignado el ROHU se puede adelantar al trabajo de entender la solución actual e ir trazando este mapa que casi ninguna organización tiene: la relación entre iniciativas – componentes (las épicas que lo componen) y sistemas base.

C: Unir el as-is y el to-be y modelar el sistema visualmente: llegado al punto donde ya se ha conceptualizado la solución nueva de un modo poco contaminado, hacer el mapping entre el as-is y el to-be ya estará adelantado. No tiene sentido pararse a hacer un mapa de todo el sistema y sus dependencias. El modelo irá creciendo y definiendo el nivel de abstracción a medida que se va participando en más proyectos.

Haciendo este trabajo en distintas iniciativas en paralelo con distintos representantes de oficia de historias de usuario, coordinados entre ellos, se podrá empezar a hacer un mapa de dependencias, progresivo, entre iniciativas y componentes (épicas/temas que lo componen).

D: Identificar los retos técnicos de un modo temprano: A medida que se trabaja en un proyecto y en fases muy tempranas aparecerán chores/spikes o labores técnicas (seguras o pruebas de concepto) que se pueden identificar para adelantar a la propia ejecución del proyecto. Por ejemplo: si estamos pensando capturar más información de un cliente puede ser interesante investigar almacenarla de un modo menos estructurado y se hace necesario una prueba de concepto que se puede iniciar casi el día 1.

Ahora lo complicado es convencer a la organización que sin tener el pliego detallado, sin tener un presupuesto total, sin tener asignado un proveedor, tiene que haber gente en el departamento de tecnología que empiece a hacer una prueba técnica, acotada en tiempo, para determinar si la solución teórica aporta el valor que se espera de ella.

También se tiene que procurar que estas pruebas técnicas aporten valor a toda la organización (gobierno y gestión del conocimiento), evitando los silos, o lo que es peor, que se le page a un proveedor por hacerlo y no se interiorice el conocimiento.

Obviamente esto pasa por tener unos conocimientos técnicos avanzados. Parece lógico que si la tecnología es un valor diferencial para la organización hay que potenciar a los departamentos de arquitectura propios y que dejen de ser “arquitectos power-point” para que sean los que rascan código y cuentan con los proveedores para aprovisionarse de nuevo conocimiento no para simplemente hacer de dispatchers de presupuestos y tareas.

Parece que en este país, con estructuras “gerenciales” el valor del técnico se ha tirado por tierra. Fijaros en los perfiles de los lideres de las empresas de hoy: Facebook, Amazon, Tesla .. y de quién se rodean: de los mejores profesionales técnicos. Si no les copias en esto no les podrá copiar en lo demás.

La oficina de Historias de Usuario puede dar visibilidad a estas iniciativas técnicas y al nivel de independencia de proveedores. El equipo de historias de usuario puede ayudar a bajar para evaluar las prácticas XP y DevOps que se usan por debajo: Integración continua, TDD, pruebas unitarias, pruebas automatizadas, métricas de calidad, etc. ¿qué sentido tiene entregar funcionalidad más atómicamente si no se puede probar y entregar más rápido? Muchas organizaciones han perdido el camino.

E: Detallar las historias inminentes y retrasar las demás a medida que avanza el proyecto Cuando está definido el User Story Mapping, hay que detallar las historias. Las historias tienen 3 Cs, la Card, la Confirmación y la Conversación (el orden está así a propósito)

Primero hay que aprender a trabajar con historias más pequeñas y descomponer en elementos menos: “épicas pueden contener historias no prioritarias”. Esto ayudará a hacer los proyectos más pequeños. Existen al menos 10 patrones de descomposición de historias que el equipo debe manejar, a medida que avanza su aprendizaje.

Imaginemos que de las primeras 5 o 10 primeras historias (priorizadas) el ROHU escribe el detalle. De tal modo que ya tienen todos los miembros del equipo un ejemplo. Por ejemplo la confirmación se puede ejecutar con esta plantilla.

Si forzamos a que los equipos definan casos de éxito, de fracaso y fallo operativo, será fácil no dejar fuera escenarios reales. Por ejemplo, un escenario de éxito, en una web de compras es que el usuario hace un pedido y puede pagar bien. Un escenario de fracaso es que ha superado un límite de compra o la tarjeta no pasa. Un escenario de fallo operativo es que se le cobra dos veces el mismo pedido. Esto da lugar a que, desde el principio, se planteen conversaciones interesantes y aparezcan y descarten (voluntariamente historias)

Y con diagramas de secuencia (yo uso DSS de UML no formales) y mockups se puede detallar la conversación como secuencias de baja fidelidad (mejor dicho, encontrar conversación a través de descubrir secuencias). De este modo pensamos desde la perspectiva del cliente final e integramos UX. Podemos convertir a los diseñadores en analistas o conseguir que el PO baje de la abstracción al detalle: decir, píntamelo es una buena práctica, pero si antes le enseñas como se puede pintar en algunos casos.

¿Qué costaría, delante de un proyector, dirigido por el ROHU, empezar a escribir las siguientes historias en base a este patrón con los miembros del equipo de definición? Poco.

Primero se divide al equipo en dos y se ayuda a cada grupo a que asimilen la técnica. Luego, se descompone otra vez en dos. Se ayuda a los que le cueste más, que no todo el mundo tiene el mismo foco, tiempo ni capacidad. Después de unas cuantas horas todo el mundo tendrá la dinámica cogida y poco a poco se hará menos cuesta arriba el nuevo modelo. Si el ROHU se centra ya no en hacerlo todo (se hace colaborativamente) sino en matizar y ayudar a afinar, el trabajo es escalable.

F: Reducir el tamaño de lote, los silos y la comunicación por documento: no tiene ningún sentido dedicarse unas semanas a hacer un documento de historias para luego entregar otra vez un pliego entero y que tecnología te devuelva sus comentarios en bloque o te de una valoración conjunta. Tiene que co-crearse la definición detallada del proyecto como historias a medida que se está construyendo la solución.

Es decir, desde el principio del proyecto el equipo técnico trabaja en los Chores/Spikes, empieza a crear el entorno, trabaja en las primeras historias (detallando), se empieza de un modo temprano a montar el entorno DevOps y pruebas y a construir. En poco tiempo se lima el proceso.

Os puedo contar hasta como conseguir cuantificar el avance de la adopción de estas prácticas.

EL PROCESO DE DEFINIR LAS HISTORIAS

Una de las cosas más frustrantes que puede suceder a un equipo que se afronta a un nuevo modelo de trabajo es no saber donde está y que pasos tiene que dar.

Para hacerlo fácil podemos enseñarles un método concreto de hacer las cosas. Obviamente habrá muchos modos de descomponer un proyecto en historias, pero es casi preferible dar una única verdad, aunque sea temporalmente. Cuando la gente tenga ganas de estudiar y avancen empezarán a cuestionar el método o ver alternativas o variar pasos. En ese momento se podrán ampliar las alternativas y la formación.

A su vez, las historias tendrán un ciclo modelado en un Kanban: identificada, definida (3Cs), detallada por tecnología, valorada y ready. Nos vale este flujo u otro cualquiera. Recordad que menos es más. Demasiada consistencia en un principio es contra-producente.

Adicionalmente ES UN ATRASO TRABAJAR DIRECTAMENTE EN HERRAMIENTAS. En DOHO puede construir y ayudar a mantener paneles físicos. OS RECOMIENDO DURANTE LOS PRIMEROS MESES TRABAJAR LAS DINAMICAS SOBRE PANELES FÍSICOS. Si haces a negocio esclavo de las herramientas no conseguirás las adopciones.

Reporta, habla de los avances y discute sobre una pared y un panel.

Esta puede ser una labor de ROHU, incluso cuantificar el avance que supongo que veis sencillo, en cada una de las iniciativas.

CONCLUSIONES

La gente competente hace las cosas complejas sencillas. Cambiar una organización no es nada sencillo.

Los memes son palabras potentes que ayudan agrupar ideas complejas en conceptos sencillos y fácilmente extensibles. Ya me diréis que os parece el meme: OFICINA DE HISTORIAS DE USUARIO, y las prácticas que os cuento. Si os animáis a adoptarlo y si os es útil para transformar las organizaciones en que trabajéis.

Veréis que es un modo fácil para tener presencia en la organización entre negocio y tecnología y ayudarles a que racionalicen el modelo, a devolver valor al profesional técnico, tanto de conceptualización (UX+Design Thinking) como de modelado y facilitación (definir User Story Mapping y prácticas ágiles) y de desarrollo (Front-Back / DevOps). Las cosas bien hechas se hacen con pocos buenos profesionales no con muchos poco cualificados.