¿Alguna vez pensaron en lo difícil que puede llegar a ser el rol de Analista Funcional? ¿Se cuestionaron la capacidad de interpretación, pensamiento crítico, y buena comunicación que debe tener?
Cuando las cosas terminan mal, es porque se iniciaron mal…
¿Cuántos de ustedes jugaron de niños al teléfono descompuesto? Para aquellos que no lo conozcan, es el juego en el que un grupo de amig@s se coloca en fila, y el de un extremo le dice al oído una serie de palabras al que tiene a su lado, y así sucesivamente hasta llegar al último que tiene la tarea de repetir en voz alta la secuencia de palabras que le comunicaron. ¿El resultado? Risas, frustraciones y hasta algún enojo. ¿Qué es lo que había sucedido? Durante la cadena de interlocutores la comunicación se fue deformando al punto de que lo que dio origen a todo no era el resultado que se obtuvo. ¿El costo de este error? Relativamente bajo, porque se trata de un juego.
Ya de adultos, somos profesionales que desarrollamos software y es necesario que cada uno de los “interlocutores” tenga muy claro su rol y cómo mantener estable el flujo de la comunicación.
Inicié este post hablando de las capacidades que debe tener el Analista Funcional para entender, y sobre todo comprender, qué es lo que el Cliente necesita.
Sin duda, deberá ser una persona lo suficientemente curiosa como para ahondar, cuestionar y sugerir sobre esa idea que el cliente tiene. ¿Por qué? Porque es el primer responsable en que el edificio que se está erigiendo no se construya de manera torcida (se entiende la metáfora, ¿verdad?).
Desde este momento y hasta la fase final (no así en metodologías ágiles) es muy probable que no volvamos a saber de nuestro Cliente, recién lo volveremos a ver cuando hagamos el UAT (User Acceptance Testing). Claramente puede haber excepciones en donde se lo podrá contactar ante alguna eventualidad.
Ahora, cuando llevamos adelante un UAT con el Cliente (o en su caso, representado por un Usuario final) perseguimos un único objetivo que es la validación de la idoneidad para el uso de ese sistema que hemos construido. En otras palabras, que el software que le mostraremos es lo que él quiere y/o necesita.
En este preciso momento es donde el último interlocutor repetirá en voz alta el resultado de las palabras que le llegaron a su oído, este es el momento en donde el Usuario tomará contacto directo por primera vez con aquello que solicitó.
Sus ideas y pensamientos han cobrado forma y llegó el momento en que iniciará su validación.
Aquí es a dónde quería llegar…
Si ellos descubren que hay algo que no les gusta, ya sea que se trate de un problema real o no, que esté contenido dentro del alcance de la especificación o no, su postura frente al resto de la aplicación cambiará sustancialmente. Comenzarán a ver todo con otros ojos casi que desaprobando rápidamente todo el producto sólo con esa observación que hicieron. No tendrán ningún inconveniente en volver atrás, como por arte de magia, todo el desarrollo nuevamente a las fases de diseño. ¿El costo de este error? Relativamente alto.
Claramente para evitar este retroceso de llevar nuevamente el proyecto a etapas previas tenemos que trabajar en:
- La especificación creada por el Analista, que tiene que ser sumamente clara, detallada y reflejar casi que a la perfección las ideas del Cliente. Nuestra tarea como profesionales de calidad es trabajar analizando este documento, buscando ambigüedades, inconsistencias, y cuestionándonos cada línea escrita ahí. Como comentaba al inicio, estos son los cimientos de nuestro edificio.
- El Tester que acompaña el UAT debe ser una persona que tenga una habilidad especial en cuanto al trato con el Usuario, debe trabajar estrechamente con él, casi que tomándolo de la mano y guiándolo de manera entusiasta por la aplicación. Debe ser una persona con experiencia, respetada, y en lo posible, tener relacionamiento previo con el Cliente.
- El Tester debe ser centrado y objetivo. Si la aplicación claramente no cumple en absoluto con lo que el Cliente espera no deberá de “engatusarlo” convenciéndolo de que se libere de todas formas. De lo contrario, se comprarán todos un problema.
- Por último, el Tester debe ser buen negociador exponiendo al Usuario las contras y costos (tanto en tiempo como en dinero) de volver atrás la versión, mostrando, además, las virtudes y beneficios de liberarla. Tal vez, con algún pequeño bug que no revista riesgo alguno para los potenciales usuarios y aclarando que el mismo será corregido en próximos releases.
Es innegable que en el día a día de nuestro trabajo muchas veces no paramos para cuestionarnos en si lo que estamos construyendo es lo correcto, inmersos en un proceso de creación de software perdemos de vista el horizonte y simplemente navegamos creyendo que tenemos el rumbo correcto. Desafortunadamente, esto no se hace evidente hasta que llega el momento de hacer las Pruebas de Aceptación.
De nada sirve que creemos el alimento balanceado perfecto, presentado en un packaging idóneo, a un precio de mercado increíble, si cuando se lo damos a nuestra mascota no lo comerá.
0 comentarios