Tornei-me um programador em meu segundo ano de faculdade, destacando-me em todos os meus cursos de programação e desenvolvendo a mentalidade de um programador para a solução de problemas. Agora, três anos depois, como produtor de videogame, a mentalidade de programador da qual tanto me orgulhava me trouxe muitos obstáculos em meu primeiro marco PoCT (Proof of Concept Technology). Tornou-se claro que uma mudança de mentalidade é necessária.

Aqui está o que eu identifiquei como a principal diferença entre as mentalidades do programador e do produtor:

1. Os programadores precisam se concentrar em tarefas individuais, enquanto os produtores devem ser mais versáteis e disponíveis para suas equipes.
2. Os programadores recebem feedback instantâneo e respostas claras de certo ou errado, enquanto os produtores muitas vezes carecem de feedback imediato e enfrentam situações mais ambíguas.

Quando os programadores recebem recursos que precisam implementar, eles pensam na arquitetura de seus códigos e verificam se podem realizar os recursos com base em suas funções existentes. E se não puderem, eles precisam criar novas funções (grandes provavelmente incluindo a criação de arquiteturas, definição de lógica e teste e depuração) para atender aos requisitos.

Citando as palavras de um dos programadores da minha equipe:
Enquanto trabalhava no meu código, eu normalmente colocava meus fones de ouvido com cancelamento de ruído e ficava no meu cérebro. Eu não estava ouvindo música; Eu só precisava do ambiente silencioso para me concentrar em meus códigos.

No entanto, se um produtor colocar um fone de ouvido com cancelamento de ruído enquanto está sentado com sua equipe, esse é um mau produtor.

Os produtores precisam ver em todos os lugares e ouvir em todos os outros lugares.

É dever dos produtores acompanhar o progresso de todos em sua equipe, garantir que não estejam exagerando no escopo e coordenar com os produtores de outras equipes se forem necessárias colaborações entre equipes.

Como produtor de SD, durante meu PoCT, a cada dez a vinte minutos depois de sentar na minha cadeira, eu era chamado por alguém da minha equipe ou por nosso produtor de Level Design, game designer, produtor principal, etc.

Sempre que tentava me concentrar mais em uma tarefa específica, alguém me ligava. Durante o PoCT, felizmente, satisfiz quem conversou comigo, quer precisasse de esclarecimentos sobre o calendário, quer de auxílio de um especialista da nossa equipa, etc.; infelizmente, devo trabalhar um tempo extra em minhas próprias coisas após nosso horário normal de trabalho.

É verdade que os produtores precisam ficar de olho na equipe e ouvir todas as demandas, mas isso não significa que os produtores não tenham nada a fazer sozinhos. Eles devem manter o backlog do produto, contar as horas estimadas, verificar constantemente as entregas dos marcos, etc. É intolerável que um produtor, o melhor da equipe em termos de gerenciamento de tempo, não gerencie seu próprio tempo. Ajustes devem ser feitos e ações devem ser tomadas. Aqui estão algumas propostas que todo produtor poderia considerar:

• Tente criar uma lista de tarefas obrigatórias para cada dia de trabalho com horas estimadas e siga a lista com cuidado para evitar problemas.
• Defina uma caixa de tempo para cada conversa e siga rigorosamente essa caixa de tempo (dez minutos podem ser uma boa).

Os programadores estão acostumados a ter feedback instantâneo. Eles sabem quase instantaneamente depois de clicar em “Executar” se seus códigos atendem ao recurso/atendem ao requisito. No entanto, é menos provável que os produtores tenham respostas rápidas. Eles não podem dizer instantaneamente se o ajuste resolve o problema. Pode levar dias, semanas ou até mesmo até o próximo marco para saber qual será o resultado do ajuste.

Também é fácil para os programadores saberem se está certo ou errado. Por exemplo,
· É correto otimizar os códigos para usar menos recursos de memória.
· É correto escrever códigos limpos com comentários apropriados para que outros entendam seu código.
· É errado quando seus comportamentos de depuração causam mais bugs.
· É errado se eles implementam funções ruins.

No entanto, é uma história totalmente diferente para os produtores. Às vezes, a equipe se sente bem com os ajustes do produtor, mas isso é, na verdade, ruim para a produtividade. Às vezes, a equipe pode reclamar do ajuste, mas melhora a produtividade, e a equipe aceita o ajuste depois de experimentá-lo por um tempo.

Quase me enlouqueceu no primeiro momento quando percebi que precisava ajustar minha forma de gestão, mas não sabia como. Tento alocar subequipes como a equipe de IA, equipe de física, equipe de lógica do jogo etc. para dividir o tópico mais amplo em partes menores. Mas dias depois parece que todos estão um pouco distantes uns dos outros. Além disso, mal temos comunicação interdisciplinar no PoCT, nós produtores descobrimos maneiras de ajustar, mas não tínhamos ideia do que isso causaria no próximo marco.

Além disso.

De acordo com a ideia de liderança servidora. A coisa certa que os produtores devem fazer é “servir a equipe” e estar prontos para fornecer suporte quando a equipe precisar. Mas o que exatamente significa liderança servidora? Quais são as expectativas da equipe em relação aos produtores? Que tipo de problemas eles não podem resolver sem produtores? Verifique meu futuro blog especificamente sobre este tópico!

Referência:

[1]: A mentalidade de aprendizagem: como melhorar a aprendizagem de qualquer coisa

[2]: 18 habilidades que todos os programadores precisam ter

[3]: A importância do feedback oportuno e eficaz