A un toque de distancia

Resumen de la reunión, Standup del Proyecto Phoenix

Estado:

• API de pagos: Completa, en QA
• Servicio de notificaciones: 80% completado, bloqueado por problema de límite de velocidad del proveedor
• Texto de bienvenida: Pendiente de Marketing, fecha límite el jueves

Decisiones clave:

• Lanzar solo con notificaciones por correo; push pasa a actualización rápida en la primera semana
• Entrega del texto para el jueves; las cadenas de tooltips restantes pueden esperar hasta después del lanzamiento

Temas pendientes:

• Discrepancia en el límite de velocidad del proveedor (la documentación dice 100 sol/min, el real es 60)
• Si no hay respuesta del proveedor para mañana, implementar una cola de solicitudes (~1 día)

Riesgo: Posible retraso de un día en la cola de notificaciones, pero no está en la ruta crítica del lanzamiento.

"Suena como un plan sólido. Confirmemos las prioridades: solo notificaciones por correo para el lanzamiento, push como actualización rápida en la primera semana, y texto a diseño para el jueves. Speaker 3, si no tienes respuesta del proveedor para mañana al final del día, adelante con la cola, mejor tenerla lista que esperar. Enviaré un correo resumen después de esto para que todos lo tengan por escrito."

Elementos de acción:

Resultados de verificación:

Posible inconsistencia: Speaker 3 dice que la documentación del proveedor indica 100 solicitudes/minuto pero los están limitando a 60. Esta es una discrepancia del 40%, vale la pena verificar si están leyendo la documentación del nivel correcto (algunas APIs tienen límites diferentes para entornos sandbox vs producción).

Verificación de cronograma: Speaker 5 se comprometió a entregar el jueves, pero Speaker 4 dijo que necesita "al menos dos días para pulir." Si el texto llega al final del día jueves, los dos días se extenderían al lunes, una semana antes de la fecha límite de lanzamiento de dos semanas. Factible pero sin margen de error.

No se detectaron conflictos entre el plan de lanzamiento solo con correo de Speaker 2 y el cronograma establecido.

Cuestionando tres decisiones:

1. "Las notificaciones push no están en la ruta crítica"

¿Estamos seguros de esto? Si el flujo de bienvenida menciona notificaciones push, o si los primeros usuarios las esperan, lanzar sin ellas crea una mala primera impresión. ¿Alguien ha verificado si el texto de bienvenida hace referencia a push?

2. "Proceder con la cola si no hay respuesta para mañana"

Una cola de solicitudes personalizada agrega complejidad operativa que permanece en el código para siempre. Antes de construirla, ¿ha intentado Speaker 3: (a) verificar si sandbox y producción tienen límites de velocidad diferentes, o (b) contactar al proveedor por un canal más rápido que un ticket de soporte?

3. "Las cadenas de tooltips restantes pueden esperar hasta después del lanzamiento"

¿Qué pasa cuando un usuario encuentra un tooltip con texto provisional o faltante? Si alguno de esos tooltips post-lanzamiento está en rutas comunes del usuario, esto crea una experiencia deficiente justo cuando las primeras impresiones importan más.