La crítica vive en las flechas

Hay un momento que reconozco en cada proyecto. Una idea aparece —se me ocurrió algo— y minutos después ya estoy escribiendo código. El salto se siente productivo. Casi siempre es caro.

Es caro porque entre se me ocurrió y ya estoy construyendo se salta la única pregunta que importa: ¿qué prueba exactamente esta pieza? Sin esa pregunta respondida, lo que construyes no tiene contra qué medirse. Y lo que no se puede medir contra un objetivo, se termina midiendo contra el gusto —el tuyo, el del cliente, el de quien pasa por ahí. El gusto es un juez inestable. Cambia con el cansancio, con la hora, con quién habló más fuerte en la reunión.

En mi estudio armé un mecanismo para frenar ese salto. No es una herramienta ni un tablero nuevo; es una disciplina de decisión que se monta encima del flujo de trabajo que ya tengo. La escribo aquí porque creo que la parte que sí es mía puede servirle a otra gente que construye cosas —y porque la mejor manera de saber si un método aguanta es exponerlo.

La tesis

La crítica no es un evento al final del proceso; es la compuerta que controla cada transición. Ese es el reencuadre completo, y cambia dónde pones la atención. La mayoría trata la crítica como un paso: construyes, y al final alguien revisa — y así la crítica llega tarde, cuando ya invertiste, cuando ya te encariñaste, cuando cambiar duele. Si en cambio vive en las transiciones y no en los estados, nada avanza sin pasar por ella, y siempre llega a tiempo: antes de que inviertas de más.

Dicho en la forma que se me quedó grabada: una pieza nunca está en crítica. Está en un estado, esperando cruzar una compuerta. La crítica vive en las flechas, no en las cajas.

Cómo funciona

Una pieza —un módulo, un endpoint, un contrato, una feature, un documento— pasa por cuatro estados, y la crítica es el mecanismo de las flechas entre ellos. Cada flecha carga una pregunta, y se responde contra el objetivo declarado, nunca contra la preferencia.

En la divergencia la idea gira y se difiere el juicio — la compuerta pregunta si exploramos suficiente o si estamos cerrando por cansancio. En la reducción a tesis se colapsa la idea a una sola frase que la pieza tiene que probar; si no cabe en una línea no está lista, y aquí también se declara si aspira a generalizarse. En la prueba de vida se construye el mínimo que prueba esa única cosa —la evidencia de la feature, no la feature entera— y una pieza que pasa aquí y no aspira a más, cierra aquí, porque quedarse acotada es un final válido. Y en la graduación la pieza sólida se generaliza, si y solo si el contrato que declaraste en la tesis sobrevive el segundo caso sin reescribirse.

Debajo de todo esto hay un candado que no se negocia: nada avanza sin objetivo escrito. La versión verbal —ya lo tengo clarísimo en la cabeza— no cuenta. Escribir la tesis toma dos minutos y es la primera acción, antes del diseño, antes del código. Sin ella, la crítica no tiene contra qué medir y degenera en gusto.

De dónde viene (y qué no es mío)

Prefiero decir de frente lo que tomé prestado, porque casi todo lo de arriba lo tomé prestado. La separación entre generar y evaluar —diferir el juicio en la divergencia— es design thinking clásico, de IDEO. La idea de reducir hasta lo inevitable, sostener un punto de vista fuerte y criticar el objeto ya construido en vez de la idea abstracta, es el método que Apple hizo famoso bajo Jony Ive. Y el vocabulario que uso para clasificar feedback es literal de Discussing Design, de Adam Connor y Aaron Irizarry.

Hay vecinos aún más cercanos. Escribir la tesis antes de abrir código es la misma disciplina que sostiene un design doc o un RFC en cualquier equipo serio de ingeniería. Y moldear una pieza antes de comprometerse a construirla lo desarrolló Basecamp mucho mejor que yo en Shape Up. Ser honesto sobre esto no me debilita: me deja señalar con precisión las dos cosas que sí creo que aporté.

Uno: el feedback se clasifica antes de ejecutarse

