Documentar un proceso para poder delegarlo, sin que sea un proyecto

Pregunta a cualquiera por qué no delega una tarea que le come el día y la respuesta suele ser la misma: «tendría que explicárselo todo». Tiene razón. El proceso existe, funciona y da resultados, pero vive entero en su cabeza: cuarenta decisiones pequeñas que nunca nadie escribió porque a quien las toma le parecen obvias.

Ahí se atasca casi toda la delegación. No en el presupuesto ni en encontrar a la persona: en que nadie tiene el proceso escrito y escribirlo parece un proyecto aparte.

Por qué escribirlo parece un proyecto

Porque cuando alguien se sienta a documentar, lo que se imagina es un manual. Un documento largo, ordenado, con introducción y alcance, que hay que terminar antes de que sirva para algo. Ese documento no se escribe nunca, y hace bien en no escribirse: cuando estuviera listo, la mitad estaría vieja.

Lo que hace falta es lo contrario. Un documento corto, feo, incompleto y útil desde el primer párrafo. Su objetivo no es describir tu operación: es que otra persona pueda hacer una cosa concreta sin preguntarte. Se mide así y no de otra manera.

Se documenta trabajando, no antes de trabajar

El único momento en que documentar es barato es mientras haces la tarea. Tienes el caso delante, recuerdas por qué decides lo que decides y las excepciones aparecen solas.

En la práctica: la próxima vez que hagas esa tarea, abre un documento al lado y escribe lo que vas haciendo en frases sueltas. No lo ordenes. No lo redactes bien. Dos o tres pasadas sobre casos distintos y tienes el proceso, con sus excepciones reales en vez de las que te imaginarías en una sala de reuniones.

Esto tiene una consecuencia práctica: la persona nueva es quien mejor documenta. Quien lleva cuatro años haciendo algo ya no ve los pasos; quien lleva cuatro días tropieza con todos. Pedir a alguien que documente lo que acaba de aprender —y corregirlo tú— produce en dos semanas un documento mejor que cualquier manual escrito desde arriba.

Empieza por lo que se repite

No documentes lo importante: documenta lo frecuente. La tarea que aparece cinco veces al día con la misma forma se amortiza en dos días. El caso excepcional que pasa una vez al trimestre no compensa, y además se explica mejor hablando.

Un orden que funciona: coge la semana pasada, mira dónde se te fue el tiempo y ordena por número de veces, no por importancia. Los tres primeros de esa lista son los que se documentan. Todo lo demás puede esperar, y bastante de eso nunca hará falta.

En una tienda, por ejemplo, esa lista casi siempre empieza con las mismas cosas: qué se contesta a un pedido que no ha llegado, cuándo se acepta una devolución fuera de plazo y qué se hace cuando el transportista deja de responder. Están todas en la operación de un ecommerce y ninguna es difícil — lo que pasa es que nadie las ha escrito, y por eso solo las sabe responder la misma persona.

Escribe la decisión, no solo el paso

Este es el punto donde fallan casi todos los documentos que sí existen. Describen la secuencia de clics —entra aquí, filtra por esto, marca esta casilla— y no dicen nada del criterio. Y el criterio es la parte que no se puede deducir.

Comparado:

• Paso: «Si el pedido lleva más de siete días, abre una reclamación al transportista».
• Decisión: «Si el pedido lleva más de siete días, abre una reclamación al transportista. Si el cliente ya ha escrito dos veces, además se le compensa el envío sin esperar la respuesta del transportista: preferimos perder el coste del envío antes que perder el cliente».

El segundo se puede aplicar a un caso que no está en la lista. El primero, no. Y esa diferencia es exactamente la que separa una persona que trabaja sola de una persona que pregunta veinte veces al día.

La regla corta: por cada paso donde alguien pueda dudar, una frase que empiece por «porque».

Las respuestas tipo son documentación

Lo que ya tienes escrito cuenta, y suele ser más de lo que crees. Las respuestas tipo del helpdesk, los correos que reenvías siempre iguales, la plantilla del informe, la nota que le pasaste a un compañero hace un año. Todo eso es proceso documentado, solo que disperso.

Reunirlo es media hora y tiene un efecto secundario útil: al leerlo junto se ven las contradicciones. Dos respuestas tipo que dicen cosas distintas sobre el mismo caso significan que el criterio nunca estuvo claro, y que hasta ahora lo resolvía la intuición de quien contestara. Eso no se delega. Antes hay que decidirlo.

Dónde vive el documento y quién lo actualiza

Dos preguntas sin las cuales lo anterior se echa a perder en tres meses.

Dónde. En el sitio donde se trabaja, no en una carpeta de documentación. Si el trabajo pasa en el helpdesk, el criterio va en las respuestas tipo y en las notas internas del ticket. Si pasa en el CRM, va en el propio campo y en la vista que se usa todos los días. Un documento que hay que ir a buscar es un documento que no se lee.

Quién. Quien hace la tarea, no quien la diseñó. La persona que ejecuta el proceso es la que encuentra el caso que falta, y si tiene permiso para añadirlo, el documento se mantiene vivo. Si tiene que pedir permiso, el documento muere. Basta con una norma: quien se encuentra un caso nuevo lo escribe el mismo día y lo marca como pendiente de validar.

Ese trabajo de mantener el criterio escrito, cruzado y al día es, de hecho, un puesto en sí mismo cuando el volumen crece: es lo que hace un puesto de datos y documentación de procesos, y suele ser lo más rentable del sitio, porque lo que se pierde en una empresa pequeña casi nunca es el dato — es el porqué de una decisión que nadie escribió.

Por qué un onboarding a medias hunde una contratación remota

Una persona nueva en remoto no tiene el pasillo. No oye cómo contestas al teléfono, no ve la cara que pones cuando un caso huele mal y no puede girarse a preguntar algo pequeño. Todo lo que en una oficina se aprende por osmosis, en remoto se aprende leyendo o preguntando.

Si no hay nada escrito, solo queda preguntar. Y preguntar tiene un coste que se paga dos veces: interrumpe a quien delegó —que era el motivo de delegar— y genera una sensación de que la persona nueva «no es autónoma», cuando lo que ocurre es que nadie le dio con qué serlo. Ahí es donde se rompen la mayoría de las incorporaciones remotas: no en la selección, en el arranque.

Por eso el listado de lo que hace falta antes del día 1 es corto y es condición, no recomendación: accesos creados y probados, la política de incidencias escrita aunque sea en una página, las respuestas tipo que ya uses y un interlocutor único a quien preguntar. Está detallado, semana a semana, en cómo funciona un equipo.

Qué hacer esta semana

Elige una tarea: la que más veces hagas y menos te guste. La próxima vez que la hagas, escribe lo que haces y por qué, en sucio, mientras la haces. Guarda ese texto donde se trabaja, no en una carpeta aparte.

A la siguiente, dásela a otra persona con el documento delante y sin explicarle nada de palabra. Todo lo que te pregunte es un agujero del documento: anótalo y rellénalo. Dos o tres rondas y esa tarea ya no es tuya.

Delegar no empieza con una contratación. Empieza con un documento de una página que hoy no existe.