Calidad de los proyectos informáticos

El debate de esta semana promete ser interesante, pues aborda uno de los puntos más críticos y delicados de la tecnología: la calidad del software.

Oigo a mis espaldas muchas insastisfacciones, tanto por parte de clientes, como parte de profesionales del mundillo, en la que la calidad deja mucho que desear. En la calidad de un software intervienen muchos factores, todos con una involucración más o menos directa, y que afectan, indudablemente a la calidad final de los productos que se desarrollan.

Podríamos comenzar por la educación, ya que en nuestras universidades y centros de formación se centran únicamente en la docencia, y en enseñar cómo programar en diversos lenguajes de programación, y alguna que otra disciplina relacionada. Pero nunca tratan la calidad del software, a no ser que algún profesor lo mencione de corrido en alguna clase, como algo anecdótico y en lo que se detiene a hacer menciones más detalladas.

Creo que todos los que hemos estudiado programación hemos hecho nuestras propias investigaciones con proyectos de iniciativa propia, y en los que hemos aportado toda nuestra voluntad y deseos. Pero eso no es suficiente. Si bien la programación es la base del negocio, ya que es la mano de obra, lo más importante es una parte organizadora y que coordine como un reloj suizo de alta precisión a todos los equipos. ¿De qué sirve un gran equipo de remeros si el timonel está borracho o ausente, el vigía en mitad de una siesta, el grumete jugando a las cartas y el capitán despachando a un par de profesionales del placer?.

Nos preparan para tirar código, pero no nos preparan para conocer todas las funciones del barco, cómo funcionan, las relaciones entre todas las partes y cuáles son las mejores prácticas para los distintos casos que se pudieran presentar.

Hay otro punto importante en el cual hay muchas asperezas: el intrusismo.

Es muy habitual encontrar en equipos a ingenieros salidos de la facultad, y a chavales que, mientras repartían pizzas o ponían ladrillos en una obra, han estudiado un curso en una academia sobre Java. Oto punto de fricción está en los diplomados y licenciados que nada tienen que ver con la informática o las telecomunicaciones: abogados, economistas, físicos, químicos, biólogos, geólogos, matemáticos, etc.

Hay una gran polémica en este sentido, pues un ingeniero informático se queja de que cobra lo mismo o menos que un chaval con un certificado de estudios académico que le ha supuesto, en el peor de los casos, un año de estudios. Y otro punto de fricción es el hecho de un ingeniero informático ha hecho una carrera completa dedicada exclusivamente a la informática, y se le ningunea con otros compañeros que sólo conocen el lenguaje de programación, y no las teorías y detalles que hay detrás de la carrera.

Yo he conocido compañeros que no eran informáticos de carrera (tanto académicos como universitarios), que eran muy buenos programando, así como compañeros que eran informáticos de carrera que no valían mucho como profesionales del sector. Ante todo, la actitud de la persona individual como profesional es la que impera, y las ganas de realizar el trabajo y aprender cosas nuevas.

Lo que es innegable es la cantidad de ocasiones de las que he sido testigo, en las cuales un "no informático" (intruso es una palabra que no me gusta) se quedaba bloqueado ante una situación en la que era necesario explotar ciertas dotes especiales, como la algorritmia. Y lo que también es innegable es que un "no informático" cuenta con las mismas posibilidades de carrera y de evolución, además de sueldo.

Otro factor que ha existido (y que sigue existiendo), es la contratación de universitarios "no informáticos" para puestos de más alta calificación que un informático, como consultores de negocio y como analistas funcionales, pensando en que sus mentes no tienen vicios informáticos y que les permiten dilucidar mejor los requisitos de cualquier tipo de negocio. Es una mentalidad un tanto errónea, pues un "no informático" piensa cómo y en lo que le han enseñado en la carrera (física, química, economía, geología, etc.), al igual que cualquier otro universitario.

Además, en la facultad de informática ya te preparan para las labores de análisis, tanto funcional como técnico, asociado a la informática. Esto no se enseña en ninguna otra carrera, y aún menos en una academia. Por tanto un ingeniero informático está preparado para labores de análisis.


Muchos compañeros míos me han comentado que nos falta un Colegio de Informáticos oficial, y que de esa manera se acabaría el intrusismo. ¿Y sólo para éso? ¿Para acabar con el intrusismo?. A mí me parece que el problema no es el intrusismo, si no las ideas preconcebidas a la hora de asignar los mejores profesionales en cada labor. Yo estoy a favor de un Colegio Oficial de Informáticos, pero no para acabar con el intrusismo, si no para contemplar y velar por la calidad y el buen desempeño de los profesionales adscritos a él, así como extraer el conocimiento para que el sector crezca en calidad y en profesionalidad, y, sobre todo, en la confianza del cliente, en la que un cliente pueda confiar en un informático con el mayor de los respetos, al igual que un paciente en un médico o un acusado en un abogado.

Otro punto importante es que un informático no conoce un determinado negocio, y lo debe ir aprendiendo durante su carrera profesional. Puedes ser el mejor experto en Java y frameworks, pero si te metes en un proyecto para seguros o banca, y de esto no tienes ni idea, mal vamos.

Algunos me recriminareis: un programador no debe preocuparse por eso, ya que son los analistas los que extraen los requisitos e identifican las funcionalidades del negocio. Bueno, no olvidemos que un analista ha sido primero un programador, y que al evolucionar en su carrera asciende a este grado. Pero un informático (ni nadie) no está preparado con antelación para conocer un determinado negocio, si no que lo debe aprender con la experiencia. A lo largo de su período como técnico desarrollador comienza a aprender ciertos patrones de negocio que pueden reproducirse en otros negocios, así como identificar de manera instintiva nuevos patrones de negocio y entenderlos.

