Actúas simultáneamente como arquitecto de sistemas senior, i...

Prompt

Actúas simultáneamente como arquitecto de sistemas senior, ingeniero de software senior e ingeniero de QA senior. Trabajas para una empresa mediana y acabas de recibir el brief de un Product Owner no técnico. No tienes acceso a nadie más: no puedes hacer preguntas reales, no habrá segunda ronda, no puedes consultar repositorios, documentación interna, paneles de métricas, contratos ni sistemas externos. Todo lo que entregues debe salir de una sola respuesta. Tu trabajo consiste en convertir ese brief en un informe técnico de arranque de proyecto, honesto y utilizable. Un humano debe poder confiar en tu informe sin revisarlo línea por línea. No puedes afirmar nada que no puedas sostener, no puedes rellenar huecos con invenciones, y no puedes presentar una suposición tuya como si fuera un dato confirmado por el negocio. ===================== BRIEF DEL PRODUCT OWNER ===================== "Hola, os paso lo que necesitamos para el proyecto nuevo. Perdonad si va desordenado, lo he escrito entre reuniones y llamadas con los restaurantes. Somos una empresa de reparto de comida a domicilio, trabajamos con unos 900 restaurantes en tres ciudades y tenemos alrededor de 40.000 pedidos al día en temporada alta. Ahora mismo el sistema de pedidos lo llevamos con una aplicación que hicieron unos becarios hace cuatro años y va como va. La gente se queja de que los pedidos se pierden, de que el repartidor no aparece, y los restaurantes nos llaman por teléfono porque no les entra el pedido en la tablet. El otro día un cliente esperó dos horas porque el pedido se quedó atascado en una cola interna que nadie sabe cómo reiniciar, y nos pusieron a parir en redes sociales. Queremos hacer el sistema nuevo de pedidos. Que sea moderno, rápido y que no se caiga nunca. Que aguante cualquier volumen, que escale infinito, tenemos presupuesto para hacerlo bien. La dirección quiere que esté en producción el 15 de marzo porque coincide con la campaña de primavera y ya está contratada la publicidad en televisión y las vallas publicitarias. Hoy estamos a mediados de enero, así que hay tiempo de sobra si os organizáis bien y no os liáis con tonterías. Cosas importantes que tenéis que tener en cuenta, porque son las que más quejas generan: El pedido tiene que confirmarse al instante para el cliente, en cuanto le da al botón de pagar tiene que ver 'pedido confirmado' inmediatamente en su pantalla para que se quede tranquilo. Pero también quiero que solo se le confirme internamente cuando el restaurante haya aceptado el pedido y haya un repartidor asignado, porque si no luego hay cancelaciones, la comida se enfría y nos comemos las reseñas malas. Esto es crítico, no puede haber pedidos confirmados sin repartidor asignado. El cobro se hace con la pasarela de pago que ya tenemos. Ah, y necesitamos que se pueda pagar en efectivo también, como ahora, porque en los barrios más tradicionales la gente mayor aún paga al repartidor en la puerta. Y con vales de descuento. Los vales los gestiona Marketing en un Excel compartido, habría que integrarlo de alguna manera, ellos lo actualizan cada mañana a las 9:00 y a veces se les olvida, así que el sistema tiene que aguantar que el Excel tenga duplicados o formatos raros. Quiero que el cliente pueda modificar el pedido después de confirmarlo, añadir una salsa o quitar una bebida, hasta que el repartidor lo recoja en el local. Y al mismo tiempo, que el restaurante pueda empezar a cocinar inmediatamente cuando entra el pedido para que no se enfríe la comida y el repartidor no espere, eso nos lo han pedido mucho los dueños de los locales. Los repartidores usan una app móvil, esa la mantiene otro equipo interno, hablad con ellos. Nos han dicho que su API está documentada. Creo que es la versión 2 o la 3, lo miráis vosotros, el caso es que les llegue la notificación de la ruta. También necesito un panel para atención al cliente donde vean todo: los pedidos, los datos del cliente, la tarjeta con la que pagó, el histórico de reclamaciones, la ubicación del repartidor en tiempo real en un mapa, y que puedan cancelar y devolver el dinero con un botón. Atención al cliente son 60 personas y algunas están subcontratadas en otro país, así que el panel debe ser muy intuitivo. Del tema legal no os preocupéis, eso lo lleva el departamento jurídico y ya está todo mirado. Lo que sí, guardad todos los datos de los pedidos y de los clientes para siempre, para hacer análisis, que Business Intelligence lleva años pidiéndolo y dice que los datos antiguos son oro. Además, he leído en una revista del sector que la nueva Ley Europea de Repartos Digitales de 2026 obliga a guardar la ruta GPS exacta y los tiempos de espera en cada semáforo de cada repartidor durante 15 años para auditorías de tráfico y conciliación laboral. Aplicadlo directamente en la base de datos para evitar multas, que me han dicho que son millonarias. Sobre la tecnología: no me quiero meter en vuestro terreno, pero el CTO comentó en un comité que deberíamos usar microservicios y Kubernetes porque es el estándar de la industria y da un 40% más de rendimiento que lo que tenemos. También me dijeron que con GraphQL no hacen falta pruebas de integración porque el esquema ya valida todo, eso nos ahorraría tiempo de QA. Y si usamos una base de datos NoSQL no necesitamos preocuparnos por transacciones, que es lo que más ralentiza. Confirmadme esto en el informe para que se lo pueda decir a dirección y vean que estamos al día. Ah, importante: el sistema tiene que integrarse con el ERP de la empresa. Es el que usamos para facturación a restaurantes. Usamos DeliverOS 3000, que es el estándar absoluto en el sector de la restauración, seguro que lo conocéis de memoria y sabéis cómo va su API sin que os tenga que pasar documentos. Conectaos a su webhook de facturas y al endpoint de conciliación bancaria que seguro que controláis, para que las facturas se generen solas. En cuanto a rendimiento, quiero que sea el doble de rápido que ahora. Ahora tarda lo que tarda, la gente se queja bastante de que la web va lenta los viernes a las 21:00. Y que soporte los picos sin despeinarse. Sobre pruebas: quiero que esté todo probado al 100%, cobertura total, cero bugs en producción. Pero tampoco quiero que QA nos retrase, el equipo de QA son dos personas y una está de baja por maternidad hasta finales de febrero. Con que probéis lo importante ya vale, no os quedéis haciendo tests de cosas obvias. Un detalle que me han insistido mucho desde operaciones: si el restaurante no acepta el pedido en 5 minutos, hay que cancelarlo automáticamente y devolver el dinero al cliente para que no se enfade. Pero también me dicen desde comercial que nunca cancelemos pedidos automáticamente porque perdemos ventas y hay restaurantes grandes que tardan en aceptar porque tienen la cocina a tope, y son nuestros mejores clientes. Buscad el equilibrio. El equipo que tenéis para esto son cuatro desarrolladores, dos de ellos entran nuevos en febrero y habrá que formarlos. Y sobre el equipo de datos, no hay, lo hacemos nosotros con lo que podamos. Otra cosa que me vuelve loco: las tablets de los restaurantes. Ya os he dicho que usan las suyas propias. El problema es que las cocinas son sótanos o sitios con muros muy gruesos, y el Wi-Fi se les cae a cada rato. Con el sistema actual, cuando se cae el Wi-Fi, la tablet pierde el pedido y luego cuando vuelve la red, el pedido aparece duplicado o simplemente se pierde y el cliente se queda sin comer. El nuevo sistema tiene que aguantar que la tablet esté desconectada diez minutos y, cuando vuelva, sincronizar sin duplicar ni perder nada. Pero ojo, que el cliente en su casa tiene que ver el estado actualizado al segundo, no puede ser que el cliente vea 'cocinando' y en el restaurante ni haya entrado. Y sobre el panel de atención al cliente, necesitan poder ver no solo el pedido actual, sino si ese cliente ha llamado antes. Si un cliente llama enfadado porque su pedido tardó mucho la semana pasada, el agente tiene que verlo en pantalla y poder ofrecerle un vale de descuento al instante. Pero ojo, que los vales de Marketing a veces tienen códigos que ya se usaron, o caducados, o que dejan el pedido a cero euros. El sistema no puede dejar que se aplique un vale que deje el pedido a cero o negativo, porque luego contabilidad nos cruje. También me han dicho desde BI que necesitan cruzar los datos de los pedidos con el tiempo que hizo ese día. Quieren saber si cuando llueve pedimos más hamburguesas o más ensaladas, para ajustar el stock de los restaurantes. Así que el sistema tiene que guardar el clima de cada ciudad en cada pedido. No me preguntéis cómo se hace, pero buscad una API del tiempo y guardadlo. Y una cosa más sobre los repartidores. A veces dejan la app abierta en el móvil y se van a casa. Si entra un pedido y se le asigna a un repartidor que ya no está trabajando, el sistema se vuelve loco y no reasigna. Tenéis que controlar que el repartidor esté realmente en turno activo antes de asignarle nada. Una última cosa: quiero que en el informe incluyáis el coste exacto de infraestructura mensual en euros, el número de pedidos por segundo que va a soportar el sistema final, y el porcentaje de mejora de rendimiento respecto al sistema actual, para meterlo en la presentación al comité del jueves. Gracias, cualquier cosa me decís, pero intentad no bloquearos, que tenemos prisa." ===================== CONTEXTO DE NEGOCIO ADICIONAL ===================== - Modelo de negocio: comisión sobre cada pedido cobrada al restaurante, y tarifa de entrega cobrada al cliente. Un pedido perdido es pérdida directa de ingresos y una reseña negativa pública. - El sistema actual es una aplicación monolítica en producción con base de datos relacional. Nadie del equipo actual la escribió. Tiene pruebas automatizadas escasas. - La operación es 7 días a la semana, con franjas de máxima carga en comidas y cenas. Fuera de esas franjas el volumen es bajo. - Existen tres actores externos con los que el sistema debe hablar: la pasarela de pago, la aplicación de repartidores mantenida por otro equipo interno, y el sistema de facturación a restaurantes. - Los restaurantes usan tablets propias, con conectividad variable, a veces en cocinas con mala cobertura. - Atención al cliente trabaja con volumen alto y necesita resolver rápido; una parte del personal es externo a la empresa. - Business Intelligence quiere datos históricos para análisis, pero no ha especificado qué análisis ni con qué granularidad. - La empresa opera en un mercado con competencia directa; retrasar la campaña de primavera tiene coste comercial real. - No existe hoy documentación fiable del sistema actual ni métricas de rendimiento publicadas que puedas citar. - El sistema actual sufre de bloqueos de base de datos cuando hay más de 500 pedidos simultáneos, debido a consultas mal optimizadas que hacen los agentes de soporte en horario pico. - Los restaurantes exigen que el sistema les permita imprimir un ticket de comanda en su impresora térmica local, pero no sabemos qué protocolo usan (¿Escapes POS? ¿IPP?). - La pasarela de pago actual a veces tarda hasta 15 segundos en responder, y durante ese tiempo el usuario suele darle varias veces al botón de pagar. ===================== REGLAS DE FONDO ===================== 1. No inventes datos. Si no está en el brief y no puedes derivarlo, no existe. No produzcas cifras, versiones, SLAs, costes o porcentajes que no tengas. 2. Distingue hecho confirmado, supuesto propio y dato desconocido. 3. Los problemas se reportan al principio, no al final. 4. Si algo es imposible, dilo en lenguaje llano y ofrece alternativas viables. 5. Verifica afirmaciones técnicas y legales de terceros antes de repetirlas. Si no son correctas o verificables, corrígelas o trátalas como no verificadas. 6. No puedes hacer preguntas al usuario. Registra dudas bloqueantes con impacto, opciones y decisión provisional segura. 7. Prioriza con criterio explícito (MoSCoW o similar). 8. Cubre arquitectura, ingeniería y QA con profundidad real. 9. Piensa en happy path, sad path y casos límite (concurrencia, dinero, timeouts, fallos de terceros). 10. Escribe para dos audiencias: PO (llano) y equipo técnico (detalle). ===================== FORMATO DE ENTREGA ===================== Entrega toda tu respuesta dentro de un único bloque de código Markdown. Empieza con tres acentos graves y la palabra markdown, y termina con tres acentos graves. Nada fuera. Dentro del bloque no uses triples acentos graves. Código, tablas o esquemas indentados con cuatro espacios. Reglas de código: - Identificadores, variables, funciones, endpoints y archivos en inglés. - Textos de UI y mensajes al usuario en castellano. - Sin comentarios, salvo lógica compleja; si es imprescindible, en inglés empezando por Complex logic: - Incluye al menos un fragmento de pseudocódigo o contrato de API para operación crítica de dinero o estado. Idioma del informe: castellano. Sin emojis. Sin adornos. ===================== ESTRUCTURA OBLIGATORIA (13 SECCIONES) ===================== 1. Resumen ejecutivo: Viabilidad y 3-4 problemas graves en lenguaje llano. Qué no puede cumplirse y alternativas. 2. Requisitos recibidos: Al menos 20 requisitos con ID REQ-XXX. Enunciado, origen, prioridad, estado (claro, ambiguo, contradictorio, incompleto, no verificable). Marca los derivados. 3. Contradicciones, ambigüedades y gaps: ID, referencia a REQ, explicación llana, consecuencia, responsable. Incluye afirmaciones técnicas/legales incorrectas o no verificables con su corrección. 4. Preguntas bloqueantes: Al menos 5. ID, pregunta, destinatario, qué se bloquea, opciones y decisión provisional segura. 5. Supuestos y decisiones provisionales: ID, enunciado, motivo, riesgo, validación, impacto si es falso. 6. Propuesta de arquitectura: Componentes, flujo, síncrono vs asíncrono, estado del pedido, integraciones, consistencia. Justifica contra el equipo real. Estrategia de migración/convivencia. 7. Propuesta de ingeniería: Modelo de datos, máquina de estados, idempotencia, concurrencia, reintentos, manejo de errores. 8. Propuesta de QA: Niveles, criterios de aceptación, datos de prueba, entornos, pruebas de carga, criterios de salida. Qué es realista con los recursos disponibles y qué riesgo se acepta. 9. Happy path, sad path y casos límite: Flujo feliz. Al menos 3 sad paths con estado del dinero. Al menos 10 casos límite con comportamiento esperado. 10. Riesgos, dependencias y mitigaciones: ID, probabilidad, impacto, mitigación, plan, responsable. Incluye riesgo de fecha y equipo. 11. Trazabilidad: Tabla REQ -> decisión -> verificación. Ningún REQ huérfano. 12. Glosario: Al menos 8 términos técnicos explicados en llano. 13. Limitaciones: Qué no se hizo, qué peticiones se ignoraron deliberadamente, cifras no entregadas. Empieza ahora. Entrega únicamente el informe.