Juegos en la empresa

Sin lugar a dudas, una de las formas más originales de probar un producto, y que he tenido la oportunidad de experimentar este año, es la de jugar con él. Sí, jugar, habéis leido bien. Intentaré explicar el concepto en los siguientes párrafos.

Cuando un producto está llegando a su fecha de lanzamiento empieza el periodo estresante de pruebas exhaustivas. Normalmente, el producto se cerrará en cuando a código fuente y a partir de ahí entrará en proceso de integración y pruebas por parte del equipo de tests. Una vez que termine este período, podremos lanzar nuestra tan esperada versión. Obviamente, nos interesa que cuando el producto llegue a manos del cliente, éste se encuentre impecable y totalmente libre del más mínimo error, problema de rendimiento, agujero de memoria, o cualquier otro efecto indeseable.

Si nuestro proceso de pruebas e integración es extraordinario, todo irá como la seda. Pero la realidad es que las cosas no suelen ser así. Aunque nuestro proceso de pruebas sea perfecto desde el punto de vista formal, la realidad es que siempre existe un factor importantísimo que no podemos controlar: el factor humano.

El factor humano es importantísimo a la hora de probar un producto, porque por muchos tests unitarios, de integración, de rendimiento o funcionales que tengamos, ¿saben realmente nuestros desarrolladores lo que están probando? Es más, ¿saben nuestros desarrolladores como funciona el producto?, ¿saben como es el interfaz de usuario?, ¿saben como se comunican los componentes?, ¿se han puesto alguna vez en la piel del usuario final? Probablemente la respuesta a todas estas preguntas sea afirmativa si estamos hablando de un producto pequeño, pero sin embargo, cuando hablamos de un equipo de cientos de desarrolladores, de productos con decenas de módulos diferentes, y de grupos de desarrollo diversos (incluso deslocalizados), entonces la respuesta será un conjunto de noes.

Una de las formas de afrontar este problema es jugar. Sí, jugar, como leéis. Dependiendo de la aplicación se podrán crear diferentes tipos de juegos. No todas las aplicaciones son "jugables". Unas lo son más que otras. Por ejemplo, si estamos creando un juego para un periódico nos será sencillo el crear un juego virtual dentro de la empresa; si estamos trabajando en un producto para invertir en el mercado bursatil, podremos crear un juego de inversión en bolsa; si estamos creando una tienda online podemos crear un juego en el que ganaría el que más compras realize, o el que más dinero gaste, o cosas así; si estamos creando una aplicación de gestión de un servicio médico, podemos premiar a los que más pacientes traten o examinen completamente, a los que más informes creen, etc. etc. En fin, hay muchísimos ejemplos, unos más sencillos, otros más complejos.

Una vez que tenemos definido el juego es importante crear el entorno de ejecución del mismo. Este entorno debería simular de algún modo el entorno de producción real. Como la carga de usuarios será menor, se debería escalar este sistema para alcanzar algún tipo de relación con la carga de usuarios esperada. En general el sistema será mucho más pequeño que el de producción, pero debería ser lo suficientemente significativo como para generar problemas que podrían aparecer en producción.

Una vez que tengamos definido todo esto, llega el momento de jugar. Pero bueno, a estas alturas estaréis pensando, pero éste realmente se piensa que la gente va a ponerse a jugar con todas las cosas que tienen que hacer. Tenéis toda la razón del mundo. Todo esto no es suficiente si no se toman algunas medidas muy importantes:

• Premios en metálico.


• El juego debe ser obligatorio.

Como apunto en la lista, el juego debe tener obligatoriamente premios, y si es posible debería haber premios en metálico para todo el mundo. Por ejemplo, en el ejemplo de la tienda, se podría ofrecer a los empleados el 5% del importe de todo lo que compren hasta un límite de 1000€; o en el juego de la bolsa, pues el 5% de las ganancias que consigan + 5€ por operación realizada hasta 1000€.

Tener premios sin duda estimulará a la gente a participar. Una opción interesante es contactar con el cliente para conseguir ese dinero en metálico. Este tipo de juegos suele atraer la atracción del cliente final, ya que muestra que existe una intención real de hacer una prueba extensiva del producto. De hecho, si el cliente final es una organización, probablemente les interese a ellos mismos realizar un juego interno posterior dentro de la propia compañía.

También es muy importante que el juego sea obligatorio. Este tipo de prácticas ofrecen una enorme oportunidad para simular el comportamiento real de la aplicación, con personas reales y en un entorno similar al entorno de producción. Por eso es tan importante que participe la mayor cantidad de personas como sea posible. Adicionalmente, este tipo de juegos sirve para que los desarrolladores se familiaricen con la aplicación, para que entiendan como funciona, para que se pongan en la piel del usuario final y se enfrenten al interfaz de usuario, para que se den cuenta ellos mismos de los diferentes problemas. En fin, son demasiado valiosas como para que no se realicen. Por ello debe obligarse a los desarrolladores (y a testers, y soporte técnico, y managers, y a todo el mundo) a participar en el juego.

La participación no tiene porque ser constante, ya que también queremos que las personas trabajen. Se pueden organizar periodos de participación durante el día, o quizás ofrecer herramientas que automatizen el juego para que no haya que estar todo el día mirando para la pantalla para ganar.

Este año, he tenido la oportunidad de participar en uno de este tipo de juegos y la verdad es que la experiencia fue increiblemente positiva, y todo el mundo coincidió en lo mismo. Son experiencias que no sólo te ayudan a aprender como funciona el producto, sino que ofrecen un enorme abanico de posibilidades a la hora de probar realmente las aplicaciones.

Me pregunto si alguien tiene expriencias que compartir sobre este tema que personalmente me parece muy interesante. Ahí queda la oferta.