El documento de concepto era un parche

11 min de lectura

Construirlo, no describirlo

Por qué existían los documentos de concepto

Nadie escribe un documento de concepto por gusto. Lo escribe porque construir lo incorrecto solía ser catastróficamente caro.

He dirigido spikes con equipos de 25 personas. Un spike es un experimento acotado en tiempo, típicamente restringido a un solo día de trabajo, donde todo el equipo ataca una pregunta: ¿Podemos hacer esto? ¿Es viable? ¿Qué se rompe cuando lo intentamos? Un día, 25 personas, respuesta al final de la jornada.

En organizaciones hartas de documentos que describían una fantasía, la gerencia adoraba los spikes. Era liberador. En lugar de otro documento de concepto en el que nadie creía, obtenías una respuesta real en ocho horas. El equipo construía algo, chocaba contra las paredes, encontraba los límites y volvía con evidencia en lugar de opiniones. Eso se sentía honesto.

Pero los spikes cuestan dinero real. Veinticinco personas por un día no es barato. ¿Y un prototipo durante varias semanas que luego se descarta? Muchas organizaciones no podían aceptar eso. Así que el estándar seguía siendo: describir la cosa en papel, discutir la descripción, aprobar la descripción, y luego construir.

El documento era un sustituto de la cosa misma. Una hermosa representación artística de una casa en lugar de una casa real. Ese sustituto tenía sentido económico cuando cada línea de código se escribía a mano, se probaba manualmente y se desplegaba a través de un ritual con tres aprobaciones, un comité de cambios y una ventana de mantenimiento a las 2 de la mañana del sábado. El costo de construir era alto. El costo de escribir era bajo. Hacer lo barato primero. Nadie preguntó si lo barato era lo correcto.

La ilusión del plano

Los documentos de concepto tienen un problema más profundo, y no tiene nada que ver con el costo. Es un modelo mental tomado de la profesión equivocada.

Los documentos de concepto se sienten como planos de arquitectura. Un arquitecto piensa, diseña, especifica. Luego los obreros construyen según la especificación. El pensamiento ocurre primero. La construcción es ejecución mecánica. Los trabajadores del conocimiento diseñan. Los trabajadores manuales construyen.

Aplicado al software, esto siempre fue un malentendido. El desarrollo de software no es ingeniería en el sentido tradicional. Un ingeniero aplica normas conocidas a problemas conocidos. Un puente, una vez diseñado, se construye exactamente según la especificación. El plano funciona porque el problema se entiende, los materiales son predecibles y la física no cambia a mitad de camino. Los códigos de construcción y las normas técnicas tienen fuerza de ley. Ignorarlos es un delito. Un ingeniero que se desvía de la especificación enfrenta responsabilidad legal, no una retrospectiva.

El software no se parece en nada a eso. Los requisitos cambian. Los usuarios sorprenden. Los sistemas interactúan de maneras que nadie predijo. El acto de construir revela el problema. No entiendes lo que estás haciendo hasta que lo estás haciendo. El desarrollador no es un obrero que ejecuta el pensamiento de otro. El desarrollador es el pensador. El código es el pensamiento hecho concreto.

Cuando las organizaciones tratan los documentos de concepto como planos, separan el pensar del construir y se los asignan a personas diferentes. Los “trabajadores del conocimiento” producen la especificación. Los “programadores” la ejecutan. Esa separación garantiza el fracaso, porque en software el pensamiento más importante ocurre durante la construcción, no antes. Cada descubrimiento interesante, cada decisión de diseño crítica, cada momento de “espera, esto no va a funcionar porque…” sucede cuando alguien está construyendo la cosa.

El documento de concepto no solo costaba tiempo. Institucionalizó una falsa separación entre personas que piensan y personas que teclean código. Gente inteligente escribe qué construir, luego los codificadores lo codifican. Ese modelo mental nunca desapareció del todo. El documento de concepto es su último artefacto sobreviviente.

La economía se invirtió

Lo que cambió: puedo describir un sistema a un asistente de IA y tener código funcional en horas. No pseudocódigo. No un mockup. Código funcional, comprobable, desplegable. El spike que antes requería 25 personas y un día completo de trabajo, ahora un solo desarrollador con un asistente de IA llega a la misma conclusión en una tarde. El prototipo que antes consumía un sprint emerge en uno o dos días.

