El Steve Test: ¿merece existir el trabajo?

A principios de esta semana publiqué un trabajo en el que la decisión correcta era negarme a publicarlo. Un flujo de traducción escribe el contenido de este sitio en Cloudflare D1 para diez configuraciones regionales. Tres trabajos de traducción alcanzaron un límite de tasa al mismo tiempo; el mecanismo de respaldo escribió en silencio el contenido fuente en inglés dentro de D1 como la “traducción” de seis de esas configuraciones regionales, y luego actualizó los hashes de los puntos de control para que coincidieran con el contenido en inglés. En disco parecía un éxito. El flujo informó “complete”. La métrica decía que se habían publicado las diez configuraciones regionales. Todas las verificaciones automatizadas pasaron.

Un lector alemán que llegara a /de/guides/claude-code se habría topado con un párrafo en alemán, un párrafo en inglés, otro párrafo en alemán y un encabezado de sección en inglés. No había ningún indicador que explicara las transiciones. La página parecía intencional y hacía que todo el sitio se sintiera poco confiable: el tipo de producto que probablemente también fallaría en cualquier otra tarea que prometiera resolver. El Jiro Test (¿el trabajo es correcto?) pasaba en cada capa que yo había instrumentado. Y aun así, aquello no era digno. Parecía un producto y se comportaba como un insulto.

La respuesta correcta era detenerse, auditar cada lote que había caído al respaldo en inglés, limpiar quirúrgicamente los hashes de los puntos de control, ejecutar el flujo de traducción de un trabajo a la vez, verificar configuración regional por configuración regional, hacer commit y push. Aproximadamente seis horas de traducción en tiempo real y un parche de protección para evitar que volviera a ocurrir. El artefacto en disco estuvo “funcionando” todo el tiempo. El artefacto en producción era daño causado por mí.

La forma del fallo es la misma si el artefacto es un flujo de traducción, un proceso de registro, un interruptor de función, una exportación CSV o una página de marketing. Todas las verificaciones automatizadas pasan. Lo que llega frente a un usuario real es daño.

La pregunta que gobierna el producto no es ¿está terminado? ni ¿funciona? La pregunta que gobierna es ¿el trabajo merece existir? Todo artefacto tiene que responderla antes de publicarse, junto con una prueba separada de corrección. La corrección sin mérito produce inventario: cosas que funcionan, se publican y no se ganan la confianza de nadie. El mérito sin corrección produce teatro: cosas que se sienten bien y se rompen. Ambas pruebas tienen que pasar.

La abreviatura que uso es el Steve Test. Está junto al Jiro Test, que exige rigor y evidencia. Son dos preguntas distintas aplicadas por la misma mente, y no publico trabajo que falle cualquiera de las dos.

Resumen rápido

El Steve Test es la segunda prueba que debe pasar todo artefacto. Jiro pregunta si el trabajo es correcto; Steve pregunta si el trabajo merece existir como parte del conjunto que estás construyendo. La prueba es concreta, no abstracta. Se mide frente a un usuario real en un momento real, y su resultado más constante es el rechazo. Recorto alcance. Elimino funciones. Lo que queda tiene que poder llevar mi nombre. Ambas pruebas deben pasar. Si Jiro falla, te detienes y corriges. Si Steve falla, reconstruyes. Tres reconstrucciones honestas son el límite; después de eso, el problema está más arriba, en el encuadre.

Por qué “¿está terminado?” es la pregunta equivocada

La mayoría de los equipos de producto optimizan para que algo sea publicable. Los resultados medibles son commits, despliegues, gráficos de velocidad, la presencia de algo en producción. El modo de fallo es predecible: los equipos producen un flujo constante de artefactos que funcionan correctamente y gastan en silencio la confianza del usuario. La incorporación se completa; la segunda sesión nunca ocurre. Los tickets de soporte se agrupan alrededor de tareas que el producto dice resolver. La curva de retención cae hacia cero en vez de estabilizarse en un núcleo de usuarios.

