El mercado actual de soluciones y productos de Software que pueden cubrir nuestras necesidades es grandísimo. A veces por economía solemos simplificar las decisiones de selección de productos y soluciones: tendencias (mi competencia lo tiene), es una novedad e incluso a veces porque es «gratis».
Los que ya estamos escarmentados -sí, me incluyo- de basarnos en presunciones, falsas promesas de proveedores/fabricantes o de dejarnos llevar, empezamos por una evaluación o «proyecto piloto».
Algo de lo que no nos solemos dar cuenta es que, evaluando un producto, ya hemos empezado un proyecto o «el proyecto». Date cuenta, estamos involucrando personas, plazos, necesidades… ¿Vamos a dejarlo a «como salga»?
Hace tiempo preparé un «marco general» para dirigir este tipo de evaluaciones, tanto para nosotros –Olatic– como para nuestros clientes, y ahora me gustaría compartirlo por si os puedo aportar algo. Este «marco general» para las evaluaciones de un producto de software se divide en tres fases:
- Planificación
- Evaluación
- Conclusión
En este artículo os voy a contar el primer punto, y dejaré los otros dos puntos para mis siguientes artículos.
Planificación
En esta fase intento obtener toda la información que voy a necesitar para evaluar y realizar las conclusiones con unas mínimas garantías y tener margen para ajustes. Además, me sirve para mostrar a los demás de donde partimos, hacia donde vamos y donde estamos. Empecemos con los puntos:
- Objetivos. Parece obvio pero a veces en las pruebas no están claros o consensuados, otras veces no están alineados con el negocio…
- Audiencia. Lo más seguro es que el producto que estamos probando lo van a usar otras personas dentro nuestra organización. ¿Sabemos que personas son las candidatas? ¿Podemos contar con ellas? En este punto suelo buscar dos tipos de perfiles de usuarios basándome en 80/20, usuarios con un alto impacto (usuarios que van a utilizar la aplicación en un 80% de su jornada o en su mayor parte) y usuarios con impacto bajo (usuarios que usen poco la aplicación en su jornada o esporádicamente). Algo que debemos manejar cuando pensemos en las personas candidatas es como hacer que las tareas que les encomendemos no «interrumpan» la operativa del negocio y por otro lado -para mi muy importante- es buscar personas que estén motivadas para estas tareas. Cuantas veces habré oído lo de «no tengo tiempo para probar esta chorrada…»
- Plazo. Suele haberlo porque a veces viene impuesto de «arriba», otras veces no y debemos establecerlo. Dentro de este plazo podemos pensar en fases para la evaluación: por tipo de usuario, por departamento, por ubicación…
- Sensibilización y formación. Para mi este punto es muy importante. Necesitamos que los usuarios involucrados entiendan el porqué de estas pruebas, que motivación de negocio hay detrás. Es decir quiero que se impliquen en algo que entiendan y en el que además puedan aportar valor. Quiero que me digan cómo funciona la aplicación en el día a día del negocio y en que puede ayudarnos, no en si este botón funciona o no funciona. Por otro lado, necesitamos de una mínima formación inicial. Los usuarios no pueden aterrizar en la evaluación del producto sin saber cómo pueden hacer las cosas. El no hacerlo es garantía de problemas del tipo: es complicadísimo o directamente es una m.. Si el periodo de evaluación es largo también se puede diseñar un calendario de formación gradual según vaya avanzando la evaluación. Busquemos que formas tenemos para sensibilizar y formar a nuestra audiencia.
- Seguimiento. Debemos pensar y habilitar canales y espacios que nos permitan hacer el seguimiento de la evaluación con los usuarios y que éstos puedan reportarnos incidencias y sugerencias. Debemos establecer una periodicidad en caso de formalizar reuniones , entrega de informes, encuestas…
- Limitaciones. A veces la evaluación que se realiza del producto tiene limitaciones en su funcionalidad. Debemos conocerlas para saber cómo de exacta va a ser nuestra evaluación. Otro punto a tener en cuenta es la continuidad. ¿Y si termino la evaluación y el producto no satisface las necesidades? Si no lo hemos tenido en cuenta, lo más normal es que perdamos el trabajo. Puede que el producto que estemos evaluando nos permita sacar una copia de seguridad de nuestro trabajo, pero si hemos decidido que éste no es nuestro producto ¿podemos restaurar esta copia en otro producto?. Personalmente lo que suelo definir es que tipo de datos se van a utilizar en la evaluación y dependiendo del tipo de producto que estemos evaluando duplicarlos (como se venía haciendo hasta ahora y en el producto en evaluación.) ¿Os acordáis que he comentado que necesitamos personas motivadas?
- Justificación. Siempre intento aclarar este punto que en si se trata en cómo hemos decidido que vamos a evaluar este producto. Por ejemplo porque ya tenemos más productos del mismo fabricante y puede que la integración sea mejor, porque tenemos un proveedor que nos da soporte o nos lo ha recomendado, porque la tecnología que usa está alineada con la que tenemos en nuestro negocio, porque es un producto extendido y la curva de aprendizaje puede ser baja… Lo que quieras, pero déjalo por escrito para recordártelo cuando te hagas más adelante la pregunta de por qué éste y no otro.
- Soporte a IT. En este punto definiremos como vamos a actuar cuando tengamos situaciones en las que nuestro departamento de IT (o personas encargadas de la evaluación a nivel técnico) no sea capaz de resolver.
Como he comentado, podemos jugar con estos puntos quitando, poniendo, dando más o menos detalle… Como ves esta fase puede requerir de días e incluso de semanas pero vas eliminando riesgos y si la cosa no pinta bien mejor perder unos días de tu tiempo que semanas del de muchos.
El siguiente artículo será como planteamos la fase de evaluación pero hasta entonces… ¿Qué puntos añadirías a esta fase? ¿Qué detalle importante también trabajarías en alguno de estos puntos?
