Práctica reflexiva

Hay proyectos que terminan dos veces. La primera, 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 llega bastante después, cuando alguien por fin entiende qué pasó. A veces esa comprensión aparece al revisar una decisión que en su momento pareció menor. Otras, frente a un problema nuevo en otra organización, cuando una escena conocida vuelve con la claridad que no tuvo mientras ocurría.

Esa clase de revelación casi nunca es espectacular. Se parece poco al momento luminoso de una presentación y mucho 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 costaba llamarlo casualidad. Al tercero se vuelve patrón, y un patrón obliga a revisar el método.

Ahí empieza la práctica reflexiva: el trabajo de volver sobre una intervención cuando la urgencia ya pasó, reconstruir sus decisiones y separar lo que pertenece a ese caso de lo que probablemente volverá a aparecer. La expresión suena académica, pero el gesto es concreto. Consiste en frenar un momento la compulsión de pasar al proyecto siguiente y preguntarse qué se aprendió, qué se creyó aprender y con qué evidencia se sostiene cada cosa.

Esa última distinción pesa. Acumular años de trabajo no garantiza acumular experiencia: se puede repetir durante diez años la 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 de quien los reunió.

Volver al lugar donde se decidió

Una revisión útil no se conforma con anotar que el proyecto salió bien o mal. Son etiquetas demasiado gruesas. Un proyecto puede cumplir el alcance e instalar, al mismo tiempo, una dependencia que lo vuelva frágil. Puede demorar más de lo previsto y dejar una capacidad interna que justifique la espera. Puede ser celebrado por la dirección y evitado en silencio por quienes trabajan con él. Lo que interesa es menos el resultado aislado que la forma en que se produjo.

Por eso hay que 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 que todavía era barato cambiar de rumbo?

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

Distribuidora Norte muestra 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ó. Pero 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 tenía que incorporarlo.

El aprendizaje no fue “hacer interfaces más simples”, una conclusión tan general que casi no sirve. Fue más preciso: 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 su momento estaban separadas y atribuye intención a resultados que tuvieron bastante de contingencia. Por eso la reflexión necesita una bitácora escrita mientras el trabajo ocurre. No hace falta convertir cada jornada en un informe; alcanza con registrar los cambios que después podrían explicar por qué el proyecto tomó la forma que tomó.

Una entrada útil contiene pocas cosas, pero concretas: qué se observó, qué interpretación se hizo, qué decisión produjo y qué tendría que pasar para demostrar que la interpretación era errónea. Esa última pregunta impide que la bitácora se vuelva un diario de autojustificación. Si se anota que un equipo rechaza una herramienta por miedo a perder autonomía, también hay que anotar qué conducta se esperaría ver si la hipótesis fuera cierta: planillas paralelas, pedidos de autorización para acciones que antes eran informales, un uso correcto durante las demostraciones y casi nulo cuando nadie supervisa. Si nada de eso aparece, hay que buscar otra explicación.

Con el tiempo, la bitácora cumple tres funciones. Primero, ayuda a conducir el proyecto en curso, porque 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. Por último, cuando se comparan varias intervenciones, alimenta el acervo del método. Es ahí donde una observación puede pasar de caso singular a hipótesis recurrente.

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

La misma cautela vale para el 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 después habrá que contrastar con una muestra mayor. Confundir juicio acumulado con validación estadística sería repetir, dentro del método, el atajo que el método critica.

Cuando el fracaso avisa antes

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

Lo que este libro llama patrones de fracaso son esas configuraciones recurrentes: combinaciones de conductas que suelen llevar a un resultado previsible si nadie vuelve a leer la situación. La palabra fracaso no busca culpables ni anuncia que todo está perdido.

Uno de los más comunes es el piloto diseñado para innovadores, el mismo que casi atrapa a Distribuidora Norte. La persona entusiasta que acepta probar algo nuevo es valiosísima para empezar y pésima como única representante del usuario futuro: tolera errores, completa mentalmente las instrucciones que faltan y le concede al producto una paciencia que la jornada normal no le va a conceder. La corrección es sumar pronto a quienes necesitan que la herramienta sea evidente, rápida y confiable. El objetivo no es apagar el entusiasmo del innovador, sino averiguar si puede convertirse en hábito colectivo.

