Método FDE

Qué observar, qué preguntar y qué dejar escrito en cada fase

Lo que diferencia a un buen FDE no es el código, sino detectar pronto lo que nadie ha dicho, decidir con criterio y dejarlo escrito para que nadie tenga que volver a preguntar. Este método se aplica a los nueve encargos: cada step del curso tiene además sus propios puntos de atención y errores típicos.

Mira el proceso real, no el descrito

Lo que el cliente cuenta en la reunión es la versión ideal. Pide ver el trabajo en directo, con datos de verdad, y cuenta casos: cuántos formatos, cuántas excepciones, quién corrige qué.

El riesgo mayor, primero

Empieza por la pieza que puede tumbar el proyecto (el acceso a un sistema, la calidad de los datos, la precisión del modelo), no por la más cómoda. Un spike de un día evita semanas perdidas.

Nada importante solo en tu cabeza ni en un chat

Cada decisión, supuesto y cambio de alcance queda escrito en el repo con fecha y quién lo decidió. Si no está escrito, no se decidió.

Criterios de aceptación medibles y aceptados

Si el cliente no ha aceptado por escrito cómo se mide el éxito, el proyecto no termina nunca. Números, no adjetivos.

Demuestra pronto y a menudo

Una demo con datos reales cada semana destapa malentendidos cuando aún son baratos de corregir.

Diseña para el día en que tú ya no estés

El sistema lo va a operar el equipo del cliente. Si no pueden entenderlo, vigilarlo y arreglarlo sin ti, no está terminado.

Malas noticias, pronto y por escrito

Un retraso, un dato malo o un error tuyo comunicados el mismo día son un problema; descubiertos por el cliente son una crisis de confianza.

Las fases de un encargo

Objetivo

Decidir si el proyecto tiene sentido, acotarlo y dejar firmado qué se entrega, en cuánto tiempo y cómo se mide.

Qué observar

  • Si el problema tiene un dueño con presupuesto y autoridad, o es una idea de alguien sin poder de decisión.
  • El coste actual del problema en horas, errores o ventas perdidas: sin esa cifra no hay caso de negocio.
  • Las dependencias que no controlas: accesos, datos, otro proveedor, aprobaciones de TI o de legal.
  • Si lo que piden se puede validar con un piloto pequeño antes de comprometer el proyecto entero.

Señales de alarma

  • Te piden precio cerrado sin haber visto datos ni sistemas.
  • Nadie puede decir cuánto cuesta hoy el problema.
  • El sponsor no tiene presupuesto propio y 'lo va a proponer arriba'.
  • Quieren empezar mañana sin un documento firmado.
Preguntas clave
  • Al sponsor¿cuánto os cuesta hoy este problema al mes, en horas o en dinero?
  • Al sponsor¿qué presupuesto y qué plazo tenéis en mente? ¿Quién lo aprueba?
  • Al sponsor¿qué tendría que pasar en las primeras 4 semanas para seguir adelante?
  • Al sponsor¿qué otras opciones estáis valorando (otro proveedor, hacerlo internamente, no hacer nada)?
  • A TI del cliente¿qué aprobaciones de seguridad, datos o arquitectura necesita un proyecto así y cuánto tardan?
  • A ti mismo¿cuál es el riesgo que más puede disparar la estimación y cómo lo acoto en la propuesta?
  • A ti mismo¿qué dejo explícitamente fuera para que la propuesta sea defendible?

Qué documentar

  • Propuesta con problema, alcance, fuera de alcance, fases, criterios de aceptación, supuestos, dependencias del cliente, estimación con rango y precio (plantilla más abajo).
  • Estimación desglosada por bloques con su incertidumbre, guardada aunque no se envíe al cliente.
Errores típicos
Dar un precio cerrado antes del discovery.
Qué provoca
El primer imprevisto se come el margen y el proyecto empieza con tensión.
Cómo evitarlo
Propón un discovery o piloto corto de precio fijo y estima el resto con rangos tras él.
No escribir las dependencias del cliente.
Qué provoca
Los retrasos por accesos o datos se te atribuyen a ti.
Cómo evitarlo
Lista en la propuesta qué debe aportar el cliente y en qué fecha, y qué pasa con el plazo si no llega.
Estimar solo el camino feliz.
Qué provoca
Integraciones, datos malos y handoff duplican el tiempo real.
Cómo evitarlo
Estima por separado integración, calidad de datos, pruebas, documentación y handoff, y añade margen al bloque más incierto.

