Por que razão um projeto pode fracassar?

O sucesso é muitas vezes semelhante, mas o fracasso assume formas diferentes.

O sucesso de um jogo depende do cumprimento de uma série de condições necessárias, além de um pouco de sorte, mas basta cair numa armadilha para que tudo se perca para sempre. Já assistimos ao fracasso de muitos jogos que, à primeira vista, pareciam promissores, e também lamentamos projetos que, apesar de apresentarem alguns pontos positivos, acabaram por cair no abismo por um descuido.

Um produtor descreveu-me uma vez como é avançar num projeto como se estivéssemos a caminhar sobre gelo fino; a produção de um jogo acima de uma determinada dimensão é um projeto complexo, e há sempre obstáculos inesperados pelo caminho.

Embora seja difícil para a maioria das pessoas aprender verdadeiramente com as experiências alheias, e só seja possível acumular experiência através da própria experiência prática, ao passar por dificuldades, observar com frequência os fracassos vividos por outros pode, de certa forma, servir de lição.

Nesta edição da Mesa Redonda do Youcha, conversámos com profissionais do setor sobre o seguinte tema: «Por que razão um projeto pode fracassar?»

▍Caohejing Wanderers – Rei Da Xi

Os projetos que vi fracassarem podem ser resumidos a uma única razão: terem sido desenvolvidos à porta fechada.

Desde o patrão até ao produtor, passando pela gestão intermédia, todos exalam uma estranha arrogância, rejeitam qualquer experiência externa, evitam todas as opiniões e sugestões, e só querem agir de acordo com as suas próprias ideias; a validação é desnecessária, o feedback não é importante — basta concluir o desenvolvimento e tudo ficará bem.

Durante o desenvolvimento do projeto, também foram organizadas algumas sessões de experiência e entrevistas com jogadores em pequena escala, mas os questionários de feedback dos jogadores eram apenas uma formalidade; nas entrevistas, o produtor limitava-se a responder a cada um pessoalmente, para depois voltar a mergulhar no seu pequeno mundo de desenvolvimento, sem fazer a menor ideia do que era o mercado dos jogadores.

Não é possível continuar para sempre a trabalhar à luz da lua, desta forma. Quando a escala dos testes com jogadores se torna cada vez maior e os dados ficam tão maus que já não é possível fingir que não se vêem, a arrogância transforma-se em pânico; num momento de desespero, o projeto é ajustado de forma frenética, numa tentativa de se salvar, mas acaba por fracassar completamente devido a problemas acumulados e a dados de péssima qualidade.

▍Miguel, que ontem deixou a indústria dos jogos

Na verdade, no que diz respeito aos projetos individuais, o processo de fracasso é bastante comum. É como afogar-se lentamente: cada problema parece poder ser superado com um pouco de paciência, mas, no final, todos os problemas acabam por se acumular de uma só vez.

Na minha opinião, a causa principal reside no facto de a nossa criatividade estar desfasada da realidade. Após vários testes, a reação dos jogadores não foi positiva; naquela altura, eu era demasiado teimoso, achava sempre que os jogadores não tinham paciência para compreender e não me conseguia decidir a reescrever tudo do zero.

E aí entra aquele ciclo vicioso: aceitar trabalhos freelance para ganhar o sustento → o projeto fica parado → quando o dinheiro acaba, aceita-se mais trabalhos freelance. Às vezes, dedicamo-nos tanto aos trabalhos freelance que nem sequer tocamos nos nossos próprios projetos. De certa forma, talvez estejamos apenas a fingir que não vemos.

Um dia, estive a ajustar os efeitos até às três da manhã, quando de repente percebi que não estávamos a avançar, mas apenas a remendar o que já estava feito. Nessa altura, admitir que o projeto já estava morto acabou por ser mais fácil do que continuar a insistir nele.

▍XX, veterano da 3A já aposentado

A grande maioria dos jogos morre logo no dia seguinte ao início do projeto, mas só é enterrada um ano e meio, ou até mais tempo, depois.

▍A cassete que aposta na segurança para garantir a vitória

É inegável que a grande maioria dos jogos com modelo de compra definitiva tem um ciclo de vida curto, sendo possível prever o retorno sobre o investimento (ROI) do projeto no prazo de um mês após o lançamento, ou num período ainda mais curto, o que significa que os investimentos operacionais subsequentes nos jogos com este modelo são, normalmente, muito inferiores aos dos jogos GaaS. Por conseguinte, quando se fala do «fim» de um projeto de jogo com modelo de compra definitiva, refere-se geralmente ao facto de este ter sido abandonado ainda na fase de desenvolvimento.

