Escribir intencionalmente para la comunicación asincrónica puede
resolver todos los problemas mencionados anteriormente.
La escritura asincrónica es diferente de los mensajes de chat. Vive más
tiempo, se dirige a un público más potencial y es fácil de descubrir.
Para vivir más tiempo, el texto debe ser consciente de un contexto de
grupo de lectores más amplio. Cuando los chats a menudo consideran solo
uno o dos lectores que tienen el contexto para entender de qué hablas,
el texto de larga vida debe considerar a todo el grupo de lectores
potenciales. Ahora y en algún momento en el futuro.
Para que el texto viva más tiempo y se dirija a un público más amplio,
debe asumir un contexto de lector menos existente. Los mensajes de chat
se dirigen a uno / dos lectores, en un momento específico. Por lo tanto,
suponen que esos lectores tienen el contexto actual que les será claro
específicamente.
La escritura asincrónica no asume un contexto de persona específico ni
asume conocimiento de eventos «actuales». Sorprendentemente, eso no
necesariamente hace que el texto sea más largo o más difícil de
escribir.
Como ejemplo, consideramos un escenario en el que tenemos un problema de
DB en nuestro equipo en el que la instancia de MySQL falla
ocasionalmente debido a errores de falta de memoria. Escribiendo solo
para su equipo, ellos saben cuál es el problema ahora y qué DB es.
Otros, pueden no saber qué DB tiene el problema (digamos que también
usa mongodb en alguna parte), no saben cuál es el problema.
Un mensaje suficiente para el contexto del chat que no durará mucho
tiempo podría ser: «Arreglaré la base de datos hoy». El texto asíncrono
equivalente será registrar el problema en un sistema, márquelo como
«trabajando en ello» por hoy con el texto «Problema de falta de memoria
de MySQL».
El texto no es más largo, sin embargo, tiene todo el contexto que
cualquier persona ajena podría necesitar para comprender lo que está
sucediendo sin la necesidad de contactar a nadie para preguntar «¿En qué
DB tenemos un problema?» «¿Cual es el problema?» «¿Desde cuándo lo
sabemos?» «¿Quién está en eso?» etcétera etcétera’.
La capacidad de descubrimiento es la siguiente parte esencial de este
sistema de comunicación. Necesita que sus escritos sean fácilmente
reconocibles para todos los que puedan necesitarlos en el futuro.
Confiar en la búsqueda de texto completo generalmente no es una buena
idea. Necesita un sistema de organización en su lugar. ¿A dónde va la
descripción de tareas? ¿Dónde van los documentos de diseño del sistema?
¿Todos viven en un lugar o por proyecto? ¿O tal vez por departamento en
grandes organizaciones?
Cada empresa tiene algún tipo de sistema, generalmente guiado por su
intercambio de conocimientos también. Ya sea Jira, Basecamp,
Monday o cualquier otra cosa. Solo tiene que asegurarse de que el
sistema sea consistente y lo suficientemente ajustado como para que las
personas nuevas en un proyecto puedan descubrir todo lo que necesitan.
Tomando el ejemplo del problema de MySQL aquí también, digamos que un
nuevo miembro del equipo obtiene la tarea. La tarea está marcada con las
etiquetas «base de datos», «infraestructura». Puede seguir la etiqueta
de «base de datos» para encontrar tareas pasadas recientes realizadas,
para ver si hay sospechosos obvios.
No encuentra ninguno, por lo que decide verificar si algún analista de
datos hizo algo espeluznante. Él va a la lista de tareas de los equipos
de analistas de datos, encuentra la etiqueta «nuevo tablero». Parecen
una gran ventaja, encuentra que una nueva tarea en el tablero se realizó
el día que comenzó el problema.
Ahora necesita revisar este tablero, pero usa un sistema de
visualización con el que no está familiarizado. Se dirige a la wiki del
equipo de datos, donde encuentra un documento sobre «cómo usamos nuestro
sistema de visualización». Establece sus credenciales y entra a explorar
las consultas.
Ya ves a dónde voy con eso. Cuando todo es fácilmente accesible y obvio,
puede concentrarse en la tarea misma sin interrumpir el flujo. Imagine
un escenario en el que en cada paso tendría que detenerse y preguntarle
a alguien:
- Josh de mi equipo: «Oye, ¿alguien le hizo algo al DB recientemente?»
- Dani del equipo de datos: «Oye, ¿lanzaste o cambiaste alguna consulta
pesada recientemente?»
- Ramón de la infraestructura de datos: «Oye, ¿cómo usamos nuestra
herramienta de visualización para editar un tablero?»
En este caso, depende de que otros estén disponibles y recuerden todas
las respuestas. Su flujo se interrumpe constantemente sin ninguna forma
de progresar antes de obtener respuestas. No puede concentrarse en un
horario de trabajo flexible, porque debe tener todos los miembros del
equipo constantemente disponibles.