Muchos de vosotros habréis notado un descenso importante en la frecuencia de artículos en este blog. Históricamente siempre me ha pasado esto, empezando con mucho ritmo pero, a medida que se acercaba el final del año y con las urgencias que esto acaba acarreando, me acababa dedicando a todo menos a actualizar el blog.
Este año, no obstante, la razón ha sido otra. Las últimas semanas las he dedicado a una parte de mi trabajo que siempre he identificado como la más importante, pero que siempre ha quedado en un segundo plano: ALM o la Gestión del Ciclo de Vida de las Aplicaciones. Ahora que ya puedo decir con orgullo que la mayor parte de la infraestructura necesaria está en su lugar, y aprovechando que tengo preparados unos cuantos eventos que giran en torno a este asunto he pensado escribir una serie de artículos, empezando por la introducción que haré a continuación.
Antes de comenzar, una puntualización: ahí fuera hay verdaderos expertos en ALM y no querría yo meterme en su terreno. Aunque en ocasiones hablaré de forma genérica, quiero dejar claro que yo voy a hablar de ALM en el mundo SharePoint, una combinación sobre la que no hay tanto material, almenos en este país. No obstante, si digo alguna barbaridad y algún experto en ALM quiere corregirme, será más que bienvenido J
ALM es un asunto que genera cierta controversia. Pese a que la mayoría de profesionales del sector opinamos que poner atención a este asunto es primordial y aumenta espectacularmente la calidad de nuestro software, es rara la ocasión en que realmente se ponen todos los medios necesarios. Normalmente el argumento que se utiliza para no destinar presupuesto a esta partida es que es difícil de justificar de cara al cliente y, efectivamente, es un argumento totalmente válido. Cuando te compras un coche tú eliges las llantas, el número de marchas, los caballos, etc., pero el vendedor nunca pone en el presupuesto una línea donde se te cobren los procesos de calidad que han seguido y el I+D que han necesitado para construir el coche que tú estás comprando. ¿Cuál es la solución entonces? Mi opinión es que SIEMPRE hay que poner especial atención a este tema y después, a la hora de justificarlo de cara al cliente, plantear que el coste de hacer las cosas bien es un factor multiplicador en el precio por funcionalidad que se le va a cobrar.
Muchos diréis que es imposible, al menos en países como España, hacer esto que digo. Que en general aquí se mira el precio por hora final o el precio total del proyecto para decidirse entre un proveedor u otro. Pues mi objetivo con esta serie de artículos es convenceros de que ahí estáis equivocados. Yo no creo que hacer las cosas bien sea necesariamente más caro que hacerlas rápido. En los próximos artículos os explicaré cómo un buen trabajo en este apartado hace que la calidad de los desarrollos aumente, y un aumento de la calidad del software implica una disminución del número de errores y una mayor mantenibilidad del código, con lo que hacemos que el tiempo total del desarrollo y los costes recurrentes de nuestros clientes disminuyan. ¿Acaso no pasa esto en otros sectores? ¿Acaso no prefieres pagar más dinero por un elemento de más calidad que nos asegure más durabilidad o menos problemas a futuro? Evidentemente siempre nos encontraremos con quien prefiere pagar menos (o dispone de menos dinero para gastar) y se decantará siempre por la solución más barata pero, desengáñate, siempre habrá alguien más barato que tú. Si quieres luchar por conseguir esos clientes entrarás en un sistema perverso en el que facturas por debajo de coste (si no lo haces tú lo harán otros) esperando a que una vez conseguido el cliente sea más fácil subir la tarifa. ¿Cuántas veces habéis visto que, cuando quieres subir la tarifa para cubrir tus costes, el cliente se decanta por un proveedor más barato? Mi idea es que si un proveedor cobra X por un trabajo de 1 mes y tú cobras 2X por ese mismo trabajo, a priori estás cobrando más dinero. Si el primer proveedor se retrasa un mes y sigue cobrando lo mismo, evidentemente el cliente estará pagando menos dinero pero tendrá que asumir un retraso. Si resulta que ese proveedor te cobra por horas al final estarás pagando lo mismo. Además, si después estás un año resolviendo incidencias o si después el código fuente acaba siento tan poco mantenible que necesitas perfiles extremadamente altos para resolver sus incidencias, te aseguro que los costes se multiplicarán exponencialmente.
En mi opinión todos deberíamos luchar en este sector para que todo el software que se desarrollase tuviese la máxima calidad. En ese momento podríamos usar términos como Ingeniero/a o Arquitecto/a con todas las de la ley. Seguramente al inicio podría resultar un poco caos porque, no nos engañemos, la inversión inicial necesaria para poner todo esto en marcha no es pequeña, y no todas las empresas están dispuestas a hacerla. Es nuestro trabajo educar primero a nuestras empresas, haciendo ver a las personas que toman decisiones lo importante de esta inversión y las ventajas que aportan a medio y a largo plazo, y de la misma manera hacer ver esto a nuestros clientes. Yo creo que con un poco de paciencia podremos conseguir grandes cosas en este aspecto.
En los siguientes artículos de esta serie os hablaré de dos cosas que necesitáis para convencer a la gente de la importancia del ALM: herramientas y métricas. Las herramientas nos van a ayudar a llevar todos los procesos necesarios a cabo, y las métricas nos van a servir para mostrar el valor del tiempo invertido de manera que sea entendible por personal no técnico. Imaginad, por ejemplo, que sois capaces de decir que el número de errores decrece en un 80% o que el porcentaje de código fuente cubierto por una prueba unitaria es del 95%. Con este tipo de datos no resulta demasiado complejo poner un número al lado indicando la cantidad de horas no malgastadas en mantener un código y que pueden ser facturadas en otro proyecto. En el momento en que ese número de horas se equipare con el número de horas utilizadas para montar las herramientas de las que os hablaré ya habremos hecho buena la inversión y, a partir de ese momento, el beneficio será evidente.
En fin, acabo aquí la introducción a este asunto que seguro que genera muchas discusiones. Seguro que al leer esto algunos pensáis que en vuestra empresa esto no es viable o que lo habéis probado pero no os han dejado. Después habrá gente que no estará de acuerdo con las herramientas que os iré exponiendo a medida que escriba los siguientes artículos y también habrá alguno que saque a relucir el eterno dilema de lo que es un arquitecto y lo que no lo es. Ya sabréis lo que diré: cualquier opinión tiene que ser respetada ;)
0 comentarios:
Publicar un comentario