Cómo documentar un proceso antes de automatizarlo

Casi todas las automatizaciones que fallan no fallan por el código. Fallan porque automatizaron un proceso que no era el que ocurre de verdad.

Ya escribí sobre el error de automatizar un proceso que nadie entiende del todo: el fallo, cómo se ve por dentro y lo que costó. Este artículo es el paso anterior, el que evita llegar ahí. El método que uso para documentar un proceso antes de tocar una sola línea.

El proceso que te cuentan nunca es el que pasa

Esto es lo primero que hay que asumir, y no tiene nada que ver con que nadie mienta.

Cuando le preguntas a alguien cómo funciona algo, te describe el proceso ideal: el que aparece en el manual, el que le explicaron cuando entró, el que funcionaría si nunca pasara nada raro. Es lo que cualquiera contestaría. Nadie te cuenta los cuatro atajos que ha ido construyendo en tres años, entre otras cosas porque ya no los ve. Para quien los usa a diario, el atajo es el proceso.

Y esos atajos no son un vicio a corregir. Normalmente son la parte más inteligente de todo el asunto: la adaptación que alguien hizo a un caso real que el manual no contemplaba. Si automatizas el manual, te cargas la adaptación y el sistema no sirve.

Empieza por el final

El error natural es preguntar “¿por dónde empieza esto?”. La respuesta siempre es confusa, porque los procesos rara vez tienen un único comienzo.

Funciona mucho mejor al revés: qué tiene que existir cuando esto termina. Un registro, un documento, un aviso, un dato en un sitio. Algo concreto y comprobable.

Con el resultado fijado, tiras del hilo hacia atrás. Qué hace falta para producirlo, qué hace falta para eso otro, y así. Es más lento de contar pero mucho más difícil de falsear, porque cada paso tiene que justificar su existencia frente al resultado final.

Si en algún punto nadie sabe explicarte para qué sirve un paso, apúntalo. Has encontrado algo interesante: o bien es un resto de un proceso anterior que ya nadie necesita, o bien hace algo importante que nadie ha sabido nombrar. Las dos cosas conviene aclararlas antes de automatizar.

Siéntate al lado, no preguntes en una sala

Una reunión sobre un proceso produce la versión oficial del proceso. Media hora al lado de quien lo ejecuta produce el proceso.

No hace falta montar nada formal. Que hagan lo que harían igualmente y tú mires. Lo que buscas son los momentos en los que la persona hace algo que no te había contado: abre otra pestaña, consulta una hoja suelta, escribe algo en un papel, le pregunta a alguien por el chat.

Cada uno de esos gestos es un paso del proceso real que no estaba en la versión oficial. Y son exactamente los que rompen una automatización, porque son los que no has contemplado.

Pregunta en el momento, no al final. “¿Eso qué es?” dicho justo cuando acaba de pasar obtiene una respuesta precisa. La misma pregunta veinte minutos después obtiene una reconstrucción.

Las excepciones son el proceso

Aquí es donde se decide si el sistema va a funcionar.

El camino feliz suele ser fácil de documentar y ocupa poco. Lo difícil, y lo que de verdad consume tiempo en el día a día, son los casos raros. Y la pregunta que los saca no es “¿qué excepciones hay?” — nadie sabe contestar a eso en abstracto.

Lo que funciona es preguntar por la última vez:

¿Cuándo fue la última vez que esto no salió como toca? Que te lo cuenten con detalle. Qué pasó, qué hicieron, a quién avisaron.

¿Cuántas veces al mes pasa algo así, más o menos? No necesitas precisión. Necesitas saber si es una vez al año o dos veces por semana, porque eso cambia por completo si la excepción va dentro del sistema o se queda fuera a propósito.

¿Qué es lo que más te hace perder tiempo de todo esto? Suele ser algo que no aparece en ninguna descripción del proceso, y suele ser el motivo real por el que te han llamado.

Cuenta los saltos

Un proceso se rompe en las costuras, no en las piezas. Así que documenta con especial cuidado dos cosas:

Los saltos entre sistemas. Cada vez que un dato sale de un sitio y entra en otro, con o sin copiar y pegar. Ahí está casi siempre el trabajo que se puede quitar, y ahí están casi todos los errores.

Los saltos entre personas. Cada vez que alguien tiene que esperar a que otro haga algo. Son los puntos donde el proceso se para durante horas o días sin que nadie esté trabajando, y normalmente no aparecen en ninguna descripción porque nadie los vive como parte del trabajo.

Un proceso con muchos saltos entre personas rara vez se arregla automatizando. Se arregla cambiando quién decide qué, que es una conversación distinta y bastante más incómoda.

Qué documento sacas de todo esto

Corto. Muy corto.

Lo que a mí me sirve cabe en una página: el resultado final, los pasos para llegar a él en orden inverso, las excepciones con su frecuencia aproximada, y los saltos entre sistemas y entre personas marcados.

Nada de diagramas elaborados. Un diagrama bonito es una trampa: da sensación de rigor y tarda tanto en hacerse que nadie lo actualiza, así que a las dos semanas describe algo que ya no existe.

La prueba de que está bien documentado: se lo lees en voz alta a quien ejecuta el proceso y no te interrumpe. Si te corrige tres veces, no has terminado. Vuelve, que es más barato ahora que después.

Cuándo parar

Se puede documentar eternamente, y eso también es una forma de no hacer nada.

Yo paro cuando puedo responder a estas preguntas sin consultar a nadie: qué tiene que existir al final, qué pasa cuando falla, con qué frecuencia falla, y quién se entera de que ha fallado.

Si puedo contestar a las cuatro, tengo suficiente para empezar a construir. Lo que falte aparecerá durante el desarrollo, y aparecerá barato.

Por qué merece la pena el rodeo

Documentar así cuesta unas horas, y son horas en las que no estás produciendo nada visible. Es tentador saltárselo, sobre todo cuando ya tienes la solución técnica clara en la cabeza desde el primer día.

Pero el coste de automatizar el proceso equivocado no son esas horas. Es un sistema que nadie acaba usando y, peor, el permiso que pierdes para proponer el siguiente.

Ese rodeo de unas horas es lo más barato de todo el proyecto.