Do ponto de vista de um editor ou investidor, isso significa deixar de investir no projeto e deixar de «injetar recursos» na equipa de desenvolvimento. Quais são, então, as razões que levam à perda total de confiança e ao fim do projeto?

A minha experiência limita-se a projetos de jogos independentes; a escolha de parcerias e o investimento em projetos constituem uma avaliação de risco multidimensional: uma demo jogável e com potencial, um posicionamento de mercado claro e uma identidade única, planos e ideias para o desenvolvimento futuro, e uma equipa que «pareça» fiável.

Avaliar o potencial futuro de um projeto de jogo é um pré-requisito para a colaboração; além disso, considero que o aspeto mais difícil de prever é a estabilidade da equipa, uma vez que o desenvolvimento de jogos independentes é normalmente realizado por indivíduos ou pequenos estúdios, cujos membros principais raramente possuem experiência em projetos de sucesso ou competências técnicas maduras e sólidas.Na fase inicial de contacto, apenas conseguimos ter uma perceção limitada das suas capacidades de comunicação e colaboração, da clareza do plano do projeto e da existência de um «entusiasmo disciplinado», o que é, de longe, insuficiente.

Do ponto de vista dos recursos humanos: a perda de talentos essenciais e o aumento do efetivo da equipa; o equilíbrio entre a dimensão da equipa e a ambição dos projetos; problemas de eficiência no desenvolvimento decorrentes de insuficiências técnicas ou de pessoal.

Do ponto de vista do controlo do projeto: a adição constante de novas ideias e funcionalidades levou a um alargamento dos limites do projeto, o que impediu a sua conclusão e chegou mesmo a desviá-lo da mecânica de jogo central inicial; o acúmulo de dívida técnica, devido à falta de competências da equipa, e a ocorrência frequente de erros provocaram uma queda exponencial na eficiência do desenvolvimento.

Diz-se que um jogo «aborrecido», mas completo, é pior do que um jogo «divertido» mas incompleto, porque o primeiro, pelo menos, vende.

Mas mesmo depois de termos passado por problemas como o equilíbrio entre as ideias criativas do jogo e o prolongamento do ciclo de desenvolvimento, e de o projeto ter finalmente sido concretizado, ainda temos de enfrentar o último obstáculo: a mudança nas tendências do mercado dos jogos. «Por exemplo, se neste momento os jogos de ação do tipo "roguelike" ainda estão na moda, nessa altura a popularidade deles pode ter sido totalmente suplantada pelos jogos de ação AAA».Por isso, quando surge uma crise no projeto, os investidores recorrem frequentemente a uma avaliação do estado de saúde do projeto para decidir se devem manter a colaboração ou cortar as perdas atempadamente — o que, no caso de um projeto de jogo com contrato de compra total, significa a sua sobrevivência ou o seu fim.

Devido a várias razões semelhantes às acima referidas, os estúdios de desenvolvimento independentes atuais são obrigados a desenvolver o jogo até 70% ou mais para que este possa ser considerado para uma parceria de distribuição; além disso, a criatividade da jogabilidade central do jogo tem de ser suficientemente marcante. Por conseguinte, o nível máximo de conclusão do desenvolvimento do jogo está inevitavelmente limitado, o que constitui, de certa forma, um círculo vicioso no ambiente de desenvolvimento de jogos independentes no país.

No entanto, continuo otimista: todos os problemas podem ser resolvidos com o tempo. Acredito que haverá sempre mais profissionais de alto nível ou coincidências em que os desenvolvedores e os editores se complementem, construindo gradualmente o mercado de jogos 3i na China.

▍Um profissional lll

Antes de falarmos sobre as razões pelas quais um produto falha, devemos primeiro discutir por que razão um produto surge?

O ciclo de vida de cada produto está, na verdade, definido desde o momento em que é lançado, sendo que a qualidade do próprio produto constitui a base que determina esse ciclo de vida.

No decorrer do processo de investigação, desenvolvimento e operação, fatores como o marketing, a opinião pública, os incidentes e a otimização são, na verdade, apenas um reflexo do próprio produto. Essencialmente, 90% das causas do declínio de um produto estão intimamente ligadas à sua própria qualidade.

