Surikat

12. Buenas prácticas para crear un proyecto

En esta entrada se recogen recomendaciones para agilizar la creación de proyectos, optimizar su legibilidad y evitar errores comunes durante la configuración.

12.0 Configuración de proyectos

Algunas recomendaciones que solemos dar a la hora de generar un nombre de proyecto es que sea esclarecedor sobre el tipo de información que se va a encontrar, fácil de recordar y escueto. Criterios y consejos que pueden ayudar para denominar al proyecto:

  • Nombre que capture la esencia o el propósito principal del proyecto que lo hace único y cómo puedes condensarlo en una o 2 palabras.
  • Evitar jergas y términos técnicos a menos de que cualquiera pueda entenderlo. Si el proyecto está dirigido a profesionales de un campo específico.
  • Evitar Abreviaturas y Acrónimos Complicados: Aunque útiles para acortar nombres largos, las abreviaturas y los acrónimos pueden ser difíciles de recordar o de entender en el futuro.
  • Considera si el nombre seguirá siendo adecuado a medida que el proyecto crezca o se expanda.
  • Metáforas o Analogías: Usar metáforas o analogías puede ayudar a crear un nombre memorable y descriptivo.

12.1 Configuración de usuarios

Idealmente, la cuenta base para el proyecto (Admin), se basará en un correo electrónico ficticio desde la que se gestionará cualquier incidencia y a la que también tendrán acceso los trabajadores de Surikat para dar soporte. Aquello/s usuarios encargados de la gestión del proyecto pueden ser nombrados como «coadmin«, con los mismos permisos que la anterior, pero dentro de una cuenta personal del usuario en cuestión.

Generalmente, somos nosotros quienes crean este correo en base al código interno con el que asignamos ese proyecto, de manera que nos resulte sencillo de encontrar a la hora de realizar alguna tarea de soporte. P.e. «aca_composta@surikat.io» para un proyecto de compost  de la empresa ficticia «Acaymo Compost S.A.» o «lupuergc@surikat.io» para un proyecto de seguimiento de luminarias en el puerto de Gran Canaria.

En este punto, invitaremos a otros usuarios a participar en este proyecto desde sus cuentas de correo reales y les adjudicaremos roles como se indicó en el Punto 8. de este manual. Importante: A pesar de que se puede dotar a cada usuario de determinados permisos de forma manual, recomendamos encarecidamente hacer un esfuerzo en generar roles que adscribir a cada grupo de usuarios, pues nos ahorrará muchísimo tiempo en la configuración del proyecto cada vez que entre o salga un usuario nuevo.

12.2 Configuración de cuestionarios

El nombre de los cuestionarios debe ser corto, intuitivo y encontrarse agrupado junto a otros similares ya sea por la dinámica que realizan los trabajadores o por un origen común de los datos. De esta forma, generamos una vista limpia y poco cargada de información que el usuario ya conoce, además de una forma intuitiva de encontrarlos.

Idealmente, los nombres de los cuestionarios no deben superar las 2 palabras. Evitamos el uso de preposiciones y nexos y si se trata de información redundante, es conveniente acortar las palabras. P.e., Inspecciones = Insp. Además, se debe agrupar todos aquellos cuestionarios que guarden cierta relación o dinámica. En este caso, se han agrupado todos los cuestionarios que albergan las inspecciones que deben realizar los trabajadores de forma recurrente. La otra opción, sería agruparlos por procedencia. P.e. Agrupar “Insp. CM” con “Inv. CM”.

desplegable cuestionario surikat

12.3 Configuración de campos

En el Punto 2 de este manual tienes una descripción de todos los tipos de campo y en el Punto 3 destripamos algunas de sus funcionalidades. Este apartado lo hemos creado para proponer algunas recomendaciones que mejoran la legibilidad del proyecto, especialmente para el usuario que accede desde su móvil para rellenar cuestionarios.

12.3.1 Títulos

Al igual que en caso anterior, los nombres de cada campo deben ser cortos para no saturar con demasiado texto al usuario a la hora de tomar un registro, pero aportando suficiente información como para que no se creen dudas a la hora de rellenarlo. Se recomienda un máximo de 3 o 4 palabras para definirlo.

El caso de la izquierda es ideal. Casi siempre puede completarse con dos palabras. El caso de la derecha es más complejo y requiere de información más concreta, por lo que no queda más remedio que poner más de 4 palabras, pero aún puede recortarse sin perder significado. P.e. “TENSIÓN PUNTO MÁS DESFAVORABLE (V)». Aquí prima la coherencia a la legibilidad.

12.3.2 Campos ocultos