Cuando alguien se tira sus primeros meses o años de profesión en (por ejemplo) las telecomunicaciones, si accede a un proyecto de seguros, no es de extrañar que se pierda. El negocio de los seguros es muy distinto al de la telefonía o al de las redes de internet. Esta falta de conocimiento impacta en el desarrollo del software: requisitos mal entendidos, falta de previsión en detalles de negocio por desconocimiento de ciertos procesos, funcionalidades no detectadas, etc. Al final, esto se traduce en retrasos y sobrecostes.

Lo que quiero decir con estos últimos párrafos es que las empresas consultoras no tienen en cuenta el tipo de negocio. Piensan "un informático hace churros con plastelina, masa de harina o con una piedra". Y este planteamiento es equivocado. Suelen asignar profesionales a negocios en los cuales no se han formado y que desconocen. Y esto es una barrera importante a la hora de realizar un proyecto con calidad.

Otro factor muy determinante es la organización de las empresas de informática, especialmente las consultoras. Y lo digo por multitud de casos, entre los que resaltaré sólo unos pocos.

Sigue existiendo el perfil de un comercial que sólo piensa en comisiones, y que hipoteca un proyecto de forma equivocada a costa del trabajo, de la dignidad y de la profesionalidad de los informáticos. Ya sé que me he metido con los comerciales, pero no con los comerciales en general. Conozco algunos comerciales que sí saben hacer su trabajo con arreglo a la realidad.

Sigo viendo algunos comerciales que venden proyectos imposibles. Se pasan a pedir información sobre la previsión de un proyecto, y luego recortan los tiempos y el presupuesto. No hacen caso a las estimaciones ya de por sí ajustadas de los profesionales que van a sudar trabajando en el proyecto, que se van a quedar noches y fines de semana trabajando para alcanzar un objetivo imposible a costa de la comisión del dicho comercial. Son comerciales que cuando les dices que necesitas un mínimo de tres meses con un equipo de diez personas, se cabrean contigo porque no pueden vender el proyecto de esa manera, y para hacerlo, preparan una oferta con un tiempo de mes y medio y seis personas. No saben hacer un "NO GO" al proyecto, ni presentar la oferta acorde a las estimaciones de los profesionales que SÍ saben cuánto cuesta hacer el proyecto, aunque no sepan vender.

En proyectos así, que están tan deficientes en tiempo, en los que la productividad se mide por número de líneas, clases, funciones, pantallas, etc., hechas en un tiempo mínimo, es cuando destaca la falta de calidad. El cronómetro es el peor enemigo de la calidad del software, porque la productividad no es realmente efectiva. Puedes hacer cuatro o cinco pantallas al día, pero si tienen que volver a tí diez veces para que corrijas errores, al final vas a dedicar más tiempo y esfuerzos que si la hubieras hecho con una calidad mínima. Al final se traduce en más tiempo y en más coste para el proyecto.

No hay una visión de calidad en los proyectos precisamente porque no se da el tiempo necesario, ni se aporta un equipo experto, dedicados exclusivamente a la calidad del software. Cuando se planifica un proyecto, normalmente no aparecen fases suplementarias de calidad en el project, ni siquiera unos recursos asignados especialmente dedicados a estas tareas. Tampoco se prevee unos procesos de calidad en el proyecto, tales como definir unos casos de prueba en los requisitos, y que el usuario o cliente esté de acuerdo con dichos casos de prueba del sistema y acepte los requisitos con dichos casos de prueba, los cuales no hacen si no aportar un punto de control para verificar que el producto cumple con correctamente con el requisito, y que éste ha sido correctamente entendido.

Pero la calidad en el software no es suficiente, amigos. La verdad es que mejora la calidad del producto, pero no nuestros vicios de trabajo. Podemos conseguir un producto bueno y se recortan sustancialmente los costes (debidos a correcciones, garantía, etc.). Pero hay que mimar también la calidad en los procesos de desarrollo.

Este tipo de calidad la aportan las metodologías, tales como Métrica, ISO, CMMI, PRINCE o ITIL (por mencionar sólo algunas). Dichas metodologías contienen un compendio de buenas prácticas en cada uno de los procesos de desarrollo de nuestro negocio: en la oferta, en la planificación, en el análisis, en la construcción del sistema, en las pruebas, en el mantenimiento, etc. Obviamente, cada proyecto es distinto, pero conocer bien la metodología nos permitirá adecuar la metodología al mismo.

Muchas empresas anuncian a bombo y platillo que implementan una metodología, y en las ofertas es un punto de decisión de compra importante. Pero la mayor parte de las veces no se aplican, principalmente debido al tiempo irrisorio con el que se cuenta para desarrollar el proyecto, porque no se dedican los recursos ni los medios necesarios para el desempeño y cumplimiento de la metodología, y porque las empresas normalmente no se preocupan de tener personal formado o dedicado a ello, o si lo tienen, lo tienen atendiendo otras tareas de distinta finalidad.

¿A alguien le suena cosas como: no hay documento de requisitos, se acaba el proyecto y no hay un análisis, no hay un plan de pruebas, no hay documentación, se empieza a desarrollar antes de tener un documento de requisitos aceptado por el cliente, no hay actas de las reuniones, los comités de seguimiento se realizan tarde y cuando hay crisis, no hay una matriz de riesgos, no hay control de la configuración, se acomete un proyecto en una tecnología y no tenemos a nadie que sepa de ésto, y así, una infinidad de barbaridades más que no se tienen en cuenta? ¿A alguien le suena los típicos proyectos de un mes, y luego el cliente pide y pide sin fin requisitos y terminamos en seis meses, y encima casi a tortazos? Una metodología evitaría éstos y otros muchos problemas.