Connor e Irizarry distinguen tres formas de comentario. La reacción es visceral: no me gusta el azul. La dirección empieza por una solución: hazlo multi-formato. La crítica analiza contra el objetivo: esto no prueba la tesis porque X. Solo la crítica gradúa una decisión.

Mi aporte no es la taxonomía —es de ellos— sino aplicarla como compuerta obligatoria sobre mi propio trabajo, y sobre el lote completo de comentarios, sin excepción. La falla que este método existe para frenar es concreta: ante un lote —ponle azul y que genere PDFs— el instinto traduce el color, el comentario provocador, y ejecuta el PDF sin compuerta, con la excusa de que es puro alcance nuevo, no toca la tesis. Si no toca la tesis, no pertenece al mínimo: va a fuera-de-alcance o a su propia pieza. Cada ítem se clasifica. El provocador no puede colar al otro por la puerta de atrás.

El trabajo real es traducir. Quien pide casi siempre da reacción o dirección; convertir eso en crítica-contra-objetivo es el oficio. Y para que el feedback caiga como crítica y no como reflejo, declaro el objetivo antes de mostrar la pieza. Nunca la presento fría esperando aplauso. El aplauso no es información.

Dos: la graduación se declara desde la tesis, y tiene dientes

Esta es la que más me costó y la que más uso. Una pieza declara desde su tesis si aspira a generalizarse, y la prueba es concreta: ¿puedes nombrar dos usos distintos que consumen el mismo contrato interno? No dos clientes ni dos instancias del mismo caso —eso no prueba nada nuevo— sino dos consumidores distintos: otra superficie, otro pipeline, otro sistema.

La distinción tiene consecuencias. Una pieza genuinamente generalizada es un contrato que ya usan tres consumidores reales sin haberse reescrito ni una vez. Tengo uno así: un mismo contrato de identidad de marca —colores, tipografías, logos— que hoy leen tres superficies sin relación entre sí, el sitio público del estudio, una herramienta interna de diseño y un generador de piezas de marca. Tres consumidores distintos, un contrato, cero reescrituras. Una pieza que aspira bien nombró sus dos usos desde el principio, aunque el segundo todavía no exista. Y lo que este método persigue matar es la tercera categoría: la deuda disfrazada, la pieza que finge ser genérica sin un segundo uso nombrado.

Luego lo generalizamos no es una declaración. Es el retrofit que garantiza que la abstracción no aguante, porque la diseñaste contra un solo caso y le pediste que sirviera a casos que nunca miraste. La graduación no se añade después. Se diseña desde el principio, o no se diseña.

Por qué lo vi

Un punto de vista fuerte es una ventaja rara. Converge rápido, no discute lo que ya sabe, corta el ruido. Yo trabajo con uno y me ha servido para construir en meses lo que a un comité le tomaría años.

Pero un punto de vista fuerte tiene una sombra exacta: el criterio que no se discute puede volverse el criterio que no se revisa. Convergir rápido y convergir bien no son lo mismo, y de noche, cansado, con ganas de no volver a abrir un tema, se sienten idénticos. Ahí es donde tomo las decisiones que después me cuesta deshacer.

Construí este método, en el fondo, como contrapeso a mí mismo. No para frenar el trabajo —eso lo mata— sino para que algo cante, claro y una sola vez, cuando una decisión irreversible parece estar naciendo de la fatiga y no del juicio. La distinción es fina pero decide todo: ejecutar cansado está bien; decidir algo irreversible cansado se señala y se deja para cabeza fresca. La regla del contrapeso es señalar, nunca frenar: dice la cosa una vez, ofrece hacer ya lo ejecutable, y me deja decidir. Un estudio pequeño no tiene el lujo del comité que te obliga a justificarte. El contrapeso hay que construirlo. Este método es el mío.

El cierre

No es una metodología que pida que abandones la tuya. Es una disciplina de decisión que se monta encima del flujo de PR, revisión y demo que ya usas —cuatro preguntas en cuatro flechas, y un candado que dice: escribe la tesis primero. Tómalo, adáptalo, discútelo. Si lo pruebas sobre tu propio trabajo y una de las dos reglas propias te ahorra un refactor, ya valió la pena escribirlo.