«Falla el sistema»: la última frase de una conversación que no he oído

Llega un correo. El asunto, entero, dice:

Falla el sistema.

No hay más. O hay un cuerpo que repite el asunto y le añade un «¿podéis mirarlo?» detrás, que a efectos prácticos es lo mismo.

Y yo me quedo mirando la pantalla con la cara del mecánico al que le dejan las llaves encima del mostrador y le dicen «hace un ruido».

Qué sistema. Cuál de todos. Desde cuándo. Falla en qué sentido: ¿sale un error, va lento, se ha quedado la pantalla en blanco, han dejado de llegar los correos, aparece un texto raro donde no tocaba? ¿Le pasa a quien escribe o a los cuarenta de la oficina? ¿Hoy, o desde el jueves y nadie lo dijo?

Ninguna de esas preguntas es un reproche. Todas son, en el fondo, la misma pregunta.

Le han quitado las manecillas y le han pegado la conclusión. Reloj de la estación de Waterloo, Londres, marzo de 2010. Foto: Howard Lake, CC BY-SA 2.0, vía Wikimedia Commons; imagen adaptada y disponible bajo la misma licencia.

Una palabra: contexto

Para estos casos tengo una respuesta de reserva, y cabe en una palabra:

Contexto.

La mando tal cual, sin más, cuando hay confianza suficiente para que se entienda como lo que es: no un reproche, sino la pregunta que hace falta antes de poder empezar. Y la mando continuamente y con todo tipo de interlocutores.

Porque esto no es cosa de nadie en particular. Pasa con agencias, con clientes, con compañeros, con proveedores y —para no escribir esto desde una atalaya— también me pasa a mí. Bastante.

No es pereza: es que no sabes lo que sabes

Aquí está el asunto de verdad, y no tiene nada que ver con las ganas ni con la capacidad de nadie.

Quien escribe «no funciona» tiene delante una cantidad enorme de información que no sabe que tiene. Tiene la página abierta. Sabe qué estaba intentando hacer y por qué. Recuerda la conversación de ayer con el cliente que le llevó hasta ahí. Sabe qué esperaba que ocurriera al pulsar el botón. Está viendo el mensaje de error mientras escribe.

Todo eso le parece tan evidente que ni se plantea escribirlo. Así que manda la única parte que le parece nueva: la conclusión.

Y al otro lado llega la última frase de una conversación que nunca he oído.

Esto tiene nombre y tiene estudio. Se llama la maldición del conocimiento: cuando sabes algo, se te vuelve muy difícil imaginar cómo es no saberlo. El experimento que mejor lo enseña es de 1990, en Stanford: a un grupo se le pedía que golpeara con el dedo el ritmo de una canción conocidísima, y a otro que adivinara cuál era. Los que golpeaban calculaban que acertaría alrededor de la mitad de la gente. Acertó el 2,5 %: tres de ciento veinte.

Quien golpea la mesa oye la canción entera dentro de su cabeza, con letra y arreglos. Quien escucha oye una serie de golpes sueltos.

«Falla el sistema» son los golpes en la mesa.

Uno habla, la otra escucha, y en medio no hay más que un hilo. Grabado de «Le téléphone, le microphone et le phonographe», de Théodose du Moncel (París, 1880). Ilustración en dominio público, vía Wikimedia Commons; imagen reescalada.

Las que más veo

Sin ánimo de inventario, y sabiendo que las he mandado casi todas alguna vez:

La última es mi favorita, porque es la más generosa en apariencia y la más cara en la práctica: quien reenvía te está dando todo el contexto. En bruto, sin ordenar y sin decir cuál de los catorce mensajes es el que importa. Es la diferencia entre darme un dato y darme un archivo.

Y luego está el clásico absoluto, que se merece apartado propio.

La captura recortada

Existe un género fotográfico exclusivo de nuestro oficio: el recorte de doscientos por sesenta píxeles en el que se ve un botón, medio texto y nada más.

Lo entiendo perfectamente, además. Quien la hace está siendo considerado: recorta para no marearme con lo que no viene al caso, para señalar el problema, para ahorrarme trabajo. La intención es impecable.

