新疆人在流浪:诸行无常(第三章、管理篇)

发表于2015-07-11
评论0 419浏览

想免费获取内部独家PPT资料库?观看行业大牛直播?点击加入腾讯游戏学院游戏策划行业精英群

361498939
文:刘勇(新疆人在流浪)

3.    管理篇

3.1.  零容忍(完)(重点)


3.1.1. 解释

项目的成败,取决于对问题的容忍。

零容忍,是一种态度,即对游戏中一些出现的问题和BUG……必须解决,决不回避的态度。

任何事情……决定效率的一个重要指标,都是对问题的态度。所有机构的成熟与否,都是找到应对问题,实施“零容忍”的机制。

……


但在实际的游戏开发中,我们却通常很难做到“零容忍”。主要有如下几方面原因:

1、核心开发者缺乏管理素质,总是在忙而缺乏系统的规划。

2、一些问题在报批之后,有时无法立刻解决,或是目前解决起来代价较大。于是暂时“放一放”。之后,这个问题的“关注度”就逐渐减少,一段时间大家习惯了之后,就淡出视野。

(不得不说,这是团队的通病,许多时团队的成败就在于能否克制这一点。)

3、主管或主策划对问题不重视,他们通常会优先处理一些正在进行的事物或是比较习惯做的事物。

如果QA不够强势,就很难推动对问题的关注。

……


对许多成功的游戏公司来说,“零容忍”已经不是一种态度,而是前提了。对于他们来说,从来不存在“改不改”的问题,只存在“事故有多大”的问题。


3.1.2. 一些“零容忍”的案例

1、2006年6月,《MU》出现恶性外挂。玩家在游戏中可以以任何攻击力进行全屏攻击。

在当时,这个外挂之恶属于史无前例。但令人无法容忍的是,当时负责这个游戏的韩国开发公司却不知什么原因完全无视……


三周后,当这个问题开始解决的时候……经受了致命打击的《MU》也从此缓缓的退出历史舞台。

与他一起退出的,还有几乎所有的韩国游戏。

由于对游戏中BUG的轻视,问题反应的缓慢……曾经称霸一时的“泡菜游戏”将中国市场拱手让给中国本地游戏。


2、在中国,任何一家网游公司,在游戏中出现重大问题时,是一定第一时间解决。

任何时间,任何时刻,任何公司……当游戏中发现重大问题时,相关的工作人员(程序、策划、运营)必须解决问题才可以回家。

在当时,这个制度的确立,是中国网游能够击败韩国游戏的前提。


3、在腾讯,用户反馈的设计问题会直接报审。

如果经过确认后不做修改,属于“运营事故”。

之后即使是修改了,也会被追究责任,不单相应人员会被处罚,连领导都会“连坐”。

我曾经亲眼见过一次,在星期日凌晨两点,项目主策、总监、程序、市场总监赶到单位,连夜解决了一个问题。至第二天早晨10点离开。

(而这个“问题”,仅仅是一个越级打怪会造成经验下降之类的小问题。在大多数公司,甚至根本不会被理会。)


4、在巨人,史玉柱会经常泡在游戏中,一旦发现问题和可改进之处,就会召集相应人员紧急会议(通常是在晚上9点),然后布置下修改意见。由相关人员连夜完成并测试……后半夜更新。


5、在某个成功的页游团队(“凡人”),负责人每天都在玩别人的游戏。当看到好的设计之后,就会立即组织讨论……然后连夜开发。


第二天,这个设计就会出现在自己的游戏中。


3.1.3. 黑皮书

“黑皮书”,是目前管理项目问题一个最为有效的办法和制度。


大至由如下几个步骤形成:

1、当版本提交测试后,收集意见和问题。

2、所有意见和问题汇总后收录,删除相同的内容,将有效内容汇集成册。

3、组织核心策划、程序,对内容进行评审。凡是被认可的内容均会收录在《黑皮书》中。

(目前不能执行的内容也会收录,记录为“挂起”,但要设置“唤醒”的时间。)

4、组织团队人员,对《黑皮书》上的内容进行分析,给出解决验收的时间表。