Terminado y digno son mediciones distintas. Una función puede estar terminada y no merecer existir. Una página puede renderizarse e insultar al lector. Una traducción puede estar técnicamente presente y ser, en la práctica, una mentira. La prueba para saber si algo está terminado es si ejecuta el comportamiento especificado. La prueba para saber si algo es digno es si un usuario real, en un momento real, está mejor porque lo publicaste.

Mi argumento en Producto mínimo digno es que la cultura de MVP, en la práctica, fusionó dos preguntas en una: aprender rápido se degradó en publicar rápido, y publicar se convirtió en la métrica que importaba.⁷ La cura es el doble estándar. Mínimo recorta el alcance. Digno sostiene la superficie restante en un estándar que el usuario puede sentir. El Steve Test es la herramienta que usas cuando estás decidiendo si esa superficie restante ya superó el estándar.

La pregunta que gobierna

¿El trabajo merece existir?

Uso la pregunta literalmente. Cuando termino un trabajo y tengo que decidir si lo publico, hago la pregunta en voz alta. La respuesta es un veredicto, no una sensación. Si la respuesta es sí, el trabajo puede publicarse y la siguiente pregunta es si también pasa el Jiro Test de corrección. Si la respuesta es no, el trabajo necesita una reconstrucción o una eliminación. Si la respuesta es todavía no, pero lo será con una acción correctiva definida, sigues trabajando.

La pregunta solo funciona si la respuesta puede ser no. Un Steve Test que aprueba automáticamente cualquier cosa que tenga enfrente no es una prueba. La señal de que la prueba realmente está corriendo es que algún trabajo la falla.

El polo del usuario: lo digno nunca es abstracto

El Steve Test falla en el momento en que se convierte en una discusión de gusto sobre el trabajo aislado. Mide si algo merece existir frente a un usuario específico en un momento específico. La pregunta expresada correctamente es: ¿este trabajo merece existir para este usuario en este momento?

Para blakecrosley.com, el usuario es un lector que llega sin contexto desde una búsqueda con una pregunta sin responder sobre Claude Code, Codex o infraestructura. El momento son los primeros cinco segundos después de que carga la página, antes de que la página se haya ganado alguna confianza. Una página que carga rápido, presenta su punto de vista con claridad y le dice al lector algo que su búsqueda todavía no había respondido supera el estándar. Una página que lo castiga con un paquete lento, un banner de cookies que no puede descartar y una pared de texto genérico con forma de SEO falla, por muy bien que puntúe en el eje Jiro.

Para ResumeGeni, el usuario es una persona que busca trabajo en un momento que trato como vulnerable. La mayor parte de la lista de espera inicial llegó después de un despido o en medio de un ciclo de entrevistas.⁶ La versión digna se niega a tratarla como una métrica de conversión. El texto no se refugia en evasivas. El analizador no miente sobre lo que encontró. El consejo es lo bastante concreto como para que pueda actuar. El flujo no la abandona a mitad del proceso solo porque la ruta ideal fue lo único que publiqué.

El polo del usuario es el control que evita que el Steve Test se convierta en un refugio para mis propias preferencias. Si no puedo nombrar al usuario, nombrar su momento y explicar cómo la superficie publicada lo respeta y lo fortalece, no apliqué la prueba. Solo la declaré.

La doble prueba: Jiro más Steve

La doctrina completa exige dos pruebas, no una.¹ No publico nada que falle cualquiera de las dos.

El Jiro Test pregunta: ¿esto está hecho correctamente? Exige evidencia. Casos límite resueltos. Detalles invisibles terminados. Afirmaciones respaldadas por pruebas concretas. Sin evasivas: creo que no es evidencia. Las pruebas pasan. No hay regresiones. El control de evidencia es la versión del Jiro Test que aplico a reportes de código y salidas de agentes, y la filosofía de calidad de Jiro es el desarrollo más profundo.

