¿Y dónde está el Piloto? (Pruebas y Prototipos)

share on:
piloto

Una buena práctica que teníamos en el Programa Workflows era la de hacer pruebas Piloto (o le llamábamos también Prototipo). En particular porque. Después de varios años y muchos proyectos, aprendimos que nuestro talón de Aquiles eran la Interfaces de Usuario (las pantallas, los colores, la UI). Aunque el código y todos los demás artefactos funcionaran, el cliente de turno se quejaba – por ejemplo – de los colores, o de la foto que elegimos, o el tipo de letra, etc.

Según nuestro análisis, el 70% de los problemas venían precisamente de problemas en la percepción del usuario. Trabajar con la India no fue positivo en ese aspecto (lo hubiera sido igualmente con cualquier otro país no anglosajón). Los errores ortográficos eran frecuentes.

En conclusión, un buen día decidimos intentar hacer pruebas piloto de las pantallas. Hacer interfaces o pantallas de corta-pega, de mentiras, usando el photoshop, y luego alguna herramienta de mockups (buscar en google, hay muchas). Así, el cliente podía visualizar desde temprano lo que la solución iba a “mostrar”.

Para muchos de nuestros clientes, el “sistema” que les entregamos es lo que ellos ven. No lo que está debajo del capó. Mi madre llegó a elegir un coche porque tenía porta-vasos para todos los pasajeros. Y quiero suponer que mi esposa me eligió por mis pintas de actor de Hollywood. Todo entra primero por los ojos. Cuanto antes aprendamos esto, mejor nos irá en esta profesión.

Luego íbamos integrando funcionalidades importantes a ese Prototipo o Piloto, los webservices, conexión a las bases de datos, etc. Hasta que el “Piloto” empezaba a tomar vida propia. Si no funcionaba de esa forma, le dejábamos la aplicación de pruebas al cliente para que se tome el trabajo de listar todos los cambios que quería. Así nosotros seguíamos trabajando en otra cosa.

Pero de tanto en tanto, la cosa salía mal. En alguna ocasión el cliente se sintió tan defraudado por lo propuesto en el Prototipo que decidió cancelar el proyecto y buscar otra alternativa. En particular cuando les explicábamos que había limitaciones técnicas que impedían que… digamos… pueda manejar el microondas con el control de la tele.

En esos casos nos sentíamos frustrados. A veces era nuestra culpa, por sobre producir algo cuando el cliente esperaba algo más simple, o por hacer parecer muy sencillo algo que el cliente veía como un proceso de negocio muy complicado. Muchas otras veces era por culpa del cliente, que aunque siempre tiene la razón, a veces no la tiene – no sé si me explico.

Después de esas primeras “derrotas” nos empezamos a dar cuenta que el hecho de perder alguno de esos proyectos era algo positivo. De entrada se podía ver que las Partes Interesadas (el cliente, los stakeholders) no serían tipos fáciles e iban a desgastar el proyecto si empezábamos con el mal pie. A veces el cliente volvía a nosotros después de un tiempo con los requerimientos más normalizados.

No nos olvidemos que el porcentaje de éxito de los proyectos en IT anda alrededor del 30%. Parece bajo, pero es un valor alto comparado con las pruebas de drogas nuevas en medicina, por ejemplo, que no debe llegar ni al 5%. Y ellos tan contentos. ¿Por qué?

Porque lo que nosotros definimos como éxito del proyecto es que nuestro sistema sea utilizado en Producción, que superemos las expectativas del cliente y estemos en implantación o soporte. ¿Pero qué pasaría si re-definimos nuestro criterio de éxito a determinar – en primer lugar – si el producto que nos proponen debería llegar al usuario final? ¿Y si dijéramos que el éxito para nosotros consiste en poder determinar si un proyecto es viable o no? ¿Y las consecuencias de un mal proyecto en nuestro equipo? Seguramente tendríamos mucho más motivos para ser positivos. Hay veces hay que saber elegir lo que uno va a hacer, aunque no siempre nos podemos dar el lujo.

De ahí la importancia de utilizar Pruebas de Concepto, Pilotos y Prototipos en nuestros proyectos, sin importar la metodología que usemos. Es una buena práctica hacerlo. La idea es enfrentarse a los aspectos más preocupantes de un proyecto de entrada, y empezar por lo más difícil. Y así tener la oportunidad de dar un paso al costado y “no quemarse” por un requerimiento desproporcionado.

share on: