//
Estás leyendo...
eSalud

Proyectos de eSalud: el final es sólo el principio.

Cuando abordamos un trabajo, el que sea y en el ámbito que sea, el momento de entregar el resultado final siempre es un punto tremendamente delicado y del cual depende el éxito final de lo que sea que estemos construyendo. No importa que sea un puente, un libro o un proyecto digital, el momento de la entrega siempre es un hito que en muchas ocasiones se considera el punto final, la culminación del trabajo.

En proyectos de eSalud el momento en que presentamos los resultados de un proyecto a los profesionales que lo tienen que utilizar es especialmente crítico. Los profesionales del mundo sanitario son exigentes y tienen problemáticas muy particulares. Haberlas podido resolver correctamente es solo el primer paso de una carrera que va mucho más allá de ese hito tan concreto que es el momento de la puesta en producción.

El final del proyecto nunca llega con la entrega

La creencia general es que la finalización del proyecto se alcanza cuando la aplicación o servicio se pone a disposición de los usuarios en su entorno productivo y éstos comienzan a usarla de forma cotidiana. Y aunque los contratos se redacten y firmen de esta forma todos los que hemos trabajado en proyectos de aplicaciones de salud sabemos que esta afirmación no puede estar más lejos de la realidad.

El momento en que los usuarios se enfrentan por primera vez a un nuevo sistema o servicio no es más que un hito intermedio dentro de la vida de un proyecto y así debería ser considerado desde todos los puntos de vista. A partir de ese momento se ponen en marcha otras etapas, de igual o mayor importancia pero que generalmente no se tienen en cuenta como deberían. Y son claves para el mantenimiento, mejora y evolución de los mismos.

Ayudar al usuario a progresar en el uso

La mejor formación que un profesional puede tener de una nueva herramienta será siempre el uso cotidiano y diario. Ninguna formación, por prolongada que sea, puede suplir a la experiencia que se adquiere cuando uno se enfrenta necesariamente a los retos que supone trabajar hora tras hora con un nuevo sistema.

No obstante, durante las primeras semanas, nadie puede conocer en profundidad los procedimientos y herramientas que se acaban de poner a su disposición y por lo tanto necesitará de apoyo, tanto interno como externo, capaz de resolver esas dudas, de ayudarles con cualquier problema que pueda surgir, etc. Ese soporte inicial es fundamental para asentar los conocimientos, establecer rutinas, profundizar en la experiencia de usuario y asegurar la confianza.

Gestionar las expectativas creadas y no cumplidas y, sobre todo, el cambio

Los nuevos sistemas y aplicaciones siempre vienen cargados de promesas, de buenas intenciones, de grandes mejoras para todos los usuarios y profesionales. En resumen, siempre son (a priori) mejores que lo que existía anteriormente.

No obstante y en la mayoría de las ocasiones los programas no serán tan buenos o tan sencillos como se prometía. Siempre habrá alguna parte que haya cambiado y que haga cambiar a los profesionales su mecánica de trabajo, sus hábitos o incluso su forma de pensar. Y los usuarios deben adaptarse a estos cambios, muchas veces, sin tiempo para asentar los conocimientos, lo que genera dudas, desconfianza y malestar. Gestionar esa situación es clave para que los usuarios no abandonen rápidamente las herramientas creadas y vuelvan al estado anterior.

Los cambios son, casi siempre, necesarios. Bien explicados y expuestos pueden estar justificados pero si se imponen sin ningún tipo de explicación generarán malestar y rechazo.

Terminar todo lo que no se pudo acabar a tiempo

Dos factores influyen principalmente en las condiciones en que un proyecto de esalud podrá terminar: el plazo y el presupuesto. Con plazos muy limitados en el tiempo y presupuestos ajustados al máximo, cumplir todos los objetivos de los proyectos en el tiempo estipulado es, sino imposible, casi milagroso.

Por lo tanto, tras la entrega del resultante a los usuarios, siempre quedarán cosas pendientes de terminar o mejorar. Es fundamental exponer a los usuarios esta situación pero sobre todo planificar y ejecutar estos cambios, evolucionar los servicios para incorporar todo eso que se quedó pendiente en la entrega inicial. No hay nada peor para un usuario que entregarle algo incompleto y que no vea intención de mejora o solución a esos problemas y dificultades.

No dejar de lado la documentación

Es un hecho: a los informáticos nos horroriza escribir y documentar. Y eso a pesar de que nos lo recordamos constantemente. Pero es complicado, por no decir imposible, que un proyecto se entregue con toda la documentación completa y actualizada.

