Hoy trascendía a la prensa la noticia de que cientos de interinos se han quedado sin trabajo, y otros tanto sin suficiente nota han sido convocados, en la Comunidad de Madrid. Todo esto, según fuentes oficiales, se debió a un error informático, y con este mismo calificativo ha llegado, por tanto, a la prensa.
Y yo me pregunto, ¿Por qué lo llaman error informático cuando quieren decir error de gestión?
Un error informático es un fallo en la infraestructura o en el hardware que impide, por motivos técnicos, su correcto funcionamiento. Todo lo demás son errores de gestión.
Si una aplicación tiene un mal funcionamiento, errores sin controlar, etc, esto se debe, en primer lugar, a una mala fase de especificación de requisitos, ya que el desarrollador no ha comprendido exactamente el funcionamiento del algoritmo deseado y/o el cliente tampoco se ha expresado bien, por lo que su implementación al final no es la deseada. O, segundo, es un problema en la fase de pruebas, ya que no se ha realizado una batería de pruebas decente que identificara posibles errores como el ocurrido con las adjudicaciones de plazas.
Fuente: Coder Facts!
Y esto, amigos, no es un error informático, es más, ni siquiera es un error del desarrollador. Esto es un error del gerente del proyecto y del cliente, por no controlar el producto que se está haciendo.
Los que trabajen en este mundo sabrán que esto es una constante en los proyectos de informática. Es más, me atrevo a decir que es el problema fundamental y casi exclusivo de que la gran mayoría de proyectos en España no vean el ciclo completo de desarrollo, o acaben yéndose al carajo por sobrecostes elevados. Démosle gracias de esta situación a la pésima gestión de las cabecitas “pensantes”.
Que esto ocurra en el sector privado, al fin y al cabo, es doloroso pero cada uno malgasta su dinero como quiere. En una institución pública, por el contrario, donde el dinero es de todos y debería de ser gastado con lupa, es completamente sangrante.
Los errores de gestión actualmente copan informativos a tutiplén. Los problemas sanitarios, educativos, de empleo, etc. son en el fondo culpa de los gestores, claro que en el resto de sectores uno no se puede escudar en excusas falsas que cuelan por desconocimiento de la gente.
Por ejemplo, nunca escucharemos que un paciente muera por un error en el bisturí del cirujano. ¿Suena absurdo, verdad? Pues la excusa del error informático es igual de inverosímil, sólo que mucha gente se la traga por su desconocimiento.
La culpa siempre sera del programador de mas bajo rango, o en su defecto del informático mas padefo de la sala.
Mola un montón. La mayoría de los gerentes y gestores no ponen atención a un buen análisis y los buenos análisis son chafados por decisiones de negocio.
Para los empresaurios, un proyecto informático es una caja negra desde el momento en el que alguien usa un sinónimo de “programa” para referirse a él. Por lo tanto, un error informático es cualquier cosa que ocurra en esa caja negra. Eso incluye desde un CPD en llamas hasta convertir el entorno de pruebas en el de producción por falta de tiempo.
Estoy en contra con una cosa, Jon Nieve.
El Padefo, como su propio nombre indica (Paso de Follones) nunca tiene la culpa de nada y tiene el don de saberse escabullir de los marrones justo antes de que revienten xD
Otro ejemplo en la prensa de hoy que achacan a un error “informático”:
http://www.20minutos.es/noticia/1921238/0/united-airlines/billetes/mil-a-cinco/
Pero por una vez la empresa dice que de informático nada, la culpa del que puso las manos. (Aun así en el 20 minutos se empeñan en poner en el titular que es un “error de programación”)
Hola Mar.
Aunque puedo encontrar razones para que escribas un post como este, creo también que hay algunas afirmaciones de base que no hacen gran favor a tu causa. Voy a explicar esto mejor con ejemplos del propio artículo.
Cuando hablas de “Si una aplicación tiene un mal funcionamiento, errores sin controlar, etc, esto se debe, en primer lugar, a una mala fase de especificación de requisitos…” creo que estás mezclando temas distintos. Podríamos hablar de conceptos como la calidad, entendiendo como uno de los pilares de ese calidad lo cerca que estemos de las expectativas previas recogidas en forma de requisitos. Lo que no veo es que eso tenga un reflejo en un mal o buen funcionamiento del sistema. Tú puedes disponer de unos requisitos que no tengan nada que ver con las expectativas que alguien tenga del producto y sin embargo que lo que entregues funcione perfectamente bien, aunque no valga para nada.
Por otro lado comentas “… es un problema en la fase de pruebas, ya que no se ha realizado una batería de pruebas decente…”. Una vez más, da la impresión de que atribuyes la responsabilidad de un mal funcionamiento o baja calidad a alguien que no es programador. En este caso le toca a los chicos de QA o testers. ¿Son sólo ellos los responsables de que el producto funcione? ¿A caso no tienen también parte de responsabilidad quienes lo crean?
Con la experiencia me he dado cuenta que, al final, todos somos los responsables, de forma equitativa, de que el producto que creamos no funcione como esperamos. Lo que pasa es que es más fácil echar balones fuera, y así pasa lo que pasa. Y esto no es un mensaje para ti, sino para todos aquellos profesionales que, frente a un problema, anteponen buscar un culpable que una solución.
¿Qué crees que está en tu mano, Mar, para cambiar esta situación? Tengo la suerte de llevar 2 años trabajando duro creando entornos sostenibles de desarrollo de software. Gracias a ello te puedo decir que otro modelo es distinto, lo vivo día a día. Sólo falta la determinación de cambiar las cosas.
¡Hombre Juanma, cuanto tiempo! 😀
No le quito la culpa al programador. Obviamente tiene parte de culpa de los errores, pero lo que venía a decir es que siempre se achacan los problemas (al menos en los medios de comunicación) a un error de software cuando muchas veces la culpa es del gestor.
Por ejemplo, a lo mejor al desarrollador le dieron unas especificaciones concretas y esas especificaciones estaban mal, por lo cual no es un fallo de software en sí, sino de gestión (como aquellos DFs maravillosos del proyecto donde coincidimos xD)
Lo que vengo a decir es que el gestor está para controlar que el producto del desarrollador no sea una mierda y es el principal responsable de que se lapide dinero en un producto que no es lo que se quiere.
De nada sirve tampoco tener un gran programador si los gestores no hacen bien su labor. En ese caso el proyecto está abocado al esperpento, por bueno que sean los “curritos” 🙂