为什么游戏公司做了这么多项目，下一个项目仍像从零开始？

本文系用户投稿，作者拥有15+HR从业经验

引子

你们的项目复盘，是否也经历过这样的场景？

项目没做好，大家争论了很久，每个人说的都有一部分道理，也都有自己的苦衷。最后，问题通常被归结为沟通不够、协作不好、责任心不强，会议形成的共识也很熟悉：以后要提前对齐、加强沟通、明确责任。还有一种复盘会更加和谐。每个人都认真反思自己哪里做得不好，态度很诚恳，气氛甚至有些感人。然后会议结束，换一个项目、换一批人，相似的问题再来一遍。

在游戏公司工作十多年，过去我们也曾在同一个方向上同时推进多个项目。大家面对相近的用户、市场和产品问题，却仍然各自研究竞品、各自搭建团队、各自寻找答案。项目增加了，投入增加了，大家却没有自然变得更会做。新的制作人进来，仍然要重新理解公司、寻找方向、搭建团队，再经过很长时间证明自己。过去做过的项目、踩过的坑、经历的成功和失败，能不能成为他的起点，很难说清楚。

这让我越来越无法回避一个问题：

为什么下一个项目启动时，仍然经常像从零开始？

游戏研发无法消除不确定性，也不可能依靠机制稳定制造爆款。但不确定性可以解释为什么项目不能保证成功，却不能解释为什么公司总在重复犯错。所以，这篇文章真正想讨论的是：

做了这么多项目，除了流水、团队和少数成功者，公司究竟留下了什么？

项目可以失败，但组织不能归零。

一、成功过，不等于形成了成功能力

一款产品成功以后，公司很容易形成两个判断：这个制作人被证明了，这套方法也被证明了。下一次只要继续用这个人、这支团队、这套打法，成功就可能再来一次。但结果只能证明一件事曾经发生过，不能自动说明它为什么发生。

一款产品的成功，通常来自很多条件的一次正确咬合：制作人的判断、核心班子的组合、研发与发行的配合、公司的资源，以及当时的市场机会。这些条件换掉一个，结果都可能不同。同一个制作人换一个品类、团队或者市场，未必还能成功；同一支团队面对不同的用户和竞争环境，过去有效的方法也可能失效。

公司最容易犯的错误，是把上一次成功的结果当成下一次成功的原因。看到一款产品成功，就复制它的玩法、团队配置和研发流程；看到一个制作人成功，就把更大的项目和更多资源交给他。如果没有说清楚当时究竟做对了什么，这些判断在什么条件下成立，换一个环境以后哪些需要重新验证，复制得越认真，反而可能离答案越远。

这件事我自己经历得很具体。早期手游阶段，公司形成了快速抓机会、快速上线、买量验证和数据优化的能力，也靠这套能力做出过成功产品。后来走向SLG、MMO这些生命周期更长、内容更重、用户关系更复杂的品类时，我们很自然地把过去的判断方式带了过去。但新的问题已经变了：用户为什么长期留下，内容怎样持续供给，玩家如何形成竞争与合作，大团队怎样长期协同。过去的能力并没有错，只是不能单独回答这些新问题。我们高估的不是过去的能力本身，而是它的适用范围。

成功以后，真正值得追问的是：哪些判断后来被证明是对的，哪些能力确实起了作用，哪些只是当时的市场机会？换一个品类、团队和用户，什么仍然成立，什么必须重新验证？

成功不被拆开，就只能被崇拜；经验不被验证，就可能成为下一次的包袱。

成功过和形成了成功能力，是两件不同的事。成功过，说明公司曾经在某个时间、某种条件下做对过一次；形成能力，则意味着公司对自己为什么做对有了更清楚的认识，也知道这套认识可以用到哪里、不能用到哪里。组织无法把过去的成功写成标准答案，但至少可以让公司不必继续依靠对成功者的崇拜来下注。

成功过，不等于留下了成功能力。

二、组织能力不是替代英雄，而是提高公司赢的概率

游戏公司常常在两个极端之间摇摆。项目做不好，就认为制作人不够强，接下来继续找更厉害的人；好不容易找到一个被证明过的制作人，又容易把项目完全交给他，给人、给钱、给时间，然后等待结果。如果结果仍然不好，公司便开始加强流程和过程管理，希望降低对人的依赖。这两个方向都不完整。