Para que ese barco navegue seguro por los siete mares es imprescindible varias cosas:
- En la carrera de informática deberían enseñar una materia dedicada a metodologías.
- Crear un Colegio Oficial de Informáticos, en las que haya varias categorías:
- Ingenieros Informáticos.
- Ingenieros, diplomados y licenciados no informáticos.
- No ingenieros (no diplomados, no licenciados). Nivel académico.
- Dar oportunidades ajustadas y acordes a las categorías anteriormente citadas. Recordemos que un ingeniero informático ha estudiado una especialidad, con más conocimientos en este campo que el resto de categorías, y que debería tener más derechos, oportunidades y responsabilidades que el resto de adscritos.
- En las ofertas comerciales respetar escrupulosamente, como se hacen en otras especialidades (como arquitectura, ingeniería de caminos, ingeniería industrial, etc.), la valoración realizada por un ingeniero informático. Quien conoce perfectamente las capacidades, experiencias y riesgos en la ejecución de un proyecto es un informático, no un comercial.
- Cada empresa informática debería contar con profesionales en calidad y aportar su experiencia en todos los proyectos que se ejecuten.
- Aplicar escrupulosamente las metodologías, y tener un seguimiento y control exhaustivo con los clientes de la aplicación de estas metodologías.
- Realizar periódicamente auditorías externas de calidad y de metodología, a ser posible oficiales, como si fueran inspecciones. De esta manera se aseguraría la calidad de la empresa y de sus profesionales.

Estas ideas son personales, aunque me encantaría conocer tus ideas, tus opiniones, tus críticas o tus puntos de vista. Por favor, déjame un comentario, teniendo en cuenta que será moderado, y por tanto, cualquier insulto, descalificación o mención concreta a una empresa o persona, será omitido.

¿Se acabó la creatividad tecnológica?

Cuando miro a tan sólo unos pocos años me doy cuenta de que estamos viviendo una madurez en el mundo de la tecnología, especialmente en el mundo del software.

Atrás quedaron las constantes revoluciones que día a día me sorprendían, las contínuas versiones de algún producto que, a velocidades verteginosas, incorporaban innovadoras ideas en un lapso de tiempo muy reducido. Atrás quedaban las originalidades, las virguerías y las promesas de nuevas funcionalidades.

Por un lado, el mercado no exige tanta innovación, pues lo que hay es mucho más que suficiente para prestar la mayor parte de prestaciones en un determinado producto. Por ejemplo, ¿qué más se le puede añadir a un office que realmente sea útil y aceptado por la mayoría de los usuarios?. Creo que se pueden añadir muchas cosas, pero, ¿será útil para un usuario medio o sólo para contados usuarios?.

Lo vemos también en el mundo de los videojuegos, tan innovador y tan fresco. Ya no se hacen juegos revolucionarios, si no se perfeccionan los juegos en cuanto a gráficos, realismo, efectos, sonido, 3D y algún que otro detalle, pero no añaden nada nuevo. Incluso se hacen remakes de los clásicos.

En el mundo de los sistemas operativos también parece haber estancamiento, y lo único que aportan son más programas para completar un CORE ya desfasado. A pesar de las interfaces gráficas en 3D y de los efectos especiales y las transparencias, parece no haber ideas nuevas. Seguimos dependiendo de la ventana y del ratón. La pantalla táctil sólo se aplica a TPV's y PDA's para aplicaciones muy concretas, y el reconocimiento de voz sigue sin ser fiable y reconocido.

En el mundo del diseño seguimos con las mismas aplicaciones que antaño revolucionaron este mundillo gracias a los sistemas operativos gráficos, basados en ventanas. Se van ampliando efectos, pero la forma de trabajar no ha cambiado en absoluto, y todos los programas son muy parecidos unos a otros.

Quizá fuera necesaria esta madurez, y amortizar las inversiones a un tiempo más prolongado, tanto por parte de los fabricantes como por parte de los clientes. También es bueno tener la seguridad de tener productos estables y sin sorpresas.

Pero estaría muy bien tener mentes innovadoras, que con su fuerza creativa vayan evolucionando aún más nuestro mundo, con ideas sencillas, ingeniosas y espectaculares, pero, sobre todo, útiles.

En el mundo del hardware y de los gadgets van a apareciendo nuevos artilugios innovadores, los cuales también toman el relevo de ideas anteriores. Por ejemplo, el blu-Ray o el HD-DVD no son si no una evolución o perfección del DVD, y éste del Laser Disc o del CD. Añaden más funcionalidades y más capacidad, pero el concepto es el mismo. Los televisores de plasma o LCD evolucionan de una tecnología anterior, que ya venían de los primeros ordenadores portátiles. Reducen el tamaño, ganan rapidez y nitidez. Pero el concepto es el mismo. Los reproductores, las PDA's, los teléfonos móviles... no hacen si no condensar funcionalidades que ya existían en nuevos aparatos más reducidos, pero el concepto ya existía. El RFID es un concepto que viene de después de la Segunda Guerra Mundial, y que ahora la microtecnología puede hacer realidad.

¿Crees que se ha acabado la creatividad tecnológica? ¿Crees que ya no se puede inventar nada nuevo? ¿Crees que las revoluciones son lo suficiente maduras como para innovar en el mercado? ¿Crees que las funcionalidades de las tecnologías actuales son más que suficientes y sobradas para nuestro mundo?
¿Necesitamos nuevos gurús que den un nuevo empujón a la tecnología? ¿O crees que la tecnología ya debe ser más social y ayudar a aquellos lugares de este mundo donde más se necesita para que puedan ayudar en lo que ya nos ha ayudado a los afortunados del Primer Mundo? ¿Acaso la tecnología no está preparada y madura para afrontar el reto de los grandes peligros que asolan nuestro mundo, tales como el calentamiento global, la desertización o la pobreza?

