//
Estás leyendo...
TIC's

¿Deben tener fecha los proyectos de eSalud?

Leíamos recientemente en el blog de Javier Garzas un interesante artículo sobre la posibilidad de trabajar en proyectos de desarrollo de software con un presupuesto en lugar de con una estimación de tiempo y coste y eso nos hizo reflexionar sobre el desarrollo de aplicaciones en el entorno sanitario.

Los proyectos de aplicaciones para el mundo de la salud no son distintos a los del resto de sectores. Bien sea con productos comerciales o aplicaciones construidas a medida (ya comentamos este tema con anterioridad) y a partir de unas especificaciones iniciales se realiza una estimación de esfuerzo y a partir del mismo se elabora una oferta económica. Esta es la forma en la que se han venido planificando y ejecutando los proyectos hasta la fecha.

Sin embargo todos somos conscientes de los problemas que se producen en los proyectos: especificaciones erróneas o incompletas, funcionalidades mal construidas o mal validadas, plazos que se alargan por infinitos motivos … Y los problemas que de ellos se derivan: productos incompletos, funcionalidades no desarrolladas, pérdidas económicas para los proveedores, decepción y desencanto en los clientes y un largo etc.

Quizás ha llegado el momento de pensar en que puede haber otra forma de hacer las cosas, de replantear los proyectos, de abordar la relación cliente-proveedor. La alternativa de trabajar con un presupuesto cerrado (cuánto me quiero o me puedo gastar) pero sin una funcionalidad previamente acordada (y por lo tanto sin una fecha de finalización determinada de antemano) puede ser una posibilidad válida que, bien gestionada por ambas partes, puede dar lugar a mejores productos y mayor índice de satisfacción tanto de los clientes y usuarios como de los proveedores de software. De esta forma, la fecha de finalización del proyecto será aquella en la que las funcionalidades sean suficientes para poner el marcha el proyecto. No tiene por qué estar todo construido. No tiene por qué haberse agotado el presupuesto. Pero tampoco se condiciona todo a cumplir una fecha final, a un hito previamente fijado en el calendario y que sea inamovible.

Afinar en la funcionalidad, la única prioridad

La parte más importante de todos los proyectos, y mucho más en entornos críticos como son los sanitarios, es definir correctamente la funcionalidad que se quiere desarrollar. Del trabajo, bueno o malo, que se haga en este punto dependerá en gran medida el éxito o el fracaso del resultado final del proyecto que emprendamos.

Sin embargo nunca se destina tiempo suficiente (y lo decimos con toda la intención), y mucho menos presupuesto, para realizar esta estimación de forma correcta. Por regla general los proveedores tienen que trabajar con una especificación, o análisis de requisitos, incompleta, vaga e imprecisa, que únicamente sirve para hacerse una idea de lo que hay que hacer. Además esta funcionalidad se hace por adelantado y en muchas ocasiones sin contar con el usuario final lo que produce, en el mejor de casos, cambios de alcance que se deben negociar (y no es fácil ni agradable) y en el peor productos que no cubren las necesidades de los usuarios.

Trabajar sin una especificación cerrada supone que cualquier cambio en el alcance (nuevas funcionalidades o cambios en las ya definidas) deberá ser negociado, pero no supondrá un cambio económico (la parte más compleja de asumir si supone incrementos de presupuesto) sino una priorización de funcionalidades o resultantes. Es el cliente quien decide qué quiere hacer y cómo hacerlo. Y sobre todo, el cliente decide cuándo el producto tiene funcionalidad suficiente para poder ponerse en marcha, sin necesidad de que la totalidad del producto esté desarrollada, probada y validada. No tiene por qué suponer un cambio en la fecha prevista de arranque … o sí. Dependerá de las necesidades, pero nunca de un acuerdo previo sino de una negociación sobre la marcha.

Se trata, por tanto, de priorizar el resultado final por encima de cualquier acuerdo inicial que se pudiera establecer entre las partes intentando cumplir los objetivos del producto de la mejor manera posible.

Garantizar la calidad antes que la cantidad … o la velocidad