游戏确实高度依赖人。制作人的审美、产品直觉、创造力和愿力，直接决定产品上限。组织不能制造天才，也不能让一群人投票投出一个好产品。但尊重制作人的产品主导权，不等于把项目变成黑箱。产品怎样做，可以由制作人和核心团队主导；公司是否继续投入、投入多少、什么时候调整或者停止，则必须由承担资源后果的人作出决定。这不是干预创作，而是经营一家公司必须承担的责任。

如果公司的答案只是“继续寻找下一个英雄”，很多本来可以主动做的事情就被放弃了：能不能更早看见一个人的潜力和边界，能不能为他配上合适的核心班子，能不能在关键时刻分清楚应该继续相信、尽快调整，还是及时停止。组织能力不能保证每次下注都赢，但它能让错误更早暴露、失败代价更低，也让有天赋的人得到更合适的空间和支持。

所以，组织要练的主要是三件事：更早识别人和团队，更快验证并敢于停止，把多次探索变成公司的共同认识。

更早识别，不是用一次成败给人贴标签，而是看清他在不同阶段能解决什么问题，哪些信号代表潜力，哪些问题暴露边界，他能够承担到哪一层责任。

更快验证，不是催着项目尽快出结果，也不是轻易否定。项目早期，支持和停止都要有依据：现在相信什么，下一步验证什么，什么结果出现就继续，什么结果出现就必须调整或停止。

形成共同认识，也不是把复盘写成文档。多个相近项目做下来，公司应该更清楚这类用户在意什么、产品为什么成立、哪些问题要优先验证。否则每个团队仍然独立研究、独立试错，公司只是多投入了几次。

从项目看，英雄不可替代；从公司看，只等英雄不可经营。

组织不替代英雄，它决定英雄能不能被发现、能不能充分发挥，也决定公司失败后的下限。前两章说的是两个容易混淆的前提：成功过不等于形成能力，建设组织能力也不是用流程替代英雄。把这两个前提说清楚，后面才能继续讨论公司准备靠什么赢、现有组织还缺什么，以及这些能力怎样在真实项目里长出来。

三、战略不只是选择做什么产品，更要决定未来靠什么能力赢

把两个前提说清楚以后，第一步还是要回到战略：公司下一阶段到底准备靠什么赢。

很多游戏公司的战略，最后会变成一张产品清单：做SLG、做二次元、做MMO、做出海。方向定了，接下来就是找制作人、搭团队、分预算，然后等项目给出结果。但“做什么”只是第一步，公司还要回答：这个方向为什么可能成立，我们凭什么把它做成？

“做什么”只是方向，“为什么能够赢”才决定公司需要建设什么能力。

战略不能只给出一个品类和收入目标，还要形成一组阶段性的判断：我们相信哪类用户有什么需求，产品成立的关键是什么，公司已经具备什么，还缺什么。沿着这些问题，才能从战略选择推导核心能力，再看清现有组织的能力差距。否则，公司只能去寻找一个做过相关品类的人，希望他同时带来用户理解、产品模型、团队能力和成功答案。

战略也不是CEO一个人的智慧。业务、发行、技术、财务、数据和HR都应该提供各自看到的事实和判断，由管理层一起讨论；但涉及公司方向、重大资源投入和放弃什么，CEO必须承担最终取舍。

战略判断可以共同形成，战略取舍不能无人负责。

这些判断不需要一开始就全部正确。项目中的用户、数据和结果会不断检验它们，管理层要根据事实调整方向和能力选择，而不是把最初的战略变成不能质疑的结论。

战略决定未来靠什么能力赢，组织建设负责让这种能力长出来。

四、转型的难点：产品变了，能力系统也要变

确定能力方向以后，下一步是看现有组织离它有多远。公司决定进入一个新方向，最容易做的是成立项目、引进制作人、调整人员和预算。这些动作很快，也看得见，但产品变了，不代表公司已经学会了怎样做这种产品。

进入新方向以后，项目评审仍可能沿用过去的问题，测试仍可能沿用过去的指标，资源仍按熟悉的方式投入，对制作人和核心团队的判断也仍然来自旧经验。熟悉某个品类，不等于理解它为什么成立；做过相似系统，也不等于理解用户为什么长期留下。数据当然重要，但如果没有先说清楚产品成立的关键，数据只能告诉我们结果好不好，很难告诉我们问题到底出在哪里。

过去的能力不是错误，风险在于没有看清它的边界。一家公司原来擅长快速抓机会、快速上线和买量验证，进入更依赖内容积累、长期关系和大团队协作的品类以后，原来的能力仍然有用，但已经不够。这时需要更新的不只是产品方向，还包括判断产品的标准、识别人才的信号、资源投入的节点，以及研发、发行、数据和平台的配合方式。