¿Es real la profesionalidad de los empleados TI?

El viernes pasado estuve comiendo con mi buena amiga Esther, quien trabaja en recursos humanos de una consultora multinacional de tecnologías de la información. Entre los distintos chismes de los cuales estuvimos hablando, apareció un tema interesante.

Para ella era preocupante el nivel que se estaba poniendo los sueldos y las categorías en nuestro sector, en las cuales, algunas consultoras, con tal de quedarse el cliente, eran capaces de ir bajo costes.

La compañía de mi amiga, al igual que la mayoría de las consultoras en el mercado español, trabajan con acuerdos marco con las grandes consultoras o con las grandes compañías que contratan sus servicios. Independientemente del salario mínimo y máximo que marcan los convenios, los contratante estipulan un rango de salarios para cada una de las categorías profesionales. Y de entre las consultoras que ofrecen sus tarifas, las contratantes escogen las de los precios más bajos y, a la vez, con mayores garantías, cumpliendo así ciertas certificaciones que imponen las contratantes.

Hasta aquí la cosa sería lo correcto, pero la sorpresa aparece cuando hay empresas que van bajo costes, contratando personal muy poco cualificado que exige un sueldo que ni yo, en mis buenos tiempos, podía soñar. Hay casos en los cuales un recién licenciado o un trabajador con apenas meses de experiencia, exigen sueldos de entre 20K y 30K (miles de euros), siendo lo más habitual encontrarse más cerca de los 30K. Asimismo, se pueden ver cómo chavales que aún no tienen la carrera terminada, ya van siendo contratados como consultores o analistas junior, en lugar de pasar por el obligado pase de programador junior y programador senior.

Lo más alarmante de todo, es que ella no puede contratar a estos "lechones" con esas categorías y esos sueldos "inflados", y encima otras consultoras sin escrúpulos se los llevan aceptando esas condiciones. Contra estas prácticas ella no puede luchar, pues los precios están cerrados en los acuerdos marco.

Uno cabe preguntarse que si estas consultoras "tragan" por esas condiciones, es que en realidad, o están palmando dinero con tal de conseguir entrar en el cliente (contrataciones estratégicas), o bien están ofertando al "lechón" como un profesional ya consagrado y con mucha experiencia. La primera opción es un riesgo, pues no hay provisiones en caso de penalizaciones y, con el agravante de el lechón pueda querer más y repetir esa práctica nuevamente fuera de su nueva empresa. La segunda opción es también un riesgo si la empresa contratante descubre la maniobra y se siente engañada, con lo que introduciría a la consultora en la lista negra de proveedores "non gratos".

Ante ésto uno se hace mil y una preguntas. Por un lado, si estamos otra vez ante una burbuja tecnológica como ocurrió a finales de la década de los noventa, inicio del año 2000, en donde un pinchazo haría resentir nuevamente los cimientos de nuestro mercado laboral. Yo creo que no, pues ya tenemos experiencia, y las empresas ya tienen cubiertas las espaldas con auténticos profesionales.

En el debate de esta semana invito a participar a todos a dar su opinión y a contar sus propias experiencias. ¿Qué crees que está ocurriendo en el mercado laboral?. ¿Son tan habituales estas prácticas?. Si no eres de España, ¿cuál es la situación en tu país con respecto a la contratación de profesionales en TI?. ¿Hay datos que se me han pasado al hacer la exposición de este artículo?. ¿Quién tiene la culpa, el empleado "listo" o la consultora?. ¿Quién engaña a quién?.

Tu opinión es importante y bienvenida. Los comentarios son moderados, por lo que se omitirán aquellos comentarios con descalificativos a personas, organizaciones o empresas.

¿Hay una evolución real y útil del hardware y del software?

Hay un viejo chiste que decía que la diferencia entre el hardware y el software era que, el primero, con el tiempo tendía a ser más pequeño, rápido y económico, mientras que el software, con el tiempo, tendía a ser más grande, lento y caro.

Este podía ser el inicio de nuestro debate semanal.

El hardware evoluciona a un ritmo muy acelerado, haciendo cumplir desde 1965 la ley de Moore, en la que cada dos años se duplica el número de transistores de un ordenador.

¿Quién podía imaginar que podíamos ver hoy en día una película en color en un aparato reproductor MPEG4, de menos de 100 gramos y que tiene un tamaño inferior a una tarjeta de crédito?. ¿Quién podía imaginar que en apenas 20 años hemos pasado de un ordenador casero de 4 Mhz (Spectrum, Amstrad, MSX...) a uno de con tecnología CORE Duo e incluso de 8 núcleos, de varios gigaherzios?. ¿Quién podía imaginar que podía tener una cámara de fotos y de vídeo de alta resolución dentro de un teléfono que ocupa menos que la palma de la mano?. ¿Quién podía imaginar el almacenamiento de cientos de gibabytes en dispositivos sin elementos mecánicos como una memoria Flash?. ¿Quién podía imaginar tener un ordenador multimedia en la palma de la mano, gracias a las PDA's?. ¿Y unir la tecnología PDA, con la multimedia y la telefonía móvil a través de smartphones?. ¿Quién podía imaginar que una simple consola de mano tiene un procesador con más potencia que un ordenador de sobremesa?. La lista de ingenios hardware es muy extensa, y día a día sigue sorprendiéndonos la aparición de un nuevo gadget, un nuevo producto con más y más funcionalidades. Claramente se ve una evolución en el hardware.

