Subtema: Gestión de Grupos Amateur: productividad y organización

[SiPoX]

Info: http://www.undeadcode.com/desarrollo-indie/coordinar-un-grupo-sin-morir-en-el-intento/

Debate: ¿cómo planteais la jerarquía, las funciones y la existencia de un líder o coordinador? ¿creeis necesario que haya alguien por encima que tome las decisiones finales, que decida ante puntos conflictivos? ¿quién debería tener la última palabra? ¿asignais tareas? ¿de qué tipo? ¿de qué manera organizais y distribuis el trabajo? ¿os lo tomais en serio?

------------------------------------------------------------------------------------------

Info: http://www.undeadcode.com/desarrollo-indie/gestion-de-proyectos-videojuegos/ , http://www.undeadcode.com/desarrollo-indie/la-figura-del-disenador-y-la-importancia-de-planificar/ , http://www.undeadcode.com/desarrollo-indie/productividad-y-eficiencia/

Debate: dentro de las tareas... ¿se han de marcar plazos? ¿qué metodología usáis? ¿se ha de comenzar a trabajar sin tener el documento de diseño bien definido y aceptado? ¿veis necesario el rol de diseñador o puede hacer ese rol otra persona, como el programador o el grafista? Alguna vez os habeis preguntado a vosotros mismos sobre un proyecto "y ahora, qué?"  ¿teneis en mente la productividad, el hacer más con menos? ¿cómo conseguis tener un grado alto de productividad? ¿sois productivos o pasan meses hasta que se puede ver algo?

[Mars Attacks]

Durante el CDV y charlas posteriores se habló de la inviabilidad de la democracia en este aspecto. Tomar las decisiones según lo que la mayoría prefiera no funciona en ámbitos donde lo que se necesita es que el que más conocimientos tenga sea quien decida el camino a tomar. En grupos de gente reducidos y equitativamente preparados se puede optar tanto por un consenso en las decisiones (siempre en un tiempo muy concreto y breve, nada de pasar semanas sin aclararse) como por elegir un líder echándolo a suertes o plantear turnos (total, seguramente van a fallar de forma sistemática todos los proyectos, así que da igual :D).
Si hay puntos conflictivos, mi teoría siempre es que quien se tenga que comer el mayor marrón sea quien decida. Ejemplo práctico: si el programador quiere hacer algo con cuatro cajas y el grafista insiste en hacer dinosaurios hiperrealistas, hay que hacer algo con dinosaurios hiperrealistas. Si la cosa está en hacer un pong gracioso pero el programador asegura que se curra un MMORPG, hay que optar por el MMORPG. No hay nada como aprender rápido dónde están los límites a la hora de decidir cosas :D
La asignación de tareas es prácticamente implícita cuando el equipo está compuesto de poca gente: los gráficos no los va a hacer el programador, y el compositor no va a programar. A menos que todos sean la misma persona. Lo ideal es tender siempre hacia la paralelización efectiva del trabajo (por ejemplo, el programador puede usar un modelo prehecho para probar movimientos y animaciones en el juego, y mientras el grafista va modelando y animando el personaje que realmente se va a usar al final).
¿Se puede tomar esto en serio? Hay que intentar que todos se lo tomen con el mismo nivel de seriedad. Si nadie se lo toma en serio, lo peor que puede pasar es que no se termine el proyecto, pero aprendan algo. Si todos se lo toman en serio, lo peor que puede pasar es que se frustren si no se termina el proyecto, pero aprendan algo. Si unos se lo toman más en serio que otros, lo peor que puede pasar es que el proyecto se vaya a paseo y unas cuantas amistades o colaboraciones, también.

