Durante mucho tiempo vi el entregable como el resultado principal del trabajo.

Un documento queda terminado. Una presentación se envía. Una spec se comparte. Un artículo se publica. Un pliego de condiciones vuelve al cliente.

Hemos producido algo.

Así que el trabajo parece acabado.

Pero cuanto más uso la IA con contextos, más incompleta me parece esa certeza.

El entregable es visible.

Es necesario.

Pero no siempre es el verdadero capital.

El documento final consume un pensamiento

Un entregable se hace para un uso.

Responde a un público, a un momento, a una restricción de forma. Una spec le habla a los desarrolladores. Un pitch le habla a un CPO. Una documentación de soporte le habla a un equipo que tiene que responder rápido. Un artículo le habla a lectores que aún no conocen el tema. Un pliego de condiciones le habla a un cliente con sus propias casillas, su numeración, su vocabulario.

Cada entregable selecciona, simplifica, reformula y ordena el material para una necesidad concreta.

Es normal. Es incluso su papel.

Pero darle esa forma tiene un coste: parte del pensamiento que permitió producir el entregable desaparece detrás de él.

Vemos el documento final.

Ya no siempre vemos las fuentes, las dudas, las alternativas descartadas, los ejemplos que se quedaron fuera, las decisiones intermedias, las contradicciones, los matices que guardamos en la cabeza pero no en la versión enviada.

El entregable lleva el resultado.

No lleva necesariamente el razonamiento.

El problema empieza con el segundo entregable

Este problema pasa desapercibido mientras solo hay una salida que producir.

Trabajas sobre un material. Redactas un documento. Lo envías. Fin.

Pero en la vida real, el mismo fondo tiene que servir a menudo varias veces.

A partir del mismo material, quizá haya que producir:

• una spec funcional;
• unas user stories;
• un pitch para la dirección;
• una nota para ventas;
• una documentación de soporte;
• un plan de pruebas;
• una respuesta a un pliego de condiciones;
• un artículo;
• una síntesis breve para una reunión.

En un flujo de trabajo clásico, cada formato nuevo da la sensación de empezar de cero.

Partes del documento anterior. Copias y pegas. Reformulas. Quitas lo que no le habla al nuevo público. Añades lo que falta. A veces olvidas un matiz. Dos versiones empiezan a divergir.

No es solo pesado.

Es peligroso.

Soporte puede recibir una explicación distinta de la que se le dio a ventas. La spec puede contener un supuesto que ya no está en el pitch. El pliego de condiciones puede reutilizar una formulación antigua que ya no es cierta. El artículo puede simplificar una distinción importante porque el material disponible ya viene demasiado orientado.

El problema no es producir varios documentos.

El problema es tomar un entregable como fuente principal del entregable siguiente.

Una salida no es una fuente de verdad

Un documento final es una salida.

Puede ser muy bueno.

Pero se escribió para un contexto de uso concreto.

Contiene por tanto decisiones que no siempre pertenecen al conocimiento en sí: el tono, el nivel de detalle, los ejemplos, el orden, el grado de prudencia, la manera de nombrar las cosas, lo que se revela y lo que no, lo que se da por sabido.

Si partes de ese documento para producir todo lo demás, heredas sus decisiones.

A veces resulta útil.

A menudo te encierra.

Una frase escrita para tranquilizar a un cliente no es necesariamente una buena base para una documentación interna. Una diapositiva de dirección no es una buena base para una user story. Una respuesta breve en una tabla no es una buena base para entender la decisión de producto.

El entregable está orientado.

El conocimiento de trabajo debería seguir siendo más neutro.

El mundo de las ideas

Por eso me parece útil añadir una capa intermedia entre las fuentes y los entregables.

Yo lo llamo el mundo de las ideas.

No es un nombre muy técnico.

Pero dice bien lo que tiene que hacer.

El mundo de las ideas reúne lo que se ha entendido antes de transformarlo para un público concreto.

Ahí puedes encontrar:

• notas atómicas;
• notas temáticas;
• definiciones;
• supuestos;
• contradicciones;
• decisiones;
• ejemplos;
• límites;
• relaciones entre ideas;
• puntos por verificar.

Ese material todavía no le habla a un cliente, a un desarrollador ni a un lector.

Le habla al trabajo mismo.

Su papel no es ser elegante.

Su papel es ser reutilizable.

Una nota no debe convertirse en un gancho

Es un punto más sutil de lo que parece.

Cuando escribes un artículo, tienes la tentación de convertir directamente una idea en frase.

Cuando preparas una presentación, tienes la tentación de convertir directamente una idea en viñeta de diapositiva.

Cuando redactas una spec, tienes la tentación de convertir directamente una idea en requisito.

El problema es que entonces la nota se convierte ya en un fragmento del entregable.

Pierde su neutralidad.

Una buena nota debe mantener el conocimiento a un nivel en el que pueda volver a expresarse de otra forma.