Pero, ¿y qué pasa con el software?. ¿Está evolucionando realmente el software?

Cuando uno hace un repaso, ve que el software parece estancado y poco dado a evolucionar. Hubo una época que pasamos de las pantallas de texto a las gráficas, y que la multimedia empezaba a sacar provecho de un hardware más humano e intuitivo. Pero aquellas ideas florecientes se han quedado estancadas. Acaso se añaden nuevos plug-ins con algún efecto más, o alguna funcionalidad más.

Los sistemas operativos gráficos apenas han evolucionado. El sistema de ventanas sigue ahí desde hace 20 años, con algún efecto que otro, pero sigue siendo el mismo sistema.

Los lenguajes de programación tampoco han evolucionado. Tienden a añadir librerías y frameworks que a veces suponen capas de cebolla innecesarias en muchos casos. A veces usamos tecnologías con frameworks para ir a la última, no porque la aplicación lo necesite. La mayor parte de las veces tienden a engordar innecesariamente los programas, que se ven penalizados por la velocidad y el uso de memoria. Pero eso ya no importa: nos sobra memoria y además es muy barata.

Ya no se realizan algoritmos que exprimen la potencia del lenguaje, haciendo en menos líneas y en menos tiempo, un complicado proceso. No me refiero a algoritmos ya establecidos, como los de ordenación o de búsqueda. No es necesario reinventar la rueda y se pueden reaprovechar librerías que ya lo hacen. Me refiero a la hora de programar procesos, estamos inmersos en la productividad, no en la calidad. Apenas nos detenemos para reutilizar aún más el código creando librerías versátiles, o para crear algún algoritmo que potencie la eficacia de nuestro software.

Los lenguajes de programación, así como los programas, poco han evolucionado. Java causó un furor, cuando lo que hizo fue recopilar lo mejor del C y lo mejor de la programación orientada a objetos, automatizar los procesos de limpieza de memoria y de punteros, y agregarle el uso de un runtime, como hacía el GWBasic y otros lenguajes muy anteriores. La capacidad de reutilización de librerías, ya venía de muy atrás con C y Pascal, por lo que poco se inventó.

Las aplicaciones Web son básicamente aplicaciones de terminal tonto, tal y como se hacían en los albores de Cobol y del RPG, sólo que ahora un navegador web se encarga de pintar las interfaces de usuario, y poder pintar algún gráfico.

Las aplicaciones RIA, como puedan ser las de AJAX o de Flex, vienen a sumarse a lo que ha habido siempre, pero con la posibilidad de crear algún efecto espectacular y de consultar y actualizar información desde el servidor sin necesidad de repintar de nuevo. Pero la esencia sigue siendo la misma.

Cierto es que ha habido algunos framework que han salido victoriosos, tales como CrossFire, Spring o Struts. Pero, analizando estos framework, lo único que han hecho realmente útil es facilitar al programador su trabajo, y que éste se concentre en lo realmente útil para él: ser productivo y despreocuparse del trabajo duro.

Creo, sinceramente, que la evolución debe ser interpretada también como la satisfacción de las necesidades. Conocemos de infinidad de innovaciones que han caído en el olvido precisamente porque las necesidades ya estaban cubiertas y dichas innovaciones, brillantes e ingeniosas, no eran necesarias. Recordemos el caso del sistema Beta de vídeo o de algunas consolas que fueron muy superiores a lo que el público esperaba de ellas.

El hardware evoluciona sin frenos, muy por delante de la evolución del software. Pero, ¿realmente esa evolución está al nivel de satisfacción de las necesidades del consumidor? ¿O está muy por delante de dichas necesidades?.

El usuario medio utiliza su teléfono móvil únicamente para guardar una agenda, llamar, recibir llamadas, escribir y leer mensajes SMS, y, opcionalmente, sacar alguna foto. El resto de funcionalidades apenas son utilizadas, salvo para probarlas y ver que existen y que funcionan. No necesita de un teléfono 3G y aún menos un 4G.

El usuario medio de un ordenador casero, navega por internet, chatea, escribe documentos, descarga películas o música, y se echa alguna que otra partidita con algún juego, no necesariamente novedoso. Es un ordenador de ocio, y para trabajar le sobra con un paquete de oficina medio. No necesita un ordenador de varios núcleos. De hecho, el mercado de segundamano es una opción interesante para un usuario medio.

Por otro lado, asistimos, desde hace tiempo, a una congelación de evolución del software. No aparecen importantes novedades en las características de un programa informático. De hecho, el versionado se extiende en el tiempo (antiguamente había varias versiones por año, y ahora pueden pasar varios años para una nueva versión de un producto), y las diferencias reales van más por la apariencia que por nuevas funcionalidades ingeniosas.

Pero esta involución del software quizá sea realmente una evolución. Quizá haya realmente una madurez en el software, que todo esté ya inventando, y que lo que se hace es mejorar y perfeccionar lo que ya existe, al igual que en el mercado del automóvil. Lejos de la innovación, se asiste a un perfeccionamiento y a una mejora de la calidad de lo que ya existe.

Hace poco, un importante jefe de software de IBM, adujo que el software no ha evolucionado, y que está muy lejos de las últimas novedades del hardware, abriéndose una brecha enorme entre el hardware y el software. Es posible que el software no haya evolucionado con respecto al hardware, pero sí ha evolucionado con respecto a la satisfacción de las necesidades de los usuarios.

