Programación BIM: del proceso repetido a la herramienta propia
La herramienta empezó siendo un grafo de Dynamo con un nombre perfectamente razonable: Renombrar_vistas_FINAL. Después llegaron FINAL_2, FINAL_2_bueno y una copia guardada en el escritorio de quien sabía qué nodo había que desconectar los viernes. Durante meses, el equipo la utilizó para preparar vistas y planos. Ahorraba tiempo, sí, pero también dependía de una liturgia que nadie se atrevía a escribir por miedo a descubrir que aquello ya era software.
La programación BIM suele entrar en una oficina de esta manera: una persona resuelve una tarea repetida, comparte el resultado y, casi sin darse cuenta, crea una herramienta de producción. El salto importante no ocurre al cambiar Dynamo por Python o C#. Ocurre cuando el equipo deja de tratar el script como un truco personal y empieza a diseñar su uso, sus límites, sus pruebas y su mantenimiento.
Tabla de contenidos
El grafo funcionaba porque su autor estaba cerca
La rutina leía una tabla de Excel, creaba vistas, aplicaba plantillas y componía parte de las láminas. En el proyecto donde nació, los nombres seguían una convención estable y todas las plantas compartían una estructura parecida. Al copiarla a otro encargo, aparecieron niveles duplicados, vistas ya existentes y una plantilla con otro identificador. El grafo no estaba mal hecho; simplemente contenía decisiones del primer proyecto disfrazadas de lógica universal.
Su autor sabía resolver cada tropiezo. Antes de ejecutar, revisaba dos columnas de Excel, borraba vistas antiguas y cambiaba manualmente una ruta. Si el proceso devolvía una lista vacía, recordaba que había que abrir una vista concreta. Ese conocimiento no vivía en el grafo. Vivía en una persona, que es un sistema de almacenamiento muy capaz pero poco recomendable como dependencia única.
Cuando una compañera intentó usarlo sola, generó varias vistas correctas y otras tantas con nombres inesperados. No había vista previa, registro ni una forma clara de deshacer solo lo creado. El equipo entendió que ya no necesitaba «mejorar el grafo». Necesitaba decidir qué proceso quería ofrecer como herramienta.
Antes del código apareció un contrato de uso
El equipo describió la operación con entradas, reglas, resultados y fallos. La entrada sería una tabla con nivel, disciplina, tipo de vista, plantilla y código de plano. Las reglas definirían cómo localizar niveles, cuándo reutilizar una vista, qué nombres se consideraban válidos y qué hacer ante duplicados. El resultado no sería simplemente «vistas creadas», sino un informe de creadas, actualizadas, omitidas y bloqueadas.
Los ejemplos concretos desmontaron varias ambigüedades. ¿Qué significaba actualizar una vista existente? ¿Cambiar su nombre, su plantilla y su escala, o solo completar datos vacíos? ¿Podía el sistema sustituir una plantilla aplicada por otra? ¿Qué ocurría si Excel pedía dos vistas con el mismo código? Cada pregunta revelaba una decisión que antes resolvía el autor sobre la marcha.
También se fijó el límite. La herramienta prepararía vistas y propondría una colocación inicial; no decidiría qué encuadre comunicaba mejor el proyecto ni ajustaría anotaciones a ciegas. Automatizar la parte estable liberaba tiempo. Fingir que la composición arquitectónica era una suma de coordenadas habría fabricado planos muy ordenados y bastante inútiles.
El prototipo aprendió primero a no tocar nada
La siguiente versión leyó la tabla y el modelo, pero solo generó una previsualización. Mostraba qué niveles había encontrado, qué vistas ya existían, qué plantilla aplicaría y dónde había conflictos. El usuario podía corregir la entrada antes de abrir una transacción. Esta etapa parecía menos espectacular que crear cincuenta vistas de golpe, aunque evitó bastantes demostraciones memorables por motivos equivocados.
La validación se separó de la ejecución. Primero se comprobaban columnas, valores obligatorios y referencias del modelo. Después se construía un plan de acciones. Solo al confirmarlo se iniciaban las modificaciones en Revit. Si una operación fallaba, el sistema podía cancelar el conjunto o aislar la unidad afectada según el riesgo acordado.
Esta separación hizo que las pruebas fuesen más sencillas. El equipo preparó una tabla válida, otra con niveles inexistentes, una con duplicados y un modelo donde parte de las vistas ya estaba creada. El resultado esperado se podía revisar sin llenar el archivo de objetos de prueba. Leer, decidir y escribir dejaron de formar una madeja.
Dynamo seguía siendo útil, pero ya no tenía que hacerlo todo
Para explicar reglas visuales y ajustar el flujo con usuarios BIM, Dynamo continuaba siendo una buena herramienta. Permitía enseñar cómo se filtraban niveles y cómo se construían nombres sin obligar a todo el equipo a leer código. El problema aparecía cuando el grafo mezclaba interfaz, acceso al modelo, reglas, rutas, mensajes y correcciones específicas de cada proyecto.
Parte de la lógica pasó a Python. No porque escribir texto fuese moralmente superior a conectar nodos, sino porque facilitaba dividir responsabilidades, reutilizar funciones y probar casos. La configuración de nombres y plantillas quedó fuera del código, de modo que un proyecto podía cambiarla sin editar la lógica. El grafo se convirtió en una entrada comprensible para el usuario; el script asumió el trabajo repetitivo que necesitaba más estructura.
El equipo no saltó directamente a un complemento en C#. La herramienta aún estaba aprendiendo. Cambiar de tecnología demasiado pronto habría convertido dudas de proceso en arquitectura permanente. La programación visual servía para explorar, Python para ordenar y la API de Revit estaba presente en ambos casos. La decisión dependía de madurez, distribución y mantenimiento, no de una clasificación entre herramientas «de verdad» y juguetes.
La herramienta propia apareció al crecer el número de usuarios
Meses después, la rutina se usaba en varios proyectos y las actualizaciones por correo empezaron a fallar. Algunas personas conservaban versiones antiguas; otras cambiaban el archivo de configuración; nadie sabía con certeza qué había generado una lámina. El ahorro local había creado un problema de distribución.
Entonces sí tuvo sentido empaquetar la solución con una interfaz estable y un mecanismo de versiones. El usuario elegía el archivo de entrada, veía el resumen del modelo, ejecutaba la validación y confirmaba el plan. Los mensajes evitaban jerga del código y explicaban la siguiente acción: «La plantilla ARQ_Planta no existe en este modelo» ayuda más que «KeyNotFoundException», aunque esta última tenga un indudable aire de autoridad.
La herramienta registraba versión, usuario, modelo, configuración y resultado. No necesitaba vigilar a nadie; necesitaba poder responder qué había ocurrido. Ese registro permitía comparar una incidencia con la ejecución correspondiente y reproducir errores sin pedir a la persona que recordase cada clic.
También se definieron permisos. Crear vistas podía estar disponible para modeladores; cambiar configuraciones corporativas requería otro rol. La herramienta no heredaba automáticamente toda la capacidad de quien sabía programarla. Una automatización que modifica un modelo compartido forma parte del gobierno de la información, aunque su icono sea simpático.
Las pruebas dejaron de depender del proyecto del martes
El equipo creó modelos pequeños con condiciones conocidas: niveles normales, nombres duplicados, plantillas ausentes, vistas bloqueadas y parámetros incompletos. Cada versión debía producir el mismo plan sobre los mismos datos. Además, se mantenía una prueba sobre una copia de un proyecto real para descubrir combinaciones que los modelos mínimos no representaban.
Actualizar Revit exigía comprobar compatibilidad de API y comportamiento. Una función disponible en una versión podía cambiar o requerir otra referencia. Los archivos de configuración también tenían versión, y la herramienta rechazaba los que no podía interpretar en lugar de adivinar. La imaginación es estupenda para diseñar; para migrar datos suele salir cara.
Las pruebas incluían recuperación. ¿Qué pasaba si faltaba Excel, si el modelo no permitía escribir o si una vista se borraba entre la previsualización y la confirmación? El objetivo no era impedir cualquier fallo, sino evitar resultados silenciosos o parciales imposibles de explicar. Un error claro y reversible es una característica, no una derrota.
Las excepciones no se resolvieron con casillas misteriosas
Algunos proyectos necesitaban conservar una vista con un nombre heredado. En la etapa del grafo, el autor desconectaba temporalmente un nodo. La herramienta incorporó una excepción explícita: elemento afectado, motivo, alcance y responsable. El informe la mostraba como una decisión, no como un éxito.
Otras variaciones se convirtieron en configuración porque representaban reglas legítimas de proyecto. Distinguir configuración de excepción evitó dos extremos: llenar la interfaz de opciones que nadie entiende o codificar cada encargo como una rama especial. Si cada nuevo proyecto obliga a añadir un if con su nombre, la herramienta está escribiendo su autobiografía en el peor lugar posible.
Cuando una petición alteraba el propósito central, se quedaba fuera. La misma aplicación no debía crear vistas, publicar IFC, corregir familias y preparar el café solo porque ya tenía acceso al modelo. Mantener un alcance reconocible hacía posibles las pruebas y permitía saber quién era su propietario.
El coste real apareció después de la primera versión
El equipo registró tiempo de diseño, desarrollo, pruebas, soporte y adaptación a nuevas versiones. También midió ejecuciones, errores evitados y trabajo manual restante. No convirtió cada clic ahorrado en un retorno anual fabuloso; comparó ciclos reales y revisó si la herramienta seguía resolviendo un problema frecuente.
Parte del mantenimiento era editorial: actualizar reglas y documentación. Otra parte era técnica: dependencias, API, distribución y telemetría. Y otra era humana: formar a quien entraba y recoger incidencias. La programación BIM no termina al compilar o al cerrar el grafo. Empieza a deber explicaciones en ese momento.
La propiedad se repartió con claridad. Una persona respondía por el proceso, otra por la implementación y un grupo pequeño aprobaba cambios de reglas. Así se evitó que el desarrollador tuviese que decidir convenciones BIM y que coordinación pidiese cambios urgentes sin valorar el riesgo técnico.
Cuándo sigue bastando un script
No todo necesita convertirse en producto interno. Si una tarea la ejecuta una persona experta, tiene alcance limitado, bajo riesgo y cambia a menudo, un script bien documentado puede ser la solución correcta. Debe validar entradas, mostrar resultados y tener propietario, pero no necesita una interfaz completa ni un despliegue corporativo.
La herramienta propia empieza a justificarse cuando crecen usuarios, proyectos, impacto y necesidad de trazabilidad. También cuando distribuir versiones y configuraciones consume más esfuerzo que desarrollar un canal estable. El salto no lo determina el número de líneas de código; lo determina la responsabilidad que el proceso ha adquirido.
En el otro extremo, si las reglas todavía son ambiguas o cada caso requiere criterio distinto, conviene no automatizar la decisión. Puedes preparar datos, detectar candidatos y reducir trabajo mecánico. Codificar una discusión sin resolver solo consigue que el desacuerdo se ejecute más deprisa.
Del archivo final a una capacidad del equipo
El antiguo grafo no desapareció con deshonra. Había demostrado el valor del proceso y había permitido aprender barato. Parte de su lógica sobrevivió; otra se descartó al descubrir supuestos locales. Lo importante fue dejar de copiar el artefacto y empezar a conservar el conocimiento.
Una herramienta BIM mantenible explica qué recibe, qué decide, qué modifica y qué deja en manos de una persona. Se puede probar con modelos conocidos, distribuye versiones, registra resultados y ofrece una salida cuando algo falla. Su tecnología puede ser Dynamo, Python, C# o una combinación sensata. La arquitectura debe seguir al problema y a quienes tendrán que vivir con ella.
Ese es el recorrido útil de la programación BIM: observar una repetición, formalizarla, probarla sin riesgo y aumentar la ingeniería a medida que aumenta la responsabilidad. Si el equipo llega a ese punto, quizá pueda borrar por fin FINAL_2_bueno. Con copia de seguridad, tampoco nos volvamos temerarios.
Respuestas