El Steve Test pregunta: ¿el trabajo merece existir? Exige mérito. Coherencia con el conjunto. Un punto de vista visible. Un rechazo o una eliminación explícitos que mantuvieron limpia la superficie. Un mecanismo de deleite o claridad que el lector pueda identificar, no una generalidad vaga. Aptitud para llevar tu nombre.

El arbitraje es simple. Si Jiro falla, te detienes y corriges. El trabajo incorrecto no se publica; el veto de Jiro es absoluto. Si Jiro pasa y Steve falla, reconstruyes. El trabajo correcto pero indigno tampoco se publica. Si ambos fallan, el problema está más arriba: en el encargo, el encuadre o el alcance. Solo el trabajo que pasa ambos puede publicarse.

La mayoría de las culturas de publicación ejecutan en silencio solo una de las dos pruebas. Las culturas lideradas por ingeniería suelen ejecutar un Jiro fuerte y un Steve débil: el producto se publica cuando las pruebas pasan, y el mérito se vuelve responsabilidad de otro departamento. Las culturas lideradas por diseño a veces ejecutan un Steve fuerte y un Jiro débil: el producto se publica cuando se ve bien, y la corrección se vuelve un problema operativo. Ambos modos de fallo producen artefactos reconocibles. Humo hermoso. Trabajo correcto pero sin alma. Los has visto. Quizá los has publicado.

Las dos pruebas van lado a lado:

El producto completo: eres responsable de la experiencia total

El Steve Test no juzga los artefactos aislados. Los juzga como parte de la experiencia total que encuentra el usuario.

El incidente de traducción con el que abrí es el ejemplo reciente más limpio, y vale la pena detallar el mecanismo específico del fallo porque muestra la forma de la trampa. El mecanismo de respaldo del flujo escribió el contenido fuente en inglés dentro de D1 cuando el subproceso de Claude alcanzó un límite de tasa. El escritor de D1 aceptó esos bytes porque eran bytes. El actualizador de puntos de control generó un hash del contenido almacenado y escribió ese hash en disco. Como la “traducción” almacenada era idéntica al contenido fuente en inglés, los hashes coincidían exactamente: bytes idénticos producen hashes idénticos. La siguiente pasada con --update comparó el hash del contenido fuente en inglés contra el hash almacenado, los encontró iguales y marcó el lote como sin cambios. Cada componente pasó su propio Jiro Test de manera aislada. El defecto estaba en la composición. Un usuario vio seis versiones localizadas con prosa en idiomas mezclados durante horas antes de que una persona abriera una de las páginas.

“Nos hacemos cargo de la experiencia completa” es la regla. Comportamiento de producto, flujos de UX, lenguaje, verdad de los datos, sistemas de soporte, empaquetado, precisión de la documentación, prompts, reglas, memoria, habilidades, hooks, scripts, orquestación, estructura de salida. Todo eso, no solo el artefacto que acabas de publicar. Ninguna victoria local es aceptable si degrada la integridad del conjunto. El Steve Test entra en juego cuando una superficie pasa localmente y la experiencia total del usuario no.

Eliminación: una capa Steve que solo suma es falsa

Lo más útil que produce el Steve Test es una eliminación.

Una revisión que termina sin quitar nada en realidad no se ejecutó. El acto de preguntar ¿el trabajo merece existir? frente a una superficie con complejidad real produce, casi siempre, al menos una pieza de alcance, texto, función o elemento de interacción que no puede defender su presencia. Una revisión que no encuentra ninguna suele ser teatro de revisión, no práctica real.

Lo que el Steve Test busca, concretamente:

