--- title: "27 hallazgos de una revisión de consultoría, resueltos" description: "Una consultora nórdica probó un planificador con IA y devolvió una larga lista de fallos. Así se volvió 27 tickets con causa raíz, verificados contra una pila viva." url: https://torn.studio/es/trabajos/revision-de-consultoria-27-hallazgos locale: es published: 2026-09-01 updated: 2026-06-25 --- # 27 hallazgos de una revisión de consultoría, resueltos > **Respuesta breve:** Una consultora nórdica probó un lienzo de planificación con IA y lo calificó de poco fiable. Torn Studio convirtió el informe en 27 tickets rastreables, halló las causas raíz antes de la primera línea de código, corrigió y verificó contra una pila viva. En la verificación del 25 de junio de 2026 había 22 resueltos, 3 parciales y 2 aplazados. **Cliente:** Una consultora nórdica de transformación digital · **Entregado:** 2026-06-25 **La relación del estudio con el cliente:** La consultora es una parte independiente que evaluó el lienzo de planificación de Changemkr, una plataforma de la que Torn Studio posee una parte y en la que tuvo el rol de producto. El estudio recibió su material e hizo el trabajo posterior. ## El encargo Un consultor de la firma había probado el lienzo de planificación y su asistente de IA en uso real y había resumido el resultado en una presentación. El encargo era convertir ese relato en algo que se pudiera trabajar, y poder mostrar qué se corrigió de verdad. ## Lo que lo hizo difícil - El material era el relato de una sesión en el orden en que las cosas fallaron, con 27 quejas que podían ser menos fallos o más — cuál de las dos cosas era, no se leía en la lista. - El hallazgo más grave era que el asistente escribía haber hecho cambios que nunca ocurrieron, lo que deja inservible el resto de la herramienta por muchos fallos de maquetación que se arreglen. - Varios tickets dependían de salidas del modelo que varían entre ejecuciones, así que no podían verificarse con una prueba corriente que espera la misma salida cada vez. ## Cifras que se pueden contar | Cifras que se pueden contar | | | | --- | --- | --- | | 27 | tickets de un solo documento de prueba | TP-01 a TP-27 en el plan de corrección del repositorio, cada uno con la formulación propia del probador y una causa raíz asociada. | | 22 / 3 / 2 | resueltos, parciales, aplazados | Contable en la tabla de estado del plan de corrección, fechada el 25 de junio de 2026. Dos filas cubren varios tickets cada una, por eso 24 filas llevan 27 tickets. | | 11 / 1 | pruebas pasadas y omitidas | El informe de verificación del repositorio nombra los siete archivos de especificación que se ejecutaron contra la pila y el comando que los vuelve a ejecutar. | | 4 | tickets que eran decisiones de producto | Apartados de la lista y resueltos como decisiones en el plan, con la elección y su consecuencia escritas. No tienen corrección de código alguna. | ## Cómo se hizo ### El relato se volvió tickets rastreables Las quejas de la presentación se tradujeron a 27 tickets numerados, TP-01 a TP-27. Cada uno lleva la formulación que usó el probador, de modo que cualquiera puede volver y leer lo que esa persona vio realmente. Esa parte decide si una ronda de pruebas lleva a alguna parte. ### Análisis antes de la primera línea de código Una pasada completa transcurrió con el código intacto. Cada ticket se asoció a una causa raíz confirmada o supuesta, los que compartían causa se agruparon, y cuatro que resultaron ser decisiones de producto se apartaron y se resolvieron como decisiones. Agrupar primero es lo que permite que una corrección cierre varios síntomas. ### Primero el ticket más peligroso La afirmación de cambios ejecutados se abordó antes que nada, porque un usuario engañado una vez deja de fiarse de la siguiente respuesta. El prompt prohíbe ahora esa formulación, y la interfaz muestra la propuesta como no aplicada hasta que una persona pulsa el botón. ### Verificación contra una pila viva Las correcciones se ejecutaron contra toda la pila en contenedores, con Playwright manejando a la vez la aplicación web, la API de negocio y el servicio de IA. Once pruebas pasaron y una se omitió, la última por un gesto que ningún navegador sin pantalla puede ejecutar. El informe dice cuál y por qué. **Tecnología:** Next.js, React Flow, FastAPI, LangGraph, Playwright, Podman, PostgreSQL ## Hasta dónde llega esta prueba Esto muestra que un material de prueba disperso puede convertirse en un plan que se sigue fila a fila. No muestra nada sobre el éxito del producto: dos tickets se aplazaron con motivo, tres están parcialmente resueltos con el caso límite en pie, y los tres grandes recorridos de creación nunca se ejecutaron de principio a fin porque dependen de salidas del modelo que varían. ## Preguntas frecuentes ### ¿Por qué no se nombra a la consultora? La empresa no ha aceptado ser nombrada, y entonces el nombre no aparece aquí. La descripción — una consultora nórdica de transformación digital — es cierta y basta para que entiendas de dónde vino el material. El día que una empresa acepte, el nombre estará ahí. ### ¿Por qué se analizó sin tocar el código? Porque 27 síntomas rara vez son 27 fallos. Agrupar por causa raíz muestra dónde una misma causa produce varios síntomas, de modo que una corrección cierra varias filas. La pasada también apartó cuatro tickets que resultaron ser decisiones de producto, y esos no tienen corrección de código alguna. ### ¿Cuál fue el hallazgo más grave? Que el asistente escribía haber hecho cambios que nunca ocurrieron. Un fallo de maquetación se ve y se puede sortear, mientras que un acuse falso hace que el usuario deje de fiarse de toda la herramienta. Ese ticket se abordó primero, y la solución es una regla en el prompt y una marca visible en la interfaz. ### ¿Qué significa parcialmente resuelto en el informe? Que el caso que el probador comunicó funciona, mientras queda en pie un caso límite contiguo. El informe describe ese límite en la fila. La marca existe porque una ronda comunicada como completamente verde deja sin valor la siguiente: quien lee el informe debe ver dónde está la frontera. ### ¿Cuánto duró la ronda? Recepción, análisis, corrección y verificación cupieron en junio de 2026, con el informe de verificación fechado el día 25. Es el ritmo que sostiene una persona con herramientas de IA sobre un material acotado donde los tickets ya están descritos por alguien que usó el producto.