Penso que a razão principal está relacionada com a intenção inicial com que cada projeto é lançado dentro de cada empresa. Quer se trate de projetos bem-sucedidos, quer de projetos mal sucedidos.

Já vi demasiados casos em que, partindo apenas dos «gostos» e «ideais» do diretor de criação e do produtor, a meio do projeto se aperceberam de que o seu produto era demasiado nicho ou não era suficientemente abrangente (ou não tinha potencial comercial suficiente) e, então, começaram a fazer concessões aos utilizadores, acabando por criar algo que não se assemelha a nada em particular.

Muitas equipas criam, pelas razões acima referidas, um produto desajustado — um produto que não se adequa à época, à tecnologia da empresa nem às necessidades dos utilizadores. Entre elas, há uma minoria que, graças à sua qualidade e competência excepcionais, consegue ter sucesso; no entanto, a maioria dos produtos acaba por ser, na verdade, um fracasso.

Por isso, quando se trata das razões pelas quais um projeto pode fracassar, penso que o mais importante é saber qual é o ponto de partida desse projeto. O ponto de partida determina a duração e a forma do projeto. No caso de alguns produtos, para usar uma expressão típica das telenovelas, «esta criança nem sequer devia ter nascido».

▍Os Mortos do Marco -D

Um projeto pode ir por água abaixo devido a maratonas de horas extraordinárias sem limites (tenho a certeza) — de um planeador infeliz que está a fazer horas extraordinárias.

Claro que isto é uma piada: o facto de haver ou não horas extraordinárias, de o ambiente do projeto ser ou não difícil, ou mesmo de a rentabilidade corresponder ou não às expectativas… basicamente, nada disso pode ser considerado um fator decisivo para determinar se o projeto vai ou não fracassar.

Existe apenas uma razão direta que pode realmente levar ao fim de um projeto: o próprio patrão/investidor não querer continuar.O projeto ao lado está no ar há um ano, tem vindo a perder jogadores de forma contínua, mantém-se quase sempre em prejuízo e a equipa de I&D tem visto sair um grupo atrás do outro; no entanto, apenas porque o patrão considera que este género tem de ter um produto digno, o projeto tem-se mantido de pé — claro que, na maioria das vezes, a decisão do patrão traz a má notícia do fim do projeto.

Além dos projetos já lançados apresentarem sinais claros de que estão condenados ao fracasso (receitas insuficientes para cobrir os custos dos servidores), a possibilidade de um projeto em desenvolvimento chegar a ser lançado e quanto tempo conseguirá manter-se em funcionamento é, muitas vezes, uma questão que os membros da equipa de I&D dificilmente conseguem prever. Pode ser que, há dois dias, tudo estivesse a correr sobre rodas, com todos a desfrutarem de benefícios ao máximo e a divertirem-se em atividades de team building, e, no fim de semana seguinte, o projeto tenha desaparecido de repente.

Também é possível que haja um clima de inquietação no seio do projeto, que as metas de prazos nunca sejam cumpridas, que todos considerem que a qualidade deixa a desejar e que seja necessário fazer mudanças, mas que o projeto tenha sempre novos recursos humanos e novos investimentos, e que o lançamento pareça estar muito longe, apesar de a equipa de I&D continuar de pé, mesmo após tantos anos de desenvolvimento.

Um amigo do setor disse-me uma vez que as horas extraordinárias não servem para cumprir metas de produção, mas sim para aliviar a ansiedade do patrão.Às vezes, à medida que as horas extraordinárias vão acumulando-se, ficamos realmente confusos: durante este longo período de investigação e desenvolvimento, em que estamos constantemente a «dar o máximo», será que o nosso objetivo é realmente fazer bem o projeto e lançá-lo, ou será apenas para acalmar o patrão e evitar que o projeto morra antes de chegar a um desfecho ainda incerto?

▍Guia para o fim de projetos dos dois principais produtores da You

Desde as reuniões até ao orçamento, as armadilhas que levam ao fracasso de um jogo:

As conversas vazias nas salas de reuniões, os orçamentos excessivos e as equipas sem rumo estão, silenciosamente, a sufocar um projeto de jogo após outro. «Estamos sempre a tirar conclusões das experiências de sucesso, mas raramente refletimos sobre os fracassos — seria como deitar sal na ferida», escreveu um profissional ao resumir as lições aprendidas com o fracasso de um projeto.Por trás das histórias de sucesso brilhantes da indústria dos jogos, há muitos mais projetos que fracassam na obscuridade. Estes fracassos não são acidentais, mas sim o resultado de uma falha sistémica que vai desde as reuniões, passando pelo orçamento e pela coragem, até à capacidade de definir as prioridades.

As reuniões deveriam ser uma plataforma para resolver problemas, mas tornam-se frequentemente o local onde os projetos morrem. Uma reunião eficaz requer três ações fundamentais: definir objetivos claros, determinar métodos viáveis e estabelecer um plano de execução concreto.Muitos responsáveis por projetos ignoram este princípio básico, deixando-se levar pela auto-satisfação de «falar só por falar». O planeador principal fala apenas para falar, o responsável pela equipa conduz discussões sobre questões abstratas — como, por exemplo, se o jogo precisa de um enredo — e chega mesmo a resolver questões técnicas através de votações por levantamento de mão. Estas reuniões, que carecem de uma agenda clara e de um mecanismo de tomada de decisões, conduzem diretamente a uma orientação confusa da equipa e a uma baixa eficiência.Quando os membros da equipa têm interpretações divergentes das conclusões da reunião e cada um se esforça em direções diferentes, o projeto já começa a caminhar para o fracasso. Objetivos vagos fazem com que os membros da equipa fiquem presos num ciclo de trabalho repetitivo e desvios de direção, desperdiçando recursos de desenvolvimento valiosos.

Contrariamente ao que se poderia pensar, um orçamento excessivo pode, por vezes, acelerar o fracasso de um projeto. Uma pequena equipa com um orçamento entre 1 milhão e 3 milhões tem, geralmente, objetivos claros, uma carga de trabalho equilibrada e uma execução eficiente. No entanto, quando o orçamento aumenta para 20 milhões e a equipa cresce, surge frequentemente um desequilíbrio na distribuição de recursos, em que «uns estão sobrecarregados e outros sem nada para fazer».Este desequilíbrio não só conduz a uma diminuição da eficiência, como também pode desencadear conflitos na equipa. Quando a distribuição de recursos é inadequada, as tarefas essenciais podem ser adiadas devido à falta de recursos, enquanto as tarefas não essenciais podem ocupar recursos em excesso. Nesta confusão, os custos de comunicação da equipa disparam e as desculpas e a atribuição de responsabilidades substituem a resolução conjunta de problemas.

Quando os dados de teste de um projeto são insatisfatórios ou o desempenho comercial fica aquém do esperado, a equipa tende facilmente a cair em dois extremos: ou desiste precipitadamente, ou insiste a todo o custo. Muitas equipas não têm a coragem de aprofundar os problemas centrais, preferindo fazer ajustes superficiais em vez de enfrentar as falhas fundamentais do projeto.Um reajuste bem-sucedido exige que a equipa tenha «coragem para uma transformação radical» e «paciência e rigor para uma desconstrução completa». Quando o jogo não atinge as expectativas, a equipa deve analisar-lhe a estrutura interna, esclarecendo todas as estruturas, funcionalidades, interligações, valores e relações de interação.

Durante o processo de modificação, um erro comum é tentar resolver todos os problemas ao mesmo tempo: «adicionar funcionalidades», «completar conteúdos» e «fazer otimizações» — tudo ao mesmo tempo. Esta abordagem que tenta abranger tudo acaba por ser contraproducente.A revisão deve ter prioridades claras. A tarefa principal é otimizar a experiência do jogador no fluxo principal do jogo e o feedback positivo, de modo a mantê-lo no jogo. Só depois é que se deve desenvolver funcionalidades e adicionar novas formas de jogar com base nessa experiência. A estratégia de monetização deve assentar numa boa retenção de jogadores.

Para além das questões centrais acima referidas, os projetos de jogos apresentam várias «formas comuns de fracasso»; por exemplo, as falhas técnicas são o «assassino invisível» da operação de um jogo, sendo a estabilidade técnica fundamental para jogos que dependem da interação em tempo real. Seguir cegamente as tendências e a falta de inovação são igualmente fatais.A confusão de competências, os fluxos de trabalho irracionais e a falta de identificação da equipa com o projeto são também causas frequentes do fracasso dos projetos. Quando os membros da equipa «nem sequer querem jogar este tipo de jogos», o projeto já perdeu a sua alma.

