Q 在游戏行业里，PM的存在感似乎一直不高。你觉得这个岗位的核心难点是什么？任志国：很多PM没有实权。他们没办法把控项目方向，没有人员管理的实权，也没办法做考核。所以很多PM就是老板说要做这些事情，那我就帮老板排计划；今天出了风险，我就汇报给老板，最后做成了一个“秘书”。
有些PM一听主策划要排计划，就去和策划谈：“你今晚能不能加个班？”结果策划常常说：“对不起，我今晚有事。”因为他不服你，觉得你的安排不合理。
那PM怎么突破这一点？你要培养足够的影响力，熟悉业务，在推进计划时提出有建设性的意见。这样虽然别人不是你的下属，但他们认为你对产品有价值，愿意服你，慢慢你就能成为核心。
任志国：大概3个月。当时整个团队有140多个人，项目做了3、4年还没上线，我过来之后发现有两个问题：
1. 产品的目标和方向不够清晰，大家不知道这个阶段做什么事情，要达到什么标准；
2. 产品的反馈节奏太慢，这周研发的东西，要到周五才能看到反馈，然后才能调优。
这两个问题怎么解决？我的方法是抓一头，抓一尾。
什么是抓一头？就是先制定计划，找制作人、主策划、主程共同讨论不同阶段的目标，把目标细化到每一天，每个人都做什么，然后每一天都回顾昨天做的事情，对计划做相应的变更和调整。
什么是抓一尾？就是抓版本。当时我提出要以版本为纲，每天构筑一个版本，当天就反馈当天做的事情。
这么做了几个月，大家明显感受到了团队的进步。
任志国：要用流程和工具解决这个问题。最开始大家构建版本的方法很原始，一款游戏分为客户端、服务器、美术、策划、测试等小组，每个组都有一个负责人，这些负责人要把所有资源统一，做出一个版本。后来我们做了一个工具，要求大家每个人都把工作直接提交上去。
现在这个流程可能很常见了，但当时大家有很多反对的意见，说我一天要做的事情这么多，最后还要做版本？太浪费时间了。
但最后大家发现，这个方法的性价比远大于消耗在流程上的时间。因为每个人每天都能知道今天做的事情合不合理，这就相当于迭代速度比之前快了5倍。
任志国：很多人做项目管理会采用顺序法。比如一个项目要做12个月，那就分成4个里程碑节点，3个月，3个月……一直到项目完成。
这里面有一个问题：如果第一个里程碑做了3个月，有些工作没有完成，拖到了下一个里程碑；下一个里程碑又出现了新的需求，那做到第四个里程碑，大家发现做不完，就只剩下一条路：项目delay。所以业内普遍认为，一个原计划用1年做完的项目，做1年半是非常正常的。
但我喜欢采用逆序法，以终为始，优先考虑最后的环节。比如商业化测试至少要做21天，那这个版本的目标要达到什么程度？要把所有功能做完，并且准备至少体验30天的内容……就这样一步步推算，推出拥有基础玩法的版本，只有核心玩法的版本，Demo等等，列出每个阶段相应的目标。
这样思考之后，每个阶段要把事情做到什么程度，才能做下一个阶段就非常清晰了。这样每个阶段你都会向着下一个目标来做事，最终项目就基本不会delay。
任志国：在定好宣传期的前提下，我们都是准时上线，甚至可以精确到天。我做项目比较喜欢前紧后松。
很多人做项目是前松后紧。比如项目开始时，前3天的计划是每个职业都做一个技能出来，验证核心玩法。但很多人觉得时间还长：这个项目要做2年呢，这几天做不出来没关系，我们先早点儿回家，出去玩一玩。听上去也有道理，但你这就浪费了好几天的时间。
而我做项目要求第一天大家就立刻进入状态，如果前3天计划要把技能做出来，那大家宁可加班，也要把这件事情做完。因为如果第一天的工作没做完，就会影响最后一天的工作。没有这个信念，你的项目一定会delay。
任志国：最常见的风险是沟通时的信息不对称。比如策划把需求交给程序员，等到需求做完策划一看，这个东西的质量和方向和自己想的都不一样，那怎么办？再厉害的人也没办法，只能再给你10天时间把事情做完。
PM不只要保证事情能按时做完，还要保证事情能按时按需地做完。所以针对这个风险，你就要确定关键节点，比如第3天，第7天，第12天，第15天，第18天……每个阶段都检查一下结果。
任志国：这个节点不是按3-5天随便分出来的，而是每个节点都要保证可量化，可视化。我们的标准不是指“写1200行代码”，“把图画了70%”，而是要拿着你的手机，让我确实看到这个场景，体验到这个玩法。
比如第3天我要看到可实现的功能；第7天我要看到一个临时的，可以没有UI，交互非常丑陋的界面；第12天我要在客户端服务器里看一下表现效果，同时让你对细节问题做微调；第18天修完所有bug，把稳定性调好；第20天对外发布。
在这个过程中，节点的时间也可能会随时改变。比如主程说这个需求不用3天，2天就做好了；或者对技术难度预估不足，需要4天才能完成，那还要对其他节点进行调整。
任志国：我们团队是每45天更新一个大版本。版本的大方向由制作人、主策划提出，之后PM再做细化。在这45天里，一般会拿30天用来开发，10天用来测试和稳定调优，提前5天拿1-2台服务器做灰度测试，最后全服更新。
我们的版本线一般会分为4条：1. 发布线：针对运营产品的紧急问题的修复，稳定版本分支；2. 运营线：针对运营产品的重要不紧急问题的修复，稳定版本分支；3. 开发线：针对长期特性开发的版本线，研发重要不紧急问题的修复，不稳定版本分支；4. 特性分支：多条，不稳定版本分支。
Q 在研发过程中，发现中途计划要delay，需要更长时间完成一项工作怎么办？
任志国：delay的问题很常见。调整优先级，把一些特性拆分到之后的版本中就好了。因为不是你做的功能越多产品就越好，PM也要帮助项目做减法。
比如做《轩辕传奇》手游的时候，我们想保证策略足够丰富，于是决定把端游的17-20个技能都复刻进去，但这至少要做3-5个月。
后来我们发现手游屏幕就这么小，其实一个职业做8个技能就足够了，这样还可以把每个职业都做得很精致。如果需要新的玩法套路，那我们可以再推出新的职业。最后产品上线效果很好。
所以做项目管理要不断调整计划，试着寻找更好的目标。比如你的目标不是“把端游的技能复刻到手游里”，而是“保证玩家的爽快和策略性”。
团队沟通的技巧
任志国：每周一会开一次核心团队的周会，这个会大概持续1个小时，主策、主程、主美、主测试等等都会参加，一起同步这一周的工作内容和大概目标。
然后每周三，也就是每周的中间，我们会把策划拉进来开一个同步沟通会，大家一起同步一下这周自己小组的情况。
在周五下午，我们还会开一个版本串联会。这个会所有策划都会参加，大概持续2-3个小时，大家整体review一遍这周做的新特性、新内容，再决定未来要对哪些内容进行优化，优化的排期是怎么样的——一般大家会列出50-100条优化意见。
最后我们还有很多和特性小组开的小会，用来拆解计划，讨论技术问题，信息沟通，解决临时问题等等，这种会每天都可能会开，持续时间一般在半小时到1小时左右。
任志国：其他岗位的同学也会尝试自己解决问题。如果涉及到人力资源的分配，那PM就要参与。
每个岗位都有自己的本位思想，比如主策想把功能做好，主程更在意性能和效果，而PM可以用更中立，更全局的角度看问题。所以遇到紧急事件，一般也是PM牵头，拉着大家去大会议室开会。
Q 团队的组织架构大概是怎么样的？是分成不同的职能部门，还是分成不同的业务模块？
任志国：团队还是会分为策划组，客户端组，服务器组，美术组和测试组。但针对不同的特性和功能，我们也会分出很多有策划，有程序，有美术的虚拟组，由策划负责全程跟进——Ta就起到了小PM的作用。这样开小会的时候，PM只要找到特定虚拟组的策划就可以了。
任志国：对，这份工作对情商的要求很高，有时候你要强硬，有时候你要懂得认错，有的时候你还要和一和稀泥。
比如一个需求可以客户端做，也可以服务器做，那到底让谁来做呢？大家都不知道，那你就需要强硬一点儿，比如直接拍板，拜托客户端来负责。
如果最后大家发现其实服务器做的性价比更高，那你就去请客户端主程吃个饭，赔礼道歉，说上次处理得有问题，这样问题反而变成了增进感情的机会。虽然说对事不对人，但事还是人做的。很多事情如果你们关系好，那人家还是会愿意加个班，帮你搞定。
PM还会遭遇很多沟通的僵局。比如程序跟你说，现在策划案没写好，这个事情我不能做，不然做了容易返工；但策划跟你说，今天我策划案真的出不来，周五才能给你。
这个时候怎么办？你其实可以和一下稀泥，跟策划说，你可以不写策划案，但先写一个简单的概要，跟程序讲讲核心玩法的体验，周五再补一个完整的策划案给程序？
Q 你觉得跨部门沟通时最常见的问题是什么？该怎么解决？
任志国：最常见的是双方目标不一致。比如我觉得这件事很急，希望你赶快帮忙，但你也有自己的分工和规划，没办法那么快地完成任务。
这个问题怎么解决？一定要提前沟通，这样其他部门才有足够的时间调配资源。有90%的紧急需求其实本来都不紧急，只是拖到了最后一刻，才变成了紧急的事情。至于剩下的10%，如果你们的关系比较好，那对方可能也愿意帮一次忙。
做版本规划，我们一般会提前2个月做计划；做具体的内容细节，我们一般会提前1周做计划；如果要开会，我们要求至少提前24小时和大家沟通。所有事情都提前安排，才不会出现很多临时的情况。
比如在梳理里程碑节点的时候，一般会规划团队要在30天内做多少系统和特性，其中几个系统需要策划出策划案。但如果策划案出来，主美说不可行，主程说技术搞不定，那工作肯定就做不完了。
一些PM可能会等着主策自己写，但我们一般会先找到主策，说能不能明天或后天先把策划案过一遍——主策不可能当天给你策划案，因为Ta也要思考。
这个时候主策可能说，这个方案没那么快，我周五才能写出来。那我就会问，你能不能分两期？这两天先对一下大概思路，下周再确认更多的细节。所以在写一些策划案前，我们甚至会拉主策先和美术、程序预沟通2次，正式沟通1次，最后再把策划案定下来。
Q 如果团队中某个人突然出了问题，比如突然请假怎么办？
任志国：要提前做好人员培养，保证另外有1-2个人也熟悉这份工作，避免“这份工作只能Ta来”的情况。
另外我们会让工具更加完善，减少口口相传的经验，减少对人的依赖。这样Ta今天请假，另外一个人也可以帮忙做Ta的工作，只是做的时间可能会长一些。
配备一个专职的PM
Q 你们现在面试或者招聘PM时，最看重的特质是什么？
任志国：如果是招聘比较高级的PM，我会希望对方有成熟的大型项目的经验，然后如果是程序出身，或者逻辑思维能力比较强也会加分。另外PM的情商很重要，因为这个岗位与人交互特别多。
任志国：先以导师的形式带Ta三个月，让Ta熟悉你的工作方式。这个里程碑阶段我把大方向告诉你，然后具体让你来细化执行。过了1周我发现你犯了一些问题，比如这个技术问题应该及时处理，不应该拖到下周；这个问题应该找主程、主策讨论清楚；这个跨部门的沟通不应该拖等等。
用这种方式培养，经历过一个2-3个月的里程碑阶段后，新人往往会成长得很快。如果事情做得足够好，那我就可以不断放手，让Ta去承担更多的事情。
任志国：过于关注进度，不关注质量。PM的工作是要保质保量，制作人、主策觉得这个事情要延后一天，那他们为什么会这么想？这个想法合理么？会不会没考虑到一些风险？
比如主策可能在外网反馈之后发现了很多问题，决定大改一通，提出了很多点子和想法。但站在PM的角度来看，这些想法根本做不完，或者做完品质也不高。那你就要提醒主策，我们要不要分阶段地实现这些功能？有些地方如果要调整，就和刚开始的计划产生了偏差，是不是要和大家同步？
这就是上下级沟通的重要性，你要及时向上级反馈风险，而不是上级说什么，你都说好的，我马上把这个计划安排下去。
任志国：把一个东西做好肯定需要足够的时间，在安排计划的时候，如果开发要用4周，那我们至少要留2周时间来打磨。甚至有的时候不是4+2，而是3+3——用3周做完功能之后，再用3周打磨细节。
当然，产品的打磨是无止境的。如果这个功能特别核心，大家表示加了50%的时间还不够，这时就要交给主策、制作人判断，如果值得，那下一个阶段就要继续打磨。
任志国：你是为项目服务的，而不是为计划服务的。总不能说我是PM，你们不能改我的计划吧。游戏要适应市场的变化，用户的需求。假设上一个阶段做的东西玩家发现真的不好，那就一定要改。
Q PM存在专家路线和管理路线么？是不是好的PM都会成为制作人？
任志国：制作人这条路肯定可以走通，我自己就是一个例子。因为你每天都在把控整个项目，比较有全局观，只要你再多花心思关注产品，那3-5年后你是可以成为制作人的。专家路线也可以走得通，比如你可以带一个小型PM团队，专门帮助制作人把产品做成功。
任志国：如果团队规模在30人以下，制作人和主策划往往可以兼顾。但如果团队超过30人，那就要考虑匹配1个专职的PM了，如果有100多人的话可以匹配3-4个。
Q 项目管理是不是一份非常琐碎，或者非常辛苦的工作？比如必须要留到最后做验收。任志国：一些验收工作往往会由策划牵头来做，如果大家都养成了提前沟通的习惯，也很少会出现特别紧急的任务。所以我们团队的加班情况都不严重，很少会有22点之后下班的情况。
你可能会问我，一个游戏至少要做300个特性，怎么可能忙的完？但又不是让你每天都要全部跟进这300个特性，它们是错开的。只要把工作理顺，每天你要处理、沟通的事情只有7-8件，其实并不多。