Universidad ORT Uruguay Facultad de Ingeniería
Trackeate:
Sistema de registro y monitoreo de horas trabajadas.
Entregado como requisito para la obtención del título de Licenciatura en Sistemas.
Stephany Silva - 180082 Jaime Zilberberg - 138484
Tutor: Gerardo Quintana
2022
2
Declaración de autoría
Nosotros, Stephany Silva y Jaime Zilberberg, declaramos que el trabajo que se presenta en esta obra es de nuestra propia mano. Podemos asegurar que:
• La obra fue producida en su totalidad mientras realizábamos el proyecto para la obtención del título de Licenciatura en Sistemas;
• Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con claridad;
• Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excepción de estas citas, la obra es enteramente nuestra;
• En la obra, hemos acusado recibo de las ayudas recibidas;
• Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos explicado claramente qué fue contribuido por otros, y qué fue contribuido por nosotros;
• Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto donde se han realizado las aclaraciones correspondientes.
Jaime Zilberberg Stephany Silva
8/4/2022 8/4/2022
Dedicatoria
A nuestras familias y amigos, pilares centrales en nuestras vidas, que nos acompañaron en este camino largo, lleno de obstáculos y desafíos.
4
Agradecimientos
A nuestros compañeros de trabajo por los buenos consejos y paciencia. A los profesores y demás integrantes de la Universidad, que nos formaron y acompañaron para llegar a este proyecto.
Al cliente por confiar en nosotros y a los usuarios del sistema por la buena voluntad durante el proceso de pruebas. Y finalmente a nuestro tutor que nos acompañó, aconsejó y enseñó durante tantos meses.
5
Abstract
Este proyecto se elabora en el marco de las necesidades de We are Capicua, nuestro cliente, para gestionar la dedicación horaria de sus empleados. Trackeate, permite a los empleados registrar el tiempo que dedican a sus tareas y a los encargados de los proyectos ver reportes y definir las configuraciones laborales.
Capicua es una empresa de diseño y desarrollo web que cuenta con más de 80 empleados ubicados en distintos países. Mensualmente liquida 12.000 horas de sueldos. Para que la empresa de nuestro cliente sea rentable estas horas deben estar atribuidas a proyectos.
Capicua no cuenta con información certera sobre la dedicación horaria de sus empleados.
Tampoco conoce a detalle y con seguridad en qué tareas y proyecto se invierten las horas.
Esto ocasiona desvíos presupuestales en los proyectos, complejiza la facturación a clientes y genera incertidumbre para la liquidación de sueldos, ya que los empleados trabajan bajo una modalidad que solo cobran las horas que se cargan a un proyecto.
Los reportes son de dedicación horaria de los empleados y del presupuesto de los proyectos. Las configuraciones laborales son los días y horarios donde está permitido registrar horas.
Para la construcción, se investigó las necesidades de los interesados y las posibles soluciones en el mercado. Validado el problema y estudiadas las alternativas existentes, se ideó un producto mínimo viable, que fue validado con el cliente y los usuarios.
Se decidió avanzar con una solución propia, desarrollada en Flutter y Node Js.
El valor que agrega, es generar los reportes específicos que Capicua necesita, alerte sobre desviaciones y evite el pago de una herramienta de terceros.
Pusimos especial énfasis en la usabilidad del sistema, para tener una rápida adopción, una mínima resistencia al cambio y una agradable experiencia de uso. Nos basamos en Material Design para la UI, en las Heurísticas de Nielsen para la UX e integramos Google Sign In, para facilitar el ingreso al sistema y aumentar la seguridad.
6 El proyecto se gestionó en las etapas de investigación, desarrollo y documentación. Se trabajó de forma iterativa incremental, utilizando una versión adaptada de Kanban para Documentación e investigación y una versión reducida de Scrum para el desarrollo.
Trackeate, resolvió las necesidades del cliente y está siendo utilizado. El cliente y los usuarios están satisfechos por contar con información clave para mejorar el rendimiento, mientras aporta transparencia y seguridad a los procesos internos.
Palabras clave
Registrar el tiempo, Dedicación Horaria, Configuraciones laborales, Reportes, presupuesto de los proyectos, Liquidación de sueldos, Facturación a sus clientes, Desviación, Producto mínimo viable, Flutter Web, Usabilidad del sistema, Scrum, Kanban, integraciones con Google Sign In.
Glosario
Administrador: Rol del sistema que utilizan gerentes de Capicua, permite acciones de alta, baja, modificación y configuraciones del sistema.
AWS: Amazon Web Services [1], abreviado AWS, es una colección de servicios de computación en la nube pública (también llamados servicios web) que en conjunto forman una plataforma de computación en la nube
Basic: Rol del sistema para la mayoría de los usuarios. Permite trackear y ver sus propios reportes.
Capicua: We are Capicua [2], es el nombre del cliente, de ahora en adelante utilizaremos simplemente “Capicua” para referirnos a el.
Configuraciones laborales: Se configura los días y horarios en los cuales se puede registrar horas.
Dedicación Horaria: Cantidad de horas diarias que un empleado debe dedicar a trabajar en proyectos.
Dedicación: Se refiere a la cantidad de horas que un miembro del equipo destina al proyecto, “que por compromiso o contrato ocupa todo el tiempo disponible, con exclusión de cualquier otro trabajo” [3].
Desviación: Diferencia entre la asignación definida y el estado real, puede ser en la dedicación horaria o en el presupuesto de los proyectos, se consulta con un reporte especial. “Diferencia entre la medida de una magnitud y el valor de referencia” [4].
Facturación a sus clientes: Actividad que permite conocer el detalle de cuantas horas se le imputan a un proyecto en un plazo determinado y el valor hora de cada actividad asociada.
Flutter Web: [5] Tecnología desarrollada por Google para el desarrollo de aplicaciones Web.
9 Integraciones con Google Sign In: El sistema se integra con Google Sign in [6], proveedor de identidades, facilita el proceso de registro, ingreso y egreso de los usuarios al sistema.
Kanban: [7] Es una metodología basada en señales visuales que adaptamos para gestionar las tareas, lo utilizamos para gestionar las tareas de la etapa de investigación, y las de cada Sprint.
Liquidación de sueldos: Actividad que en base a la cantidad de horas que un empleado registró en un mes y al precio hora definido, permite conocer el monto que se le debe abonar por sus servicios.
Material UI: [8] Normativa de Diseño enfocado a las interfaces de usuario y experiencia de usuario liderado por Google, estándar de Flutter.
MySQL: [9] es un sistema de gestión de bases de datos relacional.
Node Js: Es la tecnología que utilizamos para construir el backend.” Es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor basado en el lenguaje de programación JavaScript, asíncrono, con E/S de datos en una arquitectura orientada a eventos y basado en el motor V8 de Google” [10].
Owner: Rol del sistema que utilizan los dueños de la empresa Capicua. Tiene el máximo nivel de control sobre el sistema y sus datos.
Presupuesto de los proyectos: Recursos definidos para un proyecto, puede ser en horas o dinero.
Producto mínimo viable: Es el producto más pequeño que se puede realizar para cubrir las necesidades de un cliente y sus potenciales usuarios. “…es un producto con suficientes características para satisfacer a los clientes iniciales, y proporcionar retroalimentación para el desarrollo futuro. [11]”
10 Refactorear: Implica mejorar el código, dándole un estilo correcto que respete los estándares y buenas prácticas de desarrollo. “...del inglés (refactoring) es una técnica de la ingeniería de software para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo.” [12]
Registrar el tiempo: Acción de describir una tarea, definir una fecha y hora de comienzo y fin, y asociarla a un proyecto.
Reportes: Tablas y gráficas que informan sobre un conjunto de datos de forma ordenada y visual según las necesidades del usuario.
Scrum: Marco de Desarrollo agil utilizado para gestionar la etapa de desarrollo. “Scrum es un marco de trabajo simple que promueve la colaboración en los equipos para lograr desarrollar productos complejos” [13].
Trackear: Acción de registrar períodos de tiempo de tareas, asociados a un proyecto de un cliente.
Usabilidad del sistema: Experiencia positiva que se obtiene durante el uso del sistema.
Nos basamos en Jakob Nielsen [14], considerado el padre de la usabilidad, que la define como “…el atributo de calidad que mide lo fáciles que son de usar las interfaces Web”
[15].
Usuario: Actor que interactúa con el sistema
11
Índice
1 Introducción ... 24
1.1 Selección del proyecto ... 24
1.2 Descripción del equipo ... 25
1.3 Descripción del cliente ... 26
1.4 Objetivos ... 27
1.4.1 Objetivos Académicos ... 28
1.4.2 Objetivos del proyecto ... 30
1.4.3 Objetivos del producto ... 31
1.5 Estructura del documento ... 32
2 Problema ... 34
2.1 Descripción ... 34
2.2 Cliente y contexto ... 35
2.3 Interesados ... 36
2.3.1 Directores de Capicua ... 36
2.3.2 Gerentes de Capicua ... 36
2.3.3 Empleados de Capicua ... 36
2.3.4 Clientes de Capicua ... 37
2.4 Validación del problema ... 37
3 Solución ... 39
3.1 Solución propuesta ... 39
3.2 Principales funcionalidades ... 40
3.3 Alcance del proyecto ... 42
3.4 Desafíos del proyecto ... 42
3.5 Entregables ... 43
12
3.6 Imagen del Producto ... 44
3.7 Validación de la solución ... 45
4 Marco metodológico ... 47
4.1 Características del proyecto ... 47
4.2 Características del cliente ... 48
4.3 Características del equipo ... 48
4.4 Roles ... 49
4.5 Metodología de trabajo y ciclo de vida ... 51
4.5.1 Etapa de investigación ... 52
4.5.2 Etapa de desarrollo ... 55
4.5.3 Etapa de Documentación ... 58
4.5.4 Gestión de los objetivos ... 59
5 Ingeniería de requerimientos ... 62
5.1 Relevamiento ... 63
5.1.1 Estudio de documentación ... 64
5.1.2 Ingeniería reversa de sistemas de tracking ... 64
5.1.3 Encuestas a interesados ... 64
5.1.4 Entrevistas ... 66
5.2 Especificación ... 67
5.2.1 Requerimientos funcionales ... 70
5.2.2 Requerimientos no funcionales ... 73
5.2.3 Restricciones ... 75
5.3 Priorización y validación ... 75
5.3.1 Card, Conversation, Confirmation ... 76
5.3.2 Moscow ... 76
13
5.3.3 Prototipos ... 78
5.3.4 Storymap ... 79
5.4 Lecciones aprendidas ... 80
6 Arquitectura y diseño ... 82
6.1 Desafíos ... 82
6.1.1 Importancia de control de acceso al sistema ... 82
6.1.2 Importancia de controlar el acceso al contenido ... 82
6.2 Atributos de calidad ... 82
6.2.1 Interoperabilidad ... 83
6.2.2 Seguridad ... 83
6.2.3 Mantenibilidad ... 83
6.2.4 Fiabilidad ... 84
6.3 Descripción general de la arquitectura ... 84
6.4 Vista de módulos ... 85
6.4.1 Backend ... 85
6.4.2 Frontend ... 87
6.4.3 Modelo de datos ... 88
6.5 Vista de asignación ... 92
6.5.1 Despliegue ... 92
6.6 Patrones ... 94
6.6.1 Multi tier architecture ... 94
6.6.2 Federated Identity Pattern ... 95
6.7 Tecnologías y herramientas ... 98
6.7.1 Frontend ... 98
6.7.2 Backend ... 98
14
6.7.3 Base de datos ... 99
6.7.4 Infraestructura ... 99
6.8 Conclusiones y lecciones aprendidas ... 99
7 Gestión del proyecto ... 100
7.1 Etapas y principales hitos del proyecto ... 100
7.2 Etapa de investigación ... 102
7.2.1 Análisis del cliente y su contexto. ... 102
7.2.2 Análisis de mercado ... 105
7.2.3 Continuar un proyecto anterior ... 107
7.2.4 Aplicación de Popcorn Flow ... 107
7.2.5 Aplicación de Kanban ... 112
7.2.6 Capacitaciones ... 113
7.2.7 Resultados de la investigación ... 114
7.2.8 Conclusiones y lecciones aprendidas ... 114
7.3 Etapa de desarrollo ... 115
7.3.1 Aplicación de Scrum ... 116
7.3.2 Planificación de los sprints ... 119
7.3.3 Ejecución de los sprints ... 120
7.3.4 Plan de releases ... 122
7.3.5 Resultado de la metodología ... 122
7.3.6 Resultado de la etapa de Desarrollo ... 122
7.3.7 Conclusiones y lecciones aprendidas ... 123
7.4 Etapa de Documentación ... 123
7.4.1 Contenido de la documentación ... 126
7.4.2 Herramientas para documentar ... 127
15
7.4.3 Resultados de la etapa de documentación ... 128
7.4.4 Conclusiones y lecciones aprendidas ... 129
7.5 Métricas de gestión ... 129
7.5.1 Dedicación ... 129
7.5.2 Dedicación por área ... 131
7.5.3 Evolución del alcance ... 133
7.5.4 Cantidad de incidentes ... 134
7.6 Gestión de los objetivos ... 136
7.6.1 Bimestre 1 ... 137
7.6.2 Bimestre 2 ... 138
7.6.3 Bimestre 3 ... 139
7.7 Gestión de la comunicación ... 140
7.7.1 Comunicación interna del equipo ... 140
7.7.2 Comunicación con el cliente ... 141
7.7.3 Comunicación con el tutor ... 141
7.7.4 Herramientas de comunicación ... 142
7.8 Gestión de riesgos ... 143
7.8.1 Identificación ... 144
7.8.2 Análisis ... 145
7.8.3 Control ... 151
7.8.4 Resultados de la gestión de riesgos ... 155
7.8.5 Conclusiones y lecciones aprendidas ... 156
8 Gestión de la calidad ... 157
8.1 ¿Qué es la calidad? ... 157
8.2 Plan de calidad ... 157
16
8.2.1 Fase Investigación ... 159
8.2.2 Fase Ingeniería de requerimientos ... 159
8.2.3 Fase Diseño y Arquitectura ... 160
8.2.4 Fase Desarrollo ... 160
8.2.5 Fase Pruebas ... 160
8.2.6 Fase Puesta en producción ... 161
8.2.7 Fase Documentación ... 161
8.3 Prácticas de aseguramiento de la calidad ... 161
8.3.1 Aplicación de estándares ... 162
8.3.2 Capacitación en tecnologías ... 164
8.3.3 Revisiones de código y pull requests ... 164
8.3.4 Definition of DONE ... 165
8.3.5 Encuestas de satisfacción al cliente y usuarios ... 165
8.3.6 Pruebas ... 165
8.3.7 Revisiones académicas y con expertos ... 166
8.3.8 Retrospectivas ... 167
8.4 Métricas de calidad ... 167
8.4.1 Evaluación de estándar de programación ... 167
8.4.2 Métricas del analizador de código de ESLint ... 168
8.4.3 Evaluación de satisfacción del cliente ... 170
8.4.4 Incidentes detectados ... 170
8.4.5 Pruebas de usabilidad con usuarios ... 171
8.4.6 Checklist de usabilidad ... 172
8.4.7 Encuestas de satisfacción ... 173
8.4.8 Checklist de documento 303 ... 174
17
8.4.9 Revisiones académicas ... 175
8.5 Conclusiones y lecciones aprendidas ... 175
9 Gestión de la configuración ... 177
9.1 Identificación de elementos de configuración ... 177
9.2 Herramientas utilizadas ... 178
9.2.1 Gestión de la documentación ... 178
9.2.2 Gestión de software ... 179
9.3 Organización de los repositorios ... 181
9.3.1 Documentación ... 181
9.3.2 Código ... 182
9.4 Gestión de versiones ... 182
9.4.1 Documentación ... 182
9.4.2 Código ... 184
9.5 Gestión de cambios e incidentes ... 185
9.6 Conclusiones y lecciones aprendidas ... 187
10 Conclusiones y lecciones aprendidas ... 188
10.1 Conclusiones Generales ... 188
10.2 Objetivos Académicos ... 189
10.3 Objetivos del proyecto ... 190
10.4 Objetivos del producto ... 191
10.5 Lecciones aprendidas ... 191
10.6 Próximos pasos ... 192
11 Referencias bibliográficas y Trabajos Citados ... 193
12 Anexos ... 203
12.1 Vistas multimedia del sistema ... 203
18
12.2 Web Api ... 220
12.3 Comunicación con el Cliente ... 225
12.3.1 Validación del problema ... 226
12.3.2 Conformidad con solución propuesta ... 227
12.3.3 Comentarios finales del producto entregado ... 229
12.4 OKR ... 230
12.5 Evidencia de OKR ... 233
12.6 Análisis de interesados ... 238
12.6.1 Tormenta de ideas ... 238
12.6.2 Matriz de interesados ... 239
12.7 Registro de incidentes y cambios ... 240
12.7.1 Listado de bugs solucionados ... 241
12.8 Plan de calidad ... 244
12.9 Pull Requests ... 245
12.10 Pruebas de Usabilidad ... 246
12.11 Reviews ... 254
12.11.1 Primer semana de review (4/2 al 11/2) ... 254
12.11.2 Segunda semana de review ... 255
12.12 Retrospectivas ... 255
12.13 Revisiones internas ... 258
12.13.1 Primera revisión ... 258
12.13.2 Segunda Revisión ... 259
19
Índice de ilustraciones
Ilustración 1 Logo del producto ... 44
Ilustración 2 Manual de estilo ... 45
Ilustración 3 Diagrama de etapas del proyecto ... 52
Ilustración 4 Versión propia de Kanban ... 54
Ilustración 5 Tablero de Popcorn Flow ... 54
Ilustración 6 Proceso de Scrum adaptado ... 57
Ilustración 7 Ciclo de vida de documentación ... 58
Ilustración 8 Kanban de la línea de Gestión de proyectos ... 59
Ilustración 9 Objetivo 5 de los OKR del proyecto. ... 61
Ilustración 10 Proceso de gestión de requerimientos ... 63
Ilustración 11Encuesta a Empleados de Capicua. ... 65
Ilustración 12 Resultado de satisfacción con reportes actuales ... 66
Ilustración 13 Resultado de satisfacción con la herramienta actual de terceros. ... 66
Ilustración 14 Historia de Usuario en Jira. ... 69
Ilustración 15 Listado de Épicas e Historias de usuarios en Jira. ... 71
Ilustración 16 Prototipo de Figma de Listado de proyectos. ... 72
Ilustración 17 Prototipo de Figma de configuración del espacio de trabajo ... 73
Ilustración 18 Realización de Moscow, priorización de funcionalidades. ... 77
Ilustración 19 Diseño centrado en el usuario. ... 79
20
Ilustración 20 Realización de Storymap con el cliente. ... 80
Ilustración 21 Diagrama general ... 85
Ilustración 22 Vista de Módulos - Usos ... 86
Ilustración 23 Catálogo de elementos ... 86
Ilustración 24 Módulos del frontend. ... 87
Ilustración 25 Modelo relacional de la base de datos del proyecto proporcionado. ... 89
Ilustración 26 Modelo relacional de la base de datos del proyecto actual. ... 91
Ilustración 27 Diagrama general de la infraestructura ... 93
Ilustración 28 Diagramas de cómo implementamos el patrón Federated Identity. ... 97
Ilustración 29 Hitos del proyecto. ... 101
Ilustración 30 Etapas del proyecto ... 101
Ilustración 31 Respuestas de usuarios de Capicua ... 104
Ilustración 32 Precios de Toggl ... 106
Ilustración 33 Precios de Tmetric ... 106
Ilustración 34 Problema Popcorn Flow ... 108
Ilustración 35 Opciones de Popcorn Flow ... 108
Ilustración 36 Experimentos de Popcorn Flow ... 109
Ilustración 37 Compromisos del equipo de Popcorn Flow ... 109
Ilustración 38 Tareas en proceso de Popcorn Flow ... 110
Ilustración 39 Comentarios del experimento de Popcorn Flow ... 110
21
Ilustración 40 Resultado del Problema finalizado Popcorn Flow ... 111
Ilustración 41 Registro de la etapa de investigación del uso de Kanban ... 112
Ilustración 42 Distribución del trabajo en Primer Release (Sprint 1 al 4) ... 117
Ilustración 43 Distribución del trabajo en Primer Release (Sprint 5 al 8) ... 118
Ilustración 44 Realización de planning poker. ... 120
Ilustración 45 Sistema Jira utilizado para la planificación del proyecto ... 121
Ilustración 46 Comentarios de revisión ... 124
Ilustración 47 Historial de versiones de documentación ... 125
Ilustración 48 Dedicación por Integrante ... 130
Ilustración 49 Dedicación por Área. ... 131
Ilustración 50 Dedicación por Área 2 ... 132
Ilustración 51 Completitud por sprint ... 133
Ilustración 52 Evolución de completitud de los sprint ... 134
Ilustración 53 Incidentes por bimestre ... 135
Ilustración 54 Gráfica de incidentes por bimestre ... 136
Ilustración 55 Objetivos académicos con metodología OKR ... 137
Ilustración 56 Objetivos del proyecto con metodología OKR ... 137
Ilustración 57 Objetivos del producto con metodología OKR ... 137
Ilustración 58 Escala de impactos ... 146
Ilustración 59 Escala de probabilidad ocurrencia ... 146
22 Ilustración 60 PMBook V5. Definición de Escalas de Impacto para Cuatro Objetivos del Proyecto ... 147 Ilustración 61 Tabla de análisis de riesgos ... 148 Ilustración 62 Tabla de prevención de riesgos ... 151 Ilustración 63 Tabla de prevención de riesgos ... 155 Ilustración 64 Fases y Actividades del plan de calidad. ... 158 Ilustración 65 Proceso de prueba exploratorio del sistema ... 166 Ilustración 66 Hoja de chequeo de Estándar de programación ... 167 Ilustración 67 Reporte EsLint marzo 2022 ... 168 Ilustración 68 Reporte Eslint enero 2022 ... 169 Ilustración 69 Resultados de la evaluación de interfaces de usuario ... 170 Ilustración 70 Detección de incidentes por bimestre ... 171 Ilustración 71 Resultado de Checklist de usabilidad al 20 de febrero. ... 172 Ilustración 72 Resultado de encuestas de satisfacción ... 173 Ilustración 73 Hoja de chequeo documento 303 ... 175 Ilustración 74 Resultado de encuestas de revisiones académicas ... 175 Ilustración 75 Tabla de elementos de la configuración ... 178 Ilustración 76 Organización del repositorio de documentación ... 181 Ilustración 77 Repositorio del código en Bitbucket ... 182 Ilustración 78 Versionado de Microsoft Word en Google Drive ... 183 Ilustración 79 Versionado de Figma ... 183
23 Ilustración 80 Versionado de Bitbucket ... 185 Ilustración 81 Incidente reportado en planilla de testing ... 185 Ilustración 82 Incidente reportado en Jira ... 186
24
1 Introducción
El presente documento es el trabajo final de la carrera Licenciatura en Sistemas, del equipo integrado por Stephany Silva y Jaime Zilberberg. Explica el contexto en el que se crea “Trackeate: Sistema de registro y monitoreo de horas trabajadas”.
El proyecto se fundamenta en la necesidad de nuestro cliente, la cual es tener un sistema para que sus empleados puedan registrar los períodos que trabajan y especificar qué tareas realizaron y para qué proyecto.
El registro de tiempo le permite liquidar sueldos, facturar a los clientes por sus proyectos, conocer la dedicación de sus empleados, ser alertados por desviaciones y facilitar la toma de decisiones al entregar información de forma clara y visualmente atractiva.
El valor para los usuarios de utilizar el sistema es agregar y conocer las horas que llevan trabajadas en cada proyecto. Esto les permite saber cuánto dinero van generando para su próxima liquidación de sueldos.
En el primer capítulo se realiza la presentación del proyecto. En los siguientes, se describe la selección del proyecto, el equipo de trabajo, el cliente que planteó su problemática y la solución que construimos para satisfacerla. Además, se detalla el proceso de construcción del producto, con todas sus fases y etapas.
Para finalizar se realiza un resumen de todos los capítulos de este documento.
1.1 Selección del proyecto
Previo a seleccionar el proyecto es importante destacar que formamos el equipo. Lo hicimos confiados en la potencia de contar con un equipo balanceado, motivado y unido antes de decidir que tipo de proyecto podíamos seleccionar.
El equipo fue conformado por tres estudiantes, con capacidades complementarias y con buen relacionamiento previo, lo que generaba un buen ambiente para realizar el proyecto final.
25 Participamos de la feria de proyectos de la Universidad y seleccionamos uno que coincidía con nuestra idea de proyecto final. Luego, fue descartado por no contar con las características que la Universidad consideraba necesarias para un equipo conformado como el nuestro.
A raíz de esto, continuamos investigando otros proyectos de la feria, mientras en paralelo, averiguamos por posibles proyectos en las empresas donde trabajamos los integrantes del equipo.
Finalmente, elegimos el desafío que nos propuso la empresa en la cual trabajan dos integrantes del equipo, se trata de We Are Capicua (de ahora en adelante nos referiremos a la misma como Capicua), una empresa de diseño y desarrollo de aplicaciones web.
Lo analizamos y descubrimos que tenía condiciones para el equipo, un desafío interesante desde el punto de vista técnico, que nos permitiese aplicar lo aprendido y aprender tecnologías nuevas.
Rápidamente identificamos que las características del equipo se conjugaban perfectamente con las tareas necesarias para tomar un proyecto así. Se presentaban las siguientes tareas: investigación, desarrollo en tecnologías nuevas, gestión de la calidad y la gestión de un proyecto que terminaba con la creación de un producto real.
Lo seleccionamos convencidos de que este proyecto tenía las condiciones para sacar lo mejor de nosotros mismos, dejar al cliente satisfecho y cumplir con los requisitos que nos proponía la Universidad.
1.2 Descripción del equipo
El equipo se integró por tres estudiantes de Licenciatura en Sistemas, cada uno aportó una experiencia laboral y capacidades técnicas diferentes. Se conocían previamente y existía experiencia de trabajo conjunto entre los integrantes, una buena comunicación y la motivación compartida de finalizar la carrera.
Desde diciembre del 2021 hasta febrero del 2022, una integrante del equipo, que denominaremos bajo el seudónimo “Alicia”, experimentó una situación personal que le
26 impidió afrontar el proyecto como sabemos que hubiese querido, finalmente el 15 de febrero se confirmó la baja de Alicia.
Este cambio fue comunicado al cliente y a la Universidad. Recibimos la autorización de ambas partes para continuar con el proyecto.
Alicia, trabajaba en Capicua durante su participación en el proyecto, lo hacía como Tester, y anteriormente había trabajado en otra empresa de tecnología como auditora de calidad.
Stephany Silva, trabaja como desarrolladora fullstack en Capicua, nuestro cliente, desde 2019, tiene una relación fluida con los directores de la empresa y con el resto de los usuarios clave. Anteriormente trabajó como desarrolladora en otras empresas y tiene experiencia desarrollando diferentes sistemas, con distintos lenguajes de programación.
Hoy, tiene en paralelo un emprendimiento de venta de artículos de papelería llamado Serendipia.
Jaime Zilberberg, trabaja como Product Manager en Invenzis, anteriormente trabajó en equipos comerciales y gestionando productos de empresas de TI. También posee experiencia docente, ya que se desempeñó como mentor en CUTI y fue profesor de secundaria. Conjuga una buena capacidad de comunicación, de administración de los recursos, creatividad y gestión de proyectos.
A lo largo de este documento, cuando nos referiremos al equipo, lo hacemos en nombre de los integrantes finales. El trabajo aportado por Alicia, está correctamente citado.
El equipo quedó integrado por Stephany Silva y por Jaime Zilberberg, como mencionamos anteriormente, ambos estudiantes de Licenciatura en Sistemas.
1.3 Descripción del cliente
Capicua es una empresa de diseño y desarrollo web que cuenta con su oficina central en Uruguay y otra en Estados Unidos.
Capicua vive un proceso de crecimiento constante y ha duplicado su plantilla los últimos dos años. Hoy en día cuenta con más de 80 empleados, la mayoría trabajando de forma
27 remota y más de la mitad de su plantilla radicados en el exterior, realizando sus tareas en distintos horarios y proyectos.
Al cliente, a raíz de la pandemia de Covid-19 y del crecimiento que está teniendo, se le dificulta cada vez más llevar a cabo un correcto seguimiento del desempeño de sus empleados.
Los empleados trabajan bajo una modalidad independiente, facturando mes a mes las horas que trabajan. Esta modalidad es común en las empresas de tecnología en Uruguay, y por más que son independientes y desde el punto de vista laboral no son empleados, nos referimos a ellos como empleados para facilitar el entendimiento del caso.
El cliente necesita saber de forma exacta cuantas horas trabaja cada empleado para liquidarle el salario. Necesita que esas horas estén relacionadas a un proyecto, para que esas horas sean rentables, ya que finalmente las paga el cliente del proyecto.
También la situación de la pandemia de Covid-19 profundizó el trabajo remoto y fuera del horario establecido. Esta situación recién en marzo del 2022 se empezó a reglamentar en Uruguay en la ley del teletrabajo.
Como resultado de esto, hubo una distribución de las horas de trabajo por parte de los empleados diferente a la esperada por Capicua. Esto complicó aún más el seguimiento que se le da a las tareas que efectúan los empleados.
1.4 Objetivos
Los objetivos se fijaron al comienzo del proyecto, se utilizaron como guía del equipo, para conocer el destino del proyecto. Fueron medidos para evaluar el proceso y las mediciones permitieron corregir el rumbo, ante las desviaciones que se fueron presentando a lo largo del proyecto.
El objetivo central, es entregar un producto que cumpla las expectativas del cliente, los requerimientos de la Universidad y cerrar el ciclo académico.
28 Para gestionar los objetivos de forma correcta se decidió dividirlos en las siguientes tres áreas: objetivos académicos, del proyecto y del producto.
En el capítulo “Gestión del proyecto”, veremos cómo fueron gestionados y sus resultados.
En el Anexo “Evidencia de OKR”, se describen los resultados clave.
1.4.1 Objetivos Académicos
Detallamos los cuatro objetivos académicos que nos planteamos, cada uno cuenta con un título, su descripción, contexto, y la métrica que empleamos para medirlo durante el proyecto.
Aplicar el conocimiento adquirido en la carrera.
Es importante para nosotros aplicar las distintas herramientas y conocimientos que aprendimos en estos años para la gestión y construcción del producto.
Para validar el cumplimiento del objetivo, lo realizamos mediante una encuesta a los miembros del equipo para determinar el conocimiento en cada una de las siguientes áreas:
Marco teórico, Ingeniería de requerimientos, Arquitectura y diseño, Gestión del proyecto, Gestión de la calidad, Gestión de la configuración.
En ella cada miembro del equipo evaluó del uno al cinco, los conocimientos adquiridos y la relevancia en la construcción de cada una de estas secciones del proyecto.
Aprender y aplicar tecnologías nuevas, necesarias para el proyecto.
Durante este proyecto aplicaremos tecnologías que no fueron vistas en el plan de la carrera, que fueron restricciones planteadas por el cliente o elecciones del equipo.
Entre ellas destacan: Flutter Web, Prisma, Node JS y AWS. Esto lo mediremos a través del alcance conseguido y de la aprobación del curso de Flutter que nos compró la empresa.
Lograr un clima de trabajo confortable.
Durante este proceso lo más importante es cultivar las relaciones personales y profesionales entre los miembros del equipo, el cliente y la Universidad.
29 Un proyecto logra mejores resultados cuando hay cohesión entre los integrantes y se trabaja en un entorno donde prima el respeto, el compromiso y el buen ánimo.
Para cumplir con dicho objetivo, intentamos que nuestras comunicaciones sean lo más positivas posibles, evitamos los juicios de valor, intentamos dejar los problemas externos al proyecto de lado y monitorear el clima de trabajo.
Para monitorear este objetivo utilizamos el documento provisto por la Facultad de Ingeniería, “Encuesta sobre funcionamiento interno del equipo” [16] al finalizar cada bimestre. Este documento nos dio una buena evaluación del relacionamiento individual y grupal, con el cliente y con la Universidad a través del tutor. La métrica aplicada es una escala numérica del uno al cinco con el siguiente significado:
1. Totalmente en desacuerdo 2. En desacuerdo
3. Ni en desacuerdo ni de acuerdo 4. De acuerdo
5. Totalmente de acuerdo Cerrar el ciclo Académico
Es el objetivo central para el equipo de este proyecto, culminar el proceso de la carrera Licenciatura en Sistemas de la mejor forma posible, logrando un proyecto con buena calificación, acorde al producto que le entregamos al cliente y al proceso de investigación y construcción que documentamos para la Universidad.
Podemos medirlo durante el proyecto con las revisiones, esto es en base a una calificación que nosotros hacemos de la revisión, con la aprobación del tutor para el pasaje a defensa y con la calificación final.
30 1.4.2 Objetivos del proyecto
Detallamos los dos objetivos del proyecto que nos planteamos, cada uno cuenta con un título, su descripción, contexto, y la métrica que utilizamos para medirlo durante el proyecto.
Lograr que el cliente resulte satisfecho
Es importante que el cliente quede conforme con el producto entregado, tenemos la responsabilidad de entregarle un producto alineado a sus expectativas, que cumpla el alcance esperado y sea del agrado de los usuarios. También es sustancial que resulte satisfecho con el proceso, y que vaya recibiendo valor durante la construcción.
Lo validamos en las semanas de review con pruebas y encuestas de satisfacción, las mismas son realizadas en cada fecha de entregable, que es cuando se le entrega al cliente una versión utilizable con un incremento acumulado de 4 sprints. Al analizar los resultados de estas actividades obtendremos una conclusión del grado de satisfacción del cliente. La métrica es una escala numérica del uno al cinco con el siguiente significado:
1. Totalmente en desacuerdo 2. En desacuerdo
3. Ni en desacuerdo ni de acuerdo 4. De acuerdo
5. Totalmente de acuerdo
Lograr una exitosa gestión del proyecto.
Implica cumplir las fechas de entrega, cumplir con el alcance negociado, ser productivos y sobre todo respetar la dedicación horaria comprometida al comienzo del proyecto.
Para esto manejamos distintas actividades para medirlo y sus respectivas métricas:
31 Dedicación: Cantidad de horas dedicadas al proyecto. Lo medimos contra las 15-20 horas semanales que propone la Cátedra.
Productividad: Alcance obtenido dividido la dedicación esperada, a ese resultado le damos un rango del 20% de desviación como meta.
Retrabajo: Cantidad de horas dedicadas a hacer una tarea ya realizada previamente, ya sea por falla de comunicación o desorden. Manejamos un rango meta del 10%.
Cumplimiento de fechas: Manejamos 0 días de atraso para las fechas de entrega de la Universidad y las fechas de entrega al cliente.
1.4.3 Objetivos del producto
Detallamos el objetivo del producto que nos planteamos, cuenta con un título, su descripción y contexto, y la métrica que utilizamos para medirlo durante el proyecto.
Entregar al cliente un producto completo
Un producto construido bajo el plan de calidad, debe asegurar un alcance completo, ser funcional, entregado en tiempo, construido bajo los estándares y orientado a generar la satisfacción de los usuarios.
Para ello utilizamos los siguientes valores clave:
Pruebas de usabilidad: Se realizan pruebas orientadas a usuarios en los bimestres 2 y 3, y se realiza un checklist de usabilidad de las Heurísticas de Nielsen. Calificamos las sesiones con un rango 1 a 4, siguiendo el criterio de Daniel Mordeki [17]. Nuestra rango meta es de Severidad 1: 0 detectados, Severidad 2: 0 detectados, Severidad 3: menos de 5 detectados, Severidad 4: menos de 10 detectados.
Cantidad de defectos: Tras las pruebas efectuadas al sistema se establece un listado de defectos no solucionados. Utilizamos la escala de AGESIC [18], referente a la cantidad de defectos del 1 al 4. Rango meta: entregar el sistema sin errores críticos ni mayores.
32 Estándares de documentación: Aplicaremos el documento 303 para verificación del formato. Rango meta: Nivel de conformidad A.
Estándares de programación: Utilizaremos una hoja de validación de estándar y de buenas prácticas asumidas. Utilizaremos una escala del 1 al 5 para verificar el nivel de cumplimiento alcanzado. Rango meta mayor a 3.5.
Encuesta de satisfacción a usuarios: Las realizaremos en el semestre 2 y 3 con una escala de 1 a 5 con un rango meta mayor a 3.5.
1.5 Estructura del documento
Introducción: Se introduce al proyecto, su contexto, equipo, interesados, cliente, proceso de investigación, gestión de objetivos y construcción de la solución.
Problema: Se describe el problema, se analiza a los distintos interesados y sus necesidades. Se valida el problema con el cliente. Comentaremos las conclusiones y lecciones aprendidas relativas a esta sección.
Solución: Se explica la solución propuesta, sus principales funcionalidades, el alcance acordado con los interesados, los desafíos principales de la solución, los entregables y sus etapas de entrega. Por último, detallaremos la validación realizada a la solución.
Comentaremos las conclusiones y lecciones aprendidas relativas a esta sección.
Marco metodológico: Se detallan las etapas que requirió el proyecto, las herramientas y metodologías utilizadas en cada etapa y como se gestionaron los objetivos. También se analizan las características del proyecto, equipo y cliente. Comentaremos las conclusiones y lecciones aprendidas relativas a esta sección.
Ingeniería de requerimientos: Se explica cómo se priorizaron las necesidades de los interesados y se especificaron como requerimientos (funcionales, no funcionales y restricciones). Luego como fueron implementados, priorizados y cómo ayudaron a definir el alcance y cronograma del proyecto. Comentaremos las conclusiones y lecciones aprendidas relativas a esta sección.
33 Arquitectura y diseño: Se describe cómo se diseña el sistema para cumplir con los requerimientos y atributos de calidad, mediante el uso de patrones de diseño, tácticas y la selección de una infraestructura adecuada para su funcionamiento. Comentaremos las conclusiones y lecciones aprendidas relativas a esta sección.
Gestión del proyecto: Se detallan las etapas del proyecto, la aplicación y resultado de las actividades, metodologías y herramientas planteadas en el marco teórico. Incluye la gestión de la comunicación, de los riesgos y de los objetivos del proyecto. Comentaremos las conclusiones y lecciones aprendidas relativas a esta sección.
Gestión de la calidad: Explicamos qué es la calidad para nuestro equipo y cómo la aseguramos durante el proyecto. Analizamos los distintos resultados que obtuvimos de actividades que realizamos durante el proyecto. Comentaremos las conclusiones y lecciones aprendidas relativas a esta sección.
Gestión de la configuración: Detallamos los elementos de la configuración, cómo fueron gestionados en el código y documentación. Se detallan las tecnologías utilizadas y cuáles fueron sus resultados. Comentaremos las conclusiones y lecciones aprendidas relativas a esta sección.
Conclusiones y lecciones aprendidas: En esta sección final repasamos las conclusiones y aprendizajes que nos dejaron las distintas etapas del proyecto y damos nuestra conclusión final, considerando el proyecto en su completitud. Comentaremos las conclusiones y lecciones aprendidas relativas a esta sección.
34
2 Problema
En este capítulo se describe el problema que vamos a resolver. Cómo es el contexto en el que surge, los actores que involucra y cómo validamos el problema.
2.1 Descripción
Nuestro cliente, Capicua, tiene más de 80 empleados. Ellos se encuentran trabajando de forma remota en diferentes países, a diferentes horarios y con diferentes cargas horarias.
Capicua cuenta con varios proyectos en paralelo, de distintos clientes internacionales.
Estos proyectos insumen unas 12.000 horas mensuales, las cuáles deben ser facturadas a los clientes y liquidadas como salario a los empleados. Para realizar correctamente estas tareas, se requiere tener el conocimiento de la totalidad de las horas discriminadas por tarea, proyecto y referidas al usuario que las ingresó en el sistema.
Hoy en día Capicua tiene problemas para poder cumplir estas dos tareas centrales, pese a que utiliza una herramienta de terceros, llamada Tmetric, en la cual gasta unos 5000 dólares anuales.
Los empleados registran las horas sin descripciones y algunas veces sin asignarle un proyecto. Corregir esta situación implica horas de trabajo de la gerencia, para poder realizar un seguimiento de los empleados y para saber a qué proyecto atribuir esas horas.
Esta tarea disminuye la productividad de la gerencia y genera un gasto no deseado.
Tampoco contribuye a la transparencia deseada, dado que al realizar la asignación de forma posterior se apela a la memoria de las personas y muchas veces se cometen errores.
También sucede que los empleados están registrando las horas fuera del horario convenido para trabajar y distribuyen la carga horaria semanal de manera diferente a la esperada por el cliente, que es de 6-8 horas diarias de lunes a viernes.
Esto dificulta el seguimiento del avance de los proyectos y hace compleja la comunicación en horario de trabajo que la empresa espera que exista dentro de los equipos.
35 Adicionalmente, el cliente tiene una gran dificultad para procesar las horas una vez están registradas, ya que no cuenta con una funcionalidad para ordenar, filtrar y agrupar los datos a su gusto, lo que se traduce en horas extra de procesamiento de datos y dificulta la toma de decisión.
El cliente nos plantea la necesidad de investigar un sistema en el que trabajó previamente, ya que dedicó varias horas en definición de reglas de negocio que no quiere repetir.
Nos solicita refactorear, corregir lo que sea necesario y desarrollar lo que se necesite para que cumpla las reglas de negocio. El sistema fue desarrollado en Node js, utilizando Prisma como ORM para manejar una base de datos en MySQL. No cuenta con un frontend, ni documentación de calidad asociada.
Nos solicita crear un frontend desarrollado con Flutter, ya que está interesado en experimentar con esta nueva tecnología. Estas tecnologías planteadas por el cliente implican al equipo tener que capacitarse, puesto que no tenemos conocimientos sobre ellas ni del ámbito académico ni del profesional.
2.2 Cliente y contexto
El cliente tiene su oficina central en Uruguay, pero durante la pandemia de Covid-19 no ha utilizado de manera obligatoria las oficinas, por lo cual la mayoría de sus empleados trabajan de forma remota. Adicional a esto, cuenta con muchos empleados e incluso uno de sus directores en el extranjero.
Para que funcione la empresa correctamente, los procedimientos de trabajo deben estar claros y ser aplicados por todos los integrantes. En lo referido al registro de horas, detectamos un quiebre en los procedimientos establecidos. La diferencia se da porque no están correctamente comunicados y en consecuencia aplicados por los usuarios. A esto se le suma que hay asignaciones de roles que no corresponden al tipo de usuario.
Detectamos que todas las partes entienden la problemática actual. Son capaces de entenderla para su rol e interpretarla para el resto de los roles de la empresa.
36 Entienden la necesidad de una solución y tienen la voluntad necesaria para utilizar un nuevo sistema para ello.
2.3 Interesados
El sistema tiene importancia para distintos actores, los agrupamos en estos cuatro grupos de interesados: directores, administradores, empleados y clientes.
En el anexo “Análisis de interesados” es posible ver en profundidad el análisis inicial de interesados y su posterior refinamiento.
2.3.1 Directores de Capicua
Hoy en día son 3 socios que necesitan tomar decisiones gerenciales de alto nivel.
Necesitan reportes ordenados, agrupados y filtrados, para tomar decisiones, organizar la facturación de los proyectos y liquidar los sueldos a los empleados.
Desean ser reportados en caso de haber situaciones que se salgan de su curso establecido;
empleados que trabajen de menos o de más en un proyecto; proyectos que requieran recursos extra.
2.3.2 Gerentes de Capicua
Son un grupo de gerentes de segundo nivel, que manejan los proyectos, los equipos y las áreas complementarias de la empresa como RRHH, Comercial y Administración.
Necesitan darle seguimiento al proyecto y a un equipo, ver la dedicación horaria, autorizar horas extra, cargar horas no autorizadas y editar horas mal ingresadas.
Desean hacer las configuraciones del espacio de trabajo para que las tareas se hagan en los momentos que la empresa necesite.
2.3.3 Empleados de Capicua
Son la mayoría de los actores, se refiere a todos los empleados. Los roles anteriores también tienen estas necesidades que se describen a continuación:
37 Necesitan registrar periodos de tiempo, describir la tarea puntual, y asociarlo a un proyecto.
Quieren que realizar esta tarea sea simple y que les tome poco tiempo, ya que el tiempo que estén dedicando a iniciar este proceso es tiempo que no cobran.
Desean poder ver cuánto tiempo van dedicando durante la jornada laboral, cuánto tiempo libre tomaron y sus registros de tiempo de los días anteriores.
2.3.4 Clientes de Capicua
Son las empresas que contratan los servicios de Capicua mediante la adjudicación de proyectos. Están ubicados en distintos países, y tienen contacto directo con los empleados de Capicua porque integran los equipos de trabajo.
Necesitan conocer el detalle de las horas que están pagando, qué empleado las realiza y poder tener una visión a detalle de la dedicación del proyecto.
2.4 Validación del problema
La identificación del problema surge en estrecha colaboración con el cliente, la definición del problema está validada por el cliente y podemos verla en el Anexo “Validación del problema”.
A continuación, enumeramos los principales problemas:
- Los usuarios no registran en tiempo y forma los periodos trabajados.
- Los usuarios no saben cuántas horas llevan trabajadas.
- La asignación actual de roles no corresponde con el tipo de tareas que realizan los usuarios.
- Los administradores no tienen configurados los días y horarios de trabajo conforme a lo que pretende la empresa (lunes a viernes entre las 08:00 y las 20:00).
38 - No están registrados los feriados, ni es posible configurar días especiales de
trabajo.
- Los reportes requieren de revisiones para estar completos y no pueden verse en tiempo real por contener registros inválidos.
- Los reportes no presentan la información como la gerencia desea y/o necesita verlos.
- Los clientes deben confiar en los reportes confeccionados por el gerente del proyecto.
- Pagar licenciamiento de forma mensual a Tmetric y no estar satisfecho.
- No conocer las desviaciones del rendimiento esperado de un empleado, mediante alertas.
- Los empleados se encuentran distribuidos.
- Cuentan con horas previamente invertidas en un proyecto inconcluso.
39
3 Solución
En este capítulo describimos la solución que se planificó para solucionar la problemática anteriormente descrita. Explicaremos las principales funcionalidades, cómo fue el proceso de priorización y negociación del alcance. Además, detallamos a alto nivel las etapas y distintos entregables que componen a la solución.
3.1 Solución propuesta
Proponemos una solución que resuelva las principales necesidades de los interesados y al ceder los derechos económicos a Capicua, le genere un ahorro anual del entorno de los 5000 dólares, que se genera al no depender más de un software de terceros, en este caso Tmetric.
Se trata de una aplicación Web, esto permite que se ejecute en navegadores web y asegura el correcto funcionamiento con los equipos provistos por Capicua, siempre que tengan conexión a internet.
La aplicación cuenta con tres roles; Owner para el manejo de los directores, Admin para los gerentes de segundo nivel, y Basic para los empleados. Esta asignación de roles cumple con las necesidades, ya que esta pensada para la realidad específica del cliente.
Los usuarios con roles Owner y Admin, pueden configurar las reglas de trabajo; ver reportes en tiempo real de las horas registradas, del rendimiento de los proyectos y de desviaciones; también hacer las altas, bajas y modificación de las entidades del sistema.
Estas funcionalidades permiten solucionar los problemas en cuanto a reportes, claridad de los datos, organización de periodos válidos de trabajo e imprimir reportes para mostrar a los clientes en tiempo real, lo que aporta la transparencia deseada.
Todos los usuarios pueden registrar horas en los días y horarios que tienen habilitados.
Para ello deben de forma obligatoria ingresar una descripción, seleccionar un proyecto e iniciar el timer y finalmente detenerlo cuando termine la tarea. Esto soluciona la
40 problemática del registro de horas incompleto, y limita el trabajo fuera de horarios estipulados.
Adicionalmente, es posible ver los periodos de tiempo registrados históricamente. Esto permite llevar un control de las horas trabajadas y conocer cuál será la liquidación de horas mensual.
La aplicación utiliza una arquitectura de tres capas y se desarrolla con las tecnologías planteadas por el cliente. Esto permite que se reutilice parte del desarrollo previo en Node Js y su base de datos en MySQL. A la vez que utiliza Flutter Web para el desarrollo del frontend, que es una tecnología que el cliente tiene interés en experimentar.
La aplicación está diseñada siguiendo los estándares de Material UI, y un plan de calidad enfocado en la usabilidad. Esto permite que la herramienta sea fácil de utilizar, la curva de aprendizaje sea baja y que utilizarla sea beneficioso para el usuario.
Finalmente, la aplicación se hostea en los servicios de AWS de Capicua para aprovechar la infraestructura propia, utilizamos un balanceador de carga, y tenemos un dominio asociado (trackeate.com) para facilitar el acceso de los usuarios. Esto permite que los empleados puedan acceder de forma simultánea a la aplicación en el horario habitual de trabajo sin sufrir cortes o demoras.
3.2 Principales funcionalidades
A continuación, veremos en detalle las principales funcionalidades propuestas. Es posible ver en el Anexo “Vistas multimedia del sistema”, un video explicativo del uso del sistema por parte de cada tipo de usuario y las imágenes de las funcionalidades de todo el sistema.
Gestión de clientes: Permite a los usuarios con rol Owner o Admin, crear, modificar y eliminar clientes. Cada cliente cuenta con un nombre, datos de contacto, de facturación e imagen. También permite ver un listado de clientes, con un resumen de datos.
Gestión de proyectos: Permite a los usuarios con rol Owner o Admin, crear, modificar y eliminar proyectos. Cada proyecto pertenece a un cliente, tiene un nombre, datos de facturación, un presupuesto y carga horaria asignada, y un equipo de usuarios que pueden
41 cargarle registros de tiempo. También permite visualizar el listado de proyectos y un resumen de su presupuesto asignado y su carga de horas real.
Gestión de usuarios: Permite a los usuarios de rol Owner o Admin, invitar, modificar, bloquear, desbloquear y eliminar usuarios. También permite ver un listado de usuarios, con un resumen de datos.
Para invitar usuarios se utiliza una dirección de correo electrónico, que envía un correo de invitación para registrarse en el sistema. Dicho registro puede ser completado de forma manual por el usuario o agilizado con Google Sign Up.
Configuración de usuario: Permite a los usuarios de rol Owner o Admin, modificar el rol de un usuario a las categorías: Basic o Admin, modificar las condiciones de trabajo a un usuario, establecer días de trabajo, horas de trabajo, horarios de trabajo, precios de hora y tareas en las cuales se desempeña.
Login de Usuarios: Permite a todos los usuarios registrados ingresar al sistema, pueden hacerlo mediante mail y contraseña elegidos en un proceso de registro manual, o de forma simplificada con Google Sign In.
Logout de usuarios: Permite a los usuarios salir del sistema de forma controlada.
Registro de Tiempo: Permite a todos los usuarios que han ingresado al sistema iniciar un timer, agregarle una descripción y seleccionar el proyecto que corresponde, ver el tiempo que llevan trabajado ese día y sus registros de días anteriores.
Permite a los usuarios de rol Owner o Admin, cargar periodos de tiempo de forma manual, indicando una descripción, proyecto, fecha y hora de inicio, fecha y hora de fin y usuario al que corresponde ese período de tiempo. Esto se utiliza para agregar registros de tiempo que no fueron “trackeados” por algún usuario por algún olvido, o por no estar previamente autorizados a trabajar en ese momento.
Permite a los usuarios de rol Owner o Admin eliminar registros de tiempo de algún usuario.
42 Reportes: Permite a los usuarios ver sus horas cargadas del día y de períodos de tiempo anteriores. Permite a los usuarios de rol Owner o Admin, ver un reporte detallado de todas las horas cargadas, propias o de otros usuarios, pudiendo ordenar, agrupar y filtrar por determinados campos.
3.3 Alcance del proyecto
El alcance del proyecto fue negociado al iniciar el proyecto y renegociado en el mes de febrero 2022 al reducirse el equipo.
Es un proyecto complejo y desarrollado en un corto plazo, que incluyó la investigación y refactorización de un sistema del cliente al cual no se tuvo acceso hasta comenzado el proyecto.
Todas las funcionalidades descritas en la sección “Principales Funcionalidades” fueron desarrolladas.
De común acuerdo con el cliente, se priorizó la visualización en dispositivos de escritorio Mac, ya que son los que provee Capicua a sus empleados.
Quedó pendiente su ajuste para dispositivos móviles, que sabemos son de uso frecuente por los usuarios, pero no el establecido para trabajar por el cliente, por lo cual no forma parte del alcance definido.
Se trabajó pensando en funcionalidades que quedaron por fuera del alcance, como un sistema de alertas automatizado, la gestión de las licencias de personal y el despido de los empleados, dejando alguna de estas funcionalidades ya diseñadas.
3.4 Desafíos del proyecto
El proyecto presentó varios desafíos que variaron entre lo humano, técnico y de gestión.
Primero, enfrentarnos a un cliente real con expectativas altas y necesitado de una solución; con poco tiempo para dedicar al equipo, debido a la complejidad y carga laboral que afronta Capicua este año.
43 Segundo, contamos con el desafío de aplicar los conocimientos adquiridos durante la carrera para la gestión de un proyecto de una escala superior a la acostumbrada, gestionar tiempos, prioridades, definir correctamente los requerimientos, limitar el alcance, gestionar la calidad y gestionar un equipo.
Tercero, nos enfrentamos a tecnologías desconocidas por nosotros, Node js, Prisma, Flutter y AWS. Para esto, fue necesario realizar cursos, estudiar y practicar lo necesario para ir construyendo el sistema. Adicional a esto, tuvimos que trabajar con un proyecto desarrollado previamente, sin documentación clara y con una calidad completamente distinta a la prometida por el cliente.
Cuarto, construir la arquitectura de un sistema web sin tener experiencia previa en dicha área, nos capacitamos con la ayuda del tutor y de otros especialistas para lograr tener una arquitectura acorde a los requerimientos.
Quinto, sufrimos la perdida de un integrante del equipo, por lo cual tuvimos que reestructurar sobre el final del proyecto la forma de trabajar y la asignación de tareas.
Sexto, utilizamos Flutter, una tecnología que aún es nueva en el mercado, que no tiene documentación y tutoriales completos, que discontinua tecnología como nos sucedió con la herramienta de testing integrada.
Séptimo, la funcionalidad de reportes es la que aporta mayor valor al cliente dado que es diseñada a su medida, se necesitan consultas complejas para su obtención y debe ser performante para mantener una buena usabilidad del sistema.
3.5 Entregables
Durante el proceso de negociación del alcance se realizó un storymap [19]. Este fue priorizado y permitió dividir el proyecto en dos entregables, cada uno cada dos meses. En la sección “Gestión del proyecto” detallaremos el contenido de cada uno de los entregables.
El software completo cuenta con los siguientes elementos:
44 Documentación Académica: Este documento y sus anexos.
Código: Acceso al repositorio con el código del frontend y backend.
Backups: Imágenes de las bases de datos y sus contenidos.
Manuales, diagramas y video tutoriales: Para comprender el funcionamiento del sistema, mantener y extender el mismo.
Api documentada: Para cada recurso disponibilizado, se muestra su forma de consumirlo.
Aplicación en producción: Puesta en producción de la aplicación completa (Frontend, backend, balanceador de cargas y base de datos) en AWS.
3.6 Imagen del Producto
Para la imagen del producto se contó con un manual de estilos definidos por el cliente.
El dominio fue elegido y comprado por el cliente.
Nos apoyó con la utilización del sistema Figma [20] de la empresa, para el diseño de las interfaces de usuario. En él contamos con los controles, componentes, paleta de colores, fuentes, iconografía y demás recursos gráficos para el armado de prototipos y el frontend final.
Ilustración 1 Logo del producto
45
Ilustración 2 Manual de estilo
3.7 Validación de la solución
La solución fue validada con el cliente y usuarios. Lo hicimos mediante pruebas orientadas, utilizando prototipos. Al comienzo del proyecto, los prototipos fueron dibujados y al avanzar el proyecto se transformaron en los diseños en Figma.
Es importante recalcar que la solución estuvo validada desde un comienzo, trabajamos con apertura a los cambios y entendiendo que iban a producirse mejoras en el transcurso del proyecto, este es uno de los argumentos que nos llevó a gestionar este proyecto con metodologías ágiles y un proceso iterativo incremental.
Los cambios en los requerimientos durante el proyecto, sucedieron por lo que se conoce como Ley de Ziv y de Humphrey. Dos leyes populares del mundo ágil que citamos a continuación:
“La Ley de Ziv, los requisitos nunca se entienden completamente.
La Ley de Humphrey, los usuarios no saben realmente el software que quieren hasta que lo ven funcionando.” [21]
46 Esto quiere decir que el cliente y los usuarios son realmente capaces de identificar la totalidad de requerimientos en etapas más avanzadas el proyecto, especialmente cuando lo están utilizando.
Las respuestas, cambios y sugerencias que obtuvimos mediante interacciones con usuarios y cliente durante el proyecto permitieron mejorar la solución.
El cliente está satisfecho con la solución final entregada y su carta con comentarios del producto figura en el anexo “Comentarios finales del producto entregado”.
4 Marco metodológico
En esta sección se relata las herramientas y metodologías utilizadas en cada etapa del proyecto, por qué son apropiadas para el equipo, el cliente y el proyecto.
4.1 Características del proyecto
El proyecto cuenta con características positivas y otras que generan desafíos por su complejidad.
Primero, cabe destacar que entendimos las necesidades iniciales del cliente, y que al contar con dos integrantes de la empresa del cliente pudimos conocer de primera mano la situación y las necesidades de los usuarios. Por lo cual el dominio en el que se planteaba el problema fue rápidamente asimilado.
Segundo, el punto de partida del proyecto fue incierto. Esto se debió a que el cliente nos solicitó utilizar un backend desarrollado previamente, al cual no tuvimos acceso hasta comenzado el proyecto, la calidad del código, su funcionamiento y su documentación distaron de ser la deseada y transformaron la situación en un problema a resolver.
Tercero, el alcance del proyecto hubo que negociarlo al comienzo del proyecto, ya que el cliente, además de la aplicación web, deseaba aplicaciones móviles y plugins de integración con distintas herramientas web. Fue necesario adaptar el alcance al tiempo establecido para el proyecto y a las capacidades del equipo. El cliente quedo conforme con esta situación.
Cuarto, las funcionalidades a alto nivel siempre estuvieron claras, sin embargo, los requerimientos no estuvieron totalmente especificados desde un comienzo, fueron cambiando y agregándose durante el transcurso del proyecto, gracias a pruebas de prototipos o situaciones de alta complejidad.
Quinto, fue necesario brindar entregables del proyecto periódicamente para validar el avance y en el caso de las entregas al cliente, ir ganando valor desde etapas tempranas mediante la utilización de algunos módulos.
48 4.2 Características del cliente
Capicua tiene experiencia en el desarrollo de aplicaciones web mediante metodologías ágiles y expertise en usabilidad. Esta experiencia fue muy útil para manejar un mismo lenguaje técnico, y para poder integrar miembros del cliente en las actividades de Sprint planning y semanas de review.
Capicua expresó su voluntad de comprar cursos para capacitar en las tecnologías necesarias al equipo y disponibilizar un experto en Flutter para apoyarnos. Esta característica fue de apoyo para la etapa de investigación y para la realización de spikes.
Alicia y Stephany integran la empresa del cliente, y tienen buena relación con sus compañeros de trabajo. Esto ocasionó que los empleados tengan buena voluntad para apoyarnos con pruebas de usuarios y comentarios a través de encuestas cuando fue necesario.
Capicua es representado por Carlos Traibel, uno de los directores de la empresa. Cuando no tuvo disponibilidad, fue Yoselin Velazquez la representante, quien forma parte de los gerentes de segundo nivel de Capicua. Ellos participaron en la redacción de las historias de usuario y validaron los requerimientos.
Capicua se dedica a vender consultoría especializada en UI y UX, por lo cual nos apoyó con su expertise en con el manual de estilos y digitalización de algunos de los prototipos.
Esto fue de vital importancia en la etapa de investigación y con el diseño centrado en el usuario.
4.3 Características del equipo
El equipo original de la tesis, compuesto por tres estudiantes, estaba balanceado correctamente para afrontar todas las áreas del proyecto.
Alicia, contaba con experiencia en testing, en aseguramiento de la calidad, era aplicada y metódica para realizar documentación.
49 Stephany, tiene experiencia en desarrollo de software en distintos lenguajes y es perfeccionista, lo que ayuda a alcanzar altos niveles de calidad.
Jaime, en cambio, es un poco más pragmático, tiene experiencia en la gestión de proyectos, capacidad de comunicar y gestionar un equipo.
Lo mayor dificultad fue la realización de la solución con tecnologías desconocidas. Hubo que capacitarse en Flutter web, Node Js, Prisma y AWS para poder empezar a trabajar.
Aquí claramente Stephany se destacó por tener años de experiencia de desarrollo profesional. Alicia siempre tuvo dificultades con el desarrollo y Jaime nunca tuvo experiencia profesional.
En diciembre cuando comenzaba la etapa de construcción del proyecto empezamos a experimentar dificultades con la situación de Alicia. Por lo cual empezamos a reasignar las responsabilidades, este proceso terminó en febrero al confirmarse su baja del equipo y el resultado es el siguiente.
Stephany lideró el diseño y desarrollo de la solución. Y Jaime lideró la etapa de documentación, la gestión de la calidad, y las tareas relacionadas a las pruebas del sistema.
4.4 Roles
Dado que es un sistema complejo y con variedad de tareas, decidimos definir roles para el proyecto. Los roles fueron basados en las características y habilidades de los integrantes del equipo.
El responsable se encargó de que se cumplan todas las tareas adjudicadas al área, no realizándolas en su totalidad, sino gestionando las tareas para asegurar su completitud.
Durante la etapa de Investigación trabajamos con el equipo original:
Gestión del proyecto: Jaime
Definición de marco metodológico: Jaime
50 Gestión de los objetivos: Jaime
Experimentos y prototipado: Jaime Plan de calidad: Stephany
Capacitación en tecnología para investigaciones: Stephany Investigación del backend entregado: Stephany
Diseño de la arquitectura de la solución: Stephany
Investigación de la documentación del backend entregado: Alicia.
Identificación y análisis de los interesados: Alicia Validación del problema y solución: Alicia
Para la etapa de construcción, el equipo comenzó a experimentar dificultades con la situación de Alicia, por lo cual se acordó que reduzca su carga y asuma las actividades de testing y pruebas de usabilidad. Los resultados no fueron acordes a lo comprometido. A partir de febrero, tras su baja del equipo, los roles quedaron definidos de la siguiente manera:
Ingeniería de requerimientos: Jaime Diseño y Arquitectura: Stephany Construcción del sistema: Stephany Gestión de la calidad: Jaime
Pruebas: Jaime
Documentación del proyecto: Jaime Documentación del cliente: Stephany
Gestión de la comunicación con el cliente: Stephany