Las aplicaciones de salud son, en buena medida, aplicaciones críticas. No sólo porque de ellas puede depender la vida de los pacientes sino porque se utilizan para la gestión de centros que tienen que estar operativos las 24 horas del día todos los días del año.

En este entorno, la calidad de las aplicaciones es fundamental para garantizar que todo, una vez llevado al entorno de trabajo real, funcionará como se espera que lo haga, sin errores y sin poner en riesgo la continuidad del trabajo de los profesionales y los procesos de atención a los propios pacientes.

Aunque es evidente que este nivel de calidad no sólo debe ser asumido sino garantizado por el proveedor, no es menos cierto que un presupuesto demasiado ajustado con alcances demasiado amplios conduce necesariamente a que la calidad de los productos finales se vea afectada. El cliente siempre querrá (y es su privilegio) más y mejor (el bueno, bonito y barato) pero debe ser consciente de que apretar demasiado a sus proveedores va a suponer siempre que la calidad del resultado no sea la óptima. Es así, los milagros no existen.

Si cambiamos la forma de trabajar, sin fijar plazos de finalización a los desarrollos, éstos se pondrán en marcha cuando sea posible, cuando todos los actores estén de acuerdo en que la calidad de lo desarrollado es suficiente para poder ofrecer el servicio a los usuarios. Sin estar atados por plazos o hitos acordados de antemano y que difícilmente se podrán cumplir.

Si no podemos estimar el coste total, ¿cómo ponemos un precio al producto?

El hecho de no poner fecha de fin a un proyecto puede hacer pensar que no será posible realizar una estimación del coste final del producto resultante. Sin embargo pensemos que hemos fijado de antemano un presupuesto y por lo tanto el cliente sabe lo que se puede gastar. Ese es el límite económico con el que se cuenta. Sobre él se han establecido las funcionalidades que se quieren abordar con dicho presupuesto y el cliente y el proveedor han acordado hasta dónde quiere y puede llegar cada uno de ellos.

Es cierto, nunca se va a saber de antemano cuánto me voy a gastar en el producto final (considerando como final el momento en que incorpore todas las funcionalidades que el cliente quiere) pero ¿es que alguna vez lo sabemos? Las aplicaciones (todas, pero especialmente las sanitarias) están sujetas a evolución, cambios en los circuitos de trabajo que requieren adaptaciones, cambios normativos o legislativos que afectan a los datos y a los sistemas. Y por lo tanto, el coste final de las soluciones está condicionado por dichas evoluciones.

Olvidar la idea de que el proveedor quiere engañarme

En muchas ocasiones los clientes piensan que si no disponen de un presupuesto cerrado (en funcionalidades y tiempo) el proveedor tratará de engañarlos, aumentando los tiempos artificialmente o incrementando desmesuradamente las horas. Nada más lejos de la realidad. Los proveedores de software quieren ganar dinero, eso es evidente, pero en todos nuestros años de experiencia no hemos encontrado un proveedor interesado en engañar a sus clientes.

La finalidad del proveedor debe ser siempre la satisfacción del cliente. En un mundo tan competitivo como el actual, un cliente descontento es la peor publicidad que se puede recibir y por lo tanto todos los proveedores tratan de que sus clientes estén contentos con su trabajo.

La formula de no cerrar previamente las funcionalidades a implantar, como hemos dicho antes, permite rectificar sobre la marcha los errores cometidos en fases anteriores lo que generará, a la larga, mejores productos, mayor grado de satisfacción en las partes y, finalmente, una colaboración más estrecha entre todos. Debe ser prioritario establecer dicha relación de confianza lo antes posible para obtener buenos resultados finales. Proveedor y cliente deben trabajar como un equipo y no como dos partes enfrentadas.

¿Y cuándo termina el proyecto?

Este punto será quizás el más difícil de determinar. Parece que un proyecto sin fecha de finalización nunca se terminará pero recordemos que se habrá fijado un presupuesto de antemano y por lo tanto éste marcará necesariamente un punto en el que deberá haberse obtenido un producto operativo y suficiente.

