Después de toda esta temporada de pandemia, las empresas han empezado a trabajar remoto y dan mucha más oportunidad a extranjeros, al menos así lo he percibido.
Esto ha provocado que la oficina se quede pequeña para los que desean ir y usar las salas de reuniones o puestos, provocando la necesidad de un sistema de reserva de asientos y establecer fechas para usar los espacios.
En mi empresa buscaban voluntarios que armaran ese módulo dentro de un sitio existente, imagino porque no es un proyecto presupuestado; pero como soy un malito me metí de cabeza en ello sin importar qué, se ve buenísima la idea xD.
Requerimientos
Me hubiera gustado haberlo propuesto yo pero no fue así y esto los requerimientos que plantearon:
- Los roles limitan las capacidades de reserva.
- Los invitados a la oficina deben ser notificados via email.
- El sistema debe ser capaz de registrar los espacios de la oficina por hora.
- El usuario debe ser capaz de reconocer fácilmente los asientos.
- Si el que reservo no ocupa el puesto o sala de reunión en un rango de tiempo, debe liberarse.
- Renovar la interfaz existente.
Realmente hay uno que otro requerimiento faltante como un módulo de reportes y uno que otro detalle; pero esto que describo es la prioridad uno.
Propuesta de como abordar el proyecto
Como mencione, hay un sitio interno y funcional para gestión de multiples necesidades de Recursos Humanos; por lo tanto no es tan fácil como decidir hacer todo desde cero.
Dando contexto el sitio existente tiene tecnologías obsoletas y es un monolito clásico con .Net Framework. Tenemos un equipo de 6 voluntarios "supuestamente", en este tipo de iniciativas prefiero mantener mis expectativas bajas en términos de colaboración.
Propuesta #1: Crear el módulo en el sitio existente con tecnologías obsoletas.
Propuesta #2: Crear todo desde cero separando SPA y API.
Propuesta #3: Crear un SPA que mantenga la sesión del sitio existente y empezar por este módulo. Esta fue la elegida.
Yo soy parte del equipo de Frontend, por lo tanto no quiero decidir como lo realizarán; pero aún no tengo total claridad de cómo se mantendrá esa sesión.
Como he podido hablar entre pasillos, uno suele mantener una cookie que mantiene tu session Id; de este modo si publicas el sitio bajo el mismo dominio podría ser posible, pero todo depende de cómo se persiste la sesión.
De igual modo este módulo es prioridad uno; si no funciona tengo previsto un módulo de Autorización/Autenticación con su Implicit Flow y un perfil, que no debería tomarme mucho desde el Frontend.
Roles
User: Un usuario es cualquiera empleado con su correo empresarial.
Team Leader: Son igual empleados, pero son los representantes de sus equipos.
Admin: Son las autoridades de la oficina; cómo la encargada de recursos humanos o managers.
System Admin: Un rol que puede navegar entre los diversos roles para dar mantenimiento.
Entidades
Habitación: Representa un espacio que puede ser reservado por completo o por asiento, Puede contener múltiples asientos dentro.
Asiento: Representa una posición y orientación en la habitación que un usuario puede ocupar.
Evento: Representa algo que ocurre en el asiento como la reservación o el bloqueo del mismo.
Mockups
Algunos de las interfaces que se me ocurrieron por el momento; me quedaron muy desproporcionadas pero ayuda a darse una idea.
Crear una habitación
Tiempo de Espera: Es el tiempo de espera antes de ser liberado el asiento. Todavía no tengo claro si el admin será el que lo decida o si nosotros (los empleados) seremos capaz de ponerlo cada vez que reservamos; creo que mejor el admin
Tipo de reservación: Es para elegir si la habitación se reservará por completo o por asientos.
Los últimos como Columnas, Filas y Tipos de Asientos se comprenderán mejor más adelante.
Ver una habitación
Esta pantalla representa la clásica vista de detalles del producto; solo que sobrecargada con el listado, edición y eliminación. Solo un admin debe ser capaz de eliminar y editar las habitaciones.
La idea es que puedas seleccionar una habitación y buscar por rango de fecha para previsualizar los asientos ocupados y/o reservar alguno.
Registro de Habitaciones
Como se puede apreciar, las habitaciones son una cuadrícula en el que eres capaz de colocar asientos.
Diseñé el sistema con la suficiente flexibilidad de crear cualquier tipo de habitación para que fuera escalable e intuitivo al mismo tiempo.
Tipos de Asientos
Los asientos como entidad tienen una posición y orientación. La posición pienso que sea manejada como una hoja de Excel y la orientación como si de una brújula se tratase.
Los asientos de esquina, utilizan una orientación más compleja siguiendo la esquina de la mesa, mientras que los asientos comunes siguen uno simple.
No hay necesidad que el admin tenga que entender esto, esto lo tengo pensado para que el frontend y el backend hablen un mismo idioma.
El ultimo asiento circular que se ve en la imagen es para el grupo de personas en un mismo espacio, como al reunirte en una cocina a comer.
Estados del asiento
Disponible: El asiento está disponible dah!
En uso: El asiento está ocupado.. dah!
En espera: Alguien lo reservo, pero aún no ha llegado a la oficina.
Reservado: Alguien lo reservó y aún no se cumple la fecha y hora.
No se puede reservar: Fue bloqueado por un admin.
Ejemplos
Se puede representar el mismo espacio con la orientación de los puestos y los espacios.
Hasta la cocina puedo representar y eso ni me lo pidieron xD, lo que prueba las capacidades de mi diseño.
Próximos pasos
Ya mas o menos pensado:
- Como previsualizar los eventos
- Envío de notificaciones
- Modelo de datos
- El stack a utilizar
- Los componentes
- Los colores y como se utilizarán en los componentes
- Casos de Usos/Roadmap
Pero me falta terminar de moldearlo y plasmarlos en un documento, eso será en la parte 2.
