Las causas más frecuentes de este
asincronismo a mi juicio son:
- Se ha hablado, y mucho, en el mundo
del desarrollo SW sobre la importancia que tiene primero formularte
por qué abordar un desarrollo antes de buscar
soluciones sobre cómo afrontarlo. La realidad es que hay
desarrolladores con un pefil tan técnico y que les gusta siempre
estar tan a la última, que se ponen a construir aplicaciones
ultra-modernas sin saber siquiera para qué las hacen o si realmente
pueden llegar a ser útiles.
Sin embargo, no es la intención del artículo incidir sobre este tema, porque es fácilmente explicable y todo el mundo lo entiende, aunque a la hora de la verdad, la cabra siempre tira al monte y si uno es técnico a más no poder, se preocupará más por dotar a sus proyectos de la última tecnología que realmente de analizar su practicidad.
- Otra causa de este incumplimiento de
expectativas deriva de no contar en ningún momento con el usuario,
creyendo ser más inteligente y sabedor del negocio que el propio
destinatario. Realmente hay que ser consciente de que la aplicación
no la va a utilizar uno mismo sino el usuario final al cual has
ignorado por completo, y éste se tiene que sentir cómodo con la
aplicación para darle siquiera una oportunidad.
Hay que tener en cuenta al usuario
en todas las fases que constituyen el desarrollo y puesta en marcha
de una aplicación.
- Otro tema que me gustaría
desarrollar con más detalle, a simple vista es más difícil de
detectar, pero sin embargo es vital al menos en el ámbito del
desarrollo y gestión SW en la Administración Pública. Me refiero
al cortoplacismo imperante. Éste provoca que una vez se pone
una aplicación (o una nueva funcionalidad) en producción,
automáticamente se desvían todos o la gran mayoría de los recursos
hacia otro desarrollo diferente. Un ejemplo concreto sobre una
experiencia real sería el siguiente:
Mediante la adecuada coordinación con
el gestor tramitador de un procedimiento se diseña e implementa una
funcionalidad en una aplicación existente. El objetivo es que otras
Administraciones distintas puedan dar de alta expedientes online en
vez de presentarlos en formato papel y en modo presencial, como hasta
ahora se venía haciendo. Para acometer dicho desarrollo no sólo se
trabaja de forma coordinada con la unidad tramitadora del
procedimiento, sino que también se cuenta con una Administración
encargada de dar de alta los expedientes, para tener la visión tanto
del tramitador como del iniciador del procedimiento.
El diseño planteado es correcto. Pero
una vez que se finaliza el desarrollo y, suponiendo que no tiene
ningún error gordo que impida la correcta tramitación, que es mucho
decir, si en ese momento se desvían recursos hacia otros desarrollos
pensando que el trabajo ya está terminado, existen grandes
posibilidades de que el proyecto acabe siendo abandonado o no se haga
uso del mismo. La razón es que los análisis no suelen detectar al
completo los problemas de la vida real, de ahí la importancia de
usar metodologías ágiles como ya comenté en este artículo.
Además, rara vez los procedimientos son 100% homogéneos y cada
usuario final suele tener sus detalles concretos que habrá que
resolver. Respecto a este último punto, lo ideal sería unificar los
criterios a seguir en los procedimientos antes de diseñar la
solución técnica, pero entonces ya entraríamos en cuestiones de
ámbito organizativo y ahí los TIC podemos colaborar y tratar de
convencer, pero no tenemos la decisión final. Si hay que esperar a
cambios organizativos para iniciar desarrollos, muchos de los mismos
que ya están siendo utilizados todavía no habrían tenido lugar.
Esto me lleva a las siguientes
reflexiones:
1- Para tener éxito con un nuevo
desarrollo, el mantenimiento correctivo y evolutivo en los primeros
meses de funcionamiento es esencial. Esto supone un coste a nivel de
recursos y tiempo nada despreciable que incluso puede ser superior a
la implemntación inicial.
Hacer ver esto a los superiores muchas
veces es complicado, precisamente por el cortoplacismo con el
que se trabaja habitualmente. Sin embargo, la realidad dice que
desarrollar software con calidad casi siempre requiere de
iteraciones.
2- En aquellos proyectos en
los que los usuarios están constituidos por distintos colectivos o
unidades dispersas, el esfuerzo que supone el mantenimiento evolutivo
se dispara.
3.- Las formas de contratación
actuales y de dotación presupuestaria no ayudan al mantenimiento
evolutivo, al menos en mi experiencia particular. Esto se debe a que
en las memorias de contraración es preciso detallar con nitidez cada
una de las funcionalidades a realizar. Con este panorama, justificar
un mantenimiento evolutivo existiendo incertidumbre sobre lo que se
hay que abordar es más complejo que contratar aplicaciones o
desarrollos nuevos. Por otro lado, si hay que esperar a que el
mantenimiento evolutivo se defina para poder iniciar un contrato,
quizá para entonces el usuario ya haya tirado la toalla y abandonado
el barco.
4- Es demasiado costoso convencer a un
usuario a que empiece a usar una aplicación como para dejarle
desatendido en sus primeras experiencias con la misma. Éste puede
buscar cualquier excusa para no utilizar el programa y seguir
haciendo lo de siempre, que podría ser lo más cómodo para él.
Nuevamente el mantenimiento evolutivo en los primeros meses de puesta
en producción se muestra como fundamental.
5- Conviene abarcar menos pero
haciendo bien los cometidos que querer abarcar mucho y dejar los
desarrollos a medias. Entendiendo por “desarrollo a medias”
no atender (al menos de forma ágil) las cuestiones que planteen los
usuarios sobre todo al comenzar su andadura con la aplicación.
Desgraciadamente esto es lo que suele suceder de forma habitual en
los desarrollos SW.
En resumen, una de las principales
causas del fracaso de aplicaciones tiene que ver con la poca
adaptabilidad de las mismas a lo que el usuario demanda. Existen
diversas causas y conviene tenerlas presentes en aras a conseguir una
mejor sincronía con los usuarios.
No hay comentarios:
Publicar un comentario