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.