如果这些没有变化，新的制作人只能带着自己的团队单独探索；公司在项目外面沿用旧的判断方式，进入项目以后又主要依靠制作人自己找答案。多个项目同时进行，也不会自动形成共同探索。项目多了、投入多了，公司却未必更清楚什么样的人适合这个方向、什么问题应该优先验证、什么情况下应该继续或者停止。

于是，转型停留在换项目、换人和换预算。每一次调整看起来都很大，公司的能力起点却没有变化。

换产品相对容易，更新组织理解产品和使用人才的方式，才是真正的转型。

能力方向一旦含糊，旧标准又没有被更新，机制越完整、执行越勤奋，组织也可能只是更有秩序地消耗资源。即使公司已经知道需要什么新能力，“公司里有人会”和“公司已经会”之间，仍然隔着很远。

五、从高手的能力到公司的能力，隔着三道鸿沟

看清差距以后，问题就变成：公司需要的能力，怎样不只停留在少数高手身上。过去我也容易把能力沉淀理解成高手分享、项目复盘和方法总结。后来我才意识到，这些动作都有价值，但一个人的能力要变成公司的能力，还要跨过三道鸿沟。

1. 高手能做，但说不清：显性化

“说不清”不一定是高手只靠感觉。很多优秀的制作人和专业负责人，只要回到具体问题，都能讲出自己看见了什么、为什么这样判断。问题是，这些判断经常停留在当时的项目和讨论里。事情处理完了，当时相信什么、依据是什么、成立的条件是什么、后来的结果又验证了什么，也就跟着消失了。

显性化不是让高手多写一份方法论，而是把当时的判断、依据、选择和结果连起来。

真正要留下的不是高手的结论，而是他形成结论的过程。

2. 说得清，但别人学不会：训练化

一场分享可以让人听懂，却很难让人真正学会。策划只有决定过核心玩法并看到用户反馈，才会形成产品判断；技术负责人只有在成本、稳定和效率之间做过取舍，才会理解架构选择；美术负责人也只有真正承担品质、效率和协作结果，才会形成完整能力。能力不是听出来的，而是在真实责任里长出来的。

没有决策，反馈与他无关；没有反馈，决策无法校准。训练化就是把人放到真实任务中，让他独立判断、承担结果，再根据结果修正。下一步是否给他更难的任务、更大的授权，也应该来自这些真实表现。

3. 有人学会了，但公司没有承接：组织化

一个人做出成功产品以后，公司通常会给他更大的项目和更多资源。但产品成功可以证明一部分产品判断，不等于管理、带人和培养团队同样成熟。一次巨大的成功，也可能掩盖一个人的能力边界。

组织化不只是提拔成功者，还要把项目中已经被验证的能力带入任用、授权、评价和激励。既看他做成了什么，也看他怎样判断、怎样组织团队、怎样培养人，以及项目结束以后留下了什么。

六、机制不是成功生产线，而是能力训练场

跨过这三道鸿沟，靠的不是再写一套方法，而是把人放进真实任务。评审、里程碑、复盘、人才盘点、绩效和激励，都是训练发生的地方。这些机制不能直接制造成功，它们能做的是让人在真实业务中作出判断、承担结果，并让结果带来明确的后续动作。

机制不是组织能力，形成闭环的机制才可能训练能力。

这里所说的机制，不一定是一套复杂制度。对一个小团队，它可能只是在每次重要选择时，把几件事说清楚：

1.我们的判断依据和标准是什么？

2.目前我们有哪些信息和判断？

3.还有哪些关键信息和问题缺失？

4.下一步先验证什么，不同结果下我们会做出什么不同决定（项目、资源、用人等）？

5.谁为不同的信息负责，最后又由谁决定、谁承担结果?

规模不同，做法可以不同，但这几个问题不能省。以项目评审为例，重要的不只是制作人讲了什么、最后通过还是不通过，而是项目通过时大家相信了什么，仍然担心什么，下一阶段准备花多少钱、用多长时间验证哪个关键问题。到了下一个里程碑，还要回到原来的判断：哪些得到验证，哪些被证明不成立，项目应该继续、调整还是停止。

研发管理要管的不只是进度，还包括项目有哪些关键问题没有答案，公司准备花多少资源换取答案。记录判断只是第一步，更重要的是让判断带来后果：假设得到验证，项目获得下一阶段投入；关键假设没有成立，就调整方向、团队或者停止项目；谁提出过有价值的判断，谁在关键时刻承担了责任，也应该影响后续的任务、任用和授权。