5、若因突发事件,不能完成黑皮书内容,须事先进行沟通。给出延后的时间表。

6、按时间验收黑皮书内容,若未完成且没有事先沟通者,按事故论处。

7、事故会作为考评的依据,在腾讯的作法是通报批评,并处罚金。

在菲音的作法是减少评分,影响的是年终奖。

……


本人曾多次使用过《黑皮书》的管理方式,事实证明,在严格执行黑皮书内容,绝不容忍的情况下,项目组进展顺利。效率极高。


但在有时“有情可缓”、“暂不执行”的情况下,项目却经常陷入泥沼……效率极低。


3.1.4. 绝不容忍

1、绝不容忍当问题出现时,不去弄清楚原因。

2、绝不容忍当问题原因清楚时,不去规划时间点。

3、绝不容忍当时间时当出现DALEY时随意放过。(这点最关键,决定项目生死)

4、绝不容忍版本自己没跑过就扔给测试人员。

5、绝不容忍在版本推出的时期,相关人员不在岗位。

6、绝不容忍在版本的问题的时候,相关人员不去处理。

7、绝不容忍在项目有问题的情况下将项目的重心放在增开新功能。

8、绝不容忍在没有重大理由的情况下推翻自己制定的时间表,包括开发时间表和修订时间表。

9、绝不容忍策划游戏开发过程中突出奇想,修改需求。

10、绝不容忍对“习惯”、“麻木”的态度对待暂时解决不了的问题。


3.2.  规划(完)(重点)

3.2.1. 说明

指在游戏开始之前,对整个游戏进行规划。划出红线,确定什么能做什么不能做,什么能卖什么不能卖。


3.2.2. 案例:

某页游(名字保密,但群里人都知道),上线后数据一直不错。很快就破了千万,还在继续上升。

但在某天,该游戏却突然遭遇了滑铁卢,整体数据一下子一落千丈。

原来,当时游戏中有一种高级材料,是玩家的终级追求。只在副本中有限掉落。为了获得这个材料,许多玩家不惜重金砸装备、宠物……


但这次改版中,为了让玩家能快速升级,将这件终级材料变成可以直接出售的了。

……


结果是灾难性的,这个更新一出。人数立刻掉了一大半,收入也降到之前的1/5。更糟糕的是,这次事件让玩家对游戏中的“劳动的价值”和“充值的意义”产生了怀疑。导致游戏后期一撅不振。

……


教训:游戏设计中,需要规划出什么能卖什么不能卖。而且轻易不要突破。


3.2.3. 初期规划内容清单

1、功能清单,游戏中有多少个系统?

2、规划出程序、策划、美术的工作量。

3、物品编号规则

4、参数表,罗列游戏中所有数据,包括取值上限

5、装备规划表,每件装备(包括坐骑、称号)对应的属性加成效果、升级效果、关键字效果、加星效果……以及投放等级。

6、经济系统,规划中游戏中的每件物品的消费、投放、掉落、兑换渠道及消费价值。

7、材料规划表,每件材料的投放、价值、应用对象

8、活动、副本规划:规划每个副本的投放时间、游戏定位、投放(刷)定位、性价比……以及每日成就中的价值。

9、总规划表:游戏中每个阶段(新手阶段、平台阶段)的时间、开放系统、收费项、玩点、交互设计

10、技能职业表

……


建议相关策划在项目开始前将这些规划内容全部背下,并进行考试。


3.2.4. 阶段性规划内容

1、白皮书:每周项目进展情况,需要问责。

2、黑皮书:游戏中所有问题的收集整理,以及修改的时间点。


3.3.  团队中需要有人知道每人每天在做什么(完)

3.3.1. 说明

对团队的管理,是以掌握每个策划、美术、程序每天的工作进度为项目管理的成功的重要因素。

通常PM(有些项目为主策划、总监)每天上班后用半小时左右掌握整个团队中每个人的进度,同时提醒每个人今日提交或即将提交的工作内容……对整个团队的进度影响会非常大。


3.3.2. 案例

1、某项目(项目名保密)因管理混乱,整个团队陷入泥淖,五个月的时间内没有出新的版本。整个团队迷失了方向,人心惶惶。