Manuales de usuario, manuales de procedimientos, guías rápidas … estos son sólo algunos de los nombres que nos sonarán y que en alguna ocasión hemos tenido que redactar (como desarrolladores) o que habréis reclamado como usuarios. En el caso de que la entrega se haya tenido que hacer sin esta documentación es fundamental completarla en cuanto sea posible para que los usuarios, en ellos, puedan encontrar la información y el apoyo necesario si los equipos de soporte no están disponibles para ofrecer esa ayuda.

… y continuar mejorando día a día

Pero desde luego y quizás lo más importante es recoger el feedback de los usuarios una vez que empiecen a utilizar las aplicaciones o los servicios. Su experiencia y sus impresiones serán fundamentales para poder mejorar y evolucionar, para crecer profesionalmente y mejorar lo que hagamos para ellos.

Es imperativo sentarse con los usuarios, compartir su día a día, para entenderlos y comprenderlos y así disponer de información de primera mano de sus problemas y las posibles soluciones que podamos proponer. Y no sólo antes de la entrega del proyecto. También es necesario hacerlo después, cuando ya se encuentran trabajando en los nuevos sistemas, para que nos puedan transmitir sus impresiones, sus problemas, sus dificultades. Sólo así seremos capaces de hacer mejor nuestro trabajo.

Si queremos llevar a buen término aquellos proyectos que emprendamos debemos pensar que la entrega de los desarrollos es sólo un punto intermedio en el ciclo de vida de los mismos. Olvidar este hecho producirá desconfianza, rechazo y, a la larga, un importante riesgo de que lo que hayamos realizado no sea útil y se termine abandonando por ineficiente o insuficiente.

¿Cuál es vuestra experiencia con la entrega de proyectos? ¿Se terminan siempre completamente o quedan cosas pendientes? ¿Se continúa el trabajo después de la entrega inicial?

Foto: jfcherry

Anuncios

Comentarios

2 comentarios en “Proyectos de eSalud: el final es sólo el principio.

  1. En los proyectos eSalud lo más difícil como apuntas es gestionar las expectativas del cliente, en este caso de los usuarios que son profesionales altamente cualificados que trabajan en un entorno complejo como es la sanidad. Es prácticamente imposible que un usuario acepte el alcance de un proyecto ofreciéndole un conjunto de requerimientos descritos en un lenguaje técnico: simplemente lo rechazará porque no es capaz de hacerse una idea del sistema en su conjunto.
    Una metodología que me ha dado buenos resultados (por ejemplo en Ianus, la historia clínica de Galicia – SERGAS) consiste en cerrar el alcance con un grupo de usuarios representativo de las áreas involucradas, empleando una ‘maqueta’ del sistema en HTML (que requiere muy poco tiempo para fabricarse, empleando diseñadores web) y un documento que describe en leguaje llano su funcionamiento. Se itera el proceso descripción de la maqueta – feedback de usuarios – afinamiento de la maqueta hasta que los usuarios entienden bien el sistema, tienen una imagen visual del producto final y una descripción que pueden entender. Es como Scrum sustituyendo el desarrollo real por una maqueta en ‘cartón piedra’.
    De esta manera se minimiza el riesgo de no cubrir la expectativas de usuario, se dispone de una herramienta para explicar el funcionamiento del sistema desde muy pronto y se obtiene el apoyo del grupo de usuarios de referencia del cliente.
    Ánimo y al toro.

    Le gusta a 2 personas

    Publicado por Eladio Linares | 15/10/2015, 10:25
    • Muchas gracias por tu comentario, Eladio.

      Efectivamente el método que indicas suele dar muy buenos resultados (generalizando el uso de una maqueta HTML a un prototipo de funcionamiento que pueda ser muestra significativa de lo que se quiere construir pero que requiera poco esfuerzo de desarrollo). Sin embargo lo más importe en lo que indicas (y por nuestra experiencia pasada) es la selección del grupo de usuarios. Debe ser representativa (como dices), con criterio constructivo (y no destructivo) y con suficiente peso en la organización para que tanto ésta como el resto de profesionales respalden las decisiones que puedan tomar. Y esto no siempre es así, lamentablemente.

      No obstante es fundamental que los profesionales que posteriormente serán usuarios participen activamente en los procesos de análisis y desarrollo para tener éxito en el proceso final de implantación. Por ese motivo habéis obtenido buenos resultados y lo seguiréis haciendo (con toda seguridad). Os felicito porque no siempre se hacen las cosas tan bien como nos has explicado.

      Un saludo

      Le gusta a 1 persona

      Publicado por Pedro Gonzalo | 15/10/2015, 11:20

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Introduce tu dirección de correo electrónico para seguir este Blog y recibir las notificaciones de las nuevas publicaciones en tu buzón de correo electrónico.

Únete a otros 3.217 seguidores

Archivos

A %d blogueros les gusta esto: