The Game Makers Brasil

Trabalhando em equipe

Percebo que muitos tem dificuldades em trabalhar em equipes. Na maioria das vezes o projeto não dá certo ou não tem o resultado esperado.

Neste tópico irei dar dicas de como organizar uma equipe, e como trabalhar em uma.
Então prepara a pipoca, e vamos começar.

Liderança

Porque não começar com quem vai instruir os demais membros da equipe?

O líder não deve ser escolhido por votação, idade ou tempo de experiência. O tal do líder deve ser aquela pessoa que sabe o que está fazendo, que tem uma boa estratégia para comandar a equipe e fazer o projeto dar certo.

Alguns afirmam que não se pode criar um líder, ele nasce. Já outros afirmam exatamente o oposto.(não se nasce líder, faz-se um)

De qualquer forma você precisa ser esse líder(ou tê-lo em sua equipe), talvez este tópico ajude: [Artigo] Estratégia para desenvolver um jogo de sucesso

E lembre-se: Você não manda na equipe, você os instrui. Tenha isso em mente.

Organizando as tarefas

O líder deve organizar as tarefas de cada membro da equipe, de preferência planeje tudo do início ao fim.
Separe o projeto em partes menores, seguindo etapas para se manter organizado e nunca se perder no que está fazendo.

Crie metas e prazos, quando definir uma tarefa para um membro também defina um tempo limite.
Saiba o tempo que o membro tem para trabalhar no projeto antes de definir este prazo.

Organize tudo isso de forma inteligente. O que é necessário agora? Isso pode ser necessário ser alterado com o avançar do projeto?
Tenha em mente que o seu projeto agora e o resultado final são bem diferentes. Preveja se tarefa X não vai ficar encaixada agora mas vai sair dos trilhos depois.

De preferência, faça o que é necessário agora e avance andar por andar do prédio.(Começar o 5° andar antes do 4° ser completado não dá certo. )
Imagina você começar o 5° e descobrir que o 4° vai precisar mudar... O 5° andar vai ter que seguir a nova tendência da moda e será alterado.

Seu projeto pode/vai mudar com o avanço do mesmo.

Obedecer o líder, não ou nunca?

O fracasso do projeto não está apenas na mão do líder. Muitas vezes os membros da equipe não segue o que o líder diz por achar que X fica melhor que Y.
Ou não dedica o tempo esperado no projeto.

E no final das contas dão a velha e boa desculpa: "Você não está pagando"

A) Se tem plano de fazer um projeto que será vendido, o lucro será repartido contigo, ou não? Se todos se dedicarem ao máximo e fazer um projeto ideal será muito dinheiro.

B) Se o plano é só fazer um jogo gratuito sem lucros...Você não sabia disso desde o início? Entrou na equipe só para atrapalhar?
Se você se dedicou àquilo mas vai ficar enrolando por "não está sendo pago", melhor nem entrar na equipe.

Um bom líder deve remover qualquer membro do tipo da equipe, mesmo que ele fique sozinho.

E um bom membro de equipe deve seguir as instruções do líder... Mas não a risca, lembre-se que é você quem está fazendo então só você pode notar um detalhe ou outro que deve ser mudado.

Mas sempre que alterar algo, avise o líder para que ele sempre saiba cada detalhe do projeto. E se não mudou, só precisa avisar que terminou pois ele já tem (ou deveria ter) uma noção do resultado daquilo.

FAQ

Toda equipe precisa de liderança?
Sim. Decisões por consenso geral da equipe não costumam dar bons resultados.
Podem combinar as coisas, mas alguém precisa dar a palavra final.

O líder da minha equipe é um perfeito idiota, o que eu faço?
Depende do que você quer dizer com isso. Se ele for uma pessoa que exige que o obedeçam não o faz um mal líder.
Se ele é eficiente você tem que pensar o que é mais importante: Você está acima nas ordens, ou o projeto dá certo?
Talvez o problema não seja um mal líder, e sim você não gostar de não ser você o tal líder.

Agora, se o cara não é um líder ideal... Pula fora.

Sou um líder perfeito, mas nenhum membro quer obedecer. E agora?
O problema da sua equipe é que todos os membros querem ser o líder. Neste caso, você tem que mostrar pra eles porque merece esse título formulando toda a organização da equipe e sua estratégia para desenvolver o projeto.

Se os sintomas persistirem, você não escolheu membros ideais. Prefira não trabalhar em equipe se nunca encontrar as pessoas certas. E se não consegue fazer um jogo sozinho, prefira organizar seus projetos mentalmente até encontra-los.

E já parou para pensar que você não seja "o líder perfeito" como pensa? Reflita sobre.

