Modas

Ayer en el periódico Expansión en su suplemento digital se hacía un resumen del IT Forum organizado por Accenture y contaba con la participación de responsables de tecnologías de la información de importantes empresas Españolas; en esta jornada también se presento el Estudio de costes de tecnologías de la información España 2003 ( me gustaría tenerlo, tengo que buscarlo). El periódico señala que los participantes coincidieron que la optimización de los costes y la rentabilización de los activos tecnológicos han sido una de las prioridades en sus empresas en el último año. Todas estas acciones deben conducir a aportar valor al negocio, y no sufrir un empacho de tecnología como ocurrió en el famoso boom y así apunta Julio Yepes del BBA "A la hora de plantearse la adopción de nuevas tecnologías, una actitud coherente es decir no a la tecnomoda" (el énfasis mío)

Desconozco los mecanismos de mi cerebro que me llevan a enlazar lo anterior con el comentario de hoy; que como todos los comentarios de este rincón son personales y no tienen más objetivo que obligarme a escribir para ordenar mis ideas y guarda aquellos enlaces que me parecen interesantes.

Al grano, considero que se deberían aplicar estos mismos planteamientos a los entornos de desarrollo de software. Desde hace años se vienen desarrollan muchas herramientas que ayudan a las tareas de desarrollo: aplicaciones para la fase de análisis, de diseño, frameworks, entornos de desarrollo, componentes y plugins para nuestros entornos ( de todos los tipos y colores), diferentes arquitecturas y diseños; es decir, “cositas” que nos permiten construir la aplicación que un cliente quiere. Haciendo un símil con la construcción de obra civil podríamos decir que son los andamios, grúas, maquinaria, ladrillos, tubos, cables...

El objetivo que tienen estas “cositas” es mejorar la productividad; generar menos código; desarrollos de mayor calidad, más robustos, que podrán evolucionar de manera más fácil, más segura y ... bla, bla, bla.

En la actualidad la velocidad de las nuevas versiones es alta, por lo tanto se reduce el tiempo entre una y otra versión. A esto le añadimos que un defecto que tenemos las personas que nos apasiona la tecnología es querer estar a la última: probar aquella última versión, incorporar a un proyecto aquel componente o framework o lo que sea que hemos leído que es lo "más de lo más". No discuto ni pongo en duda que las características de las siguientes versiones son casi siempre mejores y con mas potencial.

Pero, resulta que nuestros proyectos presentan el siguiente escenario:

+ Intereses del cliente: cumplir presupuesto y tiempo.
+ Cambios: esto es consustancial a cualquier proyecto de software, el que no lo tenga asumido, por favor que toque el timbre y se baje que este no es su vagón [de este tema en próximos comentarios]

Entonces si sumamos las nuevas “cositas” a los proyectos, acabamos desarrollando y aprendiendo a la vez. ¿Por qué creo que este no es el camino? Porque perdemos el foco que es construir una aplicación para el cliente. Es necesario centrarse en las características de esa aplicación en el tiempo, el presupuesto y la calidad determinada.

Si estamos continuamente incorporando nosotros mismos otros elementos que añaden más piedrecillas, lo único que conseguimos son retrasos y un aumento de presupuesto. Y poco valor para el cliente.

Además, existe otro efecto pernicioso es que al no tener tiempo para profundizar cada día se desarrolla peor. Parece que si no se desarrolla con una herramienta, con unos determinados componentes o con una determinada arquitectura es como si estuviésemos antiguados o haciendo un desarrollo de poca calidad. Y no, la calidad del desarrollo no tiene que ver el número, ni tipo de "cositas" que empleamos.

Por lo tanto, de la misma manera que cualquier empresa busca que su inversión en software aporte valor al negocio, deberíamos realizar el mismo análisis. ¿Qué valor nos aporta para el tipo de desarrollo que hacemos? ¿Concretamente que ganamos?¿Cuál es nuestro target de aplicaciones, de clientes? ¿Es una moda? ¿Es coherente con nuestra estrategia de desarrollo? ¿La podremos aplicar en varios proyectos? ¿Qué ocurre con las modificaciones de proyectos anteriores? ¿Qué riesgos corremos en introducirla en nuestros proyectos? ¿Y si no lo hacemos? ¿Qué capacidad de aprendizaje tienen nuestros desarrolladores? No me vale que dos gurus consideren que es lo último, si el resto de equipo no sabe de que va y no tengo tiempo para que tengan tiempo para aprender [recordatorio: trabajamos en equipo - esto es lo deseable- pero como mínimo en grupo]. No podemos introducir cositas y aún por encima pedir que se realicen en el tiempo determinado. Y muchas más variables que hay que analizar antes de ir de cabeza a descargase la ultima versión de estas cositas.

Ocurre que muchas personas de las que estamos en este sector hemos llegado por nuestras inquietudes bastante alejadas de nuestra formación universitaria; nuestro conocimiento ha venido de probar, cacharrear y en cierta forma jugar. Por eso en algunas ocasiones, nos confundimos o despistamos cuando toca una cosa y cuando toca la otra.

Cuando estamos en un proyecto debemos estar a lo que estamos; esto no significa que veamos para otro lado, en absoluto nuestra obligación es estar a la última, descargamos, experimentar y después una vez analizado incorporarlo a los proyectos, pero porque aporten valor a nuestros desarrollos no porque sea una moda y lo haga fulano y mengano.

Por cierto, para cuando empezamos con tapestry que ya toca, impresionante todo lo que va a suponer para nuestros desarrollos. La próxima moda, y sino al tiempo. No, nada de gurú es que es la historia de siempre.