Proyecto 2
Fase 1: Recolección de la información
1.1 Justificación de Negocios Seleccionados
Negocios elegidos
Se seleccionaron dos negocios del mismo rubro: una vidriería y un taller de herrería, ambos negocios pequeños donde fue posible hablar directamente con el dueño o encargado.
¿Por qué estos negocios?
Se eligieron estos negocios porque:
- Son negocios pequeños y medianos accesibles para entrevistar
- El dueño o encargado estaba disponible para atendernos
- Ambos manejan procesos manuales con oportunidades claras de mejora tecnológica
- Pertenecen al mismo tipo de negocio: fabricación y venta de productos metálicos y de vidrio
Decisión sobre la información
Se decidió trabajar con ambos negocios de forma separada ya que cada uno presentó problemáticas distintas que enriquecen el análisis y permiten proponer soluciones más completas.
1.2 Evidencias de Entrevistas
Negocio 1 — Vidriería
Audio de la entrevista:
Descripción: Audio de la entrevista realizada el [12/04/2026] al dueño de la vidriería [Vidreria La Bendición], ubicada en [Zona 1, Ciudad de Guatemala]. Entrevistadores: [Cesar Emmanuel Cipriano López y Diego Enrique Flores Ruíz].
Negocio 2 — Taller de Herrería
Audio de la entrevista:
Descripción: Audio de la entrevista realizada el [12/04/2026] al dueño del taller de herrería [Herreria El Rey], ubicada en [Departamento de Sacatepéquez, Sumpango]. Entrevistadores: [Wagner Maximiliano Ley Monroy, Daniel Estuardo Chicoj Bolaños y Diego Rene Estrada Júarez].
1.3 Preguntas de Entrevista
Negocio 1 — Vidriería
Sobre la Operación Diaria
- ¿Cómo es un día normal de trabajo desde que abre hasta que cierra?
- ¿Qué tareas siente que hace una y otra vez durante el día?
- ¿En qué actividades siente que se le va el tiempo sin avanzar mucho?
Sobre los Puntos de Dolor
- ¿Qué es lo que más le cuesta manejar o controlar actualmente?
- ¿Qué errores ocurren con más frecuencia en su proceso de trabajo?
- Si tuviera una varita mágica, ¿qué parte de su trabajo diario mejoraría hoy mismo?
Sobre la Relación con el Cliente
- ¿Cómo es el proceso desde que un cliente llega hasta que se va con su vitrina?
- ¿Qué registros guarda de sus ventas o clientes? ¿Son manuales, mentales o digitales?
Preguntas de Especialidad
- ¿Cómo maneja los pedidos personalizados?
- ¿Cómo controla los materiales que usa como el vidrio y el aluminio?
- Cuando un trabajo está en proceso, ¿cómo sabe en qué etapa va cada pedido?
- ¿Ha tenido casos donde entregó un trabajo tarde o con errores?
Negocio 2 — Taller de Herrería
Sobre la Operación Diaria
- ¿Cómo es un día normal de trabajo desde que abre hasta que cierra?
- ¿Qué tareas siente que hace una y otra vez durante el día?
- ¿En qué actividades siente que se le va el tiempo sin avanzar mucho?
Sobre los Puntos de Dolor
- ¿Qué es lo que más le cuesta manejar o controlar actualmente en su taller?
- ¿Qué errores ocurren con más frecuencia en su proceso de trabajo?
- Si tuviera una varita mágica, ¿qué parte de su trabajo diario mejoraría hoy mismo?
Sobre la Relación con el Cliente
- ¿Cómo es el proceso desde que un cliente llega a pedir un trabajo hasta que se lo entrega?
- ¿Qué registros guarda de sus trabajos o clientes? ¿Son manuales, mentales o digitales?
Preguntas de Especialidad
- ¿Cómo maneja los pedidos? ¿Anota las medidas y el precio acordado en algún lugar?
- ¿Cómo controla los materiales como el hierro y las varillas?
- Cuando tiene varios trabajos al mismo tiempo, ¿cómo organiza cuál hacer primero?
- ¿Ha tenido situaciones donde le faltó material a mitad de un trabajo?
Fase 2: Analisis
2.1 Flujo de negocios
A continuación se presentan las dos etapas principales del proceso:
Diagrama 1 — Captación de clientes
Figura 1. Proceso de captación desde el primer contacto hasta la conversión.
Diagrama 2 — Entrega y posventa
Figura 2. Etapas de entrega del producto o servicio y seguimiento posventa.
2.2 Requisitos Identificados
Negocio 1 — Vidriería
| ID | Descripción |
|---|---|
| RQ-01 | El sistema debe permitir registrar los datos básicos de cada cliente, como nombre, teléfono y dirección. |
| RQ-02 | El sistema debe permitir consultar el historial de pedidos de cada cliente de forma rápida. |
| RQ-03 | El sistema debe registrar cada pedido nuevo con el nombre del cliente, descripción del trabajo y fecha de entrega acordada. |
| RQ-04 | El sistema debe permitir ver qué pedidos están pendientes, en proceso y entregados. |
| RQ-05 | El sistema debe centralizar la información que actualmente se maneja entre cuadernos, hojas sueltas y memoria, en un solo lugar. |
| RQ-06 | El sistema debe ser sencillo de usar, sin necesidad de conocimientos técnicos avanzados. |
| RQ-07 | El sistema debe poder usarse desde un teléfono o computadora. |
Negocio 2 — Taller de Herrería
| ID | Descripción |
|---|---|
| RQ-08 | El sistema debe permitir registrar el inventario de materiales como hierro, varillas y electrodo. |
| RQ-09 | El sistema debe alertar cuando un material esté por agotarse. |
| RQ-10 | El sistema debe registrar cada pedido con medidas, tipo de material, precio acordado y fecha de entrega. |
| RQ-11 | El sistema debe mostrar el estado de cada trabajo: pendiente, en proceso o listo. |
| RQ-12 | El sistema debe permitir consultar todos los trabajos activos en un solo lugar. |
| RQ-13 | El sistema debe ser accesible desde un teléfono o computadora. |
Fase 3: Propuesta
3.1 Acuerdos Trade-offs
Durante la negociación se identificaron y aceptaron explícitamente los siguientes cuatro trade-offs:
Trade-off 1: Tiempo vs. Calidad
Decisión: Se eligió un tiempo de entrega de 4 semanas en lugar de las 6 semanas que propuso inicialmente el Tech Lead.
Consecuencia aceptada: La arquitectura será funcional pero no perfectamente escalable. Si en el futuro el negocio crece mucho, puede que necesitemos reestructurar partes del sistema. Para el volumen actual de negocio, la solución es suficiente.
"Estamos eligiendo cuatro semanas en lugar de seis. Eso significa que la arquitectura va a ser funcional pero no perfectamente escalable." — Tech Lead
Trade-off 2: Alcance vs. Tiempo
Decisión: Se dejaron fuera de la primera fase el módulo de reportes financieros y el módulo de control de garantías para poder cumplir con las cuatro semanas.
Consecuencia aceptada: El cliente no tendrá visibilidad completa de sus ganancias ni control de garantías desde el inicio. Estos requerimientos quedan documentados para una segunda fase.
"Estamos dejando fuera el módulo de reportes financieros y el de garantías para cumplir con las cuatro semanas. Eso significa que el cliente no va a tener visibilidad completa de sus ganancias desde el inicio." — QA / Auditor
Trade-off 3: Funcionalidad vs. Simplicidad
Decisión: Para que el sistema sea fácil de usar para alguien sin experiencia técnica, se simplificaron algunas funciones.
Consecuencia aceptada: Los reportes van a ser básicos, sin gráficas complejas ni análisis avanzados. Solo listas y totales simples, priorizando la claridad y facilidad de uso sobre la profundidad analítica.
"Los reportes van a ser básicos, sin gráficas complejas ni análisis avanzados. Solo listas y totales simples." — Desarrollador
Trade-off 4: Control de datos vs. Velocidad de desarrollo
Decisión: Se utilizó Firebase como base de datos en la nube en lugar de implementar un servidor propio del cliente.
Consecuencia aceptada: Los datos van a estar alojados en servidores de Google (Firebase) y no en una infraestructura controlada directamente por el cliente. A cambio, se reduce significativamente el tiempo de desarrollo y se obtienen respaldos automáticos.
"Estamos usando Firebase como base de datos porque reduce el tiempo de desarrollo, pero eso significa que los datos van a estar en servidores de Google y no en un servidor propio del cliente." — QA / Auditor
Resumen
| # | Trade-off | Decisión | Consecuencia |
|---|---|---|---|
| 1 | Tiempo vs. Calidad | 4 semanas (vs 6) | Arquitectura funcional pero no perfectamente escalable |
| 2 | Alcance vs. Tiempo | Excluir garantías y reportes | Cliente sin visibilidad de ganancias en fase 1 |
| 3 | Funcionalidad vs. Simplicidad | Reportes básicos | Sin gráficas ni análisis avanzados |
| 4 | Control vs. Velocidad | Firebase (nube) | Datos en servidores de Google |
3.2 Documento Post-Mortem
Resumen del incidente
El día de la implementación del sistema web de gestión para la vidriería, el servidor dejó de responder luego de que el dueño intentó registrar varios clientes al mismo tiempo. Esto provocó la pérdida de datos ingresados durante esa sesión y dejó el sistema inaccesible por varias horas. El incidente ocurrió el primer día de uso real del sistema afectando directamente la operación del negocio.
Línea de tiempo
| Hora | Evento |
|---|---|
| 08:00 AM | El dueño comienza a usar el sistema por primera vez |
| 08:30 AM | Se registran los primeros 5 clientes sin problemas |
| 09:00 AM | El dueño intenta registrar 10 clientes seguidos rápidamente |
| 09:05 AM | El sistema comienza a responder lento |
| 09:10 AM | El servidor deja de responder completamente |
| 09:15 AM | El equipo recibe aviso del problema |
| 09:30 AM | Se identifica que el servidor se saturó por múltiples peticiones simultáneas |
| 10:00 AM | Se reinicia el servidor manualmente |
| 10:15 AM | El sistema vuelve a estar disponible pero sin los datos ingresados desde las 08:30 AM |
| 11:00 AM | Se confirma que el backup automático no estaba configurado correctamente |
Impacto
Usuarios afectados:
- El dueño de la vidriería perdió los datos de 5 clientes que había ingresado
- Los clientes cuyos datos se perdieron tuvieron que ser contactados nuevamente para reingresarlos
Efectos directos:
- Pérdida de datos de clientes ingresados durante la sesión
- Sistema inaccesible durante aproximadamente 1 hora
- Desconfianza del dueño hacia el sistema
Efectos indirectos:
- Retraso en la operación normal del negocio
- Tiempo adicional del equipo para resolver el incidente
- El dueño consideró volver a usar su método manual
Causa raíz
Se aplicó la técnica de los 5 porqués:
¿Por qué se cayó el sistema? Porque el servidor se saturó con múltiples peticiones simultáneas.
¿Por qué se saturó el servidor? Porque no se configuró un límite de peticiones por usuario.
¿Por qué no se configuró ese límite? Porque durante el desarrollo no se realizaron pruebas de carga ni de estrés al sistema.
¿Por qué no se hicieron pruebas de carga? Porque el equipo priorizó entregar el sistema rápido y no planificó una fase de pruebas adecuada.
¿Por qué no se planificó una fase de pruebas? Porque no se consideró que un usuario sin experiencia técnica podría usar el sistema de forma intensiva desde el primer día.
Causa raíz identificada: La falta de pruebas de rendimiento y la ausencia de configuración correcta del backup automático antes de poner el sistema en producción.
Acciones tomadas para solucionarlo
| Acción | Responsable | Resultado |
|---|---|---|
| Reinicio manual del servidor | Desarrollador | Sistema disponible nuevamente |
| Revisión de configuración del backup | Tech Lead | Se identificó que el backup no estaba activo |
| Activación manual del backup | Desarrollador | Backup configurado correctamente |
| Reingreso manual de datos perdidos | QA / Auditor | Datos recuperados con ayuda del dueño |
| Comunicación al dueño del negocio | Scrum Master | El dueño fue informado y tranquilizado |
Acciones a futuro
| Acción | Descripción |
|---|---|
| Pruebas de carga | Realizar pruebas de rendimiento antes de entregar el sistema |
| Backup automático | Verificar que el backup esté activo antes de poner en producción |
| Límite de peticiones | Configurar un límite de peticiones por usuario para evitar saturación |
| Manual de usuario | Crear una guía simple para que el dueño use el sistema correctamente |
| Monitoreo del servidor | Implementar alertas automáticas cuando el servidor esté al límite |
| Fase de pruebas | Incluir una semana de pruebas con el usuario antes de la entrega final |
3.3 Elevator Pitch
Integrante 1 — Vidriería: Control de Clientes
Integrante 2 — Vidriería: Pedidos Desorganizados
Integrante 3 — Vidriería: No sabe cuánto gana o pierde
Integrante 4 — Herrería: Control de Materiales
Integrante 5 — Herrería: Entregas Tardías
Integrante 6 — Herrería: Registro de Pedidos
3.4 Issues
Bug: El sistema no guarda el cliente si se deja un campo vacío
Tipo
- Bug
Descripción
Al intentar registrar un nuevo cliente en el módulo de gestión, si el usuario deja vacío el campo de teléfono y presiona guardar, el sistema no muestra ningún mensaje de error pero tampoco guarda el registro. El cliente simplemente desaparece sin confirmación ni aviso. Esto es crítico porque el dueño de la vidriería puede creer que guardó la información cuando en realidad se perdió.
Mockup / Imagen
Pasos para reproducir
- Abrir el módulo de clientes
- Hacer clic en "Nuevo cliente"
- Llenar nombre pero dejar teléfono vacío
- Presionar "Guardar"
- Observar que no aparece mensaje de error ni confirmación
Resultado esperado
El sistema debe mostrar un mensaje de error indicando que el campo de teléfono es obligatorio y no debe permitir guardar hasta que se complete.
Comentarios adicionales
Este bug fue identificado durante las pruebas del módulo de clientes. Afecta directamente la confiabilidad del sistema para el dueño de la vidriería.
Alerta visual cuando un material está por agotarse en inventario
Tipo
- Mejora
Descripción
El módulo de inventario muestra la cantidad de cada material pero no avisa cuando alguno está llegando a niveles bajos. Se propone agregar una alerta visual que cambie el color del material a naranja o rojo cuando la cantidad sea menor a un mínimo definido por el dueño. Esto le permitiría saber anticipadamente cuándo comprar material antes de quedarse sin él.
Mockup / Imagen
Pasos para reproducir
- Abrir el módulo de inventario
- Observar que todos los materiales se muestran igual sin importar la cantidad disponible
Resultado esperado
Los materiales con cantidad menor al mínimo configurado deben resaltarse visualmente en color naranja o rojo. Debe aparecer un ícono de advertencia y la opción de definir el nivel mínimo por cada tipo de material.
Comentarios adicionales
Esta mejora resuelve directamente uno de los problemas principales identificados en la entrevista con el taller de herrería: el herrero a veces se queda sin material a mitad de un trabajo porque no lleva control del inventario.
Agregar confirmación antes de eliminar un pedido
Tipo
- Mejora
Descripción
Actualmente el módulo de pedidos permite eliminar un registro con un solo clic sin pedir ninguna confirmación. Esto es peligroso porque el dueño podría eliminar accidentalmente un pedido activo sin darse cuenta. Se propone agregar un diálogo de confirmación que pregunte "¿Está seguro que desea eliminar este pedido?" antes de ejecutar la acción.
Mockup / Imagen
Pasos para reproducir
- Abrir el módulo de pedidos
- Seleccionar cualquier pedido
- Hacer clic en el botón "Eliminar"
- Observar que el pedido se elimina sin confirmación
Resultado esperado
Al hacer clic en "Eliminar", el sistema debe mostrar un diálogo de confirmación. Solo si el usuario confirma, el pedido debe ser eliminado. Si cancela, no debe ocurrir ningún cambio.
Comentarios adicionales
Esta mejora es especialmente importante para usuarios sin experiencia técnica como el dueño de la vidriería, quien podría eliminar datos por error sin posibilidad de recuperarlos.
Nueva funcionalidad: Sistema de estados para pedidos (Pendiente, En proceso, Listo)
Tipo
- Nueva funcionalidad
Descripción
Actualmente los pedidos solo se registran pero no tienen un estado que indique en qué etapa se encuentran. El dueño del taller de herrería necesita saber de un vistazo cuáles pedidos están pendientes, cuáles están siendo trabajados y cuáles ya están listos para entregar. Se propone agregar un sistema de estados con tres opciones: Pendiente, En proceso y Listo.
Mockup / Imagen
Pasos para reproducir
No aplica, es una funcionalidad nueva.
Resultado esperado
Cada pedido debe mostrar su estado actual con un color distintivo. El dueño debe poder cambiar el estado con un solo clic. La vista principal debe permitir filtrar pedidos por estado para ver solo los pendientes o solo los listos.
Comentarios adicionales
Esta funcionalidad fue identificada como prioritaria durante la entrevista con el taller de herrería, donde el dueño mencionó que no sabe en qué etapa va cada trabajo cuando tiene varios al mismo tiempo.
Buscador de clientes por nombre o teléfono
Tipo
- Nueva funcionalidad
Descripción
Actualmente el módulo de clientes solo muestra una lista general de todos los registros. Cuando el negocio tenga muchos clientes, el dueño va a necesitar encontrar a uno específico rápidamente sin tener que desplazarse por toda la lista. Se propone agregar una barra de búsqueda que filtre los clientes en tiempo real por nombre o número de teléfono.
Mockup / Imagen
Pasos para reproducir
No aplica, es una funcionalidad nueva.
Resultado esperado
Al escribir en la barra de búsqueda, la lista de clientes se filtra automáticamente mostrando solo los que coincidan con el texto ingresado. Si no hay resultados, mostrar el mensaje "No se encontraron clientes".
Comentarios adicionales
Esta funcionalidad fue solicitada directamente por el dueño de la vidriería durante la entrevista cuando mencionó que a veces tiene muchos clientes y necesita encontrar uno rápido.
El inventario no se descuenta automáticamente al crear un pedido
Tipo
- Bug
Descripción
Cuando se registra un nuevo pedido en el módulo de pedidos del taller de herrería y se especifica el material a usar, el inventario de materiales no se actualiza automáticamente. El dueño debe ir manualmente al módulo de inventario y descontar el material. Esto genera inconsistencias porque si el dueño olvida actualizar el inventario, puede aceptar trabajos sin el material suficiente para completarlos.
Mockup / Imagen
Pasos para reproducir
- Abrir el módulo de inventario y verificar stock actual
- Crear un nuevo pedido especificando material y cantidad
- Guardar el pedido
- Volver al módulo de inventario
- Observar que el stock no cambió
Resultado esperado
Al guardar un pedido con material especificado, el inventario debe descontarse automáticamente. Si no hay suficiente material, el sistema debe mostrar una alerta antes de guardar.
Comentarios adicionales
Este bug fue identificado como crítico ya que reproduce exactamente el problema que tiene el herrero en la vida real: aceptar trabajos sin saber si tiene material suficiente.
3.5 Flujo de la solución
Descripción general
A partir de los problemas identificados en las entrevistas realizadas a los negocios de vidriería y herrería, se encontró una necesidad crítica común: la ausencia de un sistema organizado para el registro y seguimiento de pedidos. Esto generaba olvido de detalles importantes, pérdida de información de clientes y desconocimiento del estado del inventario de materiales.
Como solución, el equipo propone el desarrollo de una aplicación web responsive accesible desde dispositivos móviles y computadoras de escritorio, respaldada por Firebase (Google) como base de datos en la nube con sincronización en tiempo real.
Diagrama 1 — Arquitectura del sistema
Muestra las cuatro capas del sistema: desde el punto de acceso del usuario hasta el almacenamiento persistente en la nube.
Diagrama 2 — Flujo de registro de un pedido
Muestra paso a paso qué ocurre cuando un usuario registra un nuevo encargo, incluyendo la validación de datos y el guardado en Firebase.
Capas del sistema
Capa 1 — Acceso del usuario
| Dispositivo | Descripción |
|---|---|
| Celular / tablet | Acceso desde el navegador web móvil, sin instalar nada |
| Computadora | Acceso desde el navegador de escritorio o laptop |
Capa 2 — Interfaz web (frontend)
Tres módulos principales accesibles desde el menú de la aplicación:
Módulo: Nuevo pedido
- Formulario: El usuario ingresa nombre del cliente, detalle del encargo, materiales requeridos, fecha de entrega y notas.
- Validación: El sistema verifica que todos los campos obligatorios estén completos antes de guardar. Si falta alguno, muestra una alerta con el campo resaltado.
Módulo: Ver pedidos
- Listado: Muestra todos los pedidos registrados con opciones de búsqueda y ordenamiento por fecha, cliente o estado.
- Detalle: Al seleccionar un pedido se visualizan todos sus datos: estado actual, materiales, notas del encargo.
Módulo: Inventario
- Stock actual: Consulta en tiempo real de materiales disponibles (vidrio, aluminio, hierro, etc.).
- Actualización automática: El stock se descuenta al registrar o cerrar un pedido.
Capa 3 — Backend en la nube (Firebase)
| Característica | Beneficio para el negocio |
|---|---|
| Sincronización en tiempo real | Cambios visibles al instante en todos los dispositivos |
| Sin servidor propio | Reduce costos de mantenimiento |
| Seguridad de Google | Datos protegidos sin configuración técnica avanzada |
| Gratuito en escala pequeña | Ideal para negocios medianos y pequeños |
Capa 4 — Almacenamiento persistente
| Colección | Contenido |
|---|---|
pedidos | Historial completo de todos los encargos |
clientes | Datos de contacto de clientes frecuentes |
materiales | Inventario con cantidades disponibles |
Justificación tecnológica
| Decisión | Justificación |
|---|---|
| Aplicación web (no nativa) | No requiere instalación; funciona desde cualquier navegador |
| Firebase como backend | Fácil de implementar, tiempo real, gratuito a pequeña escala |
| Diseño responsive | Los negocios operan principalmente desde celulares |
| Sin servidor propio | Elimina costos de hosting y mantenimiento de infraestructura |
3.6 Tablero de Trello
Para la gestión del proyecto se utilizó Trello como herramienta principal de planificación, aprovechando su sistema de tableros Kanban que permite visualizar el flujo de trabajo de manera estructurada. El tablero CAA-Proyecto2 fue organizado en cuatro columnas principales, cada una representando una fase completada del proyecto.
Hecho — Planificación
Esta columna refleja las actividades iniciales que sentaron las bases del proyecto.
Reunión - Repartición de documentación (20 abr)
Se realizó una reunión grupal con todos los integrantes del equipo con el objetivo de distribuir las responsabilidades de documentación. Esta actividad fue fundamental para garantizar que cada miembro tuviera claridad sobre su rol y sus entregables dentro del proyecto.
Reunión - Elección de negocios (12 abr)
Se llevó a cabo una sesión de discusión grupal para evaluar y seleccionar los negocios que serían objetos a entrevistar para del proyecto. La toma de decisión fue colectiva, asegurando que todos los integrantes estuvieran alineados con el enfoque del trabajo.
Tablero - Trello (10 abr)
Se configuró y estructuró el tablero de Trello como herramienta central de seguimiento del proyecto. Esta tarjeta evidencia que la organización del equipo fue planificada desde el inicio, estableciendo un flujo de trabajo claro antes de comenzar cualquier actividad.
Hecho — Recolección de Material
Esta columna agrupa las actividades de campo realizadas para obtener información de primera mano.
Pitch - Vidrería y Herrería (13 abr)
Cada miembro del equipo de trabajo grabó y subió a youtube un pitch con una porpuesta al dueño del negocio entrevistado sobre un rquerimiento uidentificado en su negocio para sacarle provecho a la plataforma web que se le ofreció.
Grabación de entrevista 1 y 2 - Vidrería y Herrería (12 abr)
Se realizó la visita y presentación a los negocios para recolectar fotografías. se realizó y grabó la entrevista formal al representante del negocio de vidrería. La tarjeta incluye un archivo adjunto y una lista de verificación completada, lo que evidencia que el material audiovisual fue recolectado y verificado correctamente.
Hecho — Proceso de Proyectos
Esta columna documenta las actividades de seguimiento y comunicación interna del equipo.
Reportar - Issues del Proyecto (22 abr)
Se registraron y reportaron los problemas identificados durante el desarrollo de los programas de cada negocio. Esta práctica refleja una gestión proactiva de riesgos, permitiendo al equipo atender y resolver obstáculos de manera oportuna.
Junta - Discusión de Proyecto (19 abr)
Se realizó una reunión general con todos los integrantes para revisar el avance del proyecto y concluir los acuerdos establecidos con los dueños de los negocios, además de esto se subió a youtube para su transparencia.
Hecho — Documentación
Esta columna concentra todas las tareas relacionadas con la elaboración y entrega de los documentos del proyecto.
Documentación - Docusaurus (22 abr)
Se completó la documentación del proyecto utilizando Docusaurus como plataforma de publicación. La lista de verificación confirma que el entregable fue finalizado en su totalidad dentro de la fecha establecida.
01 - Recolección de información (21 abr)
Se entregó la sección correspondiente a la recolección de información del informe, consolidando los datos obtenidos durante las visitas y entrevistas realizadas.
02 - Análisis (21 abr)
Se desarrolló la sección de análisis del informe, procesando e interpretando la información recolectada para extraer conclusiones relevantes sobre los negocios estudiados.
03 - Propuesta (21 abr)
Sección de pitch y reglas del negocio para los programas a trabajar.
Anexos (21 abr)
Se compilaron y organizaron todos los materiales de soporte del proyecto, incluyendo evidencias, fotografías y cualquier otro documento complementario que respalde el trabajo realizado.
Estructura y directores - Repositorio (10 abr)
Se definió la estructura del repositorio del proyecto y se asignaron los roles de dirección dentro del equipo. Con su lista de verificación completada y archivo adjunto, evidencia que la organización técnica del proyecto fue establecida desde las etapas tempranas.
El uso de Trello permitió al equipo mantener visibilidad completa sobre el estado de cada actividad, facilitando la coordinación, el cumplimiento de fechas y la distribución equitativa del trabajo entre todos los integrantes.
3.7 Simulación de Junta Directiva Técnica
Descripción de la simulación
La siguiente es una simulación de una junta directiva técnica del equipo de desarrollo de software, realizada en el marco de una fase de toma de requerimientos con dos negocios reales: una vidriería y un taller de herrería.
En esta simulación participan cinco roles clave:
- Scrum Master: Modera la reunión, facilita los acuerdos y mantiene el control de la sesión.
- Product Manager: Vela por la entrega en tiempo y el valor para el negocio.
- Tech Lead: Garantiza la solidez técnica, escalabilidad y calidad del sistema.
- QA / Auditor: Asegura que el producto funcione correctamente y cumpla con estándares de calidad.
- Cliente / Stakeholder: Representa al dueño de los negocios, expone sus necesidades y limitaciones.
El objetivo de la junta es analizar los hallazgos obtenidos durante las entrevistas, definir la solución tecnológica a implementar, establecer el alcance, los tiempos de entrega y documentar los acuerdos y trade-offs aceptados por todos los involucrados.
Resumen de la junta
Duración estimada: 40 - 45 minutos
Fecha: 19 de abril
Problema identificado
En la vidriería se detectaron tres problemas principales: falta de control de clientes, ausencia de registro formal de pedidos y nula visibilidad sobre ganancias o pérdidas. En el taller de herrería, los problemas incluyen manejo de inventario de memoria, aceptación de trabajos sin verificar disponibilidad de materiales y fechas de entrega poco confiables.
El cliente reporta una pérdida estimada de 5 clientes por mes, con un impacto aproximado de Q300 a Q400 por cliente.
Decisión de solución
Se acuerda desarrollar un sistema web responsive con tres módulos funcionales:
- Clientes
- Pedidos
- Inventario
Adicionalmente, incluirá autenticación básica de un solo usuario y backup automático mediante Firebase.
Plan de trabajo
| Semana | Actividad |
|---|---|
| Semana 1 | Diseño y arquitectura |
| Semana 2 | Desarrollo |
| Semana 3 | Desarrollo |
| Semana 4 | Pruebas y correcciones menores |
Tiempo total de entrega: 4 semanas
Requerimientos excluidos (para segunda fase)
- Módulo de reportes financieros (ganancias por mes)
- Módulo de control de garantías
Trade-offs aceptados
- Tiempo vs. Calidad: 4 semanas en lugar de 6, aceptando una arquitectura funcional pero no perfectamente escalable.
- Alcance vs. Tiempo: Exclusión de módulos de garantías y reportes financieros para cumplir con el plazo.
- Funcionalidad vs. Simplicidad: Reportes básicos sin gráficas complejas ni análisis avanzados.
- Control vs. Velocidad: Uso de Firebase (nube de Google) en lugar de servidor propio para reducir tiempos de desarrollo.
Acuerdos formales
- Se desarrollará el sistema en 4 semanas con los tres módulos base, autenticación básica y backup en Firebase.
- Los requerimientos quedan congelados a partir de hoy. Cualquier nuevo requerimiento se documenta para una segunda fase.
- Se aceptan explícitamente los cuatro trade-offs documentados.
Resultado final
La junta concluye con todos los roles de acuerdo, el cliente satisfecho dentro de sus limitaciones, y un plan concreto, documentado y firmado en el acta. El Scrum Master cierra la sesión agradeciendo la participación y el profesionalismo del equipo.