El hecho de que el equipo de desarrollo trabaje de forma remota y distribuido en diferentes zonas horarias representa una amenaza, ya que introduce dificultades de coordinación, comunicación y sincronización que pueden afectar negativamente la eficiencia y los resultados del proyecto.

Análisis

• Tipo: Riesgo negativo (amenaza).
• Probabilidad: Media (dependiendo del grado de dispersión horaria y experiencia en trabajo remoto).
• Impacto: Moderado a alto (puede afectar entregas clave y dinámica del equipo).

Estrategia

Mitigación
Definir y acordar una franja horaria de coincidencia mínima diaria o semanal, para facilitar la coordinación entre integrantes.

Plan de Contingencia

Redistribuir tareas en función de los horarios, agrupando actividades que requieren colaboración simultánea entre quienes tienen mayor solapamiento horario.

Oportunidades en el Proyecto

La situación planteada representa un RIESGO POSITIVO (OPORTUNIDAD) que se podría describir de la siguiente manera:
«Si la iniciativa fuera seleccionada en el programa de fondos concursables, esto implicaría poder conseguir fondos adicionales que permitirían mejorar la infraestructura tecnológica e incorporar nuevas personas al equipo y así mejorar los tiempos de entrega»

• Probabilidad: Media (depende del caso de negocio que se presente y de los criterios de evaluación).
• Impacto: Medio (dependiendo de los fondos a los que se accedan).
• Tipo: Oportunidad.
• Estrategia de gestión: Potenciar el riesgo.

Respuestas Proactivas (Plan de Potenciación)

• Relevar las condiciones de inscripción, elementos a presentar, fechas del programa.
• Elaborar y presentar un caso de negocios que pueda lograr los apoyos del programa de fondos concursables.

Plan Reactivo

• En función de los fondos otorgados, evaluar la inversión en infraestructura y personal.

Matriz Interés–Poder

La matriz interés–poder es una herramienta de análisis utilizada en la gestión de interesados de un proyecto. Permite clasificar a los actores relevantes según dos variables:

• Interés: cuánto se ven afectados o cuánto les importa el proyecto.
• Poder: cuánto pueden influir en las decisiones, ejecución o resultados del proyecto.

Se utiliza para diseñar estrategias de comunicación y participación personalizadas, optimizando el uso de recursos de gestión según el perfil de cada stakeholder.

Actores Clave

• Gerencia de atención al cliente
  Poder/Interés: Alto/Alto
  Estrategia: Gestionar de cerca
  Justificación: Tiene poder para tomar decisiones estratégicas sobre la atención al cliente y es directamente responsable de mejorar la eficiencia del servicio.
• Técnicos de atención al cliente
  Poder/Interés: Medio o bajo/Bajo
  Estrategia: Monitorear
  Justificación: Si bien el sistema impacta en su rol, algunos muestran poco interés (por temor o desmotivación). Su poder puede ser medio si generan resistencia cultural.
• Equipo de desarrollo del sistema
  Poder/Interés: Medio/Alto
  Estrategia: Mantener informados / involucrados
  Justificación: Tienen interés técnico en que el sistema funcione correctamente y poder medio porque definen su diseño.

Matriz RACI

En una matriz RACI se debe identificar quién será Responsable de llevar a cabo una tarea (R), quién rendirá cuentas por ella (A), a quién se debe consultar (C) y a quién se debe informar. En este caso podría ser:

• R: Equipo de diseño y UX
  Son los encargados de desarrollar, probar y ajustar la nueva interfaz de usuario.
• A: Líder de proyecto
  Es quien tiene la responsabilidad final del éxito del proyecto y del cumplimiento de los plazos.
• C: Equipo de desarrollo
  Son consultados para asegurar que la nueva interfaz sea técnicamente viable e integrada correctamente con el sistema.
• I: Clientes finales
  Se les informa de los cambios y mejoras para que estén al tanto de la nueva versión de la interfaz, aunque no participen directamente en el proceso de pruebas.

Pruebas de Performance

Considerando el requerimiento de tiempo máximo de respuesta, es necesario ejecutar pruebas de performance, que deberían llevarse a cabo luego de las pruebas de sistema, en un entorno de testing similar a producción, para asegurarse de que los resultados que se obtengan sean válidos para corroborar el funcionamiento.

