Práctica reflexiva

Hay proyectos que terminan dos veces. La primera vez terminan el día de la entrega: el sistema queda funcionando, se hace la demostración final, se cierran los pendientes y cada participante vuelve a su trabajo habitual. La segunda ocurre bastante después, cuando alguien consigue entender qué sucedió en realidad. A veces esa comprensión llega al revisar una decisión que en su momento pareció menor. Otras veces aparece frente a un problema nuevo, en otra organización, y una escena conocida vuelve con una claridad que no tuvo mientras estaba ocurriendo.

Recuerdo esa clase de revelación porque casi nunca tiene algo de espectacular. No se parece al momento luminoso de una presentación. Se parece más a descubrir que dos equipos, separados por años y por industrias enteras, inventaron el mismo rodeo manual para protegerse de sistemas que no les inspiraban confianza. En el primer caso, el rodeo parecía una excentricidad. En el segundo, ya era difícil llamarlo casualidad. Al tercero se vuelve patrón, y un patrón obliga a revisar el método.

La práctica reflexiva empieza allí. Es el trabajo de volver sobre una intervención cuando la urgencia ya pasó, reconstruir las decisiones y distinguir lo que pertenece a ese caso de aquello que probablemente volverá a aparecer. La expresión puede sonar académica, pero el gesto es muy concreto: interrumpir por un momento la compulsión de pasar al proyecto siguiente y preguntarse qué aprendimos, qué creímos aprender y qué evidencia tenemos para sostenerlo.

Esa última diferencia importa. Acumular años de trabajo no garantiza acumular experiencia. Uno puede repetir durante diez años la misma práctica de un año. La experiencia empieza cuando el trabajo deja rastros que pueden compararse, discutirse y, si hace falta, contradecir la intuición del profesional que los reunió.

Volver al lugar donde se decidió

En una revisión útil no alcanza con anotar que el proyecto salió bien o mal. Esas dos etiquetas son demasiado gruesas. Un proyecto puede cumplir el alcance y, sin embargo, instalar una dependencia que lo vuelva frágil; puede demorar más de lo previsto y dejar una capacidad interna que valga la espera; puede ser celebrado por la dirección y evitado en silencio por quienes trabajan con él. La pregunta interesante no es el resultado aislado, sino cómo se produjo.

Por eso conviene volver a las decisiones. ¿Cuándo se descartó una advertencia del equipo? ¿Qué supuesto permitió avanzar? ¿Quién lo formuló y quién no estaba en la conversación? ¿Qué señal fue visible desde el comienzo pero solo se entendió al final? ¿Hubo un momento en el que todavía era barato cambiar de rumbo?

Esta reconstrucción tiene algo de investigación. Se miran notas de entrevistas, versiones del alcance, cambios de prioridades, incidentes y conversaciones de soporte. Pero también exige recordar el clima de esas decisiones. Un acta registra que el área comercial aprobó el piloto; raramente registra que lo aprobó después de que su gerente hablara durante media hora y nadie quisiera contradecirlo. La documentación técnica conserva qué se construyó. La memoria de campo debe conservar por qué, para quién y bajo qué presión.

Distribuidora Norte permite ver la diferencia. Su primer prototipo de alertas de clientes en riesgo gustó mucho en la demostración. El gerente comercial, curioso y paciente con las herramientas nuevas, entendía cada indicador y toleraba algunos pasos de más. Si la historia se hubiera cerrado ese día, la conclusión habría sido sencilla: el piloto funcionó. Sin embargo, los vendedores que recorrían la calle no trabajaban en las condiciones de la demostración. Entre una visita y otra tenían pocos minutos, una pantalla chica y ninguna disposición a interpretar un tablero. El mismo producto era claro para quien lo había impulsado y trabajoso para la mayoría que debía incorporarlo.

