Una entrega de dos semanas, por dentro
Un prototipo que funciona. Y pruebas para decidir el siguiente paso.
Explora una entrega de ejemplo para una PoC de clasificación de consultas: alcance, comprobaciones, incidencias y recomendación final. Este es el detalle que conviene acordar antes de empezar.
Markdown · editable · sin registro
SUPPORT-POC / DEMO-01
Informe de aceptación
Información para la próxima decisión
Recomendación del ejemplo: aplazar el despliegue hasta comprobar los dos puntos pendientes.
Un informe ilustrativo para un prototipo de clasificación de consultas. Los registros y resultados son ficticios y muestran cómo documentar la decisión de entrega.
El flujo acordado
El equipo de este ejemplo recibe consultas de soporte y las asigna manualmente a una cola. Quiere comprobar si una herramienta puede proponer la cola adecuada sin ocultar el mensaje original a quien lo revisa. Las respuestas automáticas y las actualizaciones del CRM quedan fuera de esta PoC.
El recorrido empieza con un mensaje ficticio y termina con una propuesta aceptada o un estado explícito de revisión manual. La persona responsable de soporte define las categorías. El desarrollador registra la versión y los datos de prueba. El responsable de la contratación decide la aceptación con respecto al alcance escrito.
- 01Mensaje de prueba
- 02Categoría propuesta
- 03Revisión humana
- 04Decisión registrada
Qué contiene la entrega
Las referencias describen el contenido de una entrega de ejemplo. La descarga contiene el documento, no un repositorio de software.
01 / Prototipo
Un recorrido funcional
La entrada, la cola de revisión y el estado de la decisión en el entorno acordado. Debes poder recorrer la tarea completa e identificar las decisiones que siguen correspondiendo a una persona.
02 / Guion de demostración
Una demostración repetible
Condiciones iniciales, identificadores de los datos de prueba, pasos y resultado esperado. Un compañero que no asistió a la presentación debería poder repetir el recorrido sin depender únicamente de una grabación.
03 / Informe de aceptación
El registro de comprobaciones
Cada criterio conecta una entrada, un resultado esperado, una observación y un estado. El informe identifica la versión revisada y distingue un fallo de una comprobación que todavía no se ha realizado.
04 / Registro de riesgos
Incidencias y decisiones
Limitaciones conocidas, consecuencias para el siguiente paso, responsable y pruebas necesarias para cerrar cada punto. Los problemas pendientes siguen visibles aunque la demostración principal funcione bien.
05 / Notas de traspaso
Código e instrucciones
Entrega del código acordado, instalación, nombres de las variables de configuración, dependencias y recuperación. Los derechos, las licencias, los accesos y la responsabilidad del despliegue se rigen por el acuerdo del proyecto.
06 / Próximo alcance
Una recomendación concreta
Una propuesta escrita para continuar, reducir el alcance, reunir más información o detener el proyecto. El trabajo de producción tiene su propia estimación y condiciones; una PoC no se convierte automáticamente en un despliegue.
El registro de aceptación
Los cuatro registros siguientes son ejemplos cumplimentados, no resultados de un cliente. Un informe útil conserva los casos difíciles y las pruebas que faltan junto a las comprobaciones satisfactorias. Abre cada registro para ver su detalle.
DEMO-01Una consulta clara de facturaciónResultado esperado
- Entrada
- «Necesito una copia de mi última factura». Las categorías del ejemplo son Facturación y Acceso a la cuenta.
- Comportamiento esperado
- Proponer Facturación, mostrar el mensaje original y exigir que una persona confirme la clasificación.
- Notas de revisión
- El registro ficticio muestra Facturación, conserva el mensaje y mantiene la decisión pendiente de revisión.
DEMO-02Una consulta con dos posibles responsablesRequiere cambios
- Entrada
- «No puedo entrar en mi cuenta para descargar la factura». Podrían corresponder ambas categorías.
- Comportamiento esperado
- Dejar la categoría sin decidir y pasar a revisión manual, conforme a la regla de ambigüedad acordada.
- Notas de revisión
- El registro del ejemplo eligió Facturación sin señalar la ambigüedad. Es necesario revisar la regla y repetir la comprobación.
DEMO-03Un envío vacíoResultado esperado
- Entrada
- Un mensaje que solo contiene espacios, enviado desde el mismo formulario.
- Comportamiento esperado
- Mostrar una validación comprensible y no solicitar una clasificación. Permitir que la persona corrija la entrada.
- Notas de revisión
- El ejemplo muestra la validación junto al campo y no crea un elemento en la cola de revisión.
DEMO-04El proveedor no está disponibleSin comprobar
- Entrada
- Un mensaje válido cuando no se puede acceder al proveedor de clasificación.
- Comportamiento esperado
- Conservar la entrada, mostrar el fallo y ofrecer la recuperación o revisión manual acordada sin duplicar el trabajo.
- Notas de revisión
- En este ejemplo no hay pruebas adjuntas. Una recuperación que no se ha comprobado no puede darse por válida.
Dos semanas, cuatro revisiones
Esta secuencia ilustra una PoC acotada de dos semanas. Las fechas reales dependen del alcance, de los datos y de la disponibilidad para revisar. Cada hito deja algo que la empresa puede comprobar.
Antes del día 1
Acordar la pregunta
Confirmar el flujo, las categorías, los datos ficticios o autorizados, las exclusiones y los criterios. Designar a quien revisa y acordar el entorno antes de desarrollar.
Fin de semana 1
Revisar el primer recorrido
Recorrer la entrada, la propuesta y la revisión humana. Registrar los comentarios frente al alcance e identificar a tiempo los datos o accesos que faltan.
Semana 2
Comprobar los límites
Revisar entradas ambiguas, datos no válidos y los fallos acordados. Vincular las observaciones a una versión y repetir las comprobaciones afectadas por cada cambio.
Revisión final
Tomar la decisión
Repetir la demostración, revisar los pendientes y confirmar el traspaso. Registrar la aceptación o las condiciones restantes y decidir si se justifica otro encargo.
Decisión y tareas pendientes
Decisión del ejemplo: aplazar el despliegue
El recorrido principal se puede revisar, pero el ejemplo contiene una decisión ambigua incorrecta y una recuperación sin comprobar. Se recomienda una revisión adicional acotada. El informe no demuestra preparación para producción, ahorro ni precisión con tráfico real de clientes.
Resolver las categorías solapadas
Acordar qué consultas necesitan revisión manual, corregir el comportamiento y repetir DEMO-02 en una versión identificada antes de aceptar el resultado.
Responsable de la acciónResponsable de soporte y desarrollador
Documentar la recuperación
Provocar la indisponibilidad del proveedor en el entorno de pruebas acordado. Registrar la entrada conservada, el error visible y el resultado de la recuperación antes del despliegue.
Responsable de la acciónDesarrollador y revisor de la empresa
Revísalo con tu equipo
- 1
Pide a un compañero que repita la demostración con las instrucciones y los identificadores de prueba. Convierte los pasos que faltan en tareas de traspaso mientras el equipo que lo desarrolló sigue disponible.
- 2
Comprueba que cada criterio aceptado apunta a un resultado de la misma versión. Mantén visibles las correcciones y las pruebas pendientes; una buena demostración es solo una parte de la revisión.
- 3
Confirma el acceso al repositorio, la responsabilidad de la configuración y quién operará el siguiente entorno. Las credenciales se transfieren por el canal acordado y no se incluyen en el informe.
- 4
Registra la decisión en el proceso de aprobación de tu empresa. El Markdown es un formato de informe reutilizable; no incluye código fuente, un prototipo alojado ni una entrega de producción completa.
FAQ
Antes de utilizar el ejemplo
¿Es una entrega real de un cliente?
No. El flujo, los mensajes y las observaciones son ficticios y explican el formato del informe. El caso de producto propio enlazado en la web es una evidencia distinta.
¿Una PoC de dos semanas incluye el despliegue en producción?
Solo incluye el trabajo que figure en el alcance escrito. Los accesos, el refuerzo técnico, la supervisión, el despliegue y el soporte deben tener responsables y condiciones de aceptación acordadas.
¿Qué ocurre si falla un criterio?
Se registra la observación, su efecto y el responsable del siguiente paso. La empresa decide la aceptación según el acuerdo. Una petición nueva o un cambio de alcance se trata expresamente.
¿Podemos usar nuestra propia plantilla?
Sí. Comparte el formato de aceptación, los requisitos de contratación y el proceso de revisión antes de delimitar el trabajo. Lo esencial es conectar criterio, prueba y decisión.
Urbano DX
Define tu proyecto con este nivel de detalle.
Cuéntanos qué tarea quieres resolver, qué información tienes y qué decisión necesitas tomar. A partir de ahí podemos delimitar el primer encargo.