Sin embargo, como ya hemos dicho antes, el ciclo de vida de un producto es muy largo y sobre él habrá que seguir trabajando con el paso del tiempo, al margen de que éste se encuentre ya en una fase madura de implantación. Por lo tanto, ¿por qué hay que considerar que el proyecto debe terminar?** Simplemente finalizará una fase y podrá comenzar una nueva**, con nuevos objetivos y nuevos presupuestos.

La idea de trabajar sin fecha de finalización, únicamente con el objetivo de obtener un buen producto final, no es nueva. En ciertos servicios, especialmente de soporte y mantenimiento, ya se está utilizando desde hace tiempo. Desde nuestro punto de vista creemos que puede aportar al sistema más beneficios que desventajas en aras de conseguir mejores resultados finales y por eso creemos que puede ser una alternativa a la gestión clásica de proyectos en el futuro.

¿Pensáis que es posible trabajar en proyectos de desarrollo de aplicaciones para la salud sin poner fecha de fin a los trabajos? ¿Se podría pensar en trabajar con un presupuesto y con especificaciones abiertas en lugar de fijar como punto de partida un coste final y unas funcionalidades cerradas?

Foto: Julia Taylor

Anuncios

Comentarios

4 comentarios en “¿Deben tener fecha los proyectos de eSalud?

  1. Reblogueó esto en People in the eSaludy comentado:
    Replantear las relaciones proveedor – cliente y acometer desarrollos de forma conjunta

    Me gusta

    Publicado por Jose Miguel Cacho | 06/04/2015, 09:38
  2. Muy buen artículo Pedro.

    En el sector de las telecomunicaciones, en el que la exigencia de la competencia del mercado impone un ritmo muy alto para la puesta en servicio de nuevos productos, fijar un plazo objetivo es muy importante. Naturalmente que tener un producto con buena usabilidad es relevante para conseguir la satisfacción de los clientes, pero se pueden desplegar aplicaciones y servicios en fase beta. Desplegar un servicio en fase beta quiere decir que éste funciona razonablemente bien y se ha establecido un periodo de mejoras y un proceso de interacción con los usuarios para implementarlas. Entiendo que esto en sanidad no debe ser así y los desarrollos deben llegar a los usuarios con una calidad muy alta.

    En las telecos, los plazos de despliegue de nuevos servicios, forman parte de la estrategia global de cada compañía, en un mercado en el que todos nos observamos constantemente y queremos posicionarnos en el mercado cuanto antes.

    Un abrazu.

    Me gusta

    Publicado por aorviz | 24/04/2015, 06:02
    • Hola Gus!!

      Muchas gracias por acercarte a leernos y comentar. También sigo tu blog personal con atención y es un placer volver a contactar contigo después de tanto tiempo (demasiado diría yo).

      En cuanto al tema, yo diferenciaría la estrategia de desarrollo de productos y servicios (como tu caso) de los desarrollos a medida. En el primer caso es la empresa quien diseña la estrategia de puesta en marcha de dichos servicios y por lo tanto puede decir cómo y cuándo hacerlo. En los desarrollos a medida, suele ser la empresa contratante la que determina el plazo y la fecha de finalización de los trabajos. Y en estos casos donde se puede interactuar con los clientes antes de la puesta en marcha para “afinar” el resultado final.

      La sanidad no es diferente, básicamente, del resto de negocios y sectores. No obstante tienes razón en que los desarrollos deben llevar suficiente calidad (en algunos casos) como para no generar un perjuicio grave a los pacientes. No en todos los casos se pueden o se deben acelerar los tiempos de puesta en marcha de los sistemas y esto, en muchas ocasiones, no se tiene en cuenta debido a presiones en plazos, calendarios, presupuestos, etc.

      En cualquier caso, será el mercado quien determine en qué línea trabajaremos en el futuro. Veremos por dónde nos lleva.

      Un abrazo para tí también.

      Me gusta

      Publicado por Pedro Gonzalo | 24/04/2015, 15:56

Trackbacks/Pingbacks

  1. Pingback: Metodologías ágiles, ¿presente y futuro? | Hablando de eSalud - 15/06/2015

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.215 seguidores

Archivos

A %d blogueros les gusta esto: