MVP — Servicio Técnico v2 (foco técnico)

Recorte exploratorio del MVP, sesión 2026-04-28. Sustituye §18 de memoria.md en lo relativo al alcance.

Objetivo

Validar si los técnicos efectivamente cargan en el sistema la información que hoy circula por Google Chat (diagnóstico, solución aplicada, trabajos realizados) y obtener feedback real de uso. Es un MVP exploratorio: no busca cerrar el flujo de v2, busca alimentar las decisiones siguientes.

Motivación

• Evitar inversión grande sin evidencia de adopción.
• La pieza más cara de v2 (inferencia/automatización de estados) requiere antes saber si el técnico carga la información que esa lógica necesitaría.

Alcance dentro

Captura por parte del técnico

• Diagnóstico técnico.
• Lista de partes necesarias dentro del diagnóstico, en términos descriptivos (ej. "SSD 250 GB"). Sin elección de ítem SAP, sin precio, sin stock.
• Solución aplicada.
• Tareas realizadas (renombre de "actividades").
• Comentarios.

Cambios de UI acordados

• Alta de tareas: modelo simplificado — ver sección dedicada.
• Comentarios: visibles permanentemente al abrir la llamada (no en tab).
• Orden de pestañas: siguen el orden de estados → Diagnóstico → Presupuesto → Tareas → Soluciones → Documentos.
• Pestañas vs "siempre visibles": en este MVP las secciones se mantienen en pestañas. Pasar diagnóstico/tareas/soluciones/documentos a "siempre visibles" queda como idea para versiones posteriores.

Modelo del alta de tareas

• Selector con búsqueda sobre ítems tipo labor. El técnico escribe y selecciona.
• Lista a confirmar: cada selección agrega el ítem a una lista pendiente, sin commitear aún.
• Sin datos extra al seleccionar: no se piden notas, ni cantidad, ni asignado.
• Defaults preconfigurados: asunto = "Ejecución".
• Alta inline del ítem labor si no existe (como en v1).
• Quitar antes de confirmar: cualquier ítem se puede sacar de la lista pendiente.
• Confirmación única: un solo botón agrega todas las tareas a la llamada de servicio.
• Eliminación posterior: una tarea ya agregada al servicio puede eliminarse.

Alcance fuera

• Lógica de cambio de estados (sigue manual como hoy).
• Inferencia de estados desde el trabajo cargado.
• Botones de handoff con precondición ("Diagnóstico listo", "Marcar terminado").
• Flujo del encargado: resolución de partes (búsqueda en stock, marca, precio, compra), aprobación de salidas de stock.
• Sub-flujos de garantía.
• Tarifas fijas.
• Vista propia "mi trabajo ahora" del técnico.
• Ciclo de tareas con apertura/cierre y horas (queda como hoy: registrar lo hecho).
• Sugerencias rápidas (más usadas / por categoría) en el alta de tareas — postergadas hasta tener datos de uso.

Criterios de éxito (observables)

• Los técnicos cargan diagnóstico en el sistema, no en Google Chat.
• Los técnicos cargan la solución aplicada al cerrar el trabajo.
• Las tareas reflejan el trabajo realizado.
• Los comentarios se usan para coordinar (en lugar de canales externos).
• El alta de una tarea requiere menos clicks/tiempo que en v1.

Riesgos y supuestos

• Supuesto: la fricción del alta de tareas es la principal barrera de adopción. Si tras el MVP la adopción sigue baja con ese cambio aplicado, el problema está en otro lado.
• Riesgo: "siempre visibles" puede degradar la pantalla si los volúmenes crecen — observar durante el MVP.

Próximos pasos

• Análisis del qué completo. Continúa con diseño visual y técnico, fuera del alcance de este documento.