Gestión de proyectos para agencias y estudios

El trabajo cruza cuentas: el mismo diseñador está en tres marcas, el copy escribe para un retainer y un lanzamiento, y el PM es quien “sabe cómo va todo”. El caos se siente como falta de gente. Casi nunca lo es.

• Diseñadores y developers compartidos entre cuentas, sin tope de frentes.
• Slack, mail y WhatsApp como backlog paralelo al tablero.
• Kickoff que arranca “y vamos viendo”: el alcance se negocia en la semana 6.
• Un PM que aprueba por todos: si se enferma, el estudio se detiene.

Un freelancer resuelve esto con un tope personal de 2 clientes — ver gestión de proyectos para freelancers. Una agencia tiene el mismo problema a escala de equipo: capacidad compartida, no heroísmo de un PM. El mapa de portafolio está en cómo gestionar varios proyectos a la vez.

El indicador que más distorsiona un estudio es la utilización: “si nadie está idle, vamos bien”. Utilización alta con muchos frentes abiertos es lo contrario de entregar. Cada persona paga cambio de contexto; cada cuenta espera; nada cierra. Dos números importan más que las horas vendidas: frentes activos por persona (1–2 en foco profundo) y tiempo hasta el próximo entregable visible por cuenta.

Si un diseñador salta entre cinco cuentas el mismo día, la utilización se ve perfecta y la entrega, lenta. Bloques de medio día ganan a 12 tickets de 25 minutos. Cómo bajar el trabajo empezado está en reducir el trabajo en curso.

Mezclar retainer y proyecto en la misma cola es cómo el trabajo recurrente se come al trabajo con fecha. El retainer llega continuo; el proyecto tiene hito. Si compiten sin regla, gana el que grita.

• Capacidad reservada para el retainer (un bloque fijo) y capacidad aparte para proyectos. Si el retainer se desborda, es change request, no un “rato extra”.
• Cola visible: lo que no está en el tablero no se trabaja, aunque haya llegado por Slack.
• Un proyecto no se “cuela” en horas de retainer: o recorta el retainer de esa semana, o mueve la fecha del proyecto.

Scrum con sprints rígidos encaja mal cuando las cuentas no comparten ritmo. Kanban con WIP por disciplina (diseño, contenido, desarrollo, PM) encaja mejor: flujo continuo, tope por tipo de trabajo, no “un sprint para todas las marcas”. Comparativa en Kanban vs Scrum; el menú más amplio, en metodologías de gestión de proyectos.

El WIP por disciplina protege a las personas compartidas: si diseño tiene límite 2, la tercera cuenta espera aunque el comercial haya prometido “esta semana”. Cómo se fija el número está en Kanban y límites WIP.

El PM como único aprobador es un cuello de botella disfrazado de control. Por cada cuenta, una matriz RACI mínima: quién ejecuta, quién aprueba (cliente), a quién se consulta. El PM no puede ser Aprobador de todo. Cómo soltar eso está en cómo delegar y dejar de ser el cuello de botella.

El kickoff no es una bienvenida: cierra alcance dentro/fuera, canal, aprobador del cliente, WIP comprometido y fecha del primer entregable. Si no queda escrito, el proyecto ya empezó mal. Una plantilla evita improvisar — ver plantillas de gestión de proyectos.

El status interno de 45 minutos por cuenta no informa: recita el tablero. Lo que sí hace falta es una vista semanal de portafolio (estado, hito, capacidad por disciplina, riesgos) y un status escrito por cuenta, que también se le puede mandar al cliente.

Cómo migrar de la reunión al tablero está en reemplazar reuniones de status por un tablero. El mismo patrón aplica a estudios especializados: un estudio jurídico separa clientes, expedientes y tareas desde el día uno — ver cómo configurar Hito para un estudio jurídico.