Este post viene a cuento del intercambio iniciado en Iboisset's Ruminations, en los comentarios de la entrada Responsabilidad de Qué.
La frase que da el puntapié inicial es de diazjc, en Twitter:
En nuestro sector lo que veo es que el informático no sabe el coste real de sus fallos, de sus acciones, su responsabilidad.
Dos artículos me vinieron inmediatamente a la mente. Al primero lo había referenciado en Gestores vs. realidad. Es Cuando los ingenieros se ponen en la piel de los gestores, de Historias de la ciencia. Llegué a él a través de Engañemos a la realidad, artículo de Un Punto Azul Pálido que también viene al caso.
Se comenta el accidente del Challenger. Sin entrar en detalles aquí (el artículo es absolutamente recomendable), resumo lo que viene al caso:
[...]Los ingenieros de Morthon Thiokol volvieron a advertir a sus jefes y a los responsables de la NASA del Centro de Vuelo Espacial Marshall, quienes gestionaban las relaciones con el contratista, que las frías temperaturas de la Florida podían tener un efecto negativo sobre las juntas tóricas.[...]
[...]La presión desde arriba, las dudas sobre los datos y la insistencia en que pensara “como un gestor y no como un ingeniero” fueron suficientes para que Lund cambiara de parecer. Se sumó a los otros gestores de Morthon Thiokol y, pasando por alto la opinión de sus ingenieros, certificó la seguridad de los cohetes aceleradores para el lanzamiento.[...]
[...]Como ingeniero, me vais a permitir unas reflexiones. Estoy seguro que Bob Lund, el ingeniero al que presionaron “para que se pusiera en la piel de un gestor”, se sintió terriblemente responsable por ceder ante la presión. Sin embargo, sospecho que Mason, aquel ejecutivo que le presionó, se lavó las manos de cualquier responsabilidad, ya que él nunca tuvo que estampar su firma para garantizar la seguridad de los cohetes aceleradores y no era responsable de la seguridad de los mismos.[...]
El segundo es uno que referenciaba en La cadena del error. Es un artículo de TCAS Aviation Blog (a cuento de las repercusiones del accidente del avion de Spanair en Barajas) que había aparecido como referencia en Dirección de proyectos:
[...]Que un avión salga en hora es un milagro. ¿O no?
No es tanto un milagro si no un éxito del sistema, que funciona. Pero está claro que no siempre. Normalmente cuando alguno de esos elementos no funciona en el momento que le corresponde o de la manera que toca, se producen incidencias en la operación de mayor o menor calado, y que normalmente afectan tan sólo a la puntualidad o a la economía, nunca a la seguridad.
¿Pero qué pasa cuando son varios elementos los que fallan simultáneamente?
Ahí es donde entra el concepto de la cadena del error. Imaginemos que desde el primer “mal funcionamiento del sistema” hasta el último hay cinco eslabones, y el quinto significa un accidente. Es relativamente fácil que el primero aparezca, puede incluso que el segundo lo haga, es posible que aparezca un tercero, pero alguien, en algún momento (incluso sin llegar a saberlo) debería haber roto alguno de esos eslabones, impidiendo así que llegara el cuarto, y mucho menos el quinto. [...]
Creo que se entiende hacia dónde voy... volvamos al desarrollo de software.
En principio, diferenciemos claramente "error" o "fallo" de "catástrofe" o "desastre". Según la RAE:
- Fallo: Falta, deficiencia o error.
- Catástrofe: (1) Suceso infausto que altera gravemente el orden regular de las cosas. (5) Cambio brusco de estado de un sistema dinámico, provocado por una mínima alteración de uno de sus parámetros.
¿Cuál es el coste real de un fallo de un informático? ¿Cuál es su responsabilidad?
Un negocio es un sistema, diseñado por una o varias personas, con el objetivo de ganar dinero. Un sistema de software es uno de tantos subsistemas de un negocio. Puede ser más o menos importante, central o periférico (no es lo mismo la venta de pañales que una red social con publicidad), pero nunca deja de ser parte de ese sistema más grande, el negocio.
Ese subsistema de software es construído por muchas personas (necesariamente) que conforman, junto con otros elementos, un sistema de desarrollo de software. Ahí están "los informáticos". Muchas veces este sistema de desarrollo excede los límites de lo que llamamos "empresa": puede estar compuesto por personas del lado del "cliente" y del lado de "el proveedor del sistema".
El objetivo del subsistema de software está acotado por el del sistema "negocio" al que pertenece. Lo que quiero dejar en claro en este punto es que el objetivo del subsistema "software" no puede ser "ganar dinero", porque ése es el objetivo del sistema "negocio" que lo contiene.
En el lenguaje cotidiano, cuando hablamos de "desastre" o "catástrofe" informática estamos hablando de pérdida de dinero o de cualquier situación que pueda traducirse en tal. Si hay una pérdida de dinero, el sistema que está fallando es el "negocio", porque ganar dinero es su objetivo, y no lo está cumpliendo, o deja de cumplirlo por un período de tiempo determinado, o en vez de ganarlo lo está perdiendo.
Ahora, ¿quién o quiénes son los responsables del negocio? ¿"El informático"?
El origen de una catástrofe (léase: evento que implica pérdida de dinero, fallo del negocio) puede estar en el subsistema de software. Es como decir que el primer eslabón en la cadena del error (que mencionaba arriba, en el artículo sobre el accidente de Spanair) se encuentra en ese subsistema.
No puedo hablar de otros subsistemas (recursos humanos, gerencia, ventas, facturación...), pero si hay algo que conozco bien son las características generales de un subsistema de software.
Una de ellas es: este sistema, tarde o temprano, fallará (probablemente como cualquier otro, pero yo soy experto en éste, y no quiero pisar terreno desconocido).
Si un programador dice que su código no tiene errores miente o peca de soberbia, y se equivoca.
Si un administrador de base de datos manipula la base sin un resguardo, está pecando de soberbia (eventualmente se equivocará). Si lo están obligando o presionando a ello estamos en una situación como la que describíamos arriba, hablando del Challenger.
Lo mismo sucede cuando se administran redes, proyectos de desarrollo, o cualquier elemento informático.
Cuando un líder de proyecto presiona a los programadores para que escriban código sin errores, no hace más que mostrarle al mundo su absoluto desconocimiento del desarrollo.
Cuando un cliente o empresario se apoya únicamente en un sistema informático para hacer funcionar su negocio está pecando de soberbia, ceguera, optimismo, pensamiento mágico, mala administración, falta de previsión... muchas cosas. Pero bueno, es su negocio y es libre de llevarlo como le venga en gana.
Entonces, cuando un cliente o empresario se queja de que el software le ha hecho perder dinero, demuestra que no ha sabido o sido capaz de crear un sistema de negocio tolerante a un fallo en uno de sus subsistemas. Un subsistema con alta probabilidad de fallo, característica harto conocida por todo el mundo.
¿O ha sido engañado por alguien?
Volvamos a la frase:
"[...] no sabe el coste real de sus fallos [...]" : No, no lo sabemos. No lo sabemos porque somos parte de un sistema externo (de desarrollo de software) que crea un subsistema (de software) que es parte del sistema en el cual se puede hablar de "coste" (el negocio)... y a veces ni siquiera eso (si el sistema de software es de depósito, por ejemplo, habría que agregar un nivel más).
A ver, yo escribo una línea de código para un sistema que conozco bien en cuanto a su flujo de información (lo administrativo), pero del cual desconozco completamente sus números monetarios, su aporte al negocio (porque se me ocultan, y en todo caso no me interesan más que como curiosidad). ¿Cómo podría evaluar el coste de un fallo? ¿Si el software falla, puede mantenerse la operatoria "a mano"? ¿Cómo podría saber yo eso?
Sólo saben decir 'ya está arreglado, ya no falla': obviamente. Es lo único que podemos decir. Es la única información de la que, como informáticos, disponemos (cuando la tenemos, que no es siempre).
Ésta es la dura verdad, aunque podemos ser soberbios y pensar que realmente somos responsables por todo lo que ocurre en "el negocio".
Lo demás, es limar asperezas. Podemos asumir responsabilidad sobre un sistema que no controlamos para quedar bien con el cliente. Puedo no decirle al jefe del equipo que el problema no está aquí para quedar bien o para no enojarlo. Puedo no decir "¿dónde están los procedimientos alternativos?", arremangarme y corregir las cosas lo más rápidamente posible. Podemos tener conciencia de equipo y ayudar en todo lo posible.
Si éstas son las actitudes que el autor de la frase siente en falta, puede ser. La vida es más fácil cuando están presentes. Pero hay veces en las que es difícil ser comprensivo y ponerse la camiseta cuando un cliente, líder de proyecto o jefe de lo que sea descarga su ira hablándonos de números sin sentido, pidiendo explicaciones que no quiere escuchar, y exigiendo que hagamos lo imposible: no generar errores.
.jpg)
(Las imágenes en caricatura de este post fueron encontradas en El ciclo de la vida, en "El rincón de Basulto".)
3 comentarios:
En nuestro sector lo que veo es que el informático no sabe el coste real de sus fallos, de sus acciones, su responsabilidad.
Y que rueguen que nunca lo sepamos. El día que lo cuantifique voy a ser algo así como Atila negociando el presupuesto.
Porque si el costo de mi error era tan alto, era que ese equipo de testing que estoy pidiendo, al fin y al cabo, no era tan caro, no?
¡Hombre, qué manera de dar en la tecla!
Una muy buena forma de demostrar quién elige y por tanto debe asumir (conscientemente o no) los riesgos: cuando el negocio busca el precio más bajo (ajustando tiempos, personal, recursos), lo hace a costa de... ¿de qué?
De esas cosas que faltan cuando el software falla y nadie sabe qué hacer.
Te has extendido bien Andrés. Sigo pensando que tu reacción es extremadamente corporativista, sigues hurtando de responsabilidad alguna a los programadores dejándolos como una mera pieza de una maquina.
Bien en ese caso, totalmente de acuerdo en todo.
Pero esa no es una realidad objetiva. Primero quiero diferenciar una gran organización con 30 programadores en un único sistema y las que yo conozco donde los equipos "son de 1" (o 2).
Son dos entornos distintos y la visibilidad de las cosas en los dos sentidos es distinta.
Ese desentendimiento que propugnas del programador respecto del negocio no acabo de entenderlo, todos estamos en el mismo barco y tienen que saber qué hacemos tanto si es un programador en una empresa final como en una de desarrollo de software.
Y ese conocimiento del que huís te llevaría a entender el impacto (quizá no el coste real) de los defectos de su software.
En ambos caso hablo de conocimiento no de responsabilidad.
En una empresa del tamaño que conozco un programador quiere responsabilidad (bueno lo que quiere es la pasta :( ), quiere ser él el que analice, quiere diseñar la solución puesto que quiere evolucionar en su puesto.
¿Y luego no quiere la responsabilidad? ¿No quiere dedicar el tiempo necesario a comprender el negocio en el que está involucrado?.
Si te ciñes a la definición de programador "raso"/junio tendré que estar de acuerdo contigo en todo. Pero cuando uno tiene 7 años de experiencia en la empresa. Se le de la responsabilidad de analizar y desarrollar una solución software, con libertad, tiene que asumir que debe demostrar una capacidad para minimizar los defectos importante.
Si al final hay un fallo, 1500 registros no se grabaron bien. No me vale el "ya está, ya no falla", se tiene que postular para arreglar el desaguisado sea por programa o a mano. ¿Por que voy yo solo a tener que picarme a mano 1500 correcciones o a llamar a 35 agencias de viajes?
Mencionas "ira". Estoy de acuerdo. Nunca se tiene que perder la perspectiva ni las formas. Yo no creo haber incurrido demasiado en esa situación. De hacerlo, entiendo que la reacción sea "ahí te las apañes".
Pero bien al contrario creo que soy flexible y escucho las necesidades, me pliego a sus consejos y explicaciones, negocio con el cliente y aún así ¡Cuantas veces me han dejado tirado!.
Era de esto último de lo que veníamos hablando en diversos foros, de la motivación e implicación de los equipos y de donde salió la frase de diazjc.
También creo que retuerces la cuestión utilizando "dos pruebas de cargo" catastróficas como son el accidente del Challenger y el de Spanair.
Desde luego que si mis proyectos de software se llevasen como se llevan los desarrollos aeroespaciales y aeronáuticos muchas cosas cambiarían. Pero no es así.
El significado de "catastrofe" en el contexto en que lo he utilizado no llega a esto. Pero si implica pérdida de dinero. La empresa gana dinero conmigo y por eso me paga. La empresa pierde dinero conmigo y me sigue pagando, pero al menos me remango y ayudo a arreglar el asunto ¿No?
Ese era el contexto de diazjc que hablaba de un router y que el turno de tarde se iba dejándolo sin arreglar y que eso implicaba a 200 compañeros parados al día siguiente.
No se. No estoy en contra de tu posición está muy bien argumentada (qué envidia) pero la veo muy polarizada.
Publicar un comentario