En 2012 empezamos a trabajar en la web con la convicción, bastante extendida entonces, de que el problema era técnico. Que si uno dominaba las herramientas, el resto se acomodaba.
Doce años después la conclusión es la contraria, y llegar a ella costó varios proyectos. Todo lo técnico cambió por completo. Los problemas que hacen fracasar un proyecto son casi exactamente los mismos.
Lo que cambió
La construcción se abarató muchísimo
Lo que en 2012 era un proyecto de meses hoy es de semanas. Las herramientas mejoraron, hay bibliotecas para casi todo, y buena parte de lo que antes había que programar hoy se configura.
Eso tuvo un efecto de segundo orden que casi nadie anticipó: como construir se abarató, la ventaja competitiva dejó de estar ahí. Cuando cualquiera puede levantar un sistema razonable en un mes, el diferencial se corre entero hacia si la organización lo va a usar.
El cliente sabe más
En 2012 uno podía decir «esto lleva tres meses» y la respuesta era un acto de fe. Hoy el gerente que escucha eso conoce a alguien que hizo algo parecido, leyó sobre el tema, y a veces probó una herramienta él mismo un fin de semana.
Eso es bueno y es más exigente. La autoridad técnica ya no se da por sentada: hay que sostenerla con argumentos que el otro pueda evaluar.
Todo el mundo tiene sistemas
Hace doce años, muchos proyectos eran el primer sistema de esa empresa. Hoy prácticamente ninguno lo es: siempre hay algo funcionando, con datos adentro y con gente acostumbrada.
Eso cambió el trabajo más de lo que parece. La parte difícil de un proyecto dejó de ser construir y pasó a ser convivir: integrarse con lo que ya está, migrar lo que existe, y reemplazar sin romper.
Lo que no cambió
El pedido sigue llegando resuelto
En 2012 nos pedían una funcionalidad concreta en lugar de contarnos el problema. En 2026 exactamente igual. La gente sigue pidiendo en el idioma de las herramientas que conoce, y sigue siendo tarea del que recibe el pedido averiguar qué hay detrás.
Las estimaciones se siguen discutiendo igual
Ni las metodologías ágiles, ni los tableros, ni ninguna herramienta cambiaron la conversación de fondo: alguien dice cuánto lleva y otro pregunta por qué no menos. Lo único que cambia el resultado sigue siendo cómo está estructurada la respuesta.
Los sistemas se siguen abandonando
La tasa de sistemas entregados que nadie usa no bajó en doce años, y no bajó porque las causas nunca fueron técnicas: la forma vieja que queda disponible, las excepciones que nadie declaró, el referente que no existe.
La confianza sigue siendo el activo
Un área de sistemas en la que la organización confía consigue plazos razonables, participa antes en las decisiones y sobrevive a un error. Una en la que no confía pelea cada fecha aunque tenga razón. Eso era así en 2012 y sigue igual.
Tres cosas que creíamos y resultaron falsas
Vale nombrar los errores propios, porque son más útiles que los aciertos.
Que un buen producto se defiende solo. Creíamos que si el sistema era claramente mejor que lo anterior, la adopción venía sola. No viene. La costumbre gana casi siempre, y lo que decide no es la calidad sino que alguien haya acordado apagar el método viejo con fecha.
Que documentar era perder tiempo. En los primeros años defendíamos que el código bien escrito se explica solo y que la documentación envejece. Las dos cosas son parcialmente ciertas y llevan a una conclusión falsa. Lo que hay que documentar no es cómo funciona el código: es por qué se decidió así. Eso no se deduce leyendo, no envejece, y es lo primero que se pierde cuando alguien se va.
Que el cliente difícil era un cliente malo. Los clientes que más preguntaban, que discutían el alcance y pedían que se escribiera todo, nos parecían desconfiados. Con los años resultó lo contrario: son los proyectos que menos problemas dieron, porque las discusiones se dieron al principio y no al final. Los proyectos cómodos, donde el cliente firmaba sin leer, fueron los que terminaron peor.
Lo que aprendimos, en orden de cuánto costó
Que el diagnóstico casi nunca falta. En la enorme mayoría de las empresas donde entramos, alguien adentro sabía exactamente cuál era el problema. Lo que faltaba era que esa persona pudiera instalarlo como decisión. Eso reordenó lo que hacemos: dejamos de vender diagnósticos.
Que un proyecto que no se adopta es peor que uno que no se hace. Consume presupuesto, gasta la paciencia del área usuaria, y deja a todos convencidos de que «los sistemas acá no funcionan» — lo cual complica el proyecto siguiente, que quizás sí era bueno.
Que la parte más cara es siempre la que no se cotizó. La migración de los datos viejos, la integración con el sistema del proveedor, el mes de acompañamiento. Nunca es el desarrollo lo que rompe un presupuesto.
Que decir que no a tiempo salva relaciones. Los peores proyectos de estos doce años fueron todos aceptados sabiendo que algo no cerraba. No hubo ninguna excepción.
Lo que cambió en cómo trabajamos
Tres cambios concretos en nuestra propia forma de trabajar, resultado de todo lo anterior.
Ya no cotizamos sin conversar. Un pliego cerrado no alcanza. Media hora con quien lo escribió cambia el proyecto lo suficiente como para justificar el pedido de esa media hora.
El acompañamiento posterior dejó de ser un extra. Va adentro del alcance, y cuando el presupuesto no da, achicamos el sistema antes que sacarlo.
Escribimos las exclusiones. Cada presupuesto dice qué no incluye, con una línea de explicación en cada punto. Perdimos algún trabajo por eso y ganamos varios, y sobre todo dejamos de tener la discusión del mes cuatro.
Qué esperamos de los próximos años
Con la construcción cada vez más barata y más asistida, la brecha entre lo que se puede construir y lo que una organización puede absorber se va a seguir ensanchando. Ya hoy es habitual que una empresa tenga más sistemas de los que su gente logra usar.
Si eso es así, el trabajo que gana valor no es el de producir más software, sino el de decidir cuál hace falta, hacer que se adopte, y sostener las conversaciones donde se decide. Que es exactamente la razón por la que la formación pasó de ser algo que hacíamos de costado a ser una línea propia.
Lo que le diríamos a alguien que empieza hoy
Que aprenda a construir, porque sin eso no hay autoridad para nada de lo demás. Y que desde el primer año preste atención a lo que pasa en las reuniones donde se decide, que es donde su trabajo se gana o se pierde, y donde nadie le va a enseñar nada si no se lo propone.
Lo que no cambiamos
Una sola cosa, y es la que sostiene todo lo demás: seguimos tomando proyectos. No dejamos de construir para dedicarnos a enseñar.
Es deliberado. Un docente de estas materias que hace cinco años que no entra a una reunión de comité repite lo que le funcionaba entonces, y se nota. Lo que se enseña en la clase del jueves sale de la reunión del martes.
Vea la línea de tiempo completa o las cuatro líneas de trabajo.