2、新的PM上岗,将整个项目的问题整理汇总,整理成《黑皮书》。

3、根据黑皮书,规划出项目组中每个人的任务的前后顺序、完成时间。

4、PM每天上班时的第一件任务,就是跟组里每一个打招呼,提醒他今天的工作内容以及确认《黑皮书》中的内容是否可以按期完成。

5、三天后,《黑皮书》中的内容消化了一多半。

6、两周后(好像是一周后),整个团队结束了混乱期,重新开始了迅速高效的开发状态。


3.4.  活要见人,死要见尸(完)(重点)

3.4.1. 解释

人,是指交出的工作。

尸,是指下一个启动点或是提交点。

……


活要见人死要见尸,包括两个意思:

1、任何工作项必须交出或给个合理的说法,不能不明不白。

2、指对一个暂时DALEY的工作内容设置一个“唤醒点”。

……


此外,活要见人死要见尸,还有“零容忍”相关的内容。


3.4.2. 说明

在游戏开发过程中,因种意外会导致一些工作内容无法按期完成。这时一定要为这些发生DELAY的内容设置下一个提交点。

若是无法安排,则设置一个“唤醒点”,到时候一定要将该工作项目插入。

大多数项目组中,当一个BUG或工作内容被三次以上延期时,组内就会产生明显的懈怠情绪。

而且在排期时,因一些不可预见力(程序无法预估底层修正的时间)可能会导致你无法给出精确的时间。

于是一些应该做的功能和一些需要修正的BUG就被一次次的DALEY,直到大家开始麻木,变得熟视无睹。


3.4.3. 应用实例

1、小张(化名,真名隐去)是项目组的PM,周一开会时清点项目的上一周的《白皮书》时,发现某BUG没有修订。

2、这时与程序沟通,发现程序因版本中有更优先的内容需要实现,于是该BUG推后。

3、小张与程序沟通,预估了该任务的完成时间,于是约定十天后重新启动这个BUG的修复工作。

4、十天后,这时程序发现程序底层出了问题。于是约定将此BUG继续延后,程序无法给出时间……于是暂时约定为一周。

5、一周后,底层问题没有解决,于是再次延期。

6、经过多次延期,这时系统已经发生了很大变化。这时有许多新的BUG介入。

小张没有忘记那个BUG,仍然将其与新的BUG放在一起,重新排期。

并将其优先级放在新功能之前。

7、最终,在于新功能开工之前,程序修正了这个BUG。

……


说明:

在这个过程中真正重要的是,小张作为一个PM,在同一个功能屡次后延的情况下,没有懈怠、没有放弃……没有被牢骚或是其它的不良情绪影响。只是固执一次又一次的将对同一个功能进行规划、排期……直至完成。

在大多数项目中,如果不这么做,这个BUG可能是永远不可能完成的。几次推进之后,相关人员开始发牢骚……在抱怨的同时,这个BUG也就开始在大家的脑海中被遗忘了……和其它的BUG一起……越积越多。

在遇到项目内容DELAY,甚至是连续DELAY的情况下……是继续公事公办?还是停下抱怨?

将近一半以上项目的成败,就在这一念之间。


3.4.4. 案例

1、某页游公司的某个游戏中(项目名:《九天仙梦》),测试发现一个问题,于是提交给项目组。

2、项目组程序手中有事儿忙,没时间处理,于是先放了一下。

3、在忙完这个事儿之后,一些新的紧急任务下达,相关程序继续投入到强烈的加班状态之中。

4、一段时间过去了。

5、整个项目组不知何时已经处于如下状态:

a)  每个版本都出现很多问题,玩家报怨,外人感觉到团队问题很大。

b)  团队每个人眼中都看不到问题了。

甚至连测试都提不出问题了,一些明显的BUG和设计问题都视而不见。

c)  大家都在拼命上功能,功能越来越多,但项目的问题却越来越多。

……

6、项目陷入困境,不得已公司空降了一个制作人接手整个项目的管理。

……


新疆人在流浪:诸行无常(第四章、心得篇)


转自:游资网

原文链接

著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台