Aterrizar la daily

Bajar el nivel de abstracción sin sonar a robot: un template de Ayer/Hoy/Bloqueantes, qué jerga traducir y cuál no, y un recurso de oratoria para que no te interrumpan a mitad de la lista.

—¿Vos, Jose?

—Eh… ayer estuve viendo el tema del mapeo. Había un problema con el repositorio, así que estuve viendo eso. Y hoy sigo con eso.

Dos "estuve viendo", dos "eso", y ninguna pista de qué se entregó.

Llega un día en que la comunicación se vuelve tan importante como el código, y la daily es el ejemplo perfecto: es el momento en que hay que bajar a tierra el nivel de abstracción con el que pensamos el trabajo, y bajar también el nivel técnico con el que lo contamos.

#La muletilla no es un problema de memoria

Lo que pasa casi siempre es que no nos acordamos con detalle de en qué estuvimos, y rellenamos los silencios con muletillas.

Y ahí está lo incómodo: esa muletilla no se lee como "no me acuerdo". Se lee como mala administración del tiempo y falta de preparación para hablar. Aunque hayas tenido un día productivo.

La solución es tan aburrida como efectiva: tomá nota mientras trabajás, por mínima que sea. Una línea suelta cada vez que cerrás algo. Todo suma. Después, cuando te toca el turno, lo leés.

No hace falta que sea prolijo. Hace falta que exista.

#La regla de oro

Antes del template, el criterio que ordena todo lo demás:

Cada frase tiene que responder "¿en qué le cambia esto al negocio o al usuario?". Si no podés contestar eso en la misma línea, la frase todavía está muy técnica.

Es el filtro que convierte un log de commits en una comunicación.

#El template

Estructura: Ayer / Hoy / Bloqueantes.

Granularidad: un ítem por feature o historia de usuario. Nunca por paso técnico. Esta es la que más cambia el resultado: no es que hables "más simple", es que agrupes distinto. Cinco pasos técnicos son un solo ítem si entregan una sola cosa.

#Qué traducir y qué no

Acá hay un matiz que se pasa por alto seguido: traducir todo también está mal. Si simplificás de más, sonás condescendiente y encima perdés precisión.

Conservá los términos que tu audiencia ya maneja: historias de usuario, ambiente de desarrollo, DevOps, sprint. Esas palabras ya son parte del idioma común del equipo.

Traducí solo la jerga de implementación pura: script, DTO, handler, repositorio, endpoint, query. Nada de eso significa algo para quien no escribe código.

#Ejemplos: tareas

El primero es el mismo trabajo contado como proceso, un ítem por paso. El segundo es el mismo trabajo contado como resultado.

Fijate que en el ejemplo bueno el detalle técnico no desaparece: queda al final, entre guiones, como nota al pie. Está disponible para quien lo quiera, pero no es lo que estructura la frase.

#Ejemplos: bloqueantes

Un bloqueante bien escrito tiene tres partes: sujeto + qué necesitás + de quién.

El primero describe un estado. El segundo pide una acción, y le pone nombre a quién la tiene que hacer.

Y una aclaración que ahorra discusiones: si se resuelve con más tiempo tuyo, no es un bloqueante — es una tarea larga. Un bloqueante es algo que no depende de vos.

#Una daily completa

Ayer:

• Junté la información necesaria para arrancar con el tema de rodados.
• Armé las historias de usuario para hacerle seguimiento al trabajo.
• Empecé a preparar la carga de esos datos en el sistema.

Hoy:

• Termino de cargar los datos y los pruebo en ambiente de desarrollo antes de tocar el sistema real.

Bloqueantes: ninguno.

Nada de eso menciona una tecnología, y sin embargo cualquiera del equipo sabe exactamente en qué estás.

#Cómo cerrar cada punto sin que te interrumpan

Esta parte no es sobre qué decís, sino sobre cómo suena — y es la que más rápido se nota.

El recurso se llama inflexión descendente: cuando terminás una frase, bajás el tono y el ritmo. El cerebro de quien escucha interpreta esa caída como "cerró una idea completa". Si en cambio terminás con el tono para arriba, como quien pregunta, suena a que dejaste la puerta abierta — y ahí es mucho más probable que te corten.

Pensalo como un avión aterrizando. Durante el vuelo mantenés altura y velocidad crucero: tono conversacional normal. En el tramo final, los últimos metros antes de tocar pista, descendés y frenás de forma controlada. Ese descenso es lo que le avisa a la torre que estás aterrizando y no todavía en vuelo.

Si cortás motor de golpe en el aire, o peor, si nunca bajás y seguís en altura con tono plano, el que escucha no sabe si terminaste o vas a seguir. Y ahí mete la cuchara.

El error común es meter esa bajada en la mitad de la frase. Ahí no sirve: tiene que ser específicamente en el cierre de la idea. Es el aterrizaje al final del vuelo, no una turbulencia en el medio.

#Un vuelo corto por cada ítem

Esto funciona todavía mejor en formato lista, porque cada ítem es su propio vuelo corto. Arrancás en tono normal, desarrollás, y aterrizás al final de ese ítem — no solo al final de todo.

"Junté la información necesaria para arrancar con el tema de rodados." (aterrizás — pausa breve) "Armé las historias de usuario para hacerle seguimiento al trabajo." (aterrizás — pausa breve) "Empecé a preparar la carga de esos datos en el sistema." (aterrizás)

Cada aterrizaje marca "este ítem cerró, viene el siguiente", y la pausa le da a la audiencia el respiro para procesar antes de que arranques el próximo.

Y como bonus: así es mucho más difícil que te corten a mitad de la lista, porque nunca das la sensación de estar en el aire — que es justamente cuando la gente aprovecha para meterse.

#Lo que queda

La daily no se prepara en la daily. Se prepara durante el día, en una línea suelta cada vez que cerrás algo.

Después es solo leer lo que ya sabés, agrupado por resultado en vez de por paso, y aterrizar cada punto antes de pasar al siguiente.

#communication #agile #daily #soft-skills