Situaciones difíciles y cómo actuar

El sponsor desaparece o cambia de puesto a mitad del proyecto.

Señal: Las reuniones se cancelan, las decisiones se quedan en el aire, nadie firma.

Escala pronto: pide por escrito quién asume la decisión. Resume el estado y las decisiones pendientes en una página para el nuevo interlocutor. No sigas construyendo sobre supuestos sin validar.

TI bloquea o retrasa los accesos.

Señal: Peticiones sin respuesta, 'lo vemos en el comité', permisos más amplios de lo necesario rechazados.

Pide el mínimo privilegio con justificación técnica, ofrece una reunión de seguridad, y trabaja con mocks o sandbox mientras tanto. Deja constancia del impacto en el plazo en el informe semanal.

Los datos reales son mucho peores de lo prometido.

Señal: Un 20% de registros incompletos, formatos distintos, duplicados masivos.

Cuantifícalo con ejemplos, enséñalo en la demo y propón opciones: limpiar en origen, cuarentena y revisión humana, o reducir alcance. No lo escondas ni lo arregles en silencio.

Plazo imposible impuesto desde arriba.

Señal: La fecha no sale de ninguna estimación sino de un evento o una promesa comercial.

Muestra qué cabe en esa fecha con calidad y qué no. Ofrece recortar alcance, no calidad ni pruebas. Pon la decisión por escrito con quién la toma.

Te piden saltarte una medida de seguridad o de privacidad 'solo para la demo'.

Señal: Datos reales en un entorno sin proteger, credenciales compartidas, desactivar la autenticación.

No lo hagas. Ofrece la alternativa (datos sintéticos, cuenta de prueba, entorno aislado) y, si insisten, deja constancia escrita y escala al responsable de seguridad.

El usuario final no quiere usar el sistema.

Señal: Sigue con su Excel en paralelo, encuentra pegas a todo, no aparece en las pruebas.

Siéntate con esa persona, entiende qué pierde o qué teme. Suele ser control o carga de trabajo. Incorpórala a las decisiones de diseño y mide lo que le ahorra a ella, no solo a la empresa.

El cliente pide algo nuevo cada semana.

Señal: El backlog crece y nada sale; 'ya que estás, ¿podrías…?'.

Registra cada petición como solicitud de cambio con su impacto. Revisad juntos la prioridad cada semana: entra algo, sale algo o se mueve la fecha.

Te equivocas y rompes algo en producción del cliente.

Señal: Errores, datos incorrectos, usuarios afectados.

Avisa tú primero, con lo que sabes y lo que no. Contén el daño, corrige, y escribe un postmortem sin culpables con acciones concretas. La confianza se pierde por ocultar, no por fallar.

Plantillas de documentación

Cópialas al repo. Cada una tiene su versión en docs/es y su traducción en docs/en.

Acta de reunión

Después de cada reunión con el cliente, el mismo día. Va en docs/es/reuniones/AAAA-MM-DD-tema.md.

# Reunión: <tema>

**Fecha:** AAAA-MM-DD · **Asistentes:** nombre (rol), ...

## Objetivo de la reunión

## Lo que hemos aprendido
- 

## Acuerdos
| # | Acuerdo | Quién lo decide |
|---|---|---|
| 1 | | |

## Pendientes
| # | Tarea | Responsable | Fecha |
|---|---|---|---|
| 1 | | | |

## Supuestos nuevos o preguntas abiertas
-
Supuestos y preguntas abiertas

Un único fichero vivo: docs/es/supuestos.md. Se revisa en cada reunión.

# Supuestos y preguntas abiertas

| ID | Tipo | Descripción | Impacto si es falso | Cómo se valida | Responsable | Estado |
|---|---|---|---|---|---|---|
| S1 | Supuesto | Los ficheros siempre llegan en UTF-8 | El parseo falla en silencio | Revisar 50 ficheros reales | Gus | Abierto |
| P1 | Pregunta | ¿Quién aprueba los accesos al ERP? | Bloqueo del desarrollo real | Preguntar a TI | Marta | Abierto |
Registro de decisión (ADR)

Una decisión no obvia por fichero: docs/es/adr/0001-titulo.md, con su traducción en docs/en/adr.

# 0001. <Decisión en una frase>

