Nota: Se trata de un artículo de opinión basado en mis conocimientos y experiencias a día de hoy (2024). Mi perspectiva sobre la industria del software cambia con el tiempo. Es una reflexión que no busca ofrecer soluciones concretas, sino presentar una visión del problema.
😲 No me importa documentar
Hace unos años durante una reunión rutinaria de equipo, probablemente en una daily, pronuncié estas controvertidas palabras sobre la finalización de un entregable: “no os preocupéis, yo me encargo, no me importa documentar el proceso”.
En ese momento noté en mis compañeros una mezcla de alivio e incredulidad, y se sucedieron muecas de aprobación mezcladas con comentarios del tipo: “perfecto, porque yo ODIO documentar”.
Es obviamente un recuerdo formado por más de una experiencia al respecto pero supongo que me entendéis. Documentar no gusta, tiene fama de labor tediosa y normalmente se desarrolla como colofón a un trabajo más o menos complejo que el equipo tiene muchas ganas de entregar o simplemente dar por finalizado. Es una barrera ante nuestro afán de marcar algo como completado.
La realidad es que en ciertos escenarios la documentación no es ni siquiera opcional, pero determinadas corrientes de pensamiento nos han hecho ver este acto casi con desprecio, como un apéndice aburrido a nuestro trabajo creativo como desarrolladores de software o, en ocasiones, como una acción defensiva que nos cataloga como malos profesionales.
Mi intención con esta entrada (o serie de entradas, aún no lo he decidido) es desmitificar el proceso y ver la documentación con otros ojos. Porque uno puede estar colgado de una cruz pero decidir silbar.
🚨 ¿Cuándo nos acordamos de la documentación?
Detestamos la documentación pero ella, sin rencor, siempre aparece para salvarnos en estas situaciones tan cotidianas: cuando alguien nuevo llega, cuando alguien importante se va o cuando suena el teléfono rojo:
Onboarding: Sobre este punto hay muchos y muy buenos artículos y la buena documentación sólo es uno de los factores de éxito. Tras mis últimos procesos de incorporación puedo decir que las piezas de documentación más útiles han sido los organigramas de empresa, los handbooks actualizados sobre el día a día (vacaciones y ausencias, planes de carrera, etc.) y las guías concisas de preparación de entornos u obtención de crendenciales. Parecen temas muy comunes pero creedme que hay mundos de distancia entre unas compañías y otras.
Marcha de compañeros a otros equipos o empresas: En estos casos las alertas se activan normalmente de parte de los gestores o managers. Siempre he notado en estos casos temores infundados sobre personas que con su marcha puedan llevarse consigo cierta información importante que no está redactada en ningún lugar. Si te pasa o ha pasado, es una mala señal, y no vas a solucionarlo escribiendo páginas y páginas en Confluence a última hora. Más adelante hablaré de cómo protegerse ante estas situaciones.
Incidencias o pérdidas de servicio: Este punto es crucial porque suele ser normal que los equipos de desarrollo no tengan una experiencia perfectamente uniforme y en periodos vacacionales o bajas prolongadas de personal clave puedes encontrarte con momentos en los que aquella persona que lo solucionaba todo no esté presente. Otra bandera roja si me lo permitís, pero que tiene arreglo más allá de eternos manuales con prodecimientos de arranque, rollback o resolución de incidencias.
🙅 Siempre rechazamos deliberadamente lo que no nos motiva
La paradoja de la documentación no queda aquí. Sabemos que en determinados escenarios, como los que he listado en el punto anterior, es fundamental.
Sin embargo, si interpelas directamente a tus compañeros y compañeras muy posiblemente no encuentres a demasiados que te digan que “la documentación es inútil”.
De hecho, seguro que te has encontrado varias veces piezas de documentación manifiestamente inservibles pero que el equipo no quiere eliminar porque “a lo mejor le sirve a alguien o están allí por alguna razón”. Una especie de ‘Síndrome de Estocolmo digital’ en el que generamos apego por algo que detestamos o que sabemos inútil.
Esto me lleva a pensar que, de una manera u otra, apreciamos el valor intrínseco de la documentación pero no la manera de obtener dicho valor.
Por ello en las siguientes entradas (sí, al final habrá más de una para que el texto no sea un ladrillo incomestible) intentaré hablar de los mitos asociados a la documentación y sobre alguna que otra técnica para hacer del proceso una travesía algo menos desagradable.
➕ En resumen
Nuestra percepción sobre la documentación en el desarrollo de software está algo distorsionada.
Aunque muchos la consideran tediosa, en realidad es esencial en momentos clave, como en la integración de nuevos empleados o durante incidentes críticos. Es curioso cómo, aunque reconocemos su importancia, pocos están dispuestos a admitirlo abiertamente.
Y tú, ¿de qué equipo eres?