Parte: 16 — Producción, publicación, monetización y LiveOps · Fuente: Heather Maxwell Chandler, The Game Production Toolbox ⏱️ Duración estimada: 50 min · Nivel: Intermedio
Un juego es un producto multidisciplinar: programación, arte, diseño, audio y producción tienen que remar en la misma dirección. Esta clase te enseña a definir los roles de un equipo de desarrollo, a decidir entre un equipo pequeño (ágil pero limitado) o grande (potente pero costoso en coordinación), y a montar los procesos y herramientas de comunicación que evitan el caos.
También abordarás la cultura de equipo y el problema del crunch: por qué las horas extra sostenidas destruyen calidad y personas, y cómo una planificación sana las previene. Al final habrás diseñado la composición mínima de un equipo real y elegido su stack de herramientas y su ritmo de trabajo.
Al finalizar, el alumno podrá:
Los temas van de lo estructural (quién hace qué) a lo operativo (cómo trabajan juntos) y terminan en lo humano (cultura y sostenibilidad). Un equipo funciona cuando las tres capas están alineadas: roles claros, procesos ligeros y una cultura que no depende del sacrificio personal.
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Roles: prog, arte, diseño, audio, producción | Cada disciplina cubre una parte insustituible del producto |
| 2 | Roles híbridos y multitarea | En equipos pequeños una persona lleva varios sombreros |
| 3 | Equipos pequeños vs grandes | El tamaño cambia velocidad, coste y coordinación |
| 4 | Comunicación y reuniones | Sin flujo de información el trabajo se duplica o se pierde |
| 5 | Herramientas: Trello/Jira/Discord | Soportan tareas, seguimiento y comunicación diaria |
| 6 | Cultura de equipo | Define cómo se toman decisiones y se resuelven conflictos |
| 7 | Crunch y sostenibilidad | Las horas extra crónicas hunden calidad y retención |
| 8 | Onboarding y documentación | Reduce la dependencia de personas concretas |
Distinguir "rol" de "persona" es la clave de esta clase: en un equipo indie una sola persona suele cubrir varios roles, y en uno grande un rol lo comparten varias. Manejar estos términos te ayuda a diseñar el equipo por funciones necesarias antes de pensar en nombres concretos.
Prepara cuentas gratuitas en una herramienta de tareas (Trello, Jira o GitHub Projects) y en un canal de comunicación (Discord o Slack). Para documentación compartida sirve Notion, Google Docs o un wiki. No se escribe código en esta clase. Ten claro el alcance de tu proyecto (de la Clase 267) para dimensionar el equipo. Revisa material sobre prevención de crunch en charlas de la GDC.
Entregable: ficha de equipo mínimo viable + plan de procesos y herramientas.
Parte 1 — Composición del equipo. Completa la tabla para tu proyecto:
| Rol | ¿Cubierto por? | Dedicación (%) | Responsabilidades clave | Riesgo si falta |
|---|---|---|---|---|
| Programación | ||||
| Arte / visual | ||||
| Diseño | ||||
| Audio | ||||
| Producción |
Marca los roles híbridos (una persona en dos casillas) y señala el punto único de fallo (persona sin reemplazo).
Parte 2 — Stack y procesos. Define: (a) herramienta de tareas y estructura de columnas del tablero, (b) canal de comunicación y canales/temas, (c) reuniones fijas (frecuencia, duración, objetivo), (d) dónde vive la documentación, y (e) tres reglas de cultura sana (ej.: no mensajes de trabajo fuera de horario, retro cada sprint, decisiones documentadas).
Parte 3 — Plan anti-bus factor. Identifica el conocimiento crítico que hoy vive en la cabeza de una sola persona (contraseñas, cómo se compila, decisiones de diseño no escritas) y define para cada caso una acción de mitigación: documentarlo, compartir acceso o formar a una segunda persona. El objetivo es que ningún ausente pueda detener el proyecto.
Rúbrica de autoevaluación del laboratorio:
Aplícalos a tu proyecto real: el objetivo es que salgas con un equipo y unos procesos que podrías poner en marcha mañana.
Entrega la ficha completa de tu equipo mínimo viable (tabla de roles con dedicación y riesgos) junto al plan de procesos: herramienta de tareas con columnas definidas, canal de comunicación con sus canales, calendario de reuniones fijas, ubicación de la documentación y tres reglas de cultura anti-crunch.
Criterio de aceptación: los cinco roles están cubiertos o justificados; se identifica al menos un punto único de fallo; el plan nombra herramientas concretas con su uso; hay reuniones con objetivo y duración definidos; las reglas de cultura son accionables y verificables.
La mayoría de problemas de equipo no son técnicos sino de coordinación: información que no fluye, decisiones que se olvidan y expectativas no dichas. Prevenirlos cuesta minutos; arreglarlos, semanas.
| Síntoma | Causa y arreglo |
|---|---|
| Nadie hace producción | Se asume que "se coordina solo". Asigna el rol explícitamente, aunque sea parcial |
| Decisiones que se re-discuten | No se documentan. Registra cada acuerdo en un lugar único |
| Reuniones eternas | Sin agenda ni límite. Fija objetivo y duración máxima |
| Crunch permanente | Planificación irreal. Recorta scope antes que sumar horas |
| Un rol sin reemplazo bloquea todo | Punto único de fallo. Documenta y reparte conocimiento |
| Herramientas dispersas | Cada quien usa la suya. Estandariza un stack único |
¿Cuál es el equipo mínimo para un indie? A menudo una o dos personas cubriendo roles híbridos. Lo esencial es que ninguna disciplina crítica quede huérfana.
¿Trello o Jira? Trello para equipos pequeños y flujos simples; Jira cuando necesitas reportes, workflows complejos y escala. Empieza simple.
¿El crunch a veces es inevitable? Un empujón puntual antes de un hito es una cosa; el crunch crónico es un fallo de planificación que erosiona calidad y salud del equipo.
¿Necesito un productor si somos pocos? Sí, aunque sea a tiempo parcial. Alguien debe velar por tiempos, comunicación y bloqueos, o el equipo pierde foco.
¿Cómo reparto tareas entre gente con distinta disponibilidad? Planifica según la capacidad real de cada persona, no la ideal. Documenta cuántas horas semanales aporta cada uno y asigna trabajo en consecuencia; sobrecomprometer a un voluntario a tiempo parcial es la causa más común de fricción.
¿Qué hago si dos miembros del equipo entran en conflicto? Sepáralo pronto y en privado. Céntrate en el problema concreto y en acuerdos verificables, no en culpas. Que una decisión quede escrita evita que el mismo conflicto reaparezca.
Chandler y Keith cubren la teoría de equipos y producción; las guías de Trello y Atlassian aportan las plantillas prácticas para montar tu tablero y tus ceremonias.
Clase 267 - Producción de juegos: scope, milestones y agile