Todo jefe de proyecto una vez haya conseguido que su
aplicación sea utilizada y con cierto éxito, se enfrenta tarde o temprano al siguiente dilema moral: seguir las directrices de
sus superiores jerárquicos o actuar en consonancia con las peticiones de los usuarios en
cuanto a las evoluciones del aplicativo se refiere.
Paradójicamente no pocas veces resultan divergentes los deseos
de los jefes con respecto a los de los usuarios
finales. Los primeros, mucho más posicionados en el plano cuasi comercial y el
mundo del marketing necesitan de grandes titulares que vender constantemente para así continuar en la
cúspide de la innovación tecnológica y el progreso. Esto se traduce en que lo que quieren oír
sobre los proyectos son grandes evoluciones completamente disruptivas, que
llamen la atención por algunos de los atributos más en boga en la esfera
tecnológica actual y que en el momento presente podrían ser: servicios en la
nube, reutilización, integraciones o consolidaciones, big data, etc. En cambio, su atención disminuye
considerablemente si lo que se plantean son detalles concretos bien funcionales
bien de usabilidad, rendimiento u otros atributos no funcionales del proyecto
por mucho que los usuarios sean lo que demanden.
Esta necesidad continua de “carnaza” de los altos directivos puede
llegar a ocasionar importantes perjuicios para el programa informático. Un ejemplo de lo expuesto sería suponer que
una unidad acaba de concluir su flamante sistema de información geográfica con
establecimiento de mapas interactivos, georreferenciación, etc. A fin de hacer resonar más dicho proyecto “estratégico”,
dicta unas pautas internas para que el
resto de aplicaciones de gestión de la
propia unidad se integren con él bajo el pretexto de que las estadísticas generadas por estas
últimas sean más visuales y estéticas.
Un responsable de alguno de los citados proyectos se puede
ver coaccionado e incluso sometido a anteponer ese desarrollo de integración
pese a que él conozca que la prioridad
de los usuarios vaya por otros derroteros.
La estética de las estadísticas no debiera ser ni mucho menos una de sus
preferencias teniendo en cuenta que no se necesitan generar de modo frecuente y sin embargo sí que se reclaman
con celeridad otras tareas de mayor utilidad.
Además del tiempo perdido y el esfuerzo malgastado de la
implementación, no entro a valorar en
este ejemplo el coste producido por el mantenimiento que supondrá de cara al
futuro. Ese último coste ya es para siempre, no es lo mismo actualizar unas
sencillas estadísticas implementadas desde tu propia aplicación que aquellas
generadas a través de mapas integrando aplicaciones.
Una vez analizado el ejemplo desde la óptica de los
directivos, examinaremos la evolución de
los proyectos desde el punto de vista de los usuarios finales. Éstos, con los
pies mucho más asentados en el suelo, gravitan hacia tratar de mejorar el
momento presente. Ello se traduce en
propuestas mucho más incrementales orientadas al corto plazo que doten a la
aplicación con la que trabajan en el día a día de la usabilidad, agilidad y
eficiencia que demanda. Los grandes
avances tecnológicos citados anteriormente, si bien no los desechan, sí que actúan de modo más precavido y
conscientes de las grandes limitaciones que pueden llegar a tener en el uso diario,
no dejándose seducir por la melodía de lo fantástico y fácil que sería todo al
cambiar radicalmente el modelo apoyándose en las posibilidades de la tecnología.
Los usuarios finales
tienen más en cuenta los riesgos que los beneficios en las innovaciones
tecnológicas, mientras que los directivos ponderan en mayor medida los rendimientos.
Ninguno es ecuánime en la aplicación de la fórmula.
Con esto no quiero decir que no haya usuarios visionarios
que entiendan lo que puede aportarles la tecnología, sino que suelen sopesar
mejor las grandes barreras que hay detrás de todo proyecto innovador, evitando
así desarrollos utópicos. Si escoges a un usuario para que priorice sobre una evolución
incremental a corto plazo o innovadora a
medio y largo plazo muy raro sería que se decante por la segunda, alegando que
mejor hacer lo sencillo en primer lugar no vaya a ser que uno por otro la casa
quede sin barrer. Tiempo habrá para mejorar el mundo, de momento cíñete a
resolver mi problema actual.
Este modo de actuar también puede presentar problemas.
Supongamos ahora que disponemos de una aplicación que genera unos informes que
van dirigidos a otra unidad. El usuario está solicitando modificaciones constantemente
en dichos informes. La solución óptima sería realizar un trabajo de
coordinación previo entre responsables decidiendo, bien que esa unidad
destinataria acceda directamente a dicha información preocupándose ella del
formato, o bien mediante una integración entre aplicativos donde se
intercambien los datos en bruto. En ambos casos, lógicamente el tiempo de
desarrollo será mayor y al usuario le tocará durante un tiempo cambiar el
informe a mano, pero de una vez por todas se habrá atajado el problema.
En ciertas ocasiones, es necesario dejar un poco de lado al
usuario, al no haber recursos ilimitados, para afrontar cambios futuros que
supondrían una mejora ostensible en la forma de abordar los procesos. Con todo,
es preciso valorar bien los riesgos antes de acometer un proyecto de
envergadura ya que la historia nos recuerda severamente que son muchos los
euros invertidos que han dado como resultado la nada absoluta por el mero hecho
de poner un titular encima de la mesa dado que en ese momento mejoraba la
imagen del organismo.
No hay comentarios:
Publicar un comentario