Otro patrón aparece cuando se automatiza antes de sanear el dato. Al principio parece 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 al modelo le falta ajuste. A veces pasa lo contrario. El sistema agrega 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 hizo más rápido, más visible y más difícil de discutir, porque ahora llega con 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 sienten 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 poco dramático: cargas incompletas, uso intermitente, regreso al canal informal. Cada una de esas conductas informa 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 primero quiere demostrar valor. La secuencia ya era discutible cuando el software solo sugería; con agentes capaces de ejecutar acciones, es peligrosa. El cociente entre potencial agéntico y capacidad de gobernanza que propone el 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, así que ante la primera excepción abre un ticket o inventa un rodeo. Ese traspaso sin criterio produce dependencia y deuda sociotécnica a la vez. Si además la transformación dependía de una sola 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 raíz tecnológica. Una organización puede declarar que quiere innovar y castigar cada intento que no sale bien. Puede contratar una solución pensada para una empresa diez veces más grande y después 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 lo aprendido. En estos casos la tecnología funciona como pantalla: permite discutir herramientas en lugar de incentivos, escala o condiciones de trabajo.

Reglas que nacen del terreno

Una heurística es una regla práctica para decidir con información incompleta. No pretende ser una ley ni debería usarse para evitar el juicio. Sirve para detener la inercia y obligar a hacer una pregunta incómoda en el momento oportuno. Las que siguen se escriben en primera persona, por una razón que se explica al final de la sección.

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 averiguar antes de comprometer más recursos.

No automatizo un proceso cuyo responsable no puede explicar por qué se hace así. La regla no exige un procedimiento perfecto. Exige reconocer si se está ante una práctica comprendida o ante 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 hay que producir sentido compartido.

Con los datos pasa algo parecido. 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 tiene que 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 distinguir una cosa de la otra. Etiquetar todo desacuerdo como resistencia al cambio ahorra tiempo en la reunión y lo cobra con intereses en producción.

Estas reglas van en primera persona porque implican responsabilidad profesional. “Nunca automatizo” pesa distinto que “se recomienda no automatizar”: deja claro que alguien toma una decisión y tendrá que responder por ella. También admite revisión. Si la experiencia futura muestra que una regla es demasiado rígida, habrá que reescribirla.

Reflexionar con otros

Toda práctica reflexiva solitaria corre un riesgo: construir una mitología personal en la que el profesional siempre vio venir el problema. Para evitarlo, la revisión tiene que 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 cambiaría cada participante si volviera al comienzo. Las respuestas no siempre coinciden, y esa divergencia es valiosa: muestra que el mismo proyecto produjo experiencias distintas según el lugar que cada uno ocupaba en la organización.

La reflexión, además, tiene que separarse del ritual de la culpa. Si cada incidente termina en la búsqueda de quién se equivocó, la próxima vez habrá menos información disponible, porque las personas aprenderán a ocultar dudas y rodeos hasta que sea imposible disimularlos. Un postmortem serio reconstruye condiciones y decisiones. No borra la responsabilidad individual; 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 pasa por 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 quedarse en la bitácora sin convertirse todavía en doctrina.

Cuando las supera, el movimiento se invierte y 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é pasa durante una ausencia. El concepto no explica por arte de magia el caso nuevo; ayuda a verlo antes.

Así aprende el puente: el campo corrige el acervo y el acervo afina la mirada que vuelve al campo. En ese intercambio, el método esquiva dos extremos. Uno es convertirse en una receta que obliga a todos los problemas a parecerse. El otro es quedarse en una sensibilidad personal imposible de transmitir. La práctica reflexiva sostiene un espacio intermedio, más exigente y más fértil, que reconoce la singularidad de cada organización sin resignarse a perder lo que una experiencia puede enseñarle a la siguiente.

Trabajar así exige cierta modestia. Obliga a aceptar que una entrega correcta puede contener una mala decisión, que una hipótesis elegante puede caer ante una conversación de pasillo y que algunos aprendizajes llegan tarde para el proyecto que los produjo. Esa modestia no debilita el oficio. Es lo que le permite madurar.

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