Las innovaciones del hardware son buenas y necesarias, y todo lo último sólo satisface a aquellos que se dan el capricho de satisfacer su afán de posición, no sólo sus necesidades. Google, al ser la empresa de mayor calado mundial, podría utilizar supermegaordenadores usando la tecnología de los "petas" (el concepto de Giga ya no existe aquí), con superservidores como el del centro de energía atómica de Francia. Pero Google basa su negocio en una red de ordenadores PC de segunda mano, que satisfacen plenamente sus necesidades y a un coste muy inferior.

¿Y tú?. ¿Crees que hay evolución en hardware o en software?. ¿Crees que si hay una evolución real, ésta es realmente útil?. ¿Conoces casos o tienes experiencias al respecto?. ¿Qué opinión tienes?.

Tu opinión es importante y bienvenida. Los comentarios son moderados, por lo que se omitirán aquellos comentarios con descalificativos a personas, organizaciones o empresas.

¿Está corrupto el gremio de la consultoría informática?

Esta semana toca un tema bastante polémico, por lo que os rogaría fuéseis lo más asépticos posible en los comentarios.

En multitud de ocasiones he tenido este debate más o menos acalorado con compañeros, a la calidez de un humeante y aromático café, o en torno al pinchito de los viernes. Un debate que nos apasiona y nos preocupa, pues es nuestro día a día, nuestra forma de vida.

En líneas generales veo un gran descontento, especialmente para aquellos que empiezan en este mundillo, con el petate a la espalda nada más salir de la universidad, y muchos de ellos recorriendo grandes distancias, porque en sus provincias y en sus pueblos no hay trabajo en informática, sea cual sea la forma de dicho trabajo. También le pesa a los veteranos, especialmente en aquellos que siguen en la parte técnica, que están hartos de trabajar y no ver más que al mismo perro pero con distinto collar.

La visión desde otros gremios es que somos seres superdotados y con un cerebro especial, y por ello vivimos en mundo de cojines de pluma, con todo tipo de comodidades, haciendo lo que nos gusta y cobrando más que el resto. Ese mundo de sueño se desvanece una vez estás dentro y te encuentras metido en una trampa de la cual ni puedes ni quieres salir, como una droga.

Llevo más de veinte años trabajando en el mundo de la informática, más de diez en la consultoría, y he visto y he vivido de todo. Pero no por ello dejaré de sorprenderme, ya que las empresas son seres vivos, creadas y gestionadas por humanos que, como ya he dicho en alguna ocasión, es el ser más estúpido de cuantos existen (yo me incluyo en esa descripción).

La consultoría informática es un mundo aún muy joven y quasi virgen. Experimenta una vertiginosa explosión de colores, olores y el nacimiento de pequeñas criaturitas zumbadoras picando de flor en flor. Todo muy bonito, como en un anuncio de compresas.

El ciclo de la vida es simple: debe haber depredadores de todo tipo. El pez grande se come al pequeño, y el león macho debe morir joven para que la extirpe sea renovada por otro león macho joven.

La globalización y la feroz batalla de las grandes consultoras multinacionales es un hecho innegable, y para sobrevivir hay que tener resultados evidentes que justifiquen la eterna lucha por la supremacía del entorno. ¿Cómo conseguir esos resultados?. ¿Qué importa?.

Llevamos años viviendo el efecto "mente-factoría". Consiste en que las grandes consultoras se dediquen sólo al trabajo de la mente. Eso implica ganar ofertas y realizar el trabajo de organización, planificación, gestión y hasta de toma de requisitos. El resto del trabajo se delega a las "factorías de software", en países menos desarrollados, donde la mano de obra es irrisoria. Esto, bajo la máscara de desarrollo en aquellos países y la imagen altruista de los patrones ricos, esconde una estrategia de beneficios lucrativos con un margen aún mayor del que ya existía. Todos conocemos países "software-factory" como La India, ahora China, los países del este de Europa y la América del centro y del sur.

Dentro de las empresas consultoras vivimos operaciones que a veces creemos suicidios o delirios, debido a prácticas a veces deshonestas, otras de ignorancia, otras vanidosas... de ciertas cabezas de la hidra de la consultoría.

Los comerciales son una parte fundamental de la consultoría, pues gracias a ellos se genera el negocio y, por ende, el trabajo y el dinero que paga nuestras nóminas. Hace tiempo pecaban de ignorancia en este mundo, y les hacía cometer multitud de errores, principalmente de dimensión de proyectos. Hoy en día, los comerciales tienen una buena cultura tecnológica y aquellos errores no son tan corrientes.

Pero los comerciales son humanos, y siguen viendo negocio, comisiones y resultados. Esto, junto a las presiones de los proyectos, puede hacerles "vender motos" que no existen con tal de alcanzar las cifras, sin importar las implicaciones que los equipos técnicos tendrán que sufrir, y a los cuales se les culpará de construir una Vespa achacosa en lugar de aquella Harley Davidson de diez mil centímetros cúbicos, con radio estéreo MP8 con 200 altavoces y 30 tweeters, con 10 ruedas de 325 con llantas de aleación titanio/oro de horma ancha, y 25 tubos de escape que se le vendió al cliente.

Quiero aclarar que no todos los comerciales realizan estas prácticas, y conozco auténticos profesionales, honestos y competentes en las lides de la venta. Pero es innegable que sigue existiendo el rol del charlatán, como en cualquier gremio.

Por otro lado tenemos directores y consejeros delegados que sólo ven negocio y más negocio. No ven a las personas que levantan ese negocio, que sacan adelante ese negocio, que hacen posible con su sudor ese negocio. Directores que les hace falta honestidad y, sobre todo, humildad.

Hace poco estuve trabajando en una consultora en la que su consejero delegado se preciaba de sacar sólo proyectos cerrados y que no entrarían en las prácticas de "boddy shopping", por amor a las personas. Tras trabajar un año en esta compañía, en un kick-off, este mismo personaje se jactaba de estar "abriendo melones" en América del Sur gracias a factorías del software, y que el negocio en mi país iba creciendo gracias al "body shooping".