• Superficies que están ahí porque se sentía seguro incluirlas, no porque se ganen su lugar.
• Texto que se llena de evasivas porque quitarlas exigiría una afirmación real.
• Funciones heredadas de una versión anterior que ya no sirven a la promesa actual.
• Elementos de interacción agregados para manejar casos límite que en realidad no ocurren con el alcance actual.
• Opciones de configuración que trasladan al usuario una decisión que quien construye debería haber tomado.
• Documentación que describe un comportamiento que el producto ya no tiene.
• Pruebas que cubren código que debería eliminarse.

Eliminar es el acto que distingue el gusto de la acumulación. La superficie digna es más pequeña que la versión que habrías publicado si nadie hubiera hecho la pregunta. Nunca me arrepentí de quitar algo de un producto publicado. Sí me he arrepentido con frecuencia de lo que dejé dentro.

El rechazo como acto principal

Relacionado con la eliminación, y más fuerte: el Steve Test muchas veces se activa antes de construir algo, no después. El acto principal del gusto es el rechazo: decidir no construir la cosa en absoluto.

La frase de Steve Jobs que importa aquí es “I’m as proud of what we don’t do as I am of what we do,”, citada en un reportaje de portada de BusinessWeek de 2006 sobre la disciplina de producto de Apple.⁵ La gente cita esa frase con frecuencia porque es cierta de una forma técnica muy específica. Todo producto publicado está rodeado por un halo invisible de productos que te negaste a publicar. Ese halo es el verdadero punto de vista. Es la evidencia de que la decisión la tomó una persona y no la lista de pendientes.

Para blakecrosley.com, la pila tecnológica es un registro de lo que eliminé. Consideré React y lo rechacé. Consideré Tailwind y lo rechacé. Un empaquetador estuvo sobre la mesa durante las primeras dos semanas de la reconstrucción antes de que lo cortara. La ausencia de node_modules/ en cualquier parte del repositorio no es una elección de diseño; es un rechazo que sostengo en el tiempo contra la fuerza de atracción de las herramientas predeterminadas. Esos rechazos moldean el trabajo más que cualquier inclusión. Definen qué estaba dispuesto a sostener como estándar.

Para ResumeGeni, la validación volvió limpia. Trescientas cuarenta inscripciones por correo electrónico, doce consultas directas, tres ofertas no solicitadas para pagar por acceso anticipado.⁶ La lista de pendientes que esa demanda reveló era grande: plantillas, colaboración en equipo, paneles de analítica, integración con LinkedIn, integración con Indeed, historial de versiones, múltiples formatos de exportación, una aplicación móvil. Rechacé todo eso para la primera versión publicada. Lo que no podía rechazar: análisis preciso, evaluación honesta de brechas, reescrituras concretas que encajaran con la descripción del puesto, una exportación que abriera limpiamente en Word, un flujo que hiciera sentir segura a una persona vulnerable. Las cosas rechazadas no desaparecieron para siempre. Esperan del otro lado de la primera superficie digna.

Una superficie que no rechaza nada es una superficie sin punto de vista. Si el equipo no rechazó nada, el alcance está mal.

Llama a las cosas por su nombre temprano, empezando por ti

El rechazo y la eliminación solo funcionan si la prueba puede nombrar el falso éxito cuando aparece. El Steve Test tiene que llamar las cosas por su nombre, y hacerlo rápido, ante:

• Progreso falso. Movimiento que parece progreso y no produce nada.
• Evidencia contaminada. Una prueba que pasa por la razón equivocada; estadísticas que prueban lo que querías probar en vez de lo que era cierto.
• Conteo de vanidad. Conteos de commits, conteos de artefactos publicados, gráficos de velocidad: todo presente, todo irrelevante.
• Sistemas incoherentes que se publican limpiamente de forma aislada y se degradan entre sí al combinarse. El incidente de traducción anterior es uno de estos.
• Informes de “todo va según lo planeado” que tapan una decisión que nadie tomó. El Steve Test es enemigo de esos informes.
• Actividad automática de bajo valor. Trabajo que una computadora hace porque puede, no porque la salida se gane su lugar.