Sou um líder ou um membro?
1) Você consegue organizar um projeto perfeitamente antes de começa-lo?
2) Nos trabalhos em grupos do colégio, o que você fazia?
3) Você comparou o tal líder que citei no artigo a um ditador ou chefe chato?
4) Você pensa no desenvolvimento de jogos como uma diversão e que não deve seguir "regras" bobas do líder?
5) Na União Soviética, você seria um líder?

Respostas que um líder daria:
1) Sim
2) Organizava tudo ou não estava nem ai por não achar seus amigos capacitados para organizar o trabalho como deveria.
3) Não.
4) Não, pois é uma profissão séria. E isso não são regras, mas sim uma forma eficiente de organizar o projeto. Fazer u que si tu num manja.
5) Não.

Meu Deus!! Sou uma "líder" e nem sabia oO
kkk brincadeira

Eu nunca me dei muito bem trabalhando em equipe. Sou meio anti-social mesmo e trabalhar com pessoas é muito difícil, sempre causa complicações e estresse... Alem de que brigas ou "rixas" entre membros são quase inevitáveis.
Então tento trabalhar sozinha nos meus projetos e... Sim, tenho um mooonte de projetos... 
As vezes sinto que nunca vou concluir nenhum haha

Seu artigo é muito bom. Dá pra entender bem como funciona (ou deve funcionar) uma equipe de verdade.
Eu não acho que serviria para liderar qualquer coisa... eu fico muito chata e mandona as vezes, controladora e "a dona da verdade" (sério, sai de perto) haahha
Por isso receber ordens parece mais fácil...
Mesmo assim, todas as equipes em que trabalhei se desmancharam e o projeto foi esquecido.

Quem sabe na próxima eu me guio por esse artigo e as coisas fluem mais naturalmente, né?!
Valeu pelas dicas =)

Aposto que nesses projetos em equipe que fracassaram, você tinha uma visão do jogo bem superior que o resultado final. E ficava pensando que se te obedecessem o jogo teria um resultado ótimo.
Neste caso, você é sim uma líder. :D

Depende do que você quer dizer com isso. Se ele for uma pessoa que exige que o obedeçam não o faz um mal líder.
Se ele é eficiente você tem que pensar o que é mais importante: Você está acima nas ordens, ou o projeto dá certo?
Talvez o problema não seja um mal líder, e sim você não gostar de não ser você o tal líder.

Ser mandona faz parte de ser uma líder por natureza. Só tem que maneirar, deixa os membros dizerem suas ideias e tome uma decisão.
Se não for boa, simplesmente descarte. Essa pessoa precisa confiar em você.
Ah, e nada de tentar agradar. Se não é boa, não é boa. Não tente melhorar pra agradar o membrk, e se for aproveitar alguma parte que seja por qualidade e não pra tentar agradar.

Lembre-se que o líder não deve ser abusivo, mas se o membro não quer obedecer ele que não está agindo como deveria agir.
Se ele não for razoável, descarte-o da equipe. Você não é obrigada a estragar o projeto só porque um dos membros quer a (má) ideia dele no mesmo.

E para ganhar a confiança dos membros:

Sou um líder perfeito, mas nenhum membro quer obedecer. E agora?
O problema da sua equipe é que todos os membros querem ser o líder. Neste caso, você tem que mostrar pra eles porque merece esse título formulando toda a organização da equipe e sua estratégia para desenvolver o projeto.

Se os sintomas persistirem, você não escolheu membros ideais. Prefira não trabalhar em equipe se nunca encontrar as pessoas certas. E se não consegue fazer um jogo sozinho, prefira organizar seus projetos mentalmente até encontra-los.

Obrigado pelo feedback.

Vou apresentar algumas dificuldades que encontro no trabalho em equipes. Poderiam ser lidas como "lições aprendidas", mas eu nunca aprendo a lição, sempre cometo os mesmos erros...

Pra que se entenda como acontecem as coisas, é bom explicar que eu sempre entro como designer e programador, procurando equipe pra fazer gráficos e sons.

- Eu não sei exatamente o que quero.
Por exemplo, se quero uma música "animadinha" pra fase, eu digo que quero uma música "animadinha". No máximo, dou exemplos de outras músicas que serviriam pra fase. Eu não tenho conhecimento pra pedir algo detalhado. O tempo da música, se ela deve ser sincopada ou não, quantas oitavas o cara deve explorar. Nem sei se estou falando bobagem ao citar essas dificuldades, meu conhecimento musical é mínimo.
O mesmo vale pra desenhos.
Isso gera dificuldades na hora de pedir e avaliar o trabalho dos demais membros.
Enfim, o que quero demonstrar é que um líder precisa ter conhecimento dentro das áreas que ele está delegando.