El problema es que lo que se recorta no es ruido. En una captura de pantalla completa viene, gratis y sin pedirlo:

• La URL, que dice en qué página estamos y muchas veces si es la de producción o la de pruebas.
• La hora, que me permite ir a los registros del servidor y buscar ese minuto exacto.
• Si hay una sesión iniciada, porque la pantalla puede cambiar según la cuenta y sus permisos.
• El navegador, el tamaño de la ventana, el zoom al 150 % que explica por qué «se ve mal».
• El resto de la página, donde bastantes veces está el aviso que se ha pasado por alto.

Con una advertencia, que además es la que doy yo antes que nadie: completa no significa indiscriminada. Si en la pantalla salen datos personales, pestañas privadas o información de un cliente que no tiene por qué viajar por correo, se tapa. La idea es conservar el contexto técnico —URL, hora, navegador y pantalla—, no mandar media vida digital detrás.

Todo eso desaparece con el recorte. Y sus dos parientes cercanos duelen igual: la captura hecha con el navegador a pantalla completa, que se come justamente la barra de direcciones, y la URL de la portada pegada en el correo cuando el problema ocurre tres clics más adentro. Acabo navegando a ciegas, buscando una pantalla que el otro tenía delante.

Una incidencia sin contexto no es todavía una incidencia. Es una invitación a abrir una investigación.

Y la investigación la abre uno, sin haber visto nunca el sitio de los hechos.

El mismo aviso, dos veces

Sin contexto:

No funciona el formulario. ¿Podéis mirarlo?

Con contexto:

En esta URL, al enviar el formulario de contacto desde Chrome en el móvil, me sale este mensaje. Me pasa desde esta mañana. Esperaba llegar a la pantalla de «gracias», pero se queda cargando y no avanza. Te adjunto la captura entera.

El segundo no es más técnico que el primero. No usa una sola palabra que no sepa cualquiera. Es exactamente el mismo aviso, contado por alguien que ha caído en la cuenta de que yo no estaba ahí.

La diferencia práctica: el primero cuesta dos o tres correos de ida y vuelta antes siquiera de empezar; el segundo empieza directamente por el arreglo. Y esos dos o tres correos no son diez minutos, son dos días, porque cada uno contesta cuando puede.

Definir bien es la mitad del trabajo

Hasta aquí he hablado de averías, pero lo mismo vale —y sale más caro— cuando lo que llega no es un fallo, sino un encargo.

Una incidencia mal contada acaba en una investigación: es tiempo perdido, pero se nota enseguida. Una petición mal definida acaba en algo construido. Alguien se pone, lo hace, lo entrega, y solo entonces se descubre que lo que había que hacer era otra cosa. Esa factura no se paga en correos, se paga en semanas.

«Es un cambio pequeño» no define nada, porque pequeño es una opinión sobre un trabajo que todavía no se ha descrito. «Hazlo como en la otra web» tampoco: como en la otra web ¿en qué? ¿En el aspecto, en el orden de los pasos, en lo que ocurre al enviar? Definir bien es contestar cuatro cosas que se parecen sospechosamente a las de una incidencia:

• Qué hay que cambiar, señalado sin ambigüedad: la página, el bloque, el texto que hay ahora.
• Para qué, que es lo único que permite proponer algo mejor en vez de ejecutar a ciegas.
• Qué tiene que pasar cuando esté hecho, contado desde fuera, como lo vería quien lo use.
• Cómo sabremos que está bien, es decir, con qué se va a comprobar.

El último punto es el que casi nadie escribe y el que evita casi todas las discusiones posteriores. Mientras nadie diga cómo se comprueba que algo está terminado, «terminado» significa una cosa distinta a cada lado de la conversación, y las dos partes creen tener razón. Definir no es papeleo: es ponerse de acuerdo antes en lo que de todas formas habrá que acordar después, cuando ya está hecho y duele.

Y funciona igual en la otra dirección. Buena parte de las peticiones que llegan sin definir no es porque a nadie le apetezca definirlas, sino porque quien las manda tampoco lo tiene claro todavía. Escribir esas cuatro respuestas obliga a averiguarlo, y unos cuantos encargos se caen solos justo ahí, antes de haber costado nada.

Cuatro cosas, y ya