Um jogo não é, de forma alguma, uma mistura mecânica de planeamento, programação e arte, mas sim um organismo que requer a intervenção de pessoas reais para ser concretizado. Muitos gestores acreditam que basta tomar decisões de cabeça, ler artigos de figuras de destaque do setor e ouvir as fanfarronices dos profissionais para identificar oportunidades, e que, depois, basta «executar» o plano de desenvolvimento para concluir o jogo.Este equívoco de pensamento equivale a «achar que, só por seguir uma receita, se é um grande chef capaz de preparar um banquete». Como se deve interpretar «uma pitada», «na medida certa» ou «conforme o caso» no desenvolvimento de jogos? Como se controla o ponto de cozedura? Tudo isto requer experiência e intuição.

Por fim, não sei se devo dizer isto, mas, na minha opinião, a maioria dos decisores das empresas sofre de uma grave desconexão cognitiva em relação ao «campo de batalha» onde se cria verdadeiramente valor (ou seja, o próprio jogo), devido à sobrecarga de informação.

Os decisores estão diariamente expostos a uma enorme quantidade de notícias do setor, dados de mercado, opiniões de colegas e análises de meios de comunicação independentes. Estas informações têm, por si só, valor, mas o perigo reside no facto de serem extremamente suscetíveis de criar um mercado virtual abstrato e «idealizado», levando os decisores a perderem-se em «simulações estratégicas» a este nível abstrato.Falam de «segmentos do mundo 2D», «tendências de jogos de festa» e «modelos de aquisição de utilizadores», mas ignoram que todos estes conceitos macroeconómicos têm, em última análise, de ser concretizados e realizados através de um produto de jogo específico e divertido.Quando a base da tomada de decisões provém principalmente de relatórios de análise externos e de relatórios esporádicos, em vez de uma experiência profunda e íntima com o próprio produto, essa tomada de decisões é como construir um edifício na areia.

«Percorrer todo o processo na íntegra» é, precisamente, a forma mais eficaz de desmascarar essa bolha de perceção.Um dirigente que nunca tenha completado, na pele de um jogador comum, todo o processo — desde o download, passando pelo tutorial para principiantes, pela mecânica principal até aos pontos de compra — não consegue, de forma alguma, compreender em que fase os jogadores ficam irritados devido a tempos de carregamento excessivos, em que ponto da missão ficam bloqueados devido a um design pouco razoável, nem em que ponto de compra abandonam o jogo de forma definitiva por não perceberem o valor oferecido.As instruções de alteração que emitem baseiam-se frequentemente em conceitos abstratos como «parece-me que», «os dados mostram» ou «outros tiveram sucesso», em vez da experiência real de «quando cheguei a essa parte, também me senti incomodado».Isto leva a um enorme fosso cognitivo entre a equipa de execução (que conhece profundamente os detalhes do produto) e a instância decisora (que opera com base em informações macro), fazendo com que as instruções de alteração pareçam, naturalmente, ineficazes ou até mesmo contraproducentes.

Então, haverá alguma forma de lidar com isto? Sim, há, e consiste em forçar os decisores a desviarem a atenção das fantasias de «riqueza desmedida» e do mar de informações confusas, e a voltá-la para o «princípio fundamental» mais essencial do jogo — será que é divertido? Isto exige que os decisores se tornem os jogadores mais exigentes e fiéis do seu próprio produto.Não basta apenas jogar; é preciso jogar em conjunto com a equipa, organizar «Bug Bash» (encontros para detetar erros) e recolher de forma anónima os comentários mais autênticos e contundentes que os colaboradores da linha da frente (especialmente o apoio ao cliente e a gestão da comunidade) ouvem dos utilizadores. A base da tomada de decisões deve passar de «os relatórios do setor dizem que…» para «ontem à noite, quando cheguei ao terceiro nível, descobri que…».

Por fim, a maior parte da responsabilidade recai, de facto, sobre os próprios produtores, pois estas são questões com as quais já me deparei na prática e que já me aconteceram. Dos produtores nacionais que conheço, poucos jogam os seus próprios jogos; a maioria limita-se a fingir que joga quando chega a altura do lançamento, dando apenas algumas ordens de forma superficial.