Construye para aprender
Brooks ya lo sabía en 1975: el primer sistema siempre es un borrador. Construir en producto digital es un método de conocimiento, no solo de producción.
The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.
— The Mythical Man-Month, F.P. Brooks (1975)
Medio siglo después, esta frase sigue describiendo con precisión incómoda lo que ocurre en la mayoría de los proyectos de producto digital. Y lo interesante no es que Brooks acertara. Es que la industria ha decidido, sistemáticamente y con notable persistencia, la segunda de las dos opciones que plantea: entregar el borrador como si fuera el producto.
El primer sistema es el que te explica el problema
La afirmación de Brooks tiene una estructura curiosa. No dice que el primer sistema sea malo por falta de oficio, ni por prisa, ni por falta de recursos. Dice que es inevitable. Y la razón es epistemológica antes que técnica: el primer sistema que construyes sobre un problema nuevo es el instrumento con el que averiguas cómo era ese problema. Cuando terminas, sabes cosas que no podías saber al empezar, y precisamente por eso lo que construiste está obsoleto respecto de lo que ahora entiendes.
Peter Naur lo formuló desde otro ángulo unos años después: programar no consiste en producir un texto, consiste en construir una teoría sobre un dominio. El código es la huella de esa teoría, no la teoría misma. De ahí se sigue algo que cualquiera que haya heredado un sistema conoce por experiencia: puedes leer todo el código y seguir sin entender el sistema, porque lo que falta no está escrito en ninguna parte. Y de ahí se sigue también lo que nos importa aquí: si construir es teorizar, construir es la actividad donde se aprende, no la actividad que viene después de haber aprendido.
Esto choca de frente con la organización habitual del trabajo. En la mayoría de las empresas, construir es la fase donde se ejecuta lo que ya se decidió. El análisis está antes, la validación está después, y en medio hay un tramo que se gestiona como producción: alguien pasó un testigo, alguien lo recoge, y la métrica de éxito es la fidelidad a lo acordado. Con ese montaje, todo lo que se aprende construyendo es ruido. Peor: es una amenaza, porque cuestiona el acuerdo que legitima el trabajo.
Aprender no es lo mismo que iterar
Conviene distinguir esto de la retórica más gastada del oficio. "Iterar" se ha convertido en una palabra que puede significar cualquier cosa, incluida la más frecuente: repetir el mismo ciclo de entrega con el mismo grado de ignorancia, solo que en tramos más cortos. Un equipo puede hacer veinte iteraciones sin haber aprendido nada, si en ninguna de ellas se puso en juego una conjetura que pudiera resultar falsa.
Construir para aprender exige algo más específico y bastante más incómodo: saber qué querías averiguar antes de empezar el tramo. No la funcionalidad que querías entregar, sino la pregunta que querías cerrar. Son dos planificaciones distintas, y la segunda casi nunca se escribe. Si al llegar al hito puedes decir "funciona" pero no puedes decir "ahora sabemos que", el tramo produjo output y no conocimiento.
De ahí que las técnicas que mejor funcionan sean las que abaratan el intento sin abaratar la evidencia. Bill Buxton insistía en que un boceto y un prototipo no son lo mismo ni sirven para lo mismo: el boceto sugiere y se descarta, el prototipo responde y se conserva. La confusión entre ambos es una de las formas más eficaces de gastar semanas: hacer prototipos con la ambición de un producto para responder preguntas que un boceto habría contestado en una tarde.
Por qué cuesta tanto planificar el desecho
Brooks pone el dedo en la parte organizativa: la opción sensata —planificar el desecho— existe, es conocida y casi nunca se elige. Merece la pena preguntarse por qué.
La primera razón es contable. Un sistema que se va a tirar aparece como coste; un sistema que se entrega aparece como valor, aunque sea el mismo sistema. Ningún comité de inversión aprueba con facilidad una partida cuyo entregable declarado es aprendizaje, porque el aprendizaje no tiene un lugar en el balance y el software entregado sí. La consecuencia perversa es que se acaba prefiriendo un activo que habrá que reescribir a un coste que habría ahorrado la reescritura.
La segunda es reputacional. Anunciar de antemano que lo primero que construyas se va a tirar equivale a admitir públicamente que no sabes hacer bien las cosas a la primera. En culturas de management donde el error se administra como fallo personal, eso es indefendible, aunque sea cierto y aunque todos lo sepan. Es más seguro construir el borrador en silencio y llamarlo versión uno.
La tercera es más sutil y quizá la más determinante: el desecho planificado obliga a decidir dos veces. Una al construir el piloto y otra al decidir qué se conserva de lo aprendido. Ese segundo momento de decisión es exactamente el que las organizaciones sobrecargadas intentan evitar, porque cada punto de decisión consume atención de gente escasa. Prometer el borrador al cliente tiene la ventaja de eliminar la segunda decisión: si ya está entregado, ya no hay nada que decidir.
La versión operativa
Nada de esto pide un cambio de método. Pide un cambio en lo que se considera un buen resultado de un tramo de construcción.
Significa entrar a construir con una escala que permita cambiar de opinión: lo bastante concreta para producir evidencia y lo bastante tosca para no haber hipotecado el alcance. Significa tratar el primer arranque como lo que es, una etapa de descubrimiento de todo lo que no se podía saber antes, y por tanto reservar de antemano la posibilidad de que el alcance se mueva. Significa proteger el momento en el que alguien dice que lo construido enseñó que la conjetura era equivocada, porque ese es el momento en el que el proyecto ha producido su rendimiento más alto y también el momento en el que más gente tiene incentivos para taparlo.
Y significa aceptar la asimetría que Brooks deja implícita: el borrador se va a construir de todas formas. La única variable que controlas es quién lo paga.
¿Cuántos de los sistemas que mantienes hoy son en realidad el piloto que nadie se atrevió a tirar?