Esto no es teoría. Es mi martes.

Cuando un desarrollador produce un prototipo funcional más rápido de lo que un product manager escribe un documento de concepto, la economía se invierte completamente. El documento es ahora la opción cara. No porque el papel cueste dinero, sino porque el documento tarda más en producirse, genera menos información y crea una falsa sensación de certeza que la construcción real destruye inevitablemente.

Un documento de concepto dice lo que alguien cree que sucederá. Un prototipo dice lo que realmente sucede. Uno es opinión. El otro es evidencia.

Los feature flags lo cambiaron todo

El verdadero cambio no es solo que construir se volvió más rápido. Es que los feature toggles permiten desplegar código listo para producción mientras permanece invisible.

Piensa en lo que eso significa. Un desarrollador construye una funcionalidad. Código real, pruebas reales, despliegue real. Va a producción. Se queda detrás de un flag, invisible para los usuarios. Un product owner, un stakeholder, un comité asesor de clientes, quien necesite aprobar, puede activarlo en un entorno de pruebas, verlo funcionar, validarlo contra la realidad y decidir.

Sin documento necesario. Sin reunión de revisión de concepto donde doce personas debaten casos límite hipotéticos que quizás nunca se materialicen. Sin aprobación sobre una descripción de algo que nadie ha visto. La cosa existe. Actívala. Mírala. Decide.

La vieja objeción siempre fue: “Pero, ¿qué pasa si construimos lo incorrecto?” Preocupación válida. Mala solución. Un documento de concepto no previene construir lo incorrecto. Previene construir cualquier cosa hasta que suficientes personas se pongan de acuerdo en una alucinación compartida sobre cuál podría ser lo correcto. Luego construyes y descubres que la alucinación estaba equivocada. Como cada vez anterior.

El código detrás de feature flags logra algo que los documentos de concepto nunca pudieron: permite fracasar barato en producción. Construye tres enfoques. Ponle flag a los tres. Prueba cada uno con usuarios reales. Mide. Elimina los perdedores. Despliega el ganador. Intenta hacer eso con un documento de concepto.

Lo que los documentos de concepto realmente producen

Un documento de concepto produce tres cosas con fiabilidad: retraso, falsa confianza y reuniones.

Retraso, porque escribir el documento, revisarlo, corregirlo y obtener la aprobación toma semanas. Durante esas semanas, nadie aprende nada del software real. El mercado se mueve. Los competidores despliegan. Los usuarios desarrollan soluciones alternativas.

Falsa confianza, porque un documento bien escrito se siente como progreso. Todos asintieron. Todos estuvieron de acuerdo. El documento tiene secciones y diagramas y una evaluación de riesgos. Seguramente la parte difícil ya pasó. Nunca es así. La parte difícil comienza cuando el código se encuentra con la realidad: comportamiento inesperado de APIs, datos que no coinciden con los supuestos, usuarios que interactúan con el sistema de maneras que nadie imaginó mientras miraba un documento de Word.

Reuniones, porque cada documento genera un ciclo de revisión. Más personas en la sala significan más opiniones, más revisiones, más reuniones. Ninguna de estas reuniones produce software funcional. Producen documentos revisados que también estarán equivocados, solo de manera diferente.

La verdadera competencia siempre fue la misma

Nada de esto significa “deja de pensar y empieza a teclear.” La competencia no es teclear. El fin de la programación como trabajo mecánico no eliminó la necesidad de criterio. Sigues necesitando entender el problema. Sigues necesitando hablar con usuarios. Sigues necesitando comprender el dominio lo suficiente para construir algo útil.

La diferencia está en el cómo. Antes, escribías. Ahora, construyes. Antes, describías tu comprensión. Ahora, la demuestras. La IA como compañera de pensamiento no reemplaza el pensamiento. Hace que la distancia entre pensar y resultado tangible sea tan pequeña que el documento intermedio se vuelve innecesario.

Los buenos desarrolladores siempre lo supieron. En 2010, escribí sobre cómo usar Cucumber para iniciar el desarrollo directamente desde una conversación con el cliente, capturando requisitos como especificaciones ejecutables en lenguaje natural, construyendo test-first sin ningún documento de concepto a la vista. El archivo de features era el entendimiento compartido. La prueba aprobada era la demostración. La IA no inventó construir-como-pensar. La IA lo hizo tan rápido que ni siquiera las organizaciones adictas a los documentos pueden ignorar la alternativa.