Aquellos campos que sean autocalculables (ver Punto 3) es decir, que se generen en base a los datos que se introducen en otros campos, deben ser no visibles para los usuarios. Esto lo que hace es que no les estorbe un campo que no deben rellenar y evitar malentendidos. Para ello, el usuario al que daremos permiso para verlo y editarlo, será la cuenta ficticia que hemos configurado anteriormente. Aunque este dato no lo puedan ver durante el registro, sí que se podrá consultar una vez se haya calculado.

12.3.3 Cantidad de opciones en los campos (radio buton /desplegables)

Salvo contados casos, no es recomendable añadir demasiadas opciones en los campos tipo “Radio Button” o “Desplegables”, pues a la hora de añadir el registro desde un móvil, el “scroll” puede ser bastante largo o molesto. Un número ideal de opciones es de 3 o 4 opciones, aunque hay casos donde esto debemos saltárnoslo.

Por ejemplo, si las opciones son nombres clave de los registros a introducir. P.e., si vamos a completar una inspección de una localización con un código claro (CM_01, CM_02, […], CM_30]. Estos, además de ser fáciles de buscar por estar ordenados numéricamente, suelen abrirse utilizando tecnología NFC, por lo que, aunque se genere una lista inmensa, el usuario solo tendrá que acercar el móvil a la pegatina para localizar su código.

Otro caso que puede ser una excepción es cuando se trata de un elemento clave para determinar todo el registro, como indicar si un registro se corresponde a un mes del año concreto: “Enero, Febrero, Marzo, […]”, como en el caso del proyecto AYA_COMPOSTA, donde se hace un único registro al mes.

12.3.4 Agrupados en el cuestionario

Para generar cierta cohesión y lógica interna a la hora de rellenar un cuestionario, es importante agrupar las cuestiones en pequeños grupos. En el caso de abajo se aprecia bien cómo funciona. Un primer campo de “MATERIAS PRIMAS” nos indica que vamos a estar introduciendo datos de peso (Tn. = Toneladas) de las propias materias primas. Mientras que los campos PODA y PODA MANCOMUNIDAD nos hacen diferenciar el origen de estas materias primas y nos ayudan a interpretar mejor dónde hay que añadir cada dato que el usuario ha obtenido

Importante: Evita introducir agrupados dentro de otros, pues se puede generar ruido a la hora de realizar cálculos o introducir datos desde la app. En este caso, se ha puesto MATERIAS PRIMAS (Tn.) como un agrupado que solo recoge el MES REPORTADO para que sirva como Encabezado del resto.

12.4 Configuración de informes y maquetaciones

Siempre que puedas, separa el contenido de las fichas de impresión y los informes (ver puntos 4 5 para más información) en varias tablas diferentes. Esto hará que sean más fáciles de editar y evitaremos cambios indeseados al cambiar algún parámetro o añadir nuevos campos. En el menú de Tabla podemos seleccionar cuántas filas y columnas queremos. No pasa nada si no tenemos claro cuántas vamos a necesitar exactamente, porque podremos añadir filas y columnas como en un excel normal o incluso combinar celdas.

Recomendación: Haz click derecho en la tabla, «Propiedades de la tabla», ve a “Avanzado” y donde pone: “Estilos”, mantén el “width” (anchura) que aparece en la imagen, pero cambia los “500px” por “100%” («width:100%;). Esto cambiará la unidad de medida de la tabla, ya que en vez de calcular su ancho en píxeles (difícil de determinar al ojo), lo hará en base al grosor total de la hoja de impresión (porcentaje), mucho más intuitivo a la hora de maquetar.

12.5 Configuración de orden de columnas

Propuestas de más criterios para seleccionar columnas visibles o principales:

  • Dar prioridad a las columnas que tengan una relación directa o sean necesarias para interpretar correctamente otros datos mostrados. Esto ayuda a comprender el contexto sin necesidad de buscar información adicional.
  • Columnas que tiendan a estar completas o que sean esenciales para la integridad de los registros. Esto asegura que la vista principal refleje un conjunto de datos coherente y completo.
  • Columnas con datos que requieran actualización o revisión frecuente, como estatus de tareas o alertas de mantenimiento, para asegurar que la información relevante sea visible y esté al día.
  • Columnas que contengan datos críticos para la toma de decisiones operativas o estratégicas. Esto podría incluir indicadores clave de rendimiento (KPIs), estados de proyectos, o métricas de desempeño

Ejemplo: En el caso de AYA_COMPOSTA, las columnas seleccionadas son el MES en que se realiza el reporte, el volumen total de ENTRADAS de MATERIAS PRIMAS, que, al ser un autocalculable, el usuario no lo puede ver al rellenar el registro, pero sí que se genera y se visualiza en esta vista. El volumen total de SALIDAS de compost y el sumatorio total de PODAS y PODAS MANCOMUNADAS.

Estos datos son los más relevantes para tener una visión general de todo lo que se ha producido, pero debe consultarse con el cliente una vez hecho, por si quisieran resaltar otro valor que consideran importante.