La versión más difícil y más consistentemente útil de la regla es esta: llama las cosas por su nombre primero en tu propio resultado. El incidente de traducción del inicio de este ensayo es exactamente eso. El flujo informó éxito. Los registros estaban limpios. Todas las métricas que había instrumentado pasaron. El trabajo era puro humo, y tuve que reconocerlo antes de que lo hicieran los usuarios. Detectar el humo en tu propio trabajo es la disciplina que mantiene honesta la prueba. La cortesía no protege contra la verdad; estar ocupado no sustituye el valor.

Gradiente de superficies: calibrar la exigencia

El Steve Test no es un solo pase con un solo umbral. Cuanto más difícil sea retirar una superficie, más exigente debe ser la evaluación.²

La prueba es la misma pregunta. La exigencia de la respuesta requerida escala con el radio de impacto. Puedes corregir una respuesta de chat en el siguiente turno; no pasa nada grave. Un despliegue a producción que falla el Steve Test quema confianza del usuario que tomó meses ganarse, y corregirlo cuesta más de lo que ahorró la decisión original de publicar.

La consecuencia práctica es que la cadencia de publicación debería desacelerarse a medida que las superficies se vuelven más difíciles de revertir, no acelerarse. Los equipos que publican a velocidad uniforme en superficies con reversibilidades muy distintas dejan ver que no creen que la prueba varíe. Normalmente dejaron de ejecutarla.

El gusto no es temperamento

Hay una distinción más que exige el Steve Test, porque es la que se pierde con más frecuencia. Invocar a Steve significa invocar su gusto, no su temperamento.

La doctrina prohíbe explícitamente lo siguiente:³

• Crueldad.
• Humillación.
• Desprecio teatral.
• Disfraz de visionario.
• Agresión como sustituto del juicio.
• Teatro del resentimiento.
• Drama confundido con estándares.

La señal de que la capa Steve realmente está operando es el rechazo sereno. “No, el trabajo todavía no es digno”, dicho como veredicto y seguido por la acción correctiva concreta. No actuación. No humillación de la persona que construyó la versión indigna, que muchas veces eres tú. No desprecio visible por el equipo. No anunciar que tienes estándares más altos. El trabajo supera el estándar o no lo supera. El estándar no es una estética de severidad.

La distinción importa porque la caricatura de Steve Jobs se centra en el temperamento. Cualquiera que haya trabajado bajo alguien que actuaba como Steve sabe a qué me refiero. La crueldad no mejora el trabajo. Empeora el lugar de trabajo y, como sustituye el juicio por teatro, también empeora lo que se publica.

La prueba operativa para saber si estás en la capa de gusto de Steve o en el disfraz de su temperamento es si el resultado de la prueba es una acción técnica concreta. “El trabajo no merece existir” no es una conclusión; es el comienzo de una pregunta. La respuesta tiene que nombrar el eje que falló, la acción correctiva y la siguiente prueba. Si la revisión termina en “el trabajo es malo” sin nombrar qué lo haría digno, la revisión fue teatro.

El límite de reconstrucción y la cláusula antiparálisis

Un estándar alto sin una regla de cierre se convierte en evasión. La disciplina que aplico a toda pieza de trabajo no trivial tiene un límite de tres reconstrucciones honestas.

Un intento honesto significa que identificaste el eje fallido, nombraste la acción correctiva concreta, cambiaste el enfoque de manera material y reevaluaste el trabajo contra ambas pruebas. Tres repeticiones del mismo pase de pulido no cuentan como tres intentos. Las repeticiones cuentan como un intento fallido repetido tres veces.

Después de tres reconstrucciones honestas que no producen trabajo digno, el problema casi nunca es el oficio. El problema vive más arriba, en el encuadre, el alcance, el encargo o la composición del equipo. Deja de reconstruir la superficie y mira la premisa. A veces la promesa era demasiado grande para el alcance que puedes sostener de manera realista con ese estándar. A veces la validación era más débil de lo que pensabas. A veces el problema ni siquiera es un problema de producto.