El aprendizaje no fue “hacer interfaces más simples”. Eso habría sido demasiado general y, por lo tanto, casi inútil. La lección fue más precisa: un piloto puede validarse con personas cuya tolerancia a la fricción no representa a sus futuros usuarios. Desde entonces, la pregunta por quién participa de la prueba deja de ser logística y pasa a formar parte del diagnóstico.

La bitácora como memoria de trabajo

La memoria humana edita el pasado. Suaviza las vacilaciones, conecta decisiones que en el momento estaban separadas y atribuye intención a resultados que tuvieron bastante de contingencia. Por eso la reflexión necesita una bitácora contemporánea al trabajo. No hace falta convertir cada jornada en un informe; alcanza con registrar los cambios que podrían explicar después por qué el proyecto tomó determinada forma.

Una entrada útil contiene pocas cosas, pero concretas: qué observamos, qué interpretación hicimos, qué decisión produjo y qué tendría que ocurrir para demostrar que nos equivocamos. Esa última pregunta evita que la bitácora sea un diario de autojustificación. Si anoto que un equipo rechaza una herramienta por miedo a perder autonomía, también debo anotar qué conducta esperaría ver si la hipótesis fuera cierta. Tal vez aparezcan planillas paralelas, pedidos de autorización para acciones antes informales o un uso correcto durante las demostraciones y casi nulo cuando no hay supervisión. Si nada de eso ocurre, habrá que buscar otra explicación.

Con el tiempo, la bitácora cumple tres funciones distintas. Primero, ayuda a conducir el proyecto en curso: permite advertir que una señal se repite antes de que se vuelva incidente. Después, preserva el razonamiento para el equipo que recibirá el sistema. Finalmente, cuando se comparan varias intervenciones, alimenta el acervo del método. Es allí donde una observación puede pasar de caso singular a hipótesis recurrente.

El pasaje no debe ser automático. Que algo haya ocurrido una vez lo vuelve memorable, no general. Que ocurra dos veces lo vuelve sospechoso. Recién cuando aparece en contextos distintos y puede describirse mediante señales observables merece el nombre de patrón. Incluso entonces conserva un estatus provisional: orienta la mirada, pero no reemplaza la lectura del caso.

La misma cautela vale para IMIA. Las notas de campo pueden sugerir que un indicador pesa demasiado o que falta una dimensión, pero no sustituyen una calibración empírica. Sirven para formular mejor la pregunta que luego deberá contrastarse con una muestra mayor. Confundir juicio acumulado con validación estadística sería repetir, dentro del método, el tipo de atajo que el método critica.

Cuando el fracaso avisa antes

Los proyectos rara vez fracasan de golpe. Se van desviando mediante señales pequeñas, muchas de las cuales parecen tolerables por separado. Un líder deja de asistir a las demostraciones. Una planilla que iba a retirarse sigue circulando “por las dudas”. El equipo aprende a completar el nuevo sistema al final del día, después de haber trabajado de verdad por otro canal. La política de inteligencia artificial queda pendiente para una fase posterior que nunca llega.

Llamo patrones de fracaso a esas configuraciones recurrentes. La palabra fracaso no busca culpables ni anuncia que todo está perdido. Señala que una combinación de conductas suele conducir a un resultado previsible si nadie vuelve a leer la situación.

Uno de los patrones más comunes es el piloto diseñado para innovadores. La persona entusiasta que acepta probar algo nuevo es valiosísima para comenzar, pero pésima como única representante del usuario futuro. Tolera errores, completa mentalmente instrucciones faltantes y le concede al producto una paciencia que la jornada normal no concederá. La corrección consiste en sumar pronto a quienes necesitan que la herramienta sea evidente, rápida y confiable. No para apagar el entusiasmo del innovador, sino para averiguar si ese entusiasmo puede convertirse en hábito colectivo.