人才盘点、绩效和贡献评价也是一样。如果盘点没有改变任务和授权，评价没有影响用人和培养，它们只是把过去解释得更清楚，并没有完成自己的作用。业务团队也很现实，制作人最紧迫的始终是版本、用户、数据和结果。如果看不到这些机制怎样帮助自己识人、用人和降低项目风险，它们首先意味着额外的时间成本，配合往往只能停留在形式上。

检验一项机制，不是看它有没有运行，而是看它有没有改变下一次的判断、用人和行动。

七、我们的机制，究竟训练出了什么？

机制从来不会保持中立，它奖励什么，人就会逐渐学会什么。

如果评审只关心项目能不能过，团队学会的就可能是怎样汇报和过关；如果提出不同意见既不能改变决策，又可能承担关系成本，更理性的选择就是少说、少承担。人才机制也是一样：如果盘点只形成标签，管理者会把它当成一年一次的HR作业；如果绩效只决定奖金，大家就会更关心怎样争取分数，而不是公司希望强化什么能力。

组织很少完全失效，它通常只是在忠实地产出自己真正奖励的结果。

很多机制首先解决的是秩序问题：分工更清楚、评价更公平、分配更规范、项目能够持续推进。这些都很重要，但让公司稳定运行和让公司越来越会判断，是两件不同的事。前者解决今天怎样有序工作，后者解决公司经历一次以后究竟学到了什么。

要看清组织学到了什么，首先要把事实、判断和假设分开。事实，是已经发生了什么，用户、数据和项目结果是什么；判断，是我们怎样解释这些事实，准备因此作出什么选择；假设，是目前还不知道、需要继续验证的问题。

证据也不等于打分。真正有用的证据，是一个个连续的决策样本：当时面对什么问题，谁作出了什么判断，依据是什么，采取了什么行动，后来发生了什么，他又怎样修正。这些内容不需要做成复杂系统，一页记录也可以，重要的是后来的评审、复盘和用人决策真的会回来查看。

一个人偶尔说对一次，可能是经验，也可能是运气；连续留下几个决策样本，而且这些判断经过了结果检验，当事人也能够主动修正，才开始形成能力证据。

能力不是一个分数，而是一串经过结果校准的选择。

有了这些证据，人才培养才不只是安排课程，而是给人真实责任；人才盘点才不只是评价，而是决定下一步任务和授权；绩效和激励才不只是分配结果，而是强化公司需要的能力。过去我投入很多精力，把职级、绩效、反馈和分配做得更规范、公平。这些工作有价值，但现在回头看，我更缺少的是来自真实任务的连续证据。建立秩序是必要的，但没有证据，机制再完整，也很难提高公司识人、用人和判断项目的质量。

八、组织能力不是一个人的独角戏：谁负责什么，谁决定什么

最后还要回答一个问题：这些判断由谁作出，结果出来以后又由谁负责调整。如果权责不清，即使项目有了结果，也很难说清楚下一步该由谁改变什么。

组织不只是架构、岗位、流程和制度。遇到事情时，大家还要知道：什么问题由谁判断，依据是什么；谁提供意见，谁最后拍板，谁承担结果。

组织，本质上是一套大家共同理解和遵守的决策方式。

共同理解，不是要求所有人意见一致，也不是所有事情都集体决策。但共同参与也不能变成责任模糊。

CEO与管理层：决定公司往哪里走、愿意为此放弃什么

管理层共同形成战略和核心能力判断，CEO对公司的最终方向、重大资源投入和取舍负责。如果只有方向，没有放弃什么、优先什么、资源向哪里倾斜，战略就只是愿望。

业务负责人和项目核心团队：作出专业判断，并用结果验证

产品怎样做，主要由制作人和项目核心团队决定。他们要有真实的产品主导权，也要把关键判断和依据呈现出来。业务负责人不能只交项目结果，还要对团队能力负责：谁能够承担更大的问题，谁需要调整，哪些能力应该留在团队里。

项目是否获得下一阶段资源，则由负责项目组合和资源投入的经营负责人决定。谁承担资源后果，谁就必须拥有相应的决策权。尊重制作人的产品判断，不等于放弃公司对资源继续投入、调整和停止的权力。

HR：把战略需要、真实任务和人才决策连起来

HR不是战略制定者，也不替业务管理研发。HR能承担的是：把战略需要翻译成能力和人才问题，看清现有班子和人才供给的差距，推动人在真实任务中接受训练和验证，再把项目里形成的人才证据带入招聘、任用、培养、绩效和激励。

核心人才怎样任用和调整，业务负责人承担主要责任，HR提供证据和建议，关键岗位由CEO或者相应的最终负责人决策。