El límite de reconstrucción resuelve dos modos de fallo opuestos al mismo tiempo. Se niega a dar por válido trabajo débil, y evita que el refinamiento se convierta en una forma de esconderse. Negarse a publicar no es virtuoso por sí mismo. Reconstruir sin fin en busca de perfección es su propio modo de fallo: oficio sin valentía. El objetivo no es la perfección. El objetivo es digno y publicado. No puro y pendiente para siempre.

Si estás en la cuarta reconstrucción de la misma superficie, dejaste de hacer un producto y empezaste a usar el proyecto como lugar para esconderte.

Señales observables: ¿la prueba realmente se ejecutó?

El Steve Test es fácil de afirmar y difícil de ejecutar de verdad. La disciplina consiste en declarar, concretamente, qué produjo la prueba.

Antes de llamar completa una pieza de trabajo no trivial, me aseguro de poder responder todo lo siguiente:⁴

1. ¿Quién es el usuario? No un arquetipo de persona. Una persona real en una situación real.
2. ¿Qué punto de vista lleva esta superficie? Si no puedes nombrar uno, no hay punto de vista, solo una lista de pendientes.
3. ¿Qué rechazaste o eliminaste para mantener esto limpio? La eliminación es la evidencia de que la prueba se ejecutó.
4. ¿Cómo sirve esto al producto completo? La pieza tiene que ser coherente con todas las demás. Las victorias locales que degradan el conjunto no son victorias.
5. ¿Qué evidencia demuestra que es sólido? El eje Jiro. La verificación se ejecutó; la afirmación está respaldada.
6. ¿Por qué es digno? Dicho sin rodeos. Si la respuesta es vaga, la prueba no se ejecutó.
7. ¿Firmaría esto con mi nombre sin titubear? El oráculo del gusto. Cuando el juicio es incierto, esta es la pregunta que manda en todo el conjunto de criterios.

Si no puedo responder las siete con detalles concretos, afirmé la doctrina en vez de aplicarla. Devuelvo el trabajo.

Ejemplo trabajado: las siete señales frente a una superficie real

Estas son las señales aplicadas a una superficie específica publicada después del incidente de traducción: una protección de concurrencia que escribí en el flujo de traducción. Unas 100 líneas de Python que se niegan a iniciar guide_bootstrap.py o blog_translate_batch.py si ya hay otro proceso de traducción en ejecución.

1. ¿Quién es el usuario? Yo al inicio de una ejecución de traducción dentro de dos semanas, cuando ya habré olvidado el modo exacto de fallo por límite de tasa que arruinó seis versiones localizadas. También cualquier agente que invoque cualquiera de los dos scripts en una sesión futura.
2. ¿Qué punto de vista lleva la superficie? Las ejecuciones concurrentes de traducción nunca son la herramienta correcta. La protección codifica ese veredicto en código para que quien la invoque después no tenga que recordarlo.
3. ¿Qué rechacé o eliminé para mantener esto limpio? Me negué a convertir la protección en una advertencia. Me negué a darle una opción de anulación corta y cómoda como --force. La única anulación es una variable de entorno, I18N_ALLOW_CONCURRENT=1, lo bastante larga como para que nadie la escriba por accidente.
4. ¿Cómo sirve esto al producto completo? El flujo de traducción, el escritor de D1 y el mecanismo de respaldo son correctos individualmente. La protección es la pieza que evita que se combinen en un conjunto que se corrompe en silencio.
5. ¿Qué evidencia demuestra que es sólido? Verifiqué la protección con dos comprobaciones manuales. Una: retorno limpio cuando no corre otro trabajo de traducción. Dos: salida distinta de cero cuando un subproceso real de guide_bootstrap.py está vivo. Ambas comprobaciones corrieron contra los scripts reales, no contra dobles de prueba.
6. ¿Por qué es digno? La misma carrera de ejecuciones concurrentes que corrompió seis versiones localizadas no puede producir filas de D1 con idiomas mezclados mientras la protección esté activa. No es prevención en todos los casos; es prevención para el modo de fallo específico que la doctrina acaba de aprender.
7. ¿Firmaría esto con mi nombre? Sí. Un trabajo, semántica de anulación limpia, documentado en una nota de memoria para que una sesión futura herede la razón por la que existe la protección.