Otro patrón aparece cuando se automatiza antes de sanear el dato. Al principio se manifiesta como una discusión sobre cifras: el tablero dice una cosa y el operador, otra. La salida fácil es suponer que el operador se resiste a la evidencia o que falta ajustar el modelo. A veces ocurre lo contrario. El sistema está agregando datos cuya definición cambia entre sucursales, o toma como fecha de venta lo que un área considera fecha de despacho. La automatización no produjo el error; lo volvió más rápido, más visible y más difícil de discutir porque ahora viene acompañado por la autoridad de una pantalla.

También es frecuente el patrocinio sin arraigo operativo. Una dirección convencida puede aprobar presupuesto y despejar obstáculos, pero no puede adoptar en nombre de otras personas. Si quienes trabajan con el proceso perciben que el cambio les agrega control, les quita margen o ignora una excepción conocida, la aprobación de arriba solo posterga el conflicto. El sabotaje pasivo suele ser menos dramático: cargas incompletas, uso intermitente, regreso al canal informal. Cada una de esas conductas contiene información sobre un mapa de actores que quedó incompleto.

La gobernanza postergada pertenece a la misma familia. El equipo promete definir permisos, responsabilidades y mecanismos de apelación después del piloto porque quiere demostrar valor primero. Esa secuencia parecía discutible cuando el software solo sugería; con agentes que pueden ejecutar acciones es directamente peligrosa. El cociente entre potencial agéntico y capacidad de gobernanza que propone IMIA existe para hacer visible ese desbalance antes del incidente, cuando todavía se lo puede corregir sin daño.

Hay, por último, fracasos que llegan disfrazados de entrega exitosa. El sistema se transfiere con manuales, pero sin el razonamiento que llevó a su diseño. Quien lo recibe sabe qué botón usar y no qué supuestos sostienen la decisión. Ante la primera excepción, abre un ticket o inventa un rodeo. Ese traspaso sin criterio produce dependencia y deuda sociotécnica al mismo tiempo. Si además la transformación dependía de una única persona —el campeón que conseguía permisos, traducía entre áreas y recordaba por qué se había hecho cada cosa—, su partida devuelve el proyecto al punto inicial.

No todos los patrones tienen una raíz tecnológica. Una organización puede declarar que quiere innovar y castigar cada intento que no salga bien. Puede contratar una solución concebida para una empresa diez veces más grande y luego culpar a su gente por no seguir el proceso. Puede invertir en capacitación intensiva para una plantilla con rotación estacional, como si el problema fuera la calidad del curso y no la imposibilidad de sostener el aprendizaje. En estos casos la tecnología funciona como pantalla: permite discutir herramientas en lugar de discutir incentivos, escala o condiciones de trabajo.

Reglas que nacen del terreno

Una heurística es una regla práctica que ayuda a decidir bajo información incompleta. No tiene la pretensión de una ley ni debería usarse para evitar el juicio. Sirve para detener la inercia y obligar a formular una pregunta incómoda en el momento oportuno.

Por ejemplo: si el líder del área no participa de la demostración, no doy por listo un piloto para escalar. La ausencia puede tener explicaciones inocentes, pero también puede indicar que el proyecto perdió patrocinio o que la dirección delegó algo que todavía requiere una decisión suya. La regla no ordena cancelar; ordena averiguarlo antes de comprometer más recursos.

Otra: no automatizo un proceso cuyo responsable no puede explicar por qué se hace así. La frase no exige que exista un procedimiento perfecto. Exige reconocer si estamos frente a una práctica comprendida o frente a una secuencia de hábitos que nadie se anima a tocar. Cuando tres personas describen el mismo proceso de formas incompatibles, construir de inmediato equivale a elegir una de esas versiones sin admitirlo. Primero hace falta producir sentido compartido.

Algo parecido ocurre con los datos. Preguntar “¿qué número usarías para tomar una decisión irreversible?” suele revelar más que revisar veinte tableros. Si cada responsable elige una cifra distinta, el problema todavía no es predictivo: la organización no acordó qué considera verdadero. El trabajo debe volver a definiciones, linaje y responsabilidades antes de ofrecer un modelo.