No hace falta diagnosticar nada. Insisto en esto porque es donde más gente se bloquea: nadie espera que quien avisa sepa si el problema está en el servidor, en el navegador o en un plugin que se actualizó anoche. Ese es mi trabajo, no el suyo.

Solo hace falta que yo pueda verlo. Con cuatro cosas suele bastar:

1. Dónde. La URL completa, copiada de la barra de direcciones. O el nombre exacto de la pantalla, si no es una web.
2. Qué estabas intentando hacer.
3. Qué esperabas que pasara.
4. Qué pasó en realidad.

Y cuando venga a mano, sin obligación ninguna, cualquiera de estas ayuda muchísimo: el mensaje de error entero —copiado como texto, mejor que descrito—, una captura sin recortar, el dispositivo y el navegador, desde cuándo ocurre, si pasa siempre o solo a veces, y si le pasa a más gente.

Fíjate en que el 3 y el 4 son los que casi nunca se escriben y los que más valen. «Qué esperabas» es lo que separa un fallo de un malentendido, y hay peticiones enteras que se resuelven justo ahí: descubriendo que el sistema hacía exactamente lo que tenía que hacer, y no lo que la otra persona daba por hecho. Que es, otra vez, un problema de definición: nadie llegó a escribir qué se suponía que tenía que pasar.

Nada de esto es un formulario que haya que rellenar para tener derecho a pedir ayuda. Si alguien está agobiado, con un cliente encima y la web caída, que llame; ya lo ordenamos entre los dos. Esto va de la petición normal, la de un martes cualquiera, esa en la que escribir dos frases más ahorra dos días.

Y la mitad que me toca a mí

Sería muy cómodo dejarlo aquí, con la lista de lo que hacen los demás. Pero hay una parte incómoda: el que más contexto se salta es siempre el que más sabe del asunto. Y en muchas conversaciones ese soy yo.

Mando mensajes que solo se entienden desde dentro de mi cabeza. Contesto «ya está subido» sin decir qué ni dónde. Explico una decisión técnica dando por supuestas tres cosas que la otra persona no tiene ninguna obligación de saber, y me quedo tan ancho porque para mí eran obvias. Escribo presupuestos redactados como si todo el mundo distinguiera un entorno de pruebas de uno de producción. He soltado la conclusión sin el razonamiento más veces de las que me gustaría reconocer, que es el mismo pecado exacto, solo que cometido desde el lado del que sabe.

Y hay una versión todavía peor, que también he practicado: pedir contexto para no ponerse. Contestar con una batería de preguntas, dejar la pelota en el otro tejado y respirar tranquilo hasta que conteste. Eso ya no es pedir contexto, es un interrogatorio haciendo las veces de parachoques. La diferencia se nota en una cosa: si preguntas lo que necesitas para empezar o todo lo que se te ocurre. Tres preguntas concretas mueven un asunto; doce lo entierran.

De esto va también aquella entrega sobre suponer en vez de verificar: actuar sobre lo que uno cree entender, sin comprobarlo, sale caro en las dos direcciones.

Contexto

Voy a seguir contestando «contexto» durante unos cuantos años más. Y voy a seguir recibiendo, de vez en cuando, la última frase de una conversación que todavía no me habían contado.

No pasa nada. A estas alturas la siguiente pregunta ya se la sabe todo el mundo, y se contesta rápido.

Lo que he acabado entendiendo es que la palabra no lleva nombre propio. Vale para las agencias. Vale para los clientes, que además son quienes nos avisan de la mitad de las cosas que nosotros no vemos, y lo hacen con toda la buena fe del mundo. Vale para los compañeros. Y vale, sobre todo, para el que la dice.

Agencia, contexto.

Cliente, contexto.

Y, siendo honestos: Esteban, contexto también.

El experimento de los golpes en la mesa procede de la tesis doctoral de Elizabeth Newton, «The Rocky Road from Actions to Intentions» (Universidad de Stanford, 1990): cuarenta personas golpeando ritmos, cuarenta escuchando, ciento veinte intentos y tres aciertos. Se hizo célebre fuera del ámbito académico a partir de «Made to Stick», de Chip y Dan Heath (2007).