Puede contener una distinción, una prueba, un supuesto, un arbitraje, un matiz. Pero no debe quedar presa del artículo, de la diapositiva o de la spec del momento.

El build, por su parte, sirve para producir.

La nota sirve para conservar lo que podrá producir.

La diferencia parece leve.

Lo cambia todo cuando vuelves tres semanas después.

La IA hace esta separación mucho más útil

Antes de la IA, mantener esta capa intermedia podía parecer pesado.

Ya se podían tomar notas limpias, guardar fuentes, crear síntesis. Pero producir después varios entregables seguía siendo un trabajo manual considerable.

Con la IA, esta separación resulta mucho más rentable.

Si el material está bien organizado, la IA puede ayudar a recomponerlo.

Puede producir una versión larga, una versión breve, una versión comercial, una versión técnica, una versión prudente, una versión pedagógica.

Puede adaptar el mismo conocimiento a varios públicos.

Pero para hacerlo bien, tiene que partir de la capa correcta.

No solo del último documento enviado.

No solo de un chat.

No solo de un PDF final.

Tiene que poder volver a las fuentes, a las notas, a las decisiones, a los límites, a los elementos todavía inciertos.

Entonces el trabajo cambia de naturaleza.

Ya no produces solamente un documento.

Construyes un material capaz de producir.

El capital es lo que queda después de la salida

Una buena pregunta que hacerse después de cada entregable es sencilla:

¿qué queda?

No solo: ¿dónde está el archivo?

Sino:

• ¿qué ideas se han estabilizado?
• ¿qué fuentes sostienen esas ideas?
• ¿qué decisiones se han tomado?
• ¿qué alternativas se han descartado?
• ¿qué formulaciones se han validado?
• ¿qué puntos siguen siendo frágiles?
• ¿qué elementos podrán servir para otro público?

Si la respuesta es "nada, salvo el documento final", entonces buena parte del trabajo se ha consumido.

El entregable se ha producido.

Pero el capital no se ha construido.

En cambio, si el trabajo deja tras de sí notas, fuentes enlazadas, decisiones, preguntas abiertas, formulaciones probadas, niveles de confianza, entonces el próximo entregable no partirá de cero.

El resultado visible es el documento.

El capital es la capacidad de rehacer, adaptar, explicar, defender y prolongar.

Esto cambia la manera de trabajar

Esta idea puede sonar abstracta.

Se vuelve muy concreta en una semana de trabajo.

Una entrevista con un usuario no sirve solo para escribir un acta. Puede alimentar una nota de producto, una decisión, un supuesto, un ejemplo para una futura presentación.

Un pliego de condiciones no sirve solo para responder a un posible cliente. Puede enriquecer una memoria de preguntas recurrentes, de respuestas validadas, de pruebas y de límites de divulgación.

Un artículo no sirve solo para publicar un pensamiento. Puede estabilizar ideas que alimentarán más adelante un libro, una formación, un método, una conversación de producto.

Una spec no sirve solo para desarrollar una funcionalidad. Puede guardar el rastro de arbitrajes que permitirán entender, seis meses después, por qué el producto funciona así.

En todos estos casos, el entregable no es inútil.

Sigue siendo imprescindible.

Pero pasa a ser una salida entre otras.

Ya no agota el valor del trabajo.

El documento adecuado en el sitio adecuado

No creo que haya que despreciar los entregables.

Al contrario.

Un buen entregable suele ser lo que hace el trabajo transmisible. Obliga a aclarar, a elegir, a recortar, a formular. Pone el pensamiento en contacto con un público real.

Pero hay que dejar de pedirle que lo lleve todo.

El documento final no tiene por qué contener todas las fuentes.

No tiene por qué conservar todas las alternativas.

No tiene por qué exponer todas las incertidumbres.

No tiene por qué convertirse en la memoria completa del tema.

Tiene que hacer su trabajo de entregable.

Y la memoria del trabajo tiene que existir en otro sitio.

Es exactamente lo que permite un contexto.

El contexto conserva el material.

El build produce las salidas.

El humano se queda con el juicio.

La IA ayuda a recomponer.

El desplazamiento de valor

El desplazamiento me parece importante.

Antes capitalizábamos sobre todo los documentos.

Guardábamos las specs, las presentaciones, las notas de reunión, las actas, los pliegos de condiciones enviados.

El día de mañana habrá que capitalizar más el material que permite producirlos.

No es lo mismo.

Capitalizar un entregable es conservar una forma pasada.

Capitalizar un contexto es conservar una capacidad futura.

El entregable dice: esto es lo que hemos enviado.

El contexto dice: esto es lo que hemos entendido, decidido, verificado, descartado, y esto es lo que aún podemos producir a partir de ahí.

Por eso el entregable ya no es el capital principal.

Sigue siendo la parte visible.

Pero el valor duradero se desplaza hacia lo que permite producir varias veces sin perder el fondo.

El documento se va.

El pensamiento organizado se queda.