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