Así que me he bajado las aplicaciones en versión demostración y las he instalado. Bueno, al menos la primera, la segunda está en espera.
Es fácil saber si una aplicación “te va a servir”. Es tan sencillo como si la empiezas a utilizar inmediatamente y se integra dentro del flujo de trabajo o no. Si la descargas, la instalas y no la empiezas a utilizar inmediatamente, aunque sea de forma sencilla, es que esa aplicación no es para ti. Una utilidad, una aplicación, debe solucionar un problema “real” que tienes, ya sea porque necesitas ampliar la capacidad de un software existente o porque soluciona parte de un flujo de trabajo unificando varios pasos que tienes que realizar de forma manual.
El siguiente paso es mirar las Preferencias de la aplicación, incluso antes de empezar a utilizarla y hay un razón muy clara para eso: es la mejor forma de entender qué características tiene el software para iniciar el trabajo con la misma. En la mayoría de los casos la gente se salta este paso y empieza a usar una aplicación y simplemente el set de configuración inicial puede que no se adapte a tu manera de trabajar, pero con unos pocos ajustes simplemente la cosa “funciona”.
El siguiente paso es empezar a utilizar la aplicación en un entorno de trabajo para iniciar la evaluación. Es el momento de medir. Hay que medirlo todo, desde el tiempo que ahorras a la facilidad de uso pasando por el rendimiento (rapidez, estabilidad) de la aplicación o utilidad, ya sea de forma global por la propia aplicación (un plug in de correo electrónico, por ejemplo) como de forma puntual (una aplicación que utilizas para un flujo de trabajo específico, como exportar vídeo). Tampoco tienes que andar con un cronómetro, pero sí has de evaluar durante el proceso de prueba de demo si el tiempo que ahorras tanto físicamente como relativamente (por ejemplo, a la hora de organizar proyectos) cumple con nuestro particular SLA (Service Level Agreement), algo que deberíamos firmar con nosotros mismos ya que somos proveedores-clientes a la vez.
Un acuerdo de nivel de servicio o ANS (en inglés Service Level Agreement o SLA), es un acuerdo escrito entre un proveedor de servicio y su cliente con objeto de fijar el nivel acordado para la calidad de dicho servicio. El ANS es una herramienta que ayuda a ambas partes a llegar a un consenso en términos del nivel de calidad del servicio, en aspectos tales como tiempo de respuesta, disponibilidad horaria, documentación disponible, personal asignado al servicio, etc.
Básicamente el ANS establece la relación entre ambas partes: proveedor y cliente. Un ANS identifica y define las necesidades del cliente a la vez que controla sus expectativas de servicio en relación a la capacidad del proveedor, proporciona un marco de entendimiento, simplifica asuntos complicados, reduce las áreas de conflicto y favorece el diálogo ante la disputa.
También constituye un punto de referencia para el proceso de mejora continua, ya que el poder medir adecuadamente los niveles de servicio es el primer paso para mejorarlos y de esa forma aumentar los índices de calidad, KPI…
Esto no debe quedarse solo ahí, sino que también tenemos que evaluar si la ausencia de este nuevo software, que puede convertirse en crítico para nuestro trabajo, va a causar más problemas de los que soluciona. A mi me pasa con Herald, el plug in de Mail: al final he separado mi correo personal con Spark del profesional con Mail y Herald, la aplicación de notificaciones, deja de funcionar con cada actualización de Mail hasta que está disponible unos pocos días después conforme la actualiza el desarrollador. Herald me permite tomar decisiones instantáneas sobre las notificaciones lo que facilita una gestión muy ágil del correo, pero claro, esos días que “falta” la gestión del correo lleva mucho más tiempo y no haces más que cabrearte. Si la ausencia del software, por ejemplo, por una actualización del sistema o de sus aplicaciones supone que tu flujo de trabajo se vaya a interrumpir durante mucho tiempo mientras se actualiza es otro de los temas que tienes que tener en cuenta a la hora de valorar la aplicación. Echa un vistazo al histórico de actualizaciones de la aplicación, que ofrecer muchas pistas sobre cómo el desarrollador tiene de “bien cuidado el jardín” o simplemente te verás metido en un fregado importante porque tendrás que tener un flujo de trabajo de repuesto y eso complica mucho el trabajo.
Evaluar software no es solo descargar y cacharrear: es medir, ver cómo afecta a nuestro propio SLA y evaluar costes económicos y de tiempo. Esa es la clave para incorporar software.