No sólo se había pasado al "lado oscuro" de la consultoría, si no que además se jactaba de ello, ya que estaba obteniendo resultados como nunca, y la esperanza de crecimiento en apenas dos o tres años era exponencial en cuanto número de empleados.

Su humildad, además, se hizo irónica, ya que se burlaba con guasa, precisamente, de empresas número uno mundiales, con decenas e incluso centanas de miles de empleados en todo el mundo. Las ninguneaba como si fueran bichitos pequeños. Soberbia y vanidad del consejero delegado de una empresa que no alcanzaba los doscientos empleados en España.

Otra empresa para la que trabajé hace algunos años, dió como beneficios 1000 millones de pesetas. Pero nadie vió (y aún menos recibió) los beneficios prometidos en el variable.

La empresa seguía creciendo en número de empleados, aunque yo veía como nos íbamos acumulando en las salas, y todos desasignados, sin proyecto. Al final, no podía aguantar más y me fui a otra empresa.

Al poco tiempo, se cerró ese año con un agujero de más de mil millones de pesetas, y con más de doscientos empleados en la calle, con una mano delante y otra detrás, con tres meses de sueldo sin percibir.

Esta es una anécdota que es la tónica de directores "langosta", que van arrasando con las cosechas por donde pisan. Y lo peor de todo es que son más voraces cuanto más grandes se hacen.

Suelo ser empático, y me gusta ponerme las gafas de todos: la del director, la del gerente, la del jefe de proyectos, la del comercial, la del técnico, la del becario... Quiero sentir lo que sienten, y ver el conjunto en su justa medida. Creo que al final es como todo: no se puede achacar la culpa a una empresa, si no a las personas que formamos las empresas. Puedes entrar en una empresa "buena", pero dar en un proyecto con personas de trato extremo y poco honesto. O bien dar con una empresa "de las peores", y dar con un proyecto y personas de las mejores.

He contado alguna anécdota, pero existen innumerables anécdotas, cada cual más increíble, pero cierta. Se verterían mares de tinta para escribir todas ellas. y el post sólo pretendía remarcar algunos puntos por los que empezar un debate.

¿Crees tú que hay corrupción en el gremio de la consultoría informática?. ¿O son las personas las corruptibles, y por consiguiente, corrompen su entorno?. ¿Qué crees tú que se puede mejorar?. ¿Qué experiencias tienes a colación de este tema de debate?

Tu opinión es importante y bienvenida. Los comentarios son moderados, por lo que se omitirán aquellos comentarios con descalificativos a personas, organizaciones o empresas.

¿Son realmente útiles las metodologías del software?

CMMI (Capability Maturity Model Integration), SPICE, Métrica, Prince2, RUP (Rational Unified Process), XP (eXtreme Programming), MSF (Microsoft Solution Framework)... ¿Hasta qué punto una metodología del software es realmente útil?.

La historia del software es aún muy reciente, y le queda aún mucho por madurar. En esa infancia avanzada, cercana a la pubertad, la criatura experimenta muchos cambios en su propia naturaleza, a ritmos frenéticos y sin saber por qué. Y ese huracán de metamorfosis interna es la que está sacudiendo cada célula de esa criatura llamada software.

Desde los primeros pasitos de la criatura, el padre de la misma ha visto necesario crear un ángel de la guardia para velar por su seguridad y por un crecimiento sano y sin peligros. Dicho ángel protector dejaría tranquilo al padre bajo la falsa esperanza de un futuro mejor para el retoño.

La vida real nos demuestra que no existe ni el padre ni el hijo perfectos. Que cada ente es diferente, y que todo lo planeado se viene abajo en cualquier momento, porque las circunstancias son caprichosas y Murphy es un bromista ingenioso que juega alevosamente.

Las metodologías hacen el papel del ángel protector, y fueron creadas por el padre que es humano, el más estúpido de todos los seres, el que más yerra, el que en su nube de soberbia y en su falsa perfección cree tenerlo todo controlado. El rol de las metodologías es definir y aplicar un conjunto de Best Practices (mejores prácticas), con el que en teoría, el retoño se formará, se educará, crecerá y madurará de la mejor manera posible. Pero ya sabemos todos que una cosa es la teoría y otra cosa bien distinta es la práctica.

La perfección de este mundo se basa en que todo, absolutamente todo, es libre de ser imperfecto y de tener un margen muy amplio para el libre albedrío y el caos (qué bonito me ha quedado). Poner orden en este mundo caótico es una labor muy ardua y difícil, que requiere un consumo de energía, una dedicación y una constancia muy grandes. Un descuido en la tarea significará que todo ese esfuerzo sólo ha servido durante ese tiempo. Eso es como construir un castillo de naipes o un gran circuito de fichas de dominó y pretender que duren siempre. Aunque se protejan dentro de un búnker, siempre habrá un momento, tarde o temprano, en el que una leve vibración, el peso de una mota de polvo, o el desgaste natural del tiempo en las moléculas de los componentes, haga perder el equilibrio de la obra. ¿O quizá ese equilibrio antinatural en realidad era un desequilibrio para la propia naturaleza del caos?.

Retomando el hilo del artículo, las metodologías pretenden perfeccionar el desarrollo del software, y para ello se definen baterías de consejos que funcionaron muy bien en algunos casos, y que lograron con éxito algún aspecto o detalle de la vida de un porcentaje importante del software existente. Viene a ser como decir: "con buenos chuletones de buey y mucho ejercicio, tendrás un muchacho musculoso y perfecto". Eso podría funcionar con un porcentaje elevado del censo actual de niños, pero hay que tener en cuenta que muchos niños no pueden realizar ejercicio debido a algún problema de salud, o bien no les gustan los chuletones o bien desean un mundo más intelectual que deportivo.