El punto del ejemplo trabajado es que cada señal tiene una respuesta específica. Cuando no puedo producir una, la prueba todavía no se ejecutó.

Contrasta eso con cómo se ve el fallo. Cuando redacté la protección de concurrencia, mi primer intento para la señal 3 fue: “Me negué a sobreingenierizarlo.” La frase es el tipo de respuesta que suena bien y no dice nada. Negarse a sobreingenierizar no nombra ninguna cosa específica que consideré y rechacé. Es una pose, no un rechazo. Me obligué a escribir la respuesta real: me negué a convertir la protección en una advertencia; rechacé un nombre cómodo para la opción de anulación; rechacé un comportamiento en el que la protección fallara en abierto si no podía listar procesos. Esas son decisiones. La primera versión era teatro doctrinal.

Ideas clave

Para fundadores y constructores independientes: - Nombra al usuario real en el momento real antes de llamar digna cualquier superficie. El mérito abstracto no sirve. - Toda superficie publicada debería tener al menos un rechazo visible. Si no quitaste nada, el alcance está mal. - Aplica el gradiente de superficies. Un despliegue a producción requiere una evaluación más dura que un borrador; las afirmaciones de marketing requieren la evaluación más dura de todas.

Para líderes de producto y PMs: - Mide si el Steve Test realmente está corriendo contando rechazos y eliminaciones por ciclo de lanzamiento. Cero es una mala señal. - Separa “funciona” de “merece existir” en tus propias listas de revisión. Trátalos como ejes independientes. - Protege el presupuesto de reconstrucción. Tres intentos honestos; luego escala. No permitas que el perfeccionismo se convierta en escondite ni que la presión de los plazos mate la prueba.

Para líderes de ingeniería: - Define un punto de control Jiro y un punto de control Steve para cada superficie que publique tu equipo. Ambos deben pasar. - Invierte en los detalles invisibles. La diferencia entre correcto y digno suele estar en las costuras. - Rechaza el temperamento. El rechazo sereno es la señal. La actuación de severidad es el modo de fallo.

Para diseñadores: - El punto de vista no es decoración. Es el mecanismo que vuelve reconocible al producto. - Una superficie digna rechaza cosas, visiblemente. Tu trabajo incluye nombrar lo que cortaste. - La prueba operativa en la ambigüedad: ¿firmarías la decisión con tu nombre sin titubear?

Cierre: ¿lo firmaría con mi nombre?

La pregunta que gobierna el producto es ¿el trabajo merece existir? La pregunta que gobierna cuando el juicio es incierto es la más simple del conjunto.

¿Lo firmaría con mi nombre sin titubear?

Si la respuesta es sí, el trabajo puede publicarse. Si la respuesta es “todavía no, pero lo será dentro de tres reconstrucciones honestas”, sigue trabajando. Si la respuesta es no, y sigue siendo no después de tres intentos honestos, reconstruye el encargo, no la superficie.

Ejecuto esta prueba cada vez. Sobre el código. Sobre el texto. Sobre el mensaje de commit. Sobre la documentación. Sobre la superficie de producto. Sobre este ensayo.

