Hay una frase muy conocida, pero no por ello menos real que nunca debemos perder de vista. Esa frase es: el mapa no es el territorio. El sentido de la frase es que literalmente, si bien la teoría es correcta, su aplicación práctica va a diferir de esa teoría; o dicho de una forma más sencilla: las cosas en la teoría son de una forma y en la realidad de otra.
El sentido de la frase es el sentido de que aquello que nos vamos a encontrar no es una rayita en un mapa, sino algo más importante, algo real, algo que nos puede complicar mucho más de lo que pensábamos o incluso que nos va a evitar conseguir nuestros objetivos. Vamos a verlo con algunos ejemplos.
El primero es el propio origen de la frase o, por lo menos, el origen que más se le atribuye. Dicen que la primera persona que la dijo, Alfred Korzybski, la profirió durante la Primera Guerra Mundial, cuando junto con el grupo con el que iba cayeron en una profunda fosa sin previo aviso. ¿Cómo no sabían nada de ella? ¿Cómo no aparecía en los mapas? No aparecía porque el mapa no es el territorio.
De la misma forma, lo demostró Richard Feynman en su investigación del desastre del transbordador espacial Challenger en 1986, cuando a regañadientes asistió a la comisión que evaluaba el desastre por la insistencia de su esposa. Los mapas que revisaban el resto de los miembros de la comisión de investigación nunca hubieran mostrado el problema. Richard Feynman fue al territorio, a los lugares de los hechos, a entrevistar a las personas implicadas hasta que encontró el fallo en los anillos “O” de la cápsula espacial, demostrando con una prueba empírica cómo el comportamiento de dichos anillos en la teoría distaba de lo que sucedía en el territorio.
Así lo demostró también Taiichi Ohno en el desarrollo del Toyota Production System o Lean Manufacturing como se conocería en occidente y algo similar sucede con las Pruebas de Aceptación de Usuario o UAT de sus siglas en inglés dentro del desarrollo de software y de Apps en grandes compañías. La teoría dice que el usuario de negocio es el que debe realizarlas, es el que debe ejecutarlas para aceptar la entrega del producto software que le realiza el equipo de desarrollo, pero en la realidad, en el territorio, la situación cambia.
A tener en cuenta
Cambia porque en las grandes compañías nos encontramos con algunos factores importantes que deben tenerse en cuenta:
- Primero, el volumen de las UAT en dichas empresas es muy alto, se construye mucho software y se demandan sus pruebas para cerrar la entrega.
- Segundo, en grandes compañías, el número de apps interrelacionadas puede ser muy alto, teniéndose que utilizar varias de ellas para realizar una prueba completa que asegure que los sistemas siguen funcionando como antes de la entrega de software.
- Y tercero, puede haber distintos canales con sus interrelaciones que obligan a que el usuario de negocio tenga necesidad de conocer las distintas idiosincrasias de cada uno de ellos y de cómo afecta a la nueva entrega de producto que se está liberando.
En estos escenarios, el territorio exige que el usuario de negocio cuenta con ayuda. Una ayuda que debe materializarse como un equipo cross de UAT que adquiera conocimiento de negocio y realice las funciones del usuario. Este equipo permitirá ganar estabilidad y la eficacia del mapa en el territorio, trabajando en entornos predictivos o ágiles como una parte más del equipo de desarrollo o como un equipo especializado.
Recuerda que el mapa no es el territorio y tu empresa no se puede permitir fallar en las pruebas de aceptación de usuario: pon un equipo de UAT en tu vida y no lo lamentarás.
Julián Gómez
Responsable de Nuevas Tendencias de LEDAmc