财务、数据、发行、技术和项目管理：让专业事实及时进入决策

专业部门的价值，不是用数据替代业务判断，也不是只在会后提供材料，而是在关键节点把事实、风险和约束讲清楚。他们要帮助决策者分清什么已经发生，什么只是解释，什么仍然需要验证。当这些角色各自知道要提供什么、在什么节点提供、谁最后决定，所谓协同才不是一群人一起开会。

共同负责最容易变成无人负责。有效的协同，是判断可以分布在不同角色，最终决策却有清楚的归属。

结果出来以后：回到最初的判断

项目结果出来以后，不能只用来判断成败、发奖金或者追责任，还要回到最初的几个判断：我们相信的用户需求是否成立，产品成立的关键是否判断准确，现有团队能不能承担，资源和验证方式是否合适。

这些结果要进入下一轮具体选择。产品假设错了，就调整方向和验证方式；能力判断错了，就重新审视团队和任务；一个人在真实任务中证明了自己，就给他更大的责任和授权；关键假设迟迟不成立，就不要再为原来的判断找理由。评审、复盘、盘点、绩效和激励也不再各自收尾，它们共同处理的是同一批事实：项目发生了什么，我们当初为什么这样选，现在要怎样改。

业务结果不是链条的终点，而是下一次经营选择的起点。

写到这里，我也想问自己几个问题

公司下一阶段究竟准备靠什么赢，我们有没有把它和需要建设的核心能力真正连起来？项目里的关键判断和人才表现，我们有没有留下可以回看的证据，结果出来以后有没有回到这些证据，明确下一次该改什么？我们的评审、复盘、盘点、绩效和激励，究竟有没有改变资源、任务和授权？面对每一项关键决策，有没有看清最后由谁负责？

真正的检验只有一个：

下一次面对相似问题时，我们是不是比上一次更会判断、更会用人，也更敢及时调整？

结语：项目可以失败，组织不能归零

游戏行业没有稳定制造爆款的方法，但也并非只能原地等待英雄降临。

公司先要想清楚现阶段靠什么赢，才能知道需要什么能力；知道现有组织缺什么，才知道该把什么人放到什么任务里训练和验证，招聘、任用、培养、绩效和激励也才有方向。最后再回到业务结果里看这些判断对不对。

再优秀的制作人也可能判断失误，再成熟的团队也可能错过市场。但一家公司不应该在每次项目结束、制作人离开或者方向调整以后，重新变回一个新手。它至少应该留下对用户和产品更深的理解，对制作人潜力和边界更准确的判断，对项目继续、调整或者停止更成熟的依据，以及一批在真实项目中成长起来的人。

一个项目可以失败，但组织应该让错误更早、更便宜、更有信息量。组织进化不意味着永远成功，而是每一次失败以后，下一次的起点都比上一次更高。

项目可以失败，但组织不能归零。

后记

过去自己参与和主导了制作人识别、项目调整、团队搭建、职级、绩效、激励和人才盘点等等各种机制建设，也处理过很多具体而复杂的问题。某种程度上，是靠着自己的经验、韧性，长期训练的肌肉记忆，从复杂信息中分辨问题是来自人员、方向、协作还是权责。但我也越来越清楚地看到自己的边界：项目判断怎样持续进入人才评价，人才评价怎样影响任务和授权，复盘形成的认识怎样改变下一个项目的起点，这些事情，我们过去并没有稳定地连接起来。

甚至在个人能力变成组织能力的过程中，也缺失很多提炼。我自己作为组织体系里的“关键人物”。我能够进入复杂问题、判断关键人才、推动组织调整，但这些判断是怎样形成的，我看见了什么信号，为什么这样判断，又怎样让其他人逐渐掌握，做得还远远不够。如果有一天我的缺席会让一部分判断和方法随之消失，那么我同样没有完全跨过自己所说的三道鸿沟。

同时，个体的很多能力是生长在一个长期熟悉并拥有信任基础的组织中。假设更换平台以后，哪些已经真正成为自己的能力，哪些还需要在新的环境中重新建立，同样要接受新环境的实践检验。

所以，这份总结不是一套已经完成的答案，更不等于已经建立了系统和组织能力，而是为了看见问题，同时也是在反问我自己：做了这么多年组织和HR工作，参与了这么多项目和业务的起落，除了应对一个又一个问题，我究竟留下了什么？现在我越来越明确：真正值得留下的，是有没有把走过的弯路变成组织的积累，也让下一次的判断更接近正确答案。