**Estado:** propuesta | aceptada | sustituida por 000X
**Fecha:** AAAA-MM-DD · **Decide:** nombre

## Contexto
Qué problema hay y qué restricciones aplican.

## Opciones consideradas
1. Opción A: ventajas, inconvenientes
2. Opción B: ventajas, inconvenientes

## Decisión
Qué se elige y por qué.

## Consecuencias
Qué se gana, qué se pierde, qué habrá que vigilar.
Solicitud de cambio de alcance

Cada vez que el cliente pide algo que no estaba en los requisitos. Va en docs/es/cambios/.

# Cambio CR-00X: <título>

**Pedido por:** nombre · **Fecha:** AAAA-MM-DD

## Qué se pide

## Por qué

## Impacto
- Plazo: 
- Coste o esfuerzo: 
- Riesgo: 
- Qué deja de hacerse o se retrasa: 

## Decisión
Aprobado / rechazado / aplazado, por quién y cuándo.
Diario del proceso (proceso.md)

docs/es/proceso.md, con su traducción docs/en/process.md. Se actualiza al cerrar cada step: es lo que cuenta cómo se ha trabajado.

# Proceso del encargo

## Step N: <título> (AAAA-MM-DD)

**Objetivo:** 

**Qué se hizo:** 

**Decisiones:** enlace a ADRs

**Qué descubrimos:** datos, casos raros, sorpresas

**Supuestos confirmados o descartados:** S1, P2...

**Pendiente para el siguiente step:**
Handoff

docs/es/handoff.md, con su traducción. Lo que necesita el equipo del cliente para operar sin ti.

# Handoff

## El sistema en una página
Qué hace, diagrama, dónde corre.

## Dueño del lado del cliente
Nombre, rol, suplente.

## Operación diaria
Qué revisar y dónde.

## Alertas
| Alerta | Qué significa | Qué hacer |
|---|---|---|

## Tareas habituales paso a paso
- Añadir un cliente / regla / documento
- Reprocesar un periodo

## Credenciales y renovaciones
| Credencial | Dónde está | Caduca | Cómo se renueva |
|---|---|---|---|

## Límites conocidos

## Siguientes pasos recomendados
Propuesta y alcance (SOW)

Antes de empezar. Es el documento que firma el cliente; en el curso, guárdalo en docs/es/propuesta.md.

# Propuesta: <proyecto>

**Cliente:** · **Fecha:** · **Versión:**

## Problema y coste actual
Qué pasa hoy y cuánto cuesta (horas, errores, ventas).

## Objetivo y métricas de éxito
| Métrica | Valor actual | Objetivo | Cómo se mide |
|---|---|---|---|

## Alcance
- Incluye:
- Fuera de alcance:

## Fases y entregables
| Fase | Entregable | Duración |
|---|---|---|
| Discovery | Requisitos validados | 1 semana |

## Criterios de aceptación

## Dependencias del cliente
| Qué | Responsable | Fecha límite | Impacto si se retrasa |
|---|---|---|---|

## Supuestos

## Estimación y precio
Rango por fase, con el margen del bloque más incierto.

## Riesgos principales y mitigación
Informe semanal de estado

Cada viernes al sponsor. Una página. En docs/es/estado/AAAA-semana-NN.md.

# Estado semana NN: <proyecto>

**Estado general:** en plazo | en riesgo | retrasado

## Hecho esta semana
- 

## Próxima semana
- 

## Bloqueos y lo que necesito del cliente
| Bloqueo | Qué necesito | De quién | Desde cuándo |
|---|---|---|---|

## Riesgos
| Riesgo | Tendencia | Acción |
|---|---|---|

## Decisiones pendientes

## Métricas
Avance contra criterios de aceptación.
Informe de campo para producto

Cuando trabajas para una empresa de producto (un FDE de una plataforma o de un modelo de IA): lo que aprendes en el cliente vuelve al equipo de producto. Uno por hallazgo relevante.

# Informe de campo: <título>

**Cliente y sector:** · **Fecha:** · **Gravedad:** bloqueante | molesta | mejora

## Qué intentaba hacer el cliente

## Qué pasó
Pasos, versión, ejemplo mínimo reproducible.

## Cómo lo resolvimos en campo
Workaround y su coste.

## Por qué importa
Cuántos clientes podrían tenerlo, impacto en adopción o ingresos.

## Propuesta para producto