Metodología de trabajo... muchos conocerán metodologías ágiles como Scrum y similares. La nuestra, que es la más usual, es la SQP (sálvese quien pueda), que consiste en imaginar por dónde para la línea de meta y correr hacia ella lo más rápido posible, y mariquita l'últim. Nuestro mejor documento de diseño es un boceto ilegible en una servilleta usada hecha en un rato después de cenar. Esto pone de manifiesto que el diseñador es necesario, pero es difícil encontrar diseñadores. Todos son unos flipados (incluso cuando el diseño lo hace uno mismo y sabe lo que hay, también termina flipándose de algún modo).
En cuanto a la productividad, es increíble el poder de las fechas límite, sobre todo si son altamente cercanas a las fechas de inicio. Seguramente porque es imposible montar en ese tiempo un proyecto tan complejo que no quepa por completo en todos sus ámbitos dentro de la memoria y recursos de los N componentes dedicándose por completo a él. Para todos los demás ámbitos, productividad cercana a 0, o incluso -1.

[SiPoX]

¿Se puede tomar esto en serio? Hay que intentar que todos se lo tomen con el mismo nivel de seriedad. Si nadie se lo toma en serio, lo peor que puede pasar es que no se termine el proyecto, pero aprendan algo. Si todos se lo toman en serio, lo peor que puede pasar es que se frustren si no se termina el proyecto, pero aprendan algo. Si unos se lo toman más en serio que otros, lo peor que puede pasar es que el proyecto se vaya a paseo y unas cuantas amistades o colaboraciones, también.

He contestado algo parecido en el post de los objetivos. Justo me refería a eso.

En cuanto a lo demás... todo de acuerdo! :P aunque no entendí las dos últimas frases, sobre todo la frase final xDDD! Eres todo un crack con los comentarios, Mars.

[Mars Attacks]

Lo que quería decir con lo último es que la productividad es inversamente proporcional al tiempo dado para hacer el proyecto. Cuanto más tiempo hay, probablemente no sólo no haces nada, sino que terminas olvidando lo que sabías hacer (productividad -1 :D).

[SiPoX]

Entonces, también totalmente de acuerdo :P Y es curioso... porque de forma lógica se iría más relajado, con calma... pero.... se observa eso, esa inversabilidad... :P

[Tyrell]

¿cómo planteais la jerarquía, las funciones y la existencia de un líder o coordinador?

Para un grupo amateur no hace falta mucha jerarquía, sólamente un director de proyecto actuando en modo "dictador benevolente".

¿creeis necesario que haya alguien por encima que tome las decisiones finales, que decida ante puntos conflictivos? ¿quién debería tener la última palabra?

Bueno ya veo por dónde vas. La democracia no funciona en una empresa.

¿asignais tareas? ¿de qué tipo? ¿de qué manera organizais y distribuis el trabajo?

Cada quince días el feje marcaba unos objetivos concretos para cada persona.

¿os lo tomais en serio?

El que no se lo tome en serio debe ser expulsado del grupo. Más bien, no hay que permitir que entre nadie que no se lo tome en serio.

¿se han de marcar plazos? ¿qué metodología usáis?

Sí hay que marcar plazos. Yo usaba un diagrama de Gant para hacer una planificación general del proyecto, y luego una libreta y un boli para los objetivos concretos.

¿se ha de comenzar a trabajar sin tener el documento de diseño bien definido y aceptado?

No.

¿veis necesario el rol de diseñador o puede hacer ese rol otra persona, como el programador o el grafista?

Un grupo amateur normalmente no puede permitirse el lujo de tener una persona dedicada exclusivamente a diseñar o dirigir. Creo que la figura del diseñador y director debe residir en una misma persona, que además debería ser programador.

Alguna vez os habeis preguntado a vosotros mismos sobre un proyecto "y ahora, qué?"

No, eso sólo significaría que no se ha hecho el documento de diseño.

¿cómo conseguis tener un grado alto de productividad? ¿sois productivos o pasan meses hasta que se puede ver algo?

Manteniendo las reuniones físicas periódicas. Si alguien se atranca lo mejor es que reciba una visita en su casa del director de proyecto, luego misteriosamente todo vuelve a fluir.