Este ensayo cortó tres secciones que pensé que necesitaba cuando empecé a redactarlo: una larga sección biográfica sobre Jobs, una introducción a la frase “dent in the universe” y una defensa de por qué la doctrina usa el nombre de una persona real en vez de una abstracción. Ninguna servía al usuario para quien estaba escribiendo: alguien que construye y está tratando de decidir si debe publicar una superficie sobre la que no tiene certeza. Los cortes hicieron la pieza más pequeña y más honesta. Y el fallo de traducción que abre el ensayo produjo un artefacto permanente más allá de la corrección: una protección de concurrencia en el flujo de traducción que ahora se niega a iniciar si ya hay otro trabajo de traducción corriendo. El trabajo rechazado produjo un cambio en las reglas. La doctrina aprendió.

Steve pasa. Jiro pasa. Se publica.

Preguntas frecuentes

¿Qué es el Steve Test?

El Steve Test pregunta si una pieza de trabajo merece existir para un usuario real en un momento real. Está junto a la filosofía de calidad de Jiro: Jiro revisa corrección, evidencia y casos límite; Steve revisa mérito, coherencia, rechazo y gusto.

¿En qué se diferencia el Steve Test del Jiro Test?

Jiro pregunta si el trabajo está hecho correctamente. Steve pregunta si el trabajo correcto debería publicarse. Una función puede pasar las pruebas y aun así fallarle al usuario, al producto o al punto de vista detrás de la superficie.

¿Cuándo debería un equipo ejecutar el Steve Test?

Ejecútalo antes de publicar superficies difíciles de revertir: despliegues públicos, afirmaciones de marketing, flujos de incorporación, páginas de precios, documentación y funciones de producto que moldearán la confianza del usuario. El trabajo liviano puede usar una evaluación más suave, pero las superficies públicas necesitan una estricta.

¿Qué debería producir la prueba?

La prueba debería producir una decisión específica: publicar, reconstruir, eliminar o rechazar. Un pase real nombra al usuario, el momento, el punto de vista, la evidencia y al menos una cosa que el equipo eliminó para preservar el conjunto.

¿Puede el Steve Test convertirse en perfeccionismo?

Sí. Por eso la doctrina necesita un límite de reconstrucción. Tres reconstrucciones honestas son suficientes; después de eso, el problema suele vivir más arriba, en el encargo, el alcance, el equipo o la premisa.

La plantilla de revisión

Copia esto en un bloc de notas, una descripción de PR, una página de Notion o la parte superior de tu mensaje de commit. Complétalo antes de declarar terminado un trabajo no trivial. Si no puedes responder una fila con algo específico, la prueba todavía no se ejecutó.

Steve Test: registro de revisión

Usuario:          [persona real en una situación real, no un arquetipo]
Momento:          [el momento específico en que el usuario encuentra el trabajo]
Punto de vista:   [lo que esta superficie afirma; lo que se niega a hacer]
Rechazo:          [lo que consideré y corté, o me negué a construir]
Producto completo:[cómo esto encaja con cada pieza adyacente del producto]
Evidencia:        [eje Jiro: se verificó; prueba específica que respalda la afirmación]
Veredicto digno:  [sí / no / todavía no dentro de N reconstrucciones definidas]
Firma:            [¿lo firmaría con mi nombre sin titubear? si no, detente]

La plantilla tiene exactamente un trabajo: obligar a quien prueba a producir una respuesta específica en cada fila. Las respuestas vagas no superan el estándar. “Me negué a sobreingenierizarlo” no es un rechazo; “rechacé una opción de anulación cómoda y una ruta de fallo abierto” sí lo es. “Sirve al usuario” no es una respuesta sobre el producto completo; “cierra la brecha composicional específica que causó el último incidente” sí lo es. Cuando una fila se resiste a la especificidad, el trabajo no está listo; esa resistencia es la prueba diciéndote hacia dónde va la reconstrucción.

Esta plantilla es el artefacto operativo del ensayo. Todo lo demás en esta página es explicación de por qué existen las filas.

Referencias