Idea principal

Un Product Manager que lleva tres años trabajando con el mismo desarrollador no necesita escribir lo que sí debe escribir para un desarrollador que llegó hace tres meses. Un equipo que habla todos los días puede dejar ciertas cosas en lo oral; un equipo nuevo, distribuido o metido en un tema arriesgado tiene que explicitar más. La cantidad de escrito necesaria no es una propiedad del tema, es una función de lo que ambas partes ya tienen en común.

De ahí la deriva simétrica de soltar tres líneas: imponer plantillas por todas partes, añadir campos, convertir cada tarjeta en un minidosier, escribir para cubrirse en lugar de para trabajar. Referencias como la Definition of Ready y la Definition of Done ayudan mientras siguen vivas; estorban en cuanto sustituyen al juicio sobre lo que el otro ya sabe.

Por qué es importante

Esto explica por qué un estándar de escritura importado de un equipo a otro fracasa tantas veces: trae una cantidad de escrito calibrada sobre un contexto compartido que aquí no existe.

También señala la verdadera variable que hay que vigilar. Una rotación, una incorporación, un paso a trabajo distribuido aumentan la necesidad de escrito sin que ningún tema haya cambiado.

Matices y límites

El contexto compartido hace el escrito menos necesario para el equipo presente, no para el que vendrá. Un ticket que entienden dos personas ya no lo entiende el tercero que llega, ni el mismo equipo seis meses después.

Y la apreciación de lo que está "ya compartido" es optimista por naturaleza: quien escribe sobrestima lo que el otro tiene en la cabeza.

Preguntas abiertas

• ¿Cómo detectar que el contexto compartido ha bajado, antes de que los malentendidos aparezcan en el trabajo entregado?