martes, 12 de octubre de 2010

El Plan B

En los últimos días, el tema del rescate de los mineros ha sido, obviamente, el tema más relevante de la realidad nacional. Hoy comienza el rescate y, bien desde afuera, lo que se aprecia es una realidad construida desde el día cero (día del derrumbe) hasta ayer (68 días después) que no deja de impresionarme.

Dentro de los temas más relevantes de esta situación están los siguientes:
  • El día cero no había nada, hoy hay una "ciudadela" armada con personas que viven, comen, duermen, negocian, compran, etc., en términos simples, una mini-ciudad.
  • El día cero no había ningún medio, hoy están todos los medios del planeta reporteando y esperando el momento del rescate.
  • Se realizaron varios sondajes para lograr dar con el refugio, todos realizados en paralelo y por distintas empresas, hasta que el día 17 de Agosto lograron dar con el refugio.
  • Se instalaron tres máquinas, el Plan A, B y C, para realizar las perforaciones para el rescate.
  • Se instaló un hospital de emergencia para hacer las evaluaciones de los mineros una vez que fueran rescatados.
  • Se instalaron diversas máquinas para realizar la faena de rescate, me refiero, explícitamente a la máquina con la guía del cable que sostiene la cápsula, el armazón que sostiene el cable, etc.
  • Se licitaron y construyeron tres cápsulas de rescate de alta tecnología (tema aparte lo sorprendente y sofisticado que me parece el diseño de las mismas respecto a lo que yo hubiera considerado)
  • Se definió un plan comunicacional, apoyo psicológico a los mineros, etc., destinado a protegerlos (tema aparte el hecho que si se mostró en vivo la salida de cada uno de ellos, siendo que se había dicho lo contrario).

En definitiva, del simple concepto de "hacer un hoyo y rescatarlos", se armó un plan, una maquinaria y se ejecutaron todos los procedimientos que permitirán comenzar el rescate hoy. De todos los puntos expuestos anteriormente, hay uno que no deja de asombrarme cada vez que lo pienso, probablemente, por la industria en la que trabajo y este es lo de haber habilitado tres máquinas para realizar las perforaciones: el Plan A, B y C. No deja de ser notable y sorprendente que, precisamente, la máquina del Plan B haya sido la que realizó la perforación que hoy permitirá rescatarlos.

No vivo en un país caracterízado por ser estructurado ni metódico y, más aún, mucho más cerca del típico "en el camino se arregla la carga", por lo tanto, el hecho de anticiparse a un error (por ejemplo, lo que pasó con el Plan A) me parece lo más rescatable de toda la operacion, obviamente, después del rescate de los mineros.

Haciendo ciencia ficción y considerando la habilitación de un plan de perforación secuencial, sin plan de contingencia, algunas preguntas básicas que habrían atentado contra el rescate serían las siguientes:

  • ¿Qué habría pasado si se detecta un desvío después de 20 días de perforación?
  • ¿Qué habría pasado si la máquina se hubiera echado a perder?
  • ¿Qué habría pasado si la máquina se hubiera destruído en el proceso?
  • ¿Qué habría pasado si la roca no hubiera permitido realizar la perforación?

Cualquier análisis simple a las preguntas anteriores permite determinar que el día del rescate se hubiera postergado de manera inversamente proporcional a la distancia del refugio (mientras más cerca del refugio la falla, más días habría que esperar) y, por lo tanto, toma mayor fuerza el hecho de haber habilitado los planes paralelos de perforación.

No tengo claro si en la industria de la minería esto es un "must" (obligación) o no, sin embargo, en la industria en la que trabajo no es algo que se ve todos los días y creo que es necesario incorporarlo como un hábito de reflexión importante en el desarrollo de software. Habitualmente estoy más cerca del desarrollo que de la infraestructura por lo que, típicamente, la dinámica obliga a desarrollar, probar y, probablemente, luego corregir una vez que los problemas y/o errores se producen.

Hay errores que no se pueden anticipar, símplemente porque los ambientes, datos y/o los volúmenes de los ambientes de producción no están disponibles para el equipo de prueba y/o desarrollo. Hay otros que a veces se pueden anticipar y que obedecen a errores de especificación de requerimientos y/o diseño y, por último, hay otros que se pueden anticipar y que obedecen a problemas de programación, típicamente gatillados por supuestos simplistas respecto a las entradas y/o las acciones de los usuarios de la aplicación.

Para estos últimos, las dos preguntas simples que hay que hacer al momento de programar son:

- ¿Qué pasa si?
- ¿Porqué?

No se que pregunta se habrán hecho los responsables del rescate al momento de definir que se requería habilitar tres planes de perforación pero creo que, alguna de las preguntas anteriores, en cualquier escenario de decisión, deben realizarse siempre para determinar que se han cubierto todos los posibles escenarios y que, efectivamente, existe un Plan B. Sin ir muy lejos, mi hija que hoy tiene dos años, hace esa pregunta cada dos segundos para intentar comprender su realidad...