Nadie es dueño de nada. Por eso el build está atrasado.
Todo proyecto de co-desarrollo tiene su momento.
Milestone 3. Tal vez el 4. El build está atrasado. El estudio dice que el brief no estaba claro. El publisher dice que no se siguieron los entregables. Los dos tienen razón. Y el proyecto sigue atrasado.
Vi este patrón antes de trabajar en gaming — en consultoría, en distintas industrias. En el momento en que un proyecto atraviesa múltiples organizaciones, el concepto de ownership se convierte en una ficción educada.
La causa raíz casi nunca es técnica. Casi nunca es el alcance. Es que nadie fue realmente dueño de la decisión que importaba.
Ownership es la palabra que todos usan y nadie define.
En co-desarrollo, estás trabajando con un publisher, un estudio externo, dirección de arte y especificaciones que llegan de distintas cadenas, y QA distribuido entre múltiples vendors — a veces más de los que puedes seguir en la práctica. Lo que en teoría tiene dueño, en la práctica no lo tiene nadie.
La pregunta que nadie hace en el kickoff
La mayoría de los proyectos empiezan con una RACI — una matriz que define quién es Responsable, Accountable, Consultado e Informado. Se alinea, se firma, todo el mundo siente que está cubierto.
Pero los proyectos no son estáticos.
La gente rota. Los leads salen. Llegan nuevos partners. Otros se van y a veces regresan.
La estructura cambia. El ownership, no. O al menos, no se revisa.
Y ahí es donde empiezan los problemas: ¿quién es realmente el dueño de esta decisión ahora?
Esa brecha — entre cómo se definió el ownership y cómo evoluciona el equipo — es lo que descarrila las producciones.
Tres patrones que veo repetidamente:
- Ownership por título, no por derechos de decisión. ¿No puedes aprobar un cambio sin escalar dos niveles hacia arriba? Eso no es ownership. Eso es un inbox bajo presión.
- Ownership compartido entre organizaciones. “Los dos somos dueños del pipeline” nunca ha terminado bien. Sin un desempate claro, cada desacuerdo se convierte en una negociación.
- Ownership sin visibilidad. Si no puedes ver el trabajo con suficiente claridad para detectar el riesgo a tiempo, no eres dueño del resultado — solo eres el que recibe las malas noticias.
Esto tiene solución.
No con más reuniones. No con un documento de milestones más apretado. Con un sistema que mantenga el ownership explícito y visible, incluso cuando los equipos cambian y los proyectos escalan.
Los estudios que entregan consistentemente tienen una cosa en común: en cualquier momento, alguien específico puede responder “quién es el dueño de esto.” No en teoría. Hoy.
El co-desarrollo funciona. Pero solo cuando la estructura operativa está a la altura de la complejidad del acuerdo.
Si no lo está, no estás corriendo un co-desarrollo. Estás corriendo un experimento caro basado en la esperanza.
En tu proyecto actual — ¿los derechos de decisión están realmente definidos, o solo asumidos?
