Power Query: Documenta el porqué, no solo el qué

TL;DR

Antes de “arreglar” algo, busca el histórico (tickets, emails, comentarios)
Cada filtro raro existe por una razón que alguien olvidó documentar
Un comentario de 10 segundos ahorra 2 horas de retrabajo
El cliente no recuerda lo que pidió hace 3 semanas

La historia

“Necesitamos que aparezcan las sedes Norte y Sur en el dashboard.”

Fácil, pienso. Voy al modelo, busco las sedes… y no existen.

Reviso la base de datos. Ahí están, con todos sus datos.

Reviso Power Query. Y encuentro esto:

= Table.SelectRows(
    Origen,
    each (
        [nombre_sede] <> "SEDE NORTE" and
        [nombre_sede] <> "SEDE SUR"
    )
)

Alguien las había filtrado explícitamente. Sin comentario. Sin documentación. Sin contexto.

El reflejo peligroso

Mi primer instinto: quitar el filtro y tirar para adelante.

Pero algo me dijo que mirara el histórico de tickets primero. Y ahí estaba, tres semanas antes:

“Por favor, eliminar esas dos sedes raras del informe, no sé qué son.”

El mismo cliente. La misma persona.

Si hubiera quitado el filtro sin mirar, habría deshecho trabajo que alguien hizo por una razón. Y cuando el cliente volviera a quejarse de “esas sedes raras”, estaríamos en bucle infinito.

Por qué pasa esto

1. El modelo acumula decisiones

Un modelo de Power BI que lleva meses en producción tiene decenas de decisiones implícitas:

Filtros que excluyen datos “basura”
Columnas renombradas para que tengan sentido
Transformaciones que corrigen errores del origen
Exclusiones por petición explícita del usuario

Cada una tenía sentido cuando se hizo. Ninguna está documentada.

2. Las personas rotan

El analista que hizo el filtro se fue. El consultor que montó el modelo terminó el proyecto. El becario que “arregló un bug” ahora es senior en otra empresa.

El conocimiento se fue con ellos. El modelo quedó.

3. El cliente olvida

No es mala fe. El cliente gestiona 50 proyectos, 200 emails diarios y 10 reuniones. Tu dashboard es una de muchas cosas en su cabeza.

Cuando te dice “arréglalo”, genuinamente no recuerda que él mismo pidió lo contrario hace un mes.

Cómo documentar en Power Query

Comentarios en pasos

Cada paso de Power Query puede tener un comentario. Úsalo.

// EXCLUIDAS: Sedes Norte y Sur por petición cliente
// Ticket #1234 - 2025-12-15
// Contacto: Juan Pérez ([email protected])
= Table.SelectRows(
    Origen,
    each (
        [nombre_sede] <> "SEDE NORTE" and
        [nombre_sede] <> "SEDE SUR"
    )
)

Nombres de pasos descriptivos

En lugar de Paso1, Paso2, usa nombres que expliquen:

Malo	Bueno
Filas filtradas	Excluir_Sedes_Prueba
Columnas eliminadas	Quitar_Columnas_Legacy
Tipo cambiado	Convertir_Fechas_ISO

Paso de documentación

Añade un paso inicial que no haga nada pero documente:

// ============================================
// DOCUMENTACIÓN DEL MODELO
// ============================================
// Autor: Tu nombre
// Última modificación: 2025-12-30
//
// DECISIONES IMPORTANTES:
// - Sedes Norte/Sur excluidas (ticket #1234)
// - Ventas < 0 tratadas como devoluciones
// - Clientes sin email marcados como "N/A"
// ============================================

let
    Origen = ...

Checklist antes de modificar

Antes de “arreglar” algo que parece un error:

1. ¿Hay histórico?

Revisar tickets/issues relacionados
Buscar emails con el cliente sobre este tema
Mirar commits/versiones anteriores si hay control de versiones

2. ¿Hay comentarios?

Revisar comentarios en el paso de Power Query
Buscar documentación del proyecto
Revisar notas en el propio informe (si las hay)

3. ¿Puedo preguntar?

Contactar al autor original (si está disponible)
Preguntar al cliente antes de actuar
Consultar con el equipo

4. Si no hay nada…

Documentar tu decisión AHORA
Crear ticket/registro del cambio
Avisar al cliente de lo que vas a hacer

Patrones comunes de “errores que no son errores”

Exclusión de datos de prueba

// Parece error: ¿por qué excluimos estos clientes?
= Table.SelectRows(Source, each [ClienteID] <> 0 and [ClienteID] <> 99999)

Realidad: Son IDs de prueba que el sistema usa internamente.

Filtro de fechas “arbitrario”

// Parece error: ¿por qué solo desde 2020?
= Table.SelectRows(Source, each [Fecha] >= #date(2020, 1, 1))

Realidad: Antes de 2020 los datos estaban en otro sistema y no son comparables.

Columnas eliminadas

// Parece error: ¿por qué quitamos el email?
= Table.RemoveColumns(Source, {"Email", "Telefono"})

Realidad: GDPR. El cliente no tiene permiso para que esos datos aparezcan en el dashboard.

Valores reemplazados

// Parece error: ¿por qué todos los negativos son 0?
= Table.ReplaceValue(Source, each [Ventas] < 0, 0, ...)

Realidad: Las devoluciones se procesan aparte. Aquí solo queremos ventas brutas.

Qué documentar (mínimo)

Elemento	Ejemplo
Qué	”Excluir sedes Norte y Sur”
Por qué	”Petición cliente - no son sedes reales, son códigos de prueba”
Cuándo	”2025-12-15”
Quién lo pidió	”Juan Pérez, ticket #1234”
Quién lo hizo	”Ana García”

Un comentario de una línea es mejor que nada:

// Sedes Norte/Sur excluidas por petición cliente (ticket #1234, dic 2025)

El coste de no documentar

Sin documentación	Con documentación
2h buscando por qué hay un filtro	10 segundos leyendo el comentario
Deshacer trabajo que era correcto	Entender que era correcto
Cliente confundido	Cliente satisfecho
Bucle infinito de cambios	Decisión informada

La documentación no es burocracia. Es ahorrarte trabajo futuro.

Conclusión

Cada filtro raro, cada exclusión extraña, cada transformación no obvia… probablemente existe por una razón.

Antes de tocar:

Busca el histórico
Lee los comentarios
Pregunta si hay dudas

Y cuando hagas cambios: documenta el porqué, no solo el qué.

10 segundos escribiendo un comentario hoy = 2 horas ahorradas dentro de 3 meses.

¿Quieres dominar Power Query? Lee Qué es Power Query y por qué deberías usarlo.

¿Problemas con las relaciones del modelo? Mira Power BI desactivó tu relación y no te avisó.

¿Números que no cuadran? Lee mi guía de debugging en Power BI.