El gran error de las metodologías es, precisamente, creer que van a lograr que obtengamos un software perfecto, ya que cada proyecto, como cada niño, es diferente, con entidad propia, y requerirá de una serie de atenciones distintas en cada caso. Los consejos están muy bien, pero no funcionan siempre con todos los proyectos.

Hace tiempo trabajé para un importante banco, en el que las metodologías suponían un lastre burrocrático, que hacía más daño que bien en el desarrollo de los proyectos. La metodología se había convertido en la espina dorsal de todos los proyectos informáticos de la organización, y era de obligado cumplimiento que todos los procesos se cumplieran. Puedo contaros que, en una semana, tuve que modificar tres veces un modelo conceptual y un modelo lógico de una simple portal presencial web, sólo porque el departamento de metodología había modificado tres veces la metodología. Hubo, por supuesto, un acalorado debate cerrado entre varios despartamentos, gerentes, jefes de proyecto y directores, ya que era una pérdida de tiempo trabajar inútilmente varias veces por capricho de la metodología. Al final hubo un terrible final, como toda historia dramática, e imperó la metodología sobre todas las cosas.

Mi caso no era único, pues cuando se pedía una mejora o un añadido a un desarrollo antiguo, había que aplicar todo lo nuevo o no pasaba el test de calidad. Un simple pase podía suponer un mes o mes y medio, y, lo peor de todo, es que durante ese tiempo, la metodología cambiaba o añadía algo nuevo que, en el proceso de calidad, te tiraban la entrega para que adaptaras estos cambios a tu desarrollo.

Este caso extremo sigue vivo en aquella organización y doy gracias por no encontrarme ahora trabajando allí. Aquello es como tener a un padre paranoico que no deja a su hijo ni respirar.

Las metodologías, por otra parte, requieren de un tiempo y unos esfuerzos extra que no se tienen en cuenta. Cuando se planifica un proyecto, casi nunca se tiene en cuenta el tiempo que va a suponer aplicar y supervisar sus consejos, así como tampoco se tiene en cuenta qué personas lo van a aplicar. Al final, hay que echar horas extras, y somos nosotros mismos los que hemos de aplicar estas best practices, en detrimento de nuestra productividad y la calidad.

Un escenario ideal para que las metodologías fueran efectivas y tuvieran sentido, sería el de un proyecto de larga duración (al menos de un año), y en el que se implique un amplio número de recursos humanos, con varios equipos distintos trabajando de forma conjunta. En este escenario debería haber uno o varios recursos dedicados en exclusiva a ser "el ángel de la guarda" del proyecto, identificando qué best practices realmente necesita el proyecto (de entre todo ese océano que propone la metodología), aplicando dichas best practices, realizando supervisiones continuas, midiendo la productividad y la efectividad, detectando desviaciones, generar y aplicar contingencias, etc.

Las metodologías son valiosas y útiles si se saben aplicar de manera juiciosa. En primer lugar, hay que contar con un experto en metodología dedicado en exclusiva a esa labor dentro del proyecto. En segundo lugar, hay que identificar con qué "niño" se está tratando, saber sus problemas, sus ambiciones, sus deseos, y elegir cuidadosamente qué métodos aplicar al niño para que sea beneficioso tanto para él como para su padre. En tercer lugar, también hay que tener en cuenta los costes que de la aplicación de estas prácticas se derivan, y que estén en concordancia con los tiempos y entregas del proyecto.

Todos los expertos en consultoría informática sabemos que la calidad está reñida con la productividad, y que la "burrocracia" puede ser un lastre muy pesado. La mayor parte de los proyectos son de muy corta duración, y no tiene sentido aplicar una metodología axfisiante, que suponga más tiempo y esfuerzos que el propio desarrollo del software (incluyendo la gestión del proyecto, el análisis, el diseño técnico, el desarrollo, las pruebas y la implantación). En estos casos, la metodología debería ser flexible y contar con un mínimo de puntos a cumplir, entre ellos la documentación mínima requerida (documento de requisitos, análisis funcional, diseño técnico, plan de pruebas, documento de instalación, guía de usuario...). Para este tipo de proyectos, debería aplicarse la metodología con un mínimo juego de puntos básicos que aseguren una calidad aceptable.

Los proyectos medios son más complejos de prever, ya que debe ser el experto en metodología el que tenga la habilidad innata de conocer la naturaleza del "niño", identificar sus puntos débiles y fuertes, sus deseos o apetencias, los objetivos a alcanzar y qué aspectos va a contemplar, con el fin de definir un plan de metodología adecuado y a medida. El balanceo de las posibilidades en este tipo de proyectos es un gran reto para el metodólogo.

Las metodologías no son la panacea ni un seguro para un software "perfecto" o de la más alta calidad, aunque sí un recurso valioso si se aplican sus recomendaciones, dentro de un margen de prudencia y de sentido común, sin excesos ni carencias en su aplicación. Es decir, en su justa medida.


¿Cuál es tu experiencia en la aplicación de metodologías?. ¿Las consideras realmente útiles?. ¿Cómo crees que sería el escenario ideal para la aplicación de metodologías?. ¿Cuál crees que es la mejor metodología?. ¿Qué casos conoces en el que la aplicación de una metodología ha sido un gran éxito o un rotundo fracaso?.

Tu opinión es importante y bienvenida. Los comentarios son moderados, por lo que se omitirán aquellos comentarios con descalificativos a personas, organizaciones o empresas.