¿ Que tan profundo es el agujero del conejo ?

…
Este articulo refleja como se manifiesta el agujero del conejo en tiempos modernos, de
análisis, proyectos. Factibilidad de los mismos y uso de la tecnologías para la evaluación de si
algo es viable y como llevarlo a cabo para que sea un éxito SOBRE LA TIERRA (cada uno como
CONCIENCIA ligado a su cuerpo e interactuando y confluyendo en el mismo en el hecho de
“estar parado” en un LUGAR y usándolo como SOPORTE del FLUIR INTERIOR en IMÁGENES,
significados, ideas, pensamientos que lleven finalmente a la CONCRECION de lo planeado a
nivel de la materia (confluencia interior en el cuerpo de cada uno como CONCIENCIA (ser
METAFISICO, espíritu, vida)“prendida” al cerebro).

------------------------

Durante muchos años en esta profesión (informática, analista funcional), siempre me he

preguntado que esperan los clientes que recién comienzan a creer en los estándares y en la
metodología; si, como lo leen, ¿ qué esperan obtener ?, no puedo evitar recordar a Alicia en el
país de las maravillas cuando recién comienza a comprender en donde está, sencillamente
cree que todo será maravilloso, pero todo ello no es mas que un sueño. Me explico…

El caso común (por no decir que de todos) es aquella típica reunión de arranque o
acercamiento inicial de aquellos clientes que se acaban de dar cuenta que necesitan
actualización tecnológica, nuevas aplicaciones o integración, tras 25 años de operación y sin
inversiones mayores (en tecnología) en los últimos 10 o 15 años; contratan a 3
niños recién salidos de la universidad que traen unas ganas enormes de aplicarle ITIL y RUP
hasta a sus vidas; con esto estos clientes crean unas expectativas enormes para si y para el
resto del negocio, haciéndoles creer que todos los problemas serán resueltos en un par de
meses…

Esto no es del todo malo, la mala noticia está en el ¿ cómo ?, pues “las cosas imposibles las
hacemos rápido, pero para los milagros nos tardamos un poco mas”, esto claro, si y solo si,
partimos de una base realista de en donde estamos y para donde vamos. Resulta imposible ir
de una aplicación anticuada de monoproceso a una aplicación desarrollada moderna de
multiproceso y funcionando de modo interactivo con el entorno físico en TIEMPO REAL.

Resulta super interesante, pues las exigencias van desde los nombres de los proyectos hasta el
manejo de estructuras condicionales, pero no hay estándar alguno para el diseño de la
arquitectura o peor aún, ni siquiera de los nombres dentro del LDAP (y esto es solo por
mencionar un ejemplo).

Existen cosas mas allá de lo ideal, mas allá de ese mundo utópico que no termina de funcionar
jamás, cosas que deben hacerse para poder transitar esa ruta que dirige al lugar a donde
queremos llegar y es por un par de razones muy sencillas, el negocio no se puede parar a
esperar por tecnología y es imposible correr cuando no se tienen piernas y mucho menos se ha
caminado jamás.

En lo sucesivo, como una humilde sugerencia, recomiendo que cada vez que ud. piense en atar
de manos a sus proveedores imponiéndoles un estándar o una metodología pídales su opinion
y no solo como una formalidad, escúchelos, por algo les está contratando, de seguro sus
experiencias anteriores le serán muy útiles a ud. para evitar errores que ya han visto en otros
clientes, un “DeJavú” como lo llaman.

¿ Cuales son estos errores ?, pues son miles, para nombrar algunos: proyectos con
dos técnicos y siete personas de pruebas, un lider de proyectos, un controlador, dos
documentadores, etc, etc; Plataformas en cluster para asegurar “alta disponibilidad”, pero con
nodos virtuales sobre un mismo hierro que tiene una sola fuente de poder y un solo disco
duro; “aplicaciones distribuidas” con manejo y optimización de los anchos de banda, pero los
equipos en donde están la APP y la BD conectados con un cable cruzado entre ellos para no
afectar el tráfico del Core Swicht; Roll Out masivos manuales que son verificados por una
aplicación que revisa la instalacion la cual duro 5 meses en desarrollarse, ¿ no era mejor
desarrollar un instalador ?; y como estos un gran e increíble etc., todos ellos justificados por la
“metodología” o al menos por la interpretación que se le da.

Existen puntos intermedios o metodologías y estándares mas Soft para quienes recién
comienzan a arreglar su situación actual partiendo de un desastre, que no se recomiendan ni
en la universidad, ni por los amantes de la metodología que nunca han visto nacer a una
aplicación desde cero y llevarla al extremo de atender unos 500 mil hits diarios en cuestión de
semanas, gente que aun no entiende el vertigo de trabajar sobre un proyecto que ya está en
productivo, que no se puede parar por un diagrama, es decir, por alguien que no sabe que se
pierden mas recursos y dinero esperando por un diagrama y en reuniones con 20 personas
para mirarlo, que por un ajuste en caliente que luego puede ser documentado en la paz del
escritorio mientras el negocio sigue fluyendo y llenando su caja.

Evaluar todas las opciones es parte de su labor, inclusive dejar a un lado la metodologías
excesivamente demandantes, es ud. el que decide como quiere ser recordado, “como el
gerente que dejo muchos dibujitos que no siven de nada” o “como el gerente que realmente
resolvió los problemas y mejor aún, el que hizo del negocio un negocio mas dinámico y
rentable”.

Existen cientos de iniciativas, anímense a leer XP, CRUM, Agile, son un buen comienzo…