La resistencia merece una regla propia: cuando trae una razón operativa válida, se convierte en requisito de diseño. El supervisor que se niega a eliminar una verificación puede estar defendiendo un privilegio, pero también puede conocer la excepción que evita despachar mercadería equivocada los viernes. Solo la observación permite distinguirlo. Etiquetar todo desacuerdo como resistencia al cambio ahorra tiempo en la reunión y lo cobra con intereses en producción.

Estas reglas se anotan en primera persona porque implican responsabilidad profesional. “Nunca automatizo” pesa de otro modo que “se recomienda no automatizar”. La primera fórmula deja claro que alguien toma una decisión y deberá responder por ella. También admite revisión: si la experiencia futura muestra que la regla es demasiado rígida, habrá que reescribirla.

Reflexionar con otros

Existe un riesgo en toda práctica reflexiva solitaria: construir una mitología personal en la que el profesional siempre había visto venir el problema. Para evitarlo, la revisión debe incluir a otros participantes. No solo al equipo técnico y a quien contrató el trabajo, sino también a las personas que cargaron con el cambio cotidiano.

Una buena conversación posterior no pregunta únicamente qué salió mal. Pregunta qué sorprendió, qué parte del sistema fue apropiada de un modo no previsto, qué tarea empeoró aunque el indicador general mejorara y qué decisión tomaría distinto cada participante si volviera al comienzo. Las respuestas no siempre coinciden. Esa divergencia es valiosa: muestra que el mismo proyecto produjo experiencias diferentes según la posición ocupada dentro de la organización.

También conviene separar la reflexión del ritual de culpabilidad. Si cada incidente termina en la búsqueda de quién se equivocó, la próxima vez habrá menos información disponible. Las personas aprenderán a ocultar dudas y rodeos hasta que sean imposibles de disimular. Un postmortem serio reconstruye condiciones y decisiones; no borra la responsabilidad individual, pero la ubica dentro de un sistema que hizo algunas acciones más probables que otras.

Del caso al acervo, y del acervo al caso

El acervo no debería crecer como un depósito de notas. Su función es conservar pensamiento que pueda volver al trabajo. Para eso, cada hallazgo atraviesa una pequeña prueba editorial: ¿está descrito con suficiente precisión?, ¿se distingue la observación de la interpretación?, ¿apareció en más de un contexto?, ¿cambia alguna decisión del método? Si no supera esas preguntas, puede quedar en la bitácora sin convertirse todavía en doctrina.

Cuando sí las supera, el movimiento se invierte. El concepto vuelve al campo como una pregunta nueva. La dependencia del campeón, por ejemplo, nació al observar proyectos que perdían impulso cuando se iba una persona clave. Una vez nombrada, permite preguntar desde el primer diagnóstico quién puede tomar el relevo, dónde está documentado el criterio y qué ocurre durante una ausencia. El concepto no explica mágicamente el nuevo caso; ayuda a verlo antes.

Así aprende el puente. El campo corrige el acervo y el acervo afina la mirada que regresa al campo. En ese intercambio, el método evita dos extremos: convertirse en una receta que fuerza todos los problemas a parecerse, o quedarse en una sensibilidad personal imposible de transmitir. La práctica reflexiva conserva un espacio intermedio, más exigente y más fértil. Reconoce que cada organización es singular, pero se niega a perder lo que una experiencia puede enseñarle a la siguiente.

Hay cierta modestia en trabajar de este modo. Obliga a aceptar que una entrega correcta puede contener una mala decisión, que una hipótesis elegante puede caer frente a una conversación de pasillo y que algunos aprendizajes llegan tarde para el proyecto que los produjo. Pero esa modestia no debilita el oficio. Es lo que permite que el oficio madure.

Ver también: El método del diagnóstico · La tesis del puente · Higiene sociotécnica · IMIA — el instrumento de madurez