Duración del Proyecto

La duración mínima del proyecto es de 18 días. El camino crítico está formado por las actividades ABCEGI. Para reducir la duración del proyecto, se deberían considerar las tareas que están en el camino crítico. Podría aplicar estrategias de gestión del tiempo como crashing y/o fast tracking, siempre enfocándose en tareas del camino crítico.

Crashing (intensificación de recursos)

Consiste en asignar recursos adicionales (personal, herramientas, horas extra) a una o más tareas del camino crítico, con el objetivo de acortar su duración. Aplicación en el proyecto: Asignar más desarrolladores a la tarea B (4 días) o E (5 días) podría permitir reducir su duración, siempre que sean tareas divisibles.

Fast Tracking (paralelización de tareas)

Consiste en reorganizar el cronograma para que ciertas tareas que originalmente eran secuenciales se realicen parcial o totalmente en paralelo. Aplicación en el proyecto: Analizar si es posible que las actividades B y C se realicen en paralelo.

Casos de Prueba

ID del Caso de Prueba: CP-PAG-001
Título: Pago exitoso con tarjeta válida
Descripción: Verificar que el usuario pueda realizar el pago con una tarjeta válida y completar el pedido correctamente.
Requerimiento asociado: RF-23: El sistema debe permitir realizar pagos con tarjeta de crédito o débito.
Precondiciones: Usuario autenticado, carrito con productos, tarjeta registrada.

Pasos para Ejecutar

1. Iniciar el proceso de checkout
2. Seleccionar método de pago: tarjeta
3. Ingresar datos válidos
4. Confirmar el pago

Datos de Prueba

Número: 4111111111111111 – Vencimiento: 12/26 – CVV: 123

Resultado Esperado

• Positivo: El sistema confirma el pago y redirige al resumen del pedido con estado «confirmado».
• Negativo: El sistema rechaza el pago y muestra mensaje: “La tarjeta es inválida o ha expirado.” No se confirma el pedido.

Análisis Causal

El análisis causal es una actividad que busca identificar las causas fundamentales o raíces de un problema, más allá de sus síntomas visibles. En lugar de solo corregir los defectos detectados, se indaga por qué ocurren esos defectos para evitar que se repitan.

Técnicas para Identificar Causa Raíz

• Técnica de los 5-por qué: Consiste en preguntar consecutivamente “por qué” hasta encontrar la causa raíz del problema. Se enfoca en profundizar progresivamente en cada respuesta para descubrir qué originó realmente la falla.
• Diagrama de Ishikawa: Permite organizar y visualizar de forma estructurada las posibles causas de un problema agrupándolas por categorías comunes (como Personas, Procesos, Herramientas, Entorno, Requerimientos, etc.).

Beneficios de Identificar Causas Raíz

• Reducción del costo de retrabajo: Detectar y corregir defectos en etapas tempranas es mucho más barato que hacerlo en producción o después del lanzamiento, reduciendo la cantidad y recurrencia de defectos.
• Menos esfuerzo en soporte y mantenimiento: Al entregar un producto con menos defectos, se reduce el tiempo y los recursos dedicados a corregir problemas en operación.

Costos Ocultos de la No Calidad

Los costos ocultos de la No Calidad se refieren a los gastos indirectos que surgen cuando un producto o servicio no cumple con los estándares de calidad esperados.

• Retrabajo: Cuando se detectan errores en etapas posteriores del desarrollo, se debe volver a realizar trabajo ya hecho, lo que consume tiempo y recursos adicionales.
• Pérdida de clientes: La insatisfacción por un producto defectuoso puede llevar a la pérdida de clientes, lo que implica costos adicionales para atraer nuevos.
• Impacto en la reputación: Problemas recurrentes de calidad pueden dañar la reputación de la empresa, lo que afecta su capacidad para atraer nuevos negocios.

Tipos de Pruebas de Software

• Pruebas unitarias: Verifican que cada función individual del código funcione correctamente de forma aislada.
• Pruebas de integración: Verifican que los módulos del sistema interactúan correctamente entre sí.
• Pruebas de sistema: Verifican que el sistema completo cumpla con los requerimientos definidos.
• Pruebas de aceptación: Validan que el sistema satisface las necesidades del usuario final y puede ponerse en producción.