Crear Workspace, Proyecto y Estructura Base

Objetivo

Crear una base de trabajo ordenada para un cliente, producto interno, area o iniciativa. El workspace y el proyecto son la estructura que permite que despues las tareas, horas, automatizaciones y documentos tengan contexto.

Si esta capa se crea mal, todo lo demas se vuelve mas dificil de auditar.

Cuando usar esta guia

Usala cuando:

• entra un cliente nuevo;
• arranca un producto interno;
• quieres separar una iniciativa importante;
• vas a invitar o preparar acceso para otra persona;
• necesitas medir horas por proyecto;
• vas a crear automatizaciones que deben caer siempre en un proyecto concreto.

Workspace vs proyecto

Workspace:

• separa usuarios, permisos, credenciales, proyectos y configuracion;
• representa un entorno operativo amplio;
• debe usarse como frontera de seguridad y organizacion.

Proyecto:

• agrupa tareas, tiempo, planes y documentacion;
• representa una iniciativa medible;
• vive dentro de un workspace;
• debe responder a "en que estamos trabajando y cuanto consume".

Ejemplo:

• Workspace: Soluciones Abiertas
• Proyecto: OPS Center, Web corporativa, Cliente X - mantenimiento

Paso 1: revisar si ya existe

Antes de crear nada, busca.

Por que importa:

• Duplicar workspaces o proyectos fragmenta tareas y horas.
• Si dos personas trabajan en sitios distintos, luego el resumen no sirve.
• Los duplicados hacen mas dificil configurar recurrentes y permisos.

Comprobaciones:

• El workspace aparece en el selector.
• El proyecto aparece en Producto -> Proyectos/Docs.
• El nombre coincide con la convencion usada.
• No hay otro proyecto con una variante del mismo nombre.

Paso 2: crear o seleccionar workspace

Ve a Gestion -> Workspaces.

Al crear workspace:

• usa un nombre estable y reconocible;
• evita nombres temporales como test, salvo que sea realmente un entorno de prueba;
• define si sera para cliente, producto interno o demo;
• revisa limites del plan si aplica.

Por que importa:

• El workspace sera la frontera para permisos y credenciales.
• Cambiar trabajo entre workspaces despues es mas delicado que crear bien desde el principio.
• Si se va a usar con pilotos, el workspace debe estar limpio y entendible.

Paso 3: revisar permisos basicos

Antes de crear trabajo real, confirma quien puede ver y operar.

Por que importa:

• Un usuario sin permisos adecuados no podra probar el sistema bien.
• Un usuario con demasiados permisos puede tocar credenciales o automatizaciones sensibles.
• Los pilotos deben probar flujos reales, pero con limites claros.

Regla practica:

• Owner/admin: configuracion, usuarios, credenciales y estructura.
• Operator: tareas, planes, ejecucion y revision diaria.
• Viewer/reviewer: consulta, feedback y validacion.

Paso 4: crear proyecto

Ve a Producto -> Proyectos/Docs.

Datos recomendados:

• nombre claro;
• departamento o area;
• objetivo;
• estado activo;
• descripcion breve;
• documentacion o notas iniciales si existen.

Por que importa:

• El proyecto permite agrupar trabajo por iniciativa.
• Las horas ejecutadas se suman desde los logs de tiempo de sus tareas.
• Los planes, flujos y recurrentes deben apuntar al proyecto correcto para no crear ruido.

Paso 5: definir convencion de nombres

No hace falta una taxonomia enorme, pero si una convencion minima.

Buenas convenciones:

• Cliente - area
• Producto - modulo
• Interno - iniciativa
• OPS - automatizacion

Evita:

• varios;
• pendiente;
• pruebas para trabajo real;
• nombres que mezclan cliente y producto sin criterio.

Por que importa:

• Los nombres se veran en filtros, resumenes y tareas.
• Con muchos proyectos, un nombre ambiguo cuesta tiempo todos los dias.

Paso 6: crear estructura minima del proyecto

Un proyecto listo para trabajar deberia tener:

• objetivo;
• tareas iniciales;
• plan o fase pendiente;
• responsable o persona que revisa;
• criterio de terminado general;
• documentacion base si aplica.

No hace falta documentar todo desde el primer minuto. Pero si debe existir suficiente contexto para que otra persona entienda por que existe.

Paso 7: conectar tareas y automatizaciones

Cuando crees tareas:

• asigna proyecto antes de cerrar;
• si la tarea es recurrente, fija el proyecto en la plantilla;
• si un flujo crea tareas, revisa que herede proyecto o lo pida;
• si una tarea se movio de proyecto, deja comentario si afecta a horas o contexto.

Por que importa:

• El resumen de horas por proyecto depende de que las tareas esten bien asociadas.
• Las automatizaciones sin proyecto generan trabajo dificil de encontrar.

Checklist de proyecto sano

Un proyecto esta listo si:

• tiene nombre claro;
• esta en el workspace correcto;
• tiene estado activo;
• tiene al menos una tarea o plan;
• las tareas importantes registran tiempo;
• no se usa como cajon de sastre;
• sus automatizaciones apuntan al proyecto correcto.

Errores comunes

• Crear un proyecto por cada tarea pequena.
• Crear un unico proyecto gigante para todo.
• Cerrar tareas sin proyecto.
• Mover tareas despues de registrar tiempo sin dejar contexto.
• Usar proyectos de prueba para trabajo real.
• Borrar proyectos en vez de desactivarlos.

Resultado esperado

Al terminar, deberias poder responder:

• donde vive este trabajo;
• quien puede verlo;
• como se llama el proyecto;
• que tareas y horas se asociaran a el;
• que automatizaciones lo pueden alimentar.