Me convertí en programador en mi segundo año de universidad, sobresaliendo en todos mis cursos de programación y desarrollando la mentalidad de un programador para la resolución de problemas. Ahora, tres años después, como productor de videojuegos, la mentalidad de programador de la que estaba tan orgulloso me había traído muchos obstáculos en mi primer hito PoCT (Tecnología de prueba de concepto). Está claro que es necesario un cambio de mentalidad.

Esto es lo que identifiqué como la principal diferencia entre la mentalidad del programador y la del productor:

1. Los programadores requieren enfocarse en tareas individuales, mientras que los productores deben ser más versátiles y disponibles para sus equipos.
2. Los programadores reciben comentarios instantáneos y respuestas claras de correcto o incorrecto, mientras que los productores a menudo carecen de comentarios inmediatos y se enfrentan a situaciones más ambiguas.

Cuando a los programadores se les dan las funciones que necesitan implementar, pensarán en la arquitectura de sus códigos y verán si pueden realizar las funciones basadas en sus funciones existentes. Y si no pudieran, deben crear nuevas funciones (grandes que probablemente incluyan la creación de arquitecturas, la definición de lógica y la prueba y depuración) para cumplir con los requisitos.

Citando las palabras de uno de los programadores de mi equipo:
Mientras trabajaba en mi código, normalmente me ponía los auriculares con cancelación de ruido y permanecía en mi cerebro. No estaba escuchando música; Solo necesitaba el entorno silencioso para concentrarme en mis códigos.

Sin embargo, si un productor se pone un auricular con cancelación de ruido mientras está sentado con su equipo, es un mal productor.

Los productores necesitan ver en todas partes y escuchar en todas partes.

Es deber de los productores hacer un seguimiento del progreso de todos en su equipo, asegurarse de que no excedan el alcance y coordinarse con los productores de otros equipos si es necesaria la colaboración entre equipos.

Como productor de SD, durante mi PoCT, cada diez o veinte minutos después de sentarme en mi silla, alguien de mi equipo o nuestro productor de diseño de niveles, diseñador de juegos, productor principal, etc., me llamaba.

Cada vez que intentaba concentrarme más en una tarea específica, alguien me llamaba. Durante PoCT, afortunadamente, satisfice a quienes hablaron conmigo, si necesitaban aclaraciones sobre el calendario o asistencia de un especialista de nuestro equipo, etc.; desafortunadamente, debo trabajar tiempo extra en mis propias cosas después de nuestro horario normal de trabajo.

Es cierto que los productores deben vigilar al equipo y escuchar todas las demandas diferentes, pero eso no significa que los productores no tengan nada que hacer por sí mismos. Deben mantener el backlog del producto, contar las horas estimadas, revisar constantemente los entregables por hitos, etc. Es intolerable que un productor, el mejor del equipo en gestión del tiempo, no gestione su propio tiempo. Se deben hacer ajustes y se deben tomar acciones. Aquí hay algunas propuestas que todo productor podría considerar:

• Trate de crear una lista de cosas que debe hacer para cada día de trabajo con horas estimadas y siga la lista cuidadosamente para evitar problemas.
• Establezca un cuadro de tiempo para cada conversación y siga estrictamente ese cuadro de tiempo (diez minutos puede ser bueno).

Los programadores están acostumbrados a recibir comentarios instantáneos. Saben casi instantáneamente después de presionar "Ejecutar" si sus códigos cumplen con la función/se ajustan al requisito. Sin embargo, es menos probable que los productores tengan respuestas rápidas. No pueden saber al instante si su ajuste resuelve el problema. Puede llevar días, semanas o incluso hasta el próximo hito saber en qué termina su ajuste.

También es fácil para los programadores saber si está bien o mal. Por ejemplo,
· Es correcto optimizar los códigos para usar menos recursos de memoria.
· Es correcto escribir códigos limpios con comentarios adecuados para que otros entiendan su código.
· Está mal cuando sus comportamientos de depuración causan más errores.
· Está mal si implementan malas funciones.

Sin embargo, es una historia totalmente diferente para los productores. A veces, el equipo se siente bien con los ajustes del productor, pero eso es, de hecho, malo para la productividad. A veces, el equipo puede quejarse del ajuste, pero mejora la productividad y el equipo acepta el ajuste después de experimentarlo por un tiempo.

Casi me vuelve loco en el primer momento cuando me di cuenta de que necesitaba ajustar mi forma de gestión pero no sabía cómo. Intento asignar subequipos como el equipo de IA, el equipo de física, el equipo de lógica del juego, etc. para dividir el tema más amplio en partes más pequeñas. Pero días después parece que todos están un poco separados unos de otros. Además, apenas tenemos comunicación entre disciplinas en PoCT, los productores descubrimos formas de ajustarnos, pero no teníamos idea de lo que eso causaría en el próximo hito.

Además.

De acuerdo con la idea de liderazgo de servicio. Lo correcto que deben hacer los productores es “servir al equipo” y estar listos para brindar apoyo una vez que el equipo lo necesite. Pero, ¿qué significa exactamente liderazgo de servicio? ¿Cuáles son las expectativas del equipo sobre los productores? ¿Qué tipo de problemas no pueden resolver sin productores? ¡Mira mi futuro blog específicamente sobre este tema!

Referencia:

[1]: La mentalidad de aprendizaje: cómo mejorar el aprendizaje de cualquier cosa

[2]: 18 habilidades que todos los programadores deben tener

[3]: La importancia de la retroalimentación oportuna y efectiva