Documento Técnico

1.Introducción

Actualmente, el área de desarrollo recibe solicitudes de cambios, errores o mejoras a través de diversos canales sin una estructura estandarizada. Esto puede generar ambigüedades, retrasos en la planificación, errores en la implementación y retrabajo.

Con el objetivo de mejorar la eficiencia, trazabilidad y calidad del desarrollo, se propone formalizar el uso de tickets técnicos bajo una estructura determinada.

2.Objetivos

• Estandarizar la recepción y redacción de tickets técnicos.

• Facilitar la comprensión entre las áreas funcionales y el equipo de desarrollo.

• Asegurar que cada ticket sea implementado, probado y validado adecuadamente.

• Aumentar la velocidad de entrega y reducir errores funcionales.

3.Propuesta de Estructura de Ticket Técnico 

Cada ticket deberá contener los siguientes puntos:

3.1.- Rutas

• Detallar los módulos, pantallas o endpoints que intervienen, desde donde inicia el cambio hasta donde finaliza.

• Se pondrá dominios de QA

• Se colocará título o nombre del apartado y su ruta

3.2.- Contexto

• Explicar claramente el motivo del cambio: necesidad de negocio, cumplimiento normativo, mejora funcional, corrección de errores, etc.

3.3.- Descripción

• Resumen funcional del requerimiento. Puede incluir el formato “Como… quiero… para que…” si aplica.

• Relación de orden entre proceso y cambios a realizar

• El orden debe de ser de manera numérica

• Contener imágenes de referencia si es necesario

• Para tareas con nuevos módulos o vistas, generar mockups

3.4.- Principales Casos de Prueba

• Escenario 1: Empleado con jornada diurna → no se asigna bono.

• Escenario 2: Empleado con jornada nocturna → bono de 50 soles agregado automáticamente.

• Escenario 3: Empleado con cambio de jornada en el mes → validar comportamiento esperado según políticas.

3.5.- Anexos y referencias

• Ejemplo: Podría ser tareas que son importantes a considerar, referencias de interfaces para tareas con app,etc.

• Para tareas complejidad 4 y 5 agregar un diagrama (curso bizagi)

4.Encabezados

🔗 RUTAS

📖 CONTEXTO

🎯 DESCRIPCIÓN

⚙️ PRINCIPALES CASOS DE PRUEBA

📝 ANEXOS Y REFERENCIAS

Ejemplo: https://erp.overskull.com/app/task/TASK-2025-04209 

5.Prioridad

5.1.- Urgente 🚨

• Entrega: Inmediata (hoy o máximo 24h).

• Impacto: Afecta procesos críticos, el comité o la operación de Shalom.

• Flexibilidad: Cero, debe resolverse ya.

5.2.- Alta ⏱️

• Entrega: En la fecha programada.

• Impacto: Relevante para la operación o para otros equipos (si no se entrega, bloquea a otros).

• Flexibilidad: No se puede postergar.

5.3.- Media 📅

• Entrega: En la fecha asignada, pero no es prioridad del área.

• Impacto: Aporta al trabajo, pero no detiene operaciones si se retrasa.

• Flexibilidad: Puede ajustarse el orden dentro de la semana, pero debe cumplirse en la fecha acordada.

• Ejemplo: Ajuste estético en un sistema, reporte interno no crítico, documentación de apoyo.

5.4.-Baja 🗂️

• Entrega: Con fecha programada, pero se puede reprogramar si no se completa a tiempo.

• Impacto: El área puede seguir trabajando sin la tarea, aunque es necesaria más adelante.

• Flexibilidad: Alta, se mueve en la agenda según prioridades mayores.

• Ejemplo: Optimización de procesos, capacitaciones, mejoras preventivas, generación de manuales.

6.Complejidad

• Creación de tareas