Querido colega, llevamos años intentando hacer encajar algo donde no puede encajar, a sabiendas de que no encajaría, ¿Cómo llamamos a esto?
Y dirás, ¿de qué carallo habla este? Te hablo de que durante años hemos intentado imponer una gestión de proyectos «estandar» a ámbitos en los que no encaja… y ahora tengo una prueba más. Hasta ahora lo veía en software, en nuestra ingeniería hemos heredado un argot que no nos es propio, imitando el corpus de conocimiento ingenieril existente hasta la fecha, ahí tienes a nuestros «arquitectos/as», aunque no hacemos edificios.
Y es un problema, porque el corpus de conocimiento de la construcción es muy antiguo, más que la biblia, y lo queremos hacer encajar en problemas que no existían cuando este corpus nació. ¿Que no me crees? Mira esto:
- Prácticas constructivas egipcias (2500 a.C.): Los registros muestran planificaciones detalladas y secuenciales para las pirámides con un enfoque top-down y jerarquías estrictas.
- Ingeniería romana (100-400 d.C.): Introdujeron la estandarización, documentación extensiva y prácticas de gestión de recursos que aún influyen en los modelos actuales.
- Revolución industrial (s. XVIII-XIX): Consolidación de principios como la división del trabajo, especialización y control centralizado, que se trasladaron a la gestión moderna.
- Métodos científicos de Taylor (inicios s. XX): La administración científica promovió la optimización de procesos, medición, y control estricto como bases del management moderno.
Vale, paremos un poco en Taylor, lo que hace Taylor es en procesos R E P E T I T I V O S, ¿lo son los proyectos de software? I don’t think so…
Pero es que, ahora en mi locura, me ha dado por estudiar proyectos de ayuda al desarrollo y volvemos a la matraca de la planificación por fases, al «Enfoque de Marco Lógico» a sabiendas de que todo el gran «Big design upfront» es una falacia: «A nadie en su sano juicio se le escapa que la realidad es bastante más complicada que cualquier árbol de problemas» (Sainz H. Venturas y desventuras del enfoque del marco lógico). ¿Por qué nos empeñamos?
Mi hipótesis es sencilla: que alguien te diga «no sé qué va a costar hacer esto, no sé qué riesgos habrá y lo iremos descubriendo en el camino» da mal rollo, si por cada minuto que pasa ves moverse el contado de dinero… Es como si te subes a un taxi y te pregunta ¿Dónde quiere ir? y después de darle una respuesta te dice: No tengo ni idea, pero vamos a probar a ir por ahí y veremos qué pasa. No mola.
Ojo, que no quiero tirar al traste 4000 años de corpus ingenieril y de proyectos… pero eso funciona en entornos simples y complejos (leete cynefin un poco). Pero ni los proyectos software, ni los proyectos de ayuda al desarrollo lo son, y tampoco creo que un edificio singular lo sea, (ni los colegas de la construcción se creen su bola de cristal de predicciones y estimaciones).
Y claro funciona para hacer un mapa y asegurarte de que no tienes a un tipo esperando a trabajar pero que no le han llegado las piedras de la catedral, es decir: para controlar dependencias y asegurar un flujo constante. Entiendo que estas cosas cuando hay temas logísticos son importantes… pero, ¿en IT qué carajo de logística? … la hay pero autoinducida: procesos, aprobaciones y otros retrasos que impidan tener algo a tiempo. No lo llamaría logística, lo llamaría burocracia.
Pese a todo lo anterior, nos negamos a separarnos de esa jerga heredada: identificación, diseño, planificación, control, pruebas… tenemos arquitectos, diseñadores, proyectistas… vinieron las las ágiles e intentamos cambiar -sin mucho éxito- la jerga. (Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today – Dave West, 2011)
¿Taylor? Taylor nos da un enfoque de medir y mejorar, con el peligro de caer en centrarnos en los máximos locales y dejar de ver la «big picture».
¿Entonces qué nos queda a los que somos «nuevos» y nos las queremos dar de ingenieros?
Para los que somos «nuevos» y nos las queremos dar de ingenieros, nos queda principalmente abrazar nuestra verdadera naturaleza y contexto:
- Reconocer la incertidumbre como parte inherente de nuestro trabajo. A diferencia de los proyectos constructivos tradicionales, trabajamos en dominios donde lo desconocido es la norma, no la excepción. Esto no es una debilidad, sino una característica definitoria.
- Desarrollar marcos propios adaptados a entornos complejos. En lugar de forzar metodologías heredadas, podemos crear aproximaciones que acepten la naturaleza exploratoria e iterativa de nuestros proyectos.
- Comunicar honestamente la naturaleza de nuestro trabajo. El reto está en explicar a stakeholders y clientes que la imposibilidad de predecir con exactitud no es incompetencia, sino la realidad de dominios complejos.
- Valorar más la adaptabilidad que la predictibilidad. Nuestra fortaleza no está en cumplir planes rígidos, sino en responder eficazmente a lo emergente.
- Redefinir lo que significa «ingeniería» en nuestros contextos. Quizás ser ingeniero en software o en desarrollo no debe significar lo mismo que en construcción. Podemos conservar el rigor y pensamiento sistemático sin pretender una precisión ilusoria.
En resumen, nos queda construir una nueva identidad profesional que reconozca nuestras particularidades sin complejo de inferioridad ante disciplinas más antiguas, enfocándonos en el valor que aportamos precisamente por nuestra capacidad de navegar en la incertidumbre.
