Sprint 2 ‐ Entregable
Wiki de Documentación
-
Descripción del Producto:
- Plataforma web para la gestión de capacidad y presupuestos de Equipos de Valor Continuo en Bancolombia Panamá.
- Módulos: Gestión de Proveedores, EVCs, Asignación Presupuestal, Documental y Analítica.
-
Avance de Funcionalidad Comprometida:
- Proveedores
- EVCs
- Asignación presupuestal
- Gestión documental
- Dashboards y notificaciones
-
Notas de cambios:
- Actualización de modelo de datos
Se modificó el modelo de datos, en la parte de provider, se reemplazaron las tablas category_provider, role_provider, category_role, role y country por los atributos category, role, line, role y country respectivamente por conveniencia de las funcionalidades ya implementadas y por la sencillez de manejo. Además de eso se incluyó la funcionalidad company para tener información del proveedor que proporciona los servicios a las EVC.
-
Sprint 2:
-
HU completadas:
- HU-022: Dashboard ampliado con métricas del sistema (#68)
- HU-010: Organización jerárquica de los grupos de personal (#48)
- HU-016: Permitir que el administrador cambie el estado de una EVC de "Activa" a "Inactiva" (#50)
- HU-017: Implementación de un sistema de notificaciones (#64)
- HU-020: Lectura de documentos con OCR para registro de presupuesto (#66)
- HU-023: Gestión de roles y autenticación de usuarios (#69)
- HU-040: Reestructuración de la base de datos en PostgreSQL (#106)
- HU-035: Gestionar los documentos en la nube (#105)
-
HU pendientes para seguir trabajando en Sprint 3:
- HU-024: Desarrollo inicial del módulo de asignación presupuestal (#70)
- HU-021: Generación de alertas (#67)
- HU-015: Agregar fechas de inicio y fin a la contratación de roles de proveedores (#49)
-
- Reunión #1 - Planeación Sprint 2: Link a grabación
La reunión se centró en organizar las actividades pendientes y planificar el trabajo de los siguientes sprints. Se revisaron los avances respecto a las tareas de Sprint 2, especialmente la integración de la base de datos y la estructura del frontend. Se acordó corregir malas prácticas detectadas en el código, dividir mejor la lógica de frontend, y normalizar el acceso a la base de datos mediante archivos de entorno. También se discutió sobre la necesidad de tener una versión funcional desplegada para pruebas, aunque inicialmente sea en un hosting sencillo como Vercel. Se asignaron tareas específicas para organizar la gestión de EVCs, generación de alertas presupuestales, creación de roles de usuario y ampliación del dashboard de métricas. Se destacó la importancia de trabajar de forma ordenada para no repetir los problemas de retrasos del sprint anterior.
- ¿Cómo integrar correctamente la base de datos de David con la estructura de Juan?
- ¿Quién se encargará de arreglar la conexión centralizada a la base de datos usando variables de entorno (.env)?
- ¿Cómo se organizarán los roles y las autenticaciones de usuarios en el sistema?
- ¿Se debe implementar notificaciones por correo electrónico o es suficiente con alertas internas en la plataforma?
- ¿Qué tareas específicas asumirá cada integrante para este nuevo sprint?
- ¿Cómo mejorar la estructura del frontend para separar lógicas y optimizar la calidad del código?
- ¿Cómo organizar la creación, actualización y eliminación de EVCs asegurando las reglas de negocio?
- ¿Es necesario desplegar una versión de prueba del sistema antes de finalizar el Sprint 2?
- ¿Qué prioridad tienen las tareas relacionadas con la generación de alertas de gasto presupuestal?
- ¿Cuándo y cómo se realizarán los reportes de avance semanales dentro del equipo?
- Reunión #2 - Seguimiento Sprint 2 con Andrés: Link a grabación
La reunión se enfocó en revisar y ajustar el Acuerdo de Voluntades entre el equipo de estudiantes y Bancolombia Panamá. Se discutieron los temas legales relacionados con la entrega del proyecto, aclarando que el área jurídica de Bancolombia requiere que todo quede explícito para evitar riesgos jurídicos futuros. Se acordó que los estudiantes podrán certificar su participación en el proyecto para fortalecer sus hojas de vida, y que Bancolombia reconocerá esta experiencia. Además, se dejó claro que la propiedad intelectual (código y solución) será entregada completamente al banco, respetando los derechos de autor en favor de Bancolombia.
- ¿Cómo debe quedar registrado el compromiso de Bancolombia respecto a la certificación de la experiencia de los estudiantes?
- ¿Qué nivel de propiedad intelectual sobre el código y la solución se entregará a Bancolombia?
- ¿Cómo debe registrarse formalmente la entrega de los recursos y productos del proyecto?
- ¿Qué condiciones deben quedar claras sobre la provisión de recursos y apoyo de la empresa?
- ¿Puede realizarse la entrega final de manera presencial en las oficinas del banco? ¿Qué logística se debe organizar?
- ¿Qué protocolos se deben seguir para garantizar la confidencialidad de la información manejada durante el proyecto?
- ¿Qué sucede en caso de conflictos o desacuerdos durante el proyecto y cómo se resolverían?
- Reunión #3 - Reunión Avances y Pendientes : Link a grabación
La reunión tuvo como objetivo definir el mínimo necesario para la creación de EVCs (Equipos de Valor Continuo) en la plataforma. Se acordó que el único campo obligatorio será el nombre de la EVC, permitiendo que otros campos como líder técnico, entorno y proyecto sean opcionales para facilitar la creación rápida y posterior edición de los registros. Además, se discutió la estructura de las notificaciones internas del sistema: se buscará alertar sobre asignaciones inusuales de costos (por ejemplo, proveedores que superen en 30% el promedio) y sobre eventos importantes como la creación de roles incompletos o documentos pendientes. También se planteó la necesidad de mejorar la manera de registrar gastos a partir de facturas, implementando OCR para extraer el valor automáticamente y así poder calcular el porcentaje de gasto frente al presupuesto asignado. Finalmente, se hizo énfasis en mejorar la comunicación del equipo mediante resúmenes o videos cortos en lugar de largas cadenas de mensajes, y en la importancia de concentrar los esfuerzos en terminar notificaciones y la gestión de gastos antes de la fecha límite.
- ¿Qué campos deben ser obligatorios al momento de crear una nueva EVC?
- ¿Cómo permitir flexibilidad en la creación y posterior edición de la información de EVCs?
- ¿Qué tipo de notificaciones debe implementar el sistema para alertar eventos críticos?
- ¿Cómo detectar cuando un proveedor asignado supera el 30% del costo promedio y generar una alerta?
- ¿Cómo registrar gastos de manera sencilla extrayendo automáticamente valores de facturas?
- ¿Cómo mejorar la comunicación del equipo para evitar saturar los canales de mensajería?
- ¿Qué tareas son prioritarias para finalizar antes de la entrega (notificaciones y gestión de gastos)?
- ¿Cómo organizar el trabajo pendiente de documentación y plan de negocios una vez terminada la parte funcional?
-
Casos de prueba diseñados y ejecutados:
- Se plantearon y diseñaron casos de prueba para la mayoría de historias de usuario, únicamente excluyendo por ahora las no funcionales.
- Los Test Cases tienen todos una HU relacionada, con casos donde se prueban escenarios diferentes de una misma HU. Ejemplo: registro con campos vacíos, registro exitoso, etc.
- Los Test Cases pueden estar en uno de 4 estados: en construcción, ejecución parcial, fallido y exitoso.
- Todo definido a detalle en el tablero: Finup testing
- En el detalle de cada item se ven tanto el resultado esperado como el obtenido en caso de ya haber sido ejecutados, los bugs asociados y comentarios relevantes.
La estrategia de marketing de FinUp, desarrollada por Bancoders, se enfoca en posicionar la herramienta como una solución clave para organizaciones que gestionan recursos en estructuras por proyectos. Las acciones están orientadas a reducir el riesgo operativo y aumentar la eficiencia financiera mediante predicciones inteligentes sobre asignación presupuestaria.
Acciones estratégicas clave:
-
Participación en ferias del sector: Presentación del producto en eventos de innovación, tecnología y gestión empresarial, con demostraciones en vivo y contacto directo con potenciales clientes.
-
Marketing digital profesional: Campañas segmentadas en plataformas como LinkedIn y Google Ads dirigidas a CFOs, contadores, gerentes de proyectos y fundadores de startups.
-
Contenido de valor: Creación de artículos técnicos y videos explicativos sobre gestión de presupuesto y capacidad, alojados en un blog corporativo y difundidos por redes profesionales.
-
Versión gratuita limitada: Permite a usuarios nuevos explorar las funcionalidades esenciales de FinUp con un límite en el número de EVCs, proveedores y módulos avanzados, fomentando la adopción temprana.
-
Programa de referidos: Incentivos para usuarios que recomienden la plataforma a otros profesionales o empresas.
-
Networking selectivo: Identificación y contacto con decisores en espacios donde suelen reunirse (cafeterías, eventos ejecutivos), apoyados por material visual y discursos breves de impacto.
El modelo de ventas de FinUp está centrado en la distribución directa bajo un enfoque SaaS (Software como Servicio), eliminando barreras de instalación y facilitando la escalabilidad:
-
Plataforma web autoasistida: Acceso inmediato al producto desde el sitio oficial, con onboarding asistido y documentación clara.
-
Demostraciones personalizadas: Coordinación de sesiones virtuales para empresas interesadas, presentando los beneficios de automatizar la gestión presupuestal y de capacidad.
-
Equipo de soporte técnico y atención al cliente: Resolución de incidencias, acompañamiento en la integración y capacitación inicial.
-
Estrategia de distribución 100% digital: Evita intermediarios para mantener bajos costos operativos y mayor control del proceso comercial.
La propuesta de precios de FinUp busca equilibrar accesibilidad inicial con escalabilidad para organizaciones de mayor tamaño o madurez:
Versión gratuita limitada:
-
Hasta 3 EVCs
-
1 entorno
-
2 colaboradores por EVC
-
Registro de hasta 15 proveedores
-
Acceso básico a alertas, sin visualización de etiquetas ni uso del módulo de predicciones.
-
Plan profesional: A partir de USD $500 mensuales, habilitando módulos completos de análisis predictivo, tags con insights sobre comportamiento presupuestal, múltiples entornos y más capacidad operativa.
-
Modelo de suscripción mensual: Permite a las empresas ajustar su inversión según crecimiento, manteniendo costos predecibles.
Benchmarking competitivo:
A diferencia de Tickelia o Suite Office/Google, FinUp ofrece integración nativa de alertas y sugerencias con base en modelos predictivos.
Frente a Prophix y Workday Adaptive Planning, FinUp destaca por su enfoque especializado en la gestión de proveedores y capacidad dentro de estructuras por proyecto, lo que mejora la toma de decisiones en tiempo real.
📋 Costos asociados:
| Concepto | Costo Estimado (USD) |
|---|---|
| Participación en ferias | $2,500 - $4,000 USD |
| Producción de contenido | $1,000 USD |
| Diseño y branding | $500 USD |
| Página web corporativa | $1,500 - $2,000 USD |
| Total inicial | $5,500 - $7,500 USD |
El presupuesto pre-operacional fue construido considerando el contexto real del proyecto para Bancolombia Panamá, contemplando dos tipos de aportes: los propios del equipo emprendedor, que incluyen la provisión de equipos periféricos, materiales de apoyo y transporte local; y los recursos que asumiría el cliente, como la contratación del equipo de desarrollo, infraestructura cloud, licencias de software, dominio, seguridad informática y registro de propiedad intelectual. Para su cálculo, se estimó un pago mensual de 500USD por persona durante cuatro meses, se consolidaron las licencias necesarias en un paquete económico de 250 USD, y se dimensionó la infraestructura y medidas de seguridad de acuerdo con los requerimientos básicos para un MVP bancario. Se realizaron ajustes responsables para mantener el presupuesto realista pero profesional, garantizando la viabilidad económica de la solución en un entorno académico-aplicado.
- Tabla de Rubros:
| RUBROS | Propio (equipo emprendedor) | Otras fuentes (Cliente: Bancolombia Panamá) | TOTAL (USD) |
|---|---|---|---|
| PERSONAL (500 USD por persona mensual durante 4 meses) | 0 USD | 8,000 USD | 8,000 USD |
| EQUIPOS: Monitores, teclados, mouse adicionales | 600 USD | 0 USD | 600 USD |
| SOFTWARE: Licencias básicas y Pro (Copilot, Figma Pro, Slack, Trello Business) | 0 USD | 250 USD | 250 USD |
| INFRAESTRUCTURA CLOUD: Hosting: servidores EC2/GCP (instancia pequeña) | 0 USD | 800 USD | 800 USD |
| INFRAESTRUCTURA CLOUD: Base de datos administrada (AWS RDS/GCP CloudSQL) | 0 USD | 500 USD | 500 USD |
| INFRAESTRUCTURA CLOUD: Bucket de almacenamiento (S3/GCP Storage) | 0 USD | 300 USD | 300 USD |
| DOMINIO Y SEGURIDAD: Dominio web + certificado SSL extendido | 0 USD | 150 USD | 150 USD |
| MATERIALES DE APOYO: Papelería e impresiones de manuales | 20 USD | 0 USD | 20 USD |
| TRANSPORTE: Reuniones presenciales | 40 USD | 0 USD | 40 USD |
| MATERIAL BIBLIOGRÁFICO: Documentación gratuita online | 0 USD | 0 USD | 0 USD |
| REGISTRO Y PUBLICACIONES: Registro de propiedad intelectual | 0 USD | 200 USD | 200 USD |
| SERVICIOS TÉCNICOS: Auditoría de seguridad (pentesting básico) | 0 USD | 300 USD | 300 USD |
| SERVICIOS TÉCNICOS: Configuración inicial cloud y backups | 0 USD | 180 USD | 180 USD |
| MARKETING: Participación en ferias, branding, producción de contenido, página web corporativa | 0 USD | 6,500 USD | 6,500 USD |
| TOTAL | 660 USD | 17,180 USD | 17,840 USD |
-
Costos Fijos:
| Rubro | Valor mensual (USD) |
|---|---|
| Hosting servidores (instancia EC2 o GCP pequeña) | 200 USD |
| Base de datos administrada (AWS RDS o GCP CloudSQL) | 80 USD |
| Bucket de almacenamiento de documentos (S3/GCP Storage) | 20 USD |
| Dominio web + renovación de certificado SSL | 10 USD |
| Mantenimiento mínimo de infraestructura (actualizaciones, parches de seguridad) | 50 USD |
| Monitoreo básico de servidores (CloudWatch, etc.) | 40 USD |
| TOTAL COSTOS FIJOS | 400 USD |
-
Costos Variables:
| Rubro | Valor por cliente o unidad (USD) |
|---|---|
| OCR y procesamiento de documentos adicionales (por cliente activo) | 10 USD |
| Soporte técnico adicional (por cliente que solicite ayuda personalizada) | 15 USD |
| Consumo adicional de almacenamiento (por cliente) | 5 USD |
El producto desarrollado es una plataforma web de gestión presupuestaria y de capacidad para Bancolombia Panamá, diseñada para optimizar la carga de datos, el análisis de asignaciones presupuestarias y el control de gastos de Equipos de Valor Continuo (EVC).
Incluye módulos de:
- Registro de proveedores y costos.
- Gestión de equipos EVC.
- Asignación presupuestaria con control de gasto.
- Dashboards de análisis y alertas automáticas.
- Gestión documental con integración OCR.
La solución es exclusiva para el cliente y su implementación busca reemplazar procesos manuales basados en hojas de cálculo.
Durante el primer año, se proyecta la operación con un único cliente activo, Bancolombia Panamá, al ser un producto de desarrollo personalizado.
| Mes | Clientes Activos | Ventas (USD) |
|---|---|---|
| 1 a 12 | 1 | 500 USD mensuales |
Se estima una facturación mensual de 500 USD, generando 6,000 USD de ingresos al final del primer año.
| Mes | Clientes | Ingresos (USD) | Costos Fijos (USD) | Costos Variables (USD) | Egresos Totales (USD) | Utilidad Neta (USD) |
|---|---|---|---|---|---|---|
| 1 | 1 | 500 | 400 | 30 | 430 | 70 |
| 2 | 1 | 500 | 400 | 30 | 430 | 70 |
| 3 | 1 | 500 | 400 | 30 | 430 | 70 |
| 4 | 1 | 500 | 400 | 30 | 430 | 70 |
| 5 | 1 | 500 | 400 | 30 | 430 | 70 |
| 6 | 1 | 500 | 400 | 30 | 430 | 70 |
| 7 | 1 | 500 | 400 | 30 | 430 | 70 |
| 8 | 1 | 500 | 400 | 30 | 430 | 70 |
| 9 | 1 | 500 | 400 | 30 | 430 | 70 |
| 10 | 1 | 500 | 400 | 30 | 430 | 70 |
| 11 | 1 | 500 | 400 | 30 | 430 | 70 |
| 12 | 1 | 500 | 400 | 30 | 430 | 70 |
| Total Anual | - | 6,000 | 4,800 | 360 | 5,160 | 840 |
✅ Ingresos Totales: 6,000 USD
✅ Egresos Totales: 5,160 USD
✅ Utilidad Neta Proyectada: 840 USD
📋 Balance Acumulado Mensual
| Mes | Utilidad Mensual (USD) | Balance Acumulado (USD) |
|---|---|---|
| 1 | 70 | 70 |
| 2 | 70 | 140 |
| 3 | 70 | 210 |
| 4 | 70 | 280 |
| 5 | 70 | 350 |
| 6 | 70 | 420 |
| 7 | 70 | 490 |
| 8 | 70 | 560 |
| 9 | 70 | 630 |
| 10 | 70 | 700 |
| 11 | 70 | 770 |
| 12 | 70 | 840 |
✅ El punto de equilibrio se alcanza desde el primer mes, dado que los ingresos superan a los egresos en 70 USD mensuales.
✅ El balance acumulado refleja un crecimiento lineal hasta alcanzar 840 USD de utilidad neta al finalizar el año.
Se presenta a continuación la evolución gráfica de los Ingresos, Egresos y Balance Acumulado a lo largo del año.
Definido en la página de la wiki: Protocolo de pruebas de usabilidad
- Estrategia de automatización:
| Funcionalidad | Tipo de prueba | Justificación |
|---|---|---|
| Historias de usuario, por el momento solo las funcionales | De integración y funcionales | Se automatizó mediante GitHub Actions el directorio tests del frontend, a fin de llevar un seguimiento del cumplimiento de la funcionalidad de cada HU a medida que se avanza en el desarrollo, en este directorio se encuentran pruebas tanto funcionales como de integración que simulan ingresos de datos de usuarios y demás |
-
Tipos de pruebas: Tanto funcionales como de integración.
-
Integración:
- Estamos probando la interacción entre múltiples componentes (backend, DB)
- Verifican la integración con servicios externos (APIs)
- Validan el flujo completo de datos desde la UI hasta el backend
-
Funcionales:
- Validan el comportamiento desde la perspectiva del usuario
- Verifican que la aplicación funcione como se espera en situaciones reales
-
Integración:
-
Herramientas:
- Jest: Usado en la mayor parte del testing y totalmente para el testing automático.
- Pytest: Usado en algunos archivos de prueba durante el desarrollo a modo de apoyo y verificación del funcionamiento de componentes del backend.
-
Consideraciones de la automatización:
- Cada vez que se hace un Pull Request o push a las rama dev o main se ejecuta el workflow que corre el comando que ejecuta todas las suites de tests de Jest
- Entre estos tests están incluidos algunos cuantos que se encuentran en ejecución parcial, es decir, que darán errores porque falta especificar ciertos parámetros y siguen bajo construcción.
- Por estos motivos se deja que se haga el merge a la rama aunque fallen los tests, pero a cambio, se deja un log en el workflow a modo de reporte para que en caso de que se fallen los tests se lleve trazabilidad de ello y se repare la funcionalidad, con la posibilidad de correr los tests localmente antes de hacer el push, permitiendo de este modo un flujo orgánico del manejo de funcionalidades.
- Se implementó en el workflow la funcionalidad de mostrar la cobertura (coverage) de los tests sobre el código, esta se actualiza con cada ejecución del workflow y se puede consultar en la página Actions, donde se muestra el historial de ejecuciones, se ingresa a la deseada y bajando hasta el apartado de Artifacts, se puede ver el elemento coverage-report, si lo clickeamos se descarga una carpeta comprimida, donde si entramos a: coverage-report.zip\lcov-report y abrimos el archivo index.html podremos ver el reporte detallado de la cobertura de los tests.
- Por último, se genera un reporte y comentarios en la ejecución del workflow abordando los tests que se pasaron y los que fallaron.
- De este modo, cada vez que alguien hace un push a la rama remota de su funcionalidad y abre un Pull Request, GitHub automáticamente corre los workflows y hace todas las validaciones para verificar si el merge se hace en condiciones óptimas, con todos los workflows pasados sin errores y sin conflictos.
- Adicionalmente fuera del testing como tal, tenemos un workflow auxiliar que se ejecuta bajo las mismas circunstancias y es encargado de formatear el código para cumplir con las reglas de programación definidas al inicio, además de detectar errores no fatales como declaraciones no referenciadas, etc. A fin de mantener un código limpio y trazable.