- Quando sei o que quero, eu não me expresso claramente.
Muitas vezes eu chamo o cara pra resolver um assunto amplo, quando a especialidade dele é uma parte desse assunto. Tipo chamar um músico pra administrar todos os sons do jogo. O cara é músico, não é... como chama o cara que faz os efeitos sonoros? Vou chamar de sonoplasta. O cara não é sonoplasta! Aí, ele se dá muito bem com as músicas (eu costumo me surpreender com a qualidade das composições), mas nunca libera um barulho de porta fechando.
Já trabalhei com um desenhista que não tinha computador, também. Tive que escanear, redimensionar e limpar todos os desenhos, sem falar no tempo gasto pra explicar que eu precisava dos desenhos simples feitos à mão, também, (como o tracejado da rua) pra não ficar destoando dos demais.
Quando chamar alguém pra trabalhar, deixe claro tudo o que será esperado dele. E tenha certeza que ele será capaz de cumprir isso.

- Eu não pago minha equipe
Como não pago minha equipe, não me sinto no direito de exigir prazos e qualidade. Fica tudo na base da conversa, da cobrança suave. Aí, se eu recebo uma sprite que está aceitável, mas pode ser melhorada, fico dependendo da boa vontade do desenhista em aceitar a crítica e fazer a alteração. Em geral, o que acontece é que minha equipe entende a crítica e até concorda, mas mudar que é bom, nada. Eles consideram retrabalho e, em face do trabalho que ainda existe pela frente, acham melhor manter como está e tocar o barco.
Na última experiência, o cara ia muito bem, fazia uns sprites simples e bacanas, criou uma capa fantástica pro jogo. Nós tínhamos umas cutscenes e mandei uma descrição detalhada de cada cena (seriam cenas estáticas, pra facilitar o desenho). Quando o cara viu o volume de trabalho, pronto, ficou enrolando até jogar a toalha. Pulou fora, deixou o time desfalcado e mais um projeto foi abandonado.
Prazos, esquece.
Enfim, ou sua equipe mora na sua casa ou recomendo estabelecer um vínculo de obrigatoriedade, como um pagamento pelo trabalho. Ou um contrato de sangue. Ou uma ameaça à integridade física do cara.


**************************


Mudando de assunto, tem a questão do momento em que se deve convocar a equipe. A idéia geral é que devemos ter um projeto pronto pra mostrar pra equipe. Isso é ambíguo e mesmo que não fosse, tem prós e contras.
Primeiro, os prós e contras.
A favor da idéia de ter o projeto pronto, podemos dizer que as tarefas estarão bem claras para a equipe no momento em que ela for convocada, eliminando (ou reduzindo) as chances de se ter alterações no meio do desenvolvimento, retrabalho, discórdias, etc. "O combinado não é caro".
A favor de se chamar a equipe no momento da concepção, podemos citar o brainstorming. Aquela reunião em que todo mundo fala o que acha que o jogo deve ter, cara, surgem idéias fantásticas, muitas vezes muda o direcionamento do projeto antes mesmo dele iniciar, de forma que todo mundo fica satisfeito com a meta final (o produto final, já é outra história). Mais do que ficar toda a equipe satisfeita com a meta, o projeto fica mais interessante. Muitas cabeças pensam melhor do que uma, simples. E claro, se der pra todos iniciarem o trabalho ao mesmo tempo, o projeto fica pronto em menos tempo.

Agora, deixa eu divagar sobre a ambiguidade de dizer "convocar a equipe com um projeto pronto". O problema está na palavra "pronto". O que é "pronto"?
Eu vejo dois pontos distintos em que um projeto pode estar "pronto" para se convocar a equipe e começar os trabalhos.
O primeiro é quando o GDD está concluído.
O segundo é quando a programação está concluída.
Traduzindo, um ponto considera que o programador é parte da equipe, o outro considera que o programador é parte da direção. Como eu sempre sou diretor e programador, no meu caso, ambos são verdadeiros.

Vejo, em convocar a equipe no momento em que se conclui o GDD, a vantagem de se programar já com parte dos recursos à mão. Pra testes, acho interessante ter alguma coisa pra colocar no jogo à medida em que programo. Ainda posso mexer em constantes, como image_speed ou volume do som, em função do recurso que me chega.

Agora, convocar a turma quando já se tem a programação pronta dá pra passar pra eles uma idéia bem consolidada do produto final. Aí, eles podem desenvolver o recurso pra um jogo já conhecido, não ficam tentando adivinhar como vai ser o jogo.

Fico com a impressão que programar junto com a equipe requer uma equipe com mais experiência que programar primeiro e desenvolver os recursos depois. Mas não tenho um parâmetro definitivo pra escolher um ou outro.
Normalmente, eu chamo a equipe antes de saber se vou fazer algum projeto. Deve ser por isso que nunca dá certo...