Las personas que escribían buenos documentos de concepto generalmente pensaban bien. Su habilidad nunca fue el documento. Era la claridad de pensamiento detrás de él. Esa claridad ahora se expresa en software funcional en lugar de PDFs formateados. Mejor para todos.

Los expertos piensan en pantallas, no en sistemas

Pero no romantice esto. La mayoría de los expertos funcionales no piensan en sistemas. Piensan en pantallas. Pregúntale a un stakeholder qué necesita y describirá un formulario con campos, un botón que hace algo, un reporte que muestra números. El software para ellos es lo que pueden hacer clic. Todo lo que hay detrás de esa superficie, el modelo de datos, los puntos de integración, los modos de falla, no existe en su imaginación. No porque sean tontos. Porque nadie se los mostró.

Por eso los documentos de concepto sobrevivieron tanto tiempo. El experto funcional describía pantallas. Wireframes. Etiquetas de botones. El documento de concepto capturaba lo visible e ignoraba lo estructural. Se sentía completo porque cubría cada píxel. Era hueco porque no decía nada sobre consistencia de datos, recuperación de errores, o qué pasa cuando dos usuarios presionan ese botón al mismo tiempo.

Un prototipo funcional cambia esa conversación. Cuando los expertos funcionales ven pantallas respondiendo, hacen clic, escriben, se confunden y hacen preguntas que ningún documento de concepto provocó jamás. “Espera, ¿qué pasa si no ingreso nada aquí?” Esa confusión es oro puro. Su frustración se convierte en el documento de requisitos. Su “eso no es lo que quise decir” se convierte en el caso de prueba. Todo emerge de tocar el software, no de leer sobre él.

Cuándo los documentos aún tienen sentido

Cumplimiento normativo donde un auditor exige especificación escrita antes de la implementación. Sistemas de seguridad crítica donde vidas dependen de la corrección probada antes del despliegue. Obligaciones contractuales donde un cliente paga por un entregable definido.

Estos son casos legítimos. Menos de los que se piensa.

Trabajé en un sistema de conteo de ejes para un proveedor ferroviario alemán. Más crítico para la seguridad que eso no existe. Trenes, vías, vidas. Los requisitos regulatorios eran extensos: certificación SIL (Safety Integrity Level), trazabilidad desde el requisito hasta la prueba y el despliegue. El tipo de dominio donde esperarías que los documentos de concepto fueran indispensables.

Descubrimos que TDD cumplía con cada requisito de compliance. Cada prueba estaba vinculada a un requisito. Cada requisito a una prueba. La cadena de evidencia era mejor que cualquier cosa que un documento de concepto pudiera proporcionar, porque era ejecutable. Podías correr la prueba.

Pero la empresa no lo adoptó. El marco de compliance no se trataba realmente de demostrar corrección. Se trataba de distribuir culpa. Los documentos de concepto existían para que cuando algo fallara, todos pudieran señalar la cadena de aprobaciones. “Yo aprobé el concepto. Los desarrolladores se desviaron del concepto. No es mi culpa.” Cuando la suite de pruebas es la especificación y las pruebas pasan, la responsabilidad es clara. No hay espacio para la cómoda ficción de que doce firmas en un documento significan que doce personas verificaron la corrección. No verificaron nada. Asistieron a una reunión y no objetaron con suficiente fuerza.

Incluso en industrias reguladas, el documento de concepto sobrevive frecuentemente no porque la regulación lo exija, sino porque las organizaciones prefieren responsabilidad difusa sobre rendición de cuentas clara. El documento es un escudo, no una especificación.

El otro 90% del software que se construye cada día no tiene esa excusa. Necesita un desarrollador que entienda el problema, una IA que acelere la construcción, un feature flag que controle la visibilidad y un responsable que pueda decir sí o no cuando vea la cosa real.

Basta de debatir conceptos. Empiecen a entregar evidencia.

La persona que entra a la sala con mockups y dice “construyan esto” tiene un nuevo competidor: el desarrollador que entra a la sala con la cosa funcionando y dice “prueben esto.” Uno trajo una descripción. El otro trajo evidencia.

El documento de concepto era un parche para la construcción cara. Construir se volvió barato. El parche ya no se necesita. Constrúyelo. Ponle un flag. Muéstralo. Decide. Sigue adelante.