新疆人在流浪:诸行无常(第一章、职场篇)

发表于2015-07-11
评论1 544浏览

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

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

前言

    本文是一个谈“思想”谈“方法”的卷宗。

    不涉及到具体的知识点。

    文从设计技巧、管理经验、玩家需求……等多角度入手,搜集了近十年来国内游戏高手、天晴数码以及本人的一些心得体会汇成本文。


    欢迎各位同行多提意见、心得……多多斧正。

1.    职场篇
1.1.  主策划的工作是“断”而不是“谋”(完)

1.1.1. 说明

“断”,指下决定。

“谋”,则指设计。

(如果说“房谋杜断”,那么房玄龄就是策划。杜如悔就是主策划。)

在游戏开发过程中,主策划的主要工作并不是写案子,而是那个要知道游戏要做成什么样子的人。

主策划在开发过程,要尽量避免自己的工作陷入一大堆琐碎的事物中,而没有将主要精力和时间放在项目的方向方面。


1.1.2. 能派出去的工作就不要自己做

通常情况下,大多数策划的工作主策划都可以胜任。但这未必是主策划的工作。

能派出去的工作最好就不要自己做,主要有如下几个原因:

1、耗太多精力在细节上,会导致在方向控制方面耽误时间。

2、新人缺少了锻炼的机会,很难成长。


1.1.3. 项目最大的敌人是:失去目标

项目开发过程中,最可怕的情况不是犯错。而是不知道该怎么做了。

在项目没有开始的时候,如果失去了目标,耽误的是主策划一个人。而在项目开发过程中,如果失去了目标,那么整个团队都会停下来。这时开发成本就会惊人的增长。

而且开发过程中,经常会出现朝令夕改的现象……一个案子仓促决定这么做,做了一半或是做完了之后,突然又推翻重做。……整个团队的士气和偏心会受到巨大、持续性的打击。


1.1.4. 陷入沉沼后如何处理

如果有一天,团队陷入泥淖,记着:

1、沉住气。

2、不要找身边的人倾述和寻找安慰,如果别人感觉你靠不住,恐慌会蔓延。

(朋友和外人可以。)

3、不要被一些紧急却不重要的事情纠缠。例如程序、美术没活儿干了在等策划案。

(为了让他们开工而仓促决定的策划案会导致连锁反应,造成更大的失败)

4、不要做仓促的决定,尽量深思熟虑。

5、不要让组员拼命加班做一些可能重做的内容。

a)  在迷失方向的时候,通常连常规工作都可能是没必要的。怎么会有那么多的工作要做?

b)  组员工项目不顺的时候,逆反情况会很大。

c)  组员在“会不会白做”的心理下工作,不会产生成就感。而且一旦推倒重做,打击会远远超过平时。

d)  在项目不顺的情况下,离职概率本来就远远高过平时。这时再加班做没有结果的事儿,会导致离职更大。

而项目是有机体,少一个人都是相当大的打击。

e)  ……说一千道一万,这个时候加班不产生效率,却会对项目组产生巨大的风险。

这种赔本的事儿做什么呢?

6、观察自己的状态是不是正常,在不正常的状态下尽量避免做决定。

7、一些小的地方不要患得患失,避免追求完美而导致犹豫不决。

a)  如果两个设计都没大问题,但不知那个好时,选择实现代价小的那一个。

b)  如果拿不准哪个设计玩家更能接受,选择那个感觉上玩家有些“吃亏”的那一个。

8、抓住要紧的工作,按项目的优先程度决定做什么,而不是按当前的压力决定。

9、如果有好的借鉴对象且符合你的需求,放弃创新。


1.1.5. 延伸:玩家吃亏定律

1、如果拿不准哪个设计玩家会接受,那就按玩家会比较吃亏的方式比较好。

在一个设计玩家没有比较的情况下,起点越低,将来的成长空间就越大。

而玩家是按“成长值”来衡量自己的得失的,你最开始给的东西多少他都没有概念。

(就是说不要一上来给玩家太多的东西,即造成信息过剩,而且也让玩家产生麻木情绪,减少对物品获得的期待。)

2、在一些数值的设置上,如果平衡上有压力。则按玩家比较吃亏的方式设计会比较好。

因为如果设置上对玩家吃亏,则玩家会选择尽量接近这个设计需求,这对于控制游戏会比较好。

例如动态副本的平均等级,如果设计为小队成员的最高等级。就比设计为平均等级要好。

3、不要为玩家的所有行为买单,设置一个范围,可以将所有的行为控制到一定范围内。

(例如玩家在砸装备时,可能会因为对游戏不了解选择了性价比最低的那一个(例如砸装备最好,但玩家却砸了宠物)。导致一些大R甚至比不过小R。这是玩家的事儿,你不用为此做针对性的“补偿”设计,这样会让系统变得更为混乱。)


1.2.  拒绝“民主”(完)

1.2.1. 解释

早先,许多组内在立项之初。或是在开发之初,都会招集组内意见。

“尊重大家意见”这个出发点是好的,动机也是照顾组员情绪,发挥大家积极性……

但在实际操作过程中,由于决策者将决策权下放……或是缺少“拍板”的人。于是经常出现如下结果:

1、效率低下,一个简单的想法通常几个月都定不下来。

(“目标软件”一个项目做三年半,是因为前三年半都在开会。)

2、团队关系变复杂,因为每个人都有可能对他人进行围攻,为了让游戏设计能够“顺利”进行,相关人员不得不“拉帮结派”……否则将举步维艰。

3、激发出了队员的表现欲,每个人都多说少听……下意识养成了互相拆台的习惯,团队内部人员离心离德。

4、缺乏大局观。整体上七拼八凑……不成模样。

5、策划的能力不再是“能做”而是“能说”……这个偏差令整个团队变得更为务虚。

6、策划无法再把握设计。

正常的设计应该是以用户的需求以及游戏的实现为设计目标。

但在“民主”的环境下,策划设计的主要目的则在于说服其它人。这时原本体谅用户就变成了去理解和迎合同事……

……

在实际的游戏开发过程中,“民主”的氛围被反复证实是一个“糟透了”的想法……用“没事找抽”已经不足以形象这种事儿的无聊和恶劣。

从某种意义上说,“民主”制度对项目的恶性影响可以说是所有不良因素中最大的……没有之一。

因为任何一个风险,如团队不和、经验不足、经费不够……都只能毁掉一个产品。而“民主”制度在注定毁掉一个项目的同时,会让这个项目组付出几倍的开发成本。

(看看腾讯的自研吧,多少项目几千万的投资然后无疾而终……)

这种情况多发生在大型的公司或团队,结果就是付出了几倍于正常游戏的开发量,结果非常糟糕,甚至大部分没有结果。

……

说到底,“民主”制度是发生领导缺乏权威或是项目经验不丰富的团队。目前的中国游戏已经翻过了这一页。

但,国内仍有许多新兴的团队。有时一些主导设计的人并没有开发经验或是策划经验(例如他们是程序员或是老板)。

这时“民主”这个幽灵就有可能会再次作乱。


1.2.2. 误区

其实,让团队成员参与讨论本是一件好事。即可以鼓励大家对项目的积极性,也可以多角度判断一个设计的问题。

真正的错误,是在操作过程中发生了一些“反智”行为,产生了许多误区。

1、误区:让不具备决策能力的人参与了决策。

参与投票的组员并不了解游戏设计,或是体会不深。严格的说,他们并不具备投票资格。他们的选择相当的盲目和不负责。

例如,只有了解市场的策划才会做出针对玩家的设计。而这个设计程序员却无法理解的,但程序员和策划拥有一样的决定权。

2、误区:“好的设计才能说服大家。”

真相是:只有处在特定位置的策划才会体会到一些设计的原因和关联。

但这种“感觉”根本不可能描述给没有相关经验的策划。

例如,只有数值策划知道调整一个数据可能产生的后果。只有文案策划知道什么东西在世界观的和谐与统一。

3、误区:说多过听

“民主”制度鼓励大家发言,搞“头脑风暴”。这看上去挺好,但在这种气氛下,“说”的重要度就大大高过了“听”。

意见过多,不能统一的时候……就会互相拆台……造成效率低下和团队矛盾。

4、最大的误区:决策者不尽职

一件事情,听意见是一方面,但决策却是另一方面。

决策,是主策划或是总监、制作人的工作,不是策划的工作。普通的策划不具备全局化的眼光……不应该由他们说了算的。

但许多时,由于负责决断的人顾忌“组内和谐”或是缺乏自信……于是将这方面的权利下放……造成不良后果。

5、误区:必须一致通过

许多时,开发组下意识需要“一致通过”才可以决定一样事物。这就更大限度的降低了效率。

连游戏都要有自己的目标用户定位……不可能要求所有玩家都喜欢……你又怎么能指望每个有自己想法的策划思想统一呢?特别是在认同别人的时候。

……

于是,好端端的“民主”制度被发展成一种鼓励外行决定内行的“反智”行为。同时,也成为一种鼓励自我表现排斥互相理解的反沟通行为。


1.2.3. 案例

腾讯目前可以说是中国游戏界的NO.1。但你可知腾讯游戏的自研一直是业界的笑柄?

从最初组建到今天,十年来基本上颗粒无收。如果算一算每个游戏的投入成本,腾讯自研项目成功率和性价比之低……可谓业界之最。

(近期《御龙在天》火爆,算是打破了这一魔咒。但需要说明的是,在腾讯内部。该项目以“独裁”闻名。)

从一进腾讯,就听到了“夜总会”的说法。每个项目成员对“夜总会”都报有极强的畏惧。

(夜总会:夜里总是在开会。)

经常是一个游戏还没做,先开几个月的会。讨论来讨论去没有个结果,却把大家耗得死去活来。

本人曾经两次领教过这种会议的“可怕”之处。

一次,是讨论一个世界观。之前曾征求过大家的意见,普遍感觉不错……然后开会讨论。

但在开会时,一个市场人员却对世界观表示了异议。

如果说该市场人员能够用什么有利的证据来阻止这个会议倒也罢了,问题是这个市场人员根本没有看过一眼这个世界观。他的唯一反驳观点就是“网络游戏不需要世界观。”

就是这么一个无厘头的原因,整整两个小时,大家都在说服他……结果没有结果,该讨论无疾而终……世界观也被迫回炉。

(在腾讯某些项目组,既然是因为这么无厘头的原因导致“没有通过”,也算“没有通过”。)

……

另一次讨论中也发生了争议,会议不断后延。因为团队内部发生了争吵……最终也导致某个系统无疾而终……没有生成结果。

但争吵的理由让人哭笑不得,将近一个小时,全组成员,都陪着两个策划争吵一个NPC的名字究竟是两个字还是三个字好听。

(真事)


1.2.4. 忠告

1、决策者必须要能“断”,否则会被部下的意见所左右。

2、所有参与决策的人,必须有以下素质才能具备决策资格:

a)  懂得聆听。

b)  在决策之前已经对整个设计有清晰、宏观的了解。

c)  思想集中于目前的事务,不要把不相干或已经讨论过的事物再搀和进来。

3、具备会议控场能力,将会议的主题集中于当前设计的目标,不要太发散。

4、关键人物有一票否决权,但是要慎用,最好有相应的惩罚。

(例如用了否决权之后要请全组吃饭之类。)


1.3.  沟通(完)(重点)

1.3.1. 说明

项目开发中的问题,除了少数不可抗力之外,剩下的基本上全是可以通过沟通解决的问题。

(可以这么说,开发中九成的问题是沟通问题)

沟通,可以说是项目组内成员除能力之外最重要的素质,通常情况下,没有之一。


1.3.2. 换位思考

换位思考,即从对方角度考虑问题。

将自己想像为对方,试着从对方的立场、处境……来分析问题和需求。

……

需要指出的是,换位思考绝不是“替对方着想”这么简单的。

1、从合作伙伴的角度思考,你可以弄清楚对方的情绪与顾忌……以便进一步说服对方。

2、从顾客的角度思考,你可以更好的理解顾客的需求。知道如何提高顾客的需求和心理预期……增加游戏的ARUP值。

3、从玩家的角度思考,你可以从另一个角度来理解和观察自己的设计。你会发现许多地方会是完全的不同。

从游戏设计者的角度来说,只有玩家的角度才是有价值的角度。

4、从领导的角度思考,知道一件事该如何做,为什么做?在什么框架下做?什么能做什么不能做?

对于职员来说,这决定你工作的价值。

发生争吵时和冲突时,试着换位思考。你会发现绝大多数的冲突都是没必要和可以避免的。


1.3.3. 沟通技巧

1、学会倾听。

2、先理解对方,再想办法说服对方。

3、自信的表达你的观点。

4、保持语言简洁,抓住重点。

5、不要打断别人,倾听过程中不要突然提出建议。

6、表扬下属要当众,批评下属要单独。


1.3.4. 如何与你的上级沟通

1、永远不要小看你的上级,特别是你真的比他优秀的时候。

2、永远不要让上级感觉到意外。

3、尽量自己解决问题。

4、提出问题的同时提出解决方案。

5、已经承诺的事情,不能因为有不同的观点而不执行。

6、对所有的承诺要有结果的回馈,否则会失去信任。

7、确保事态的发展在你上级的控制范围内。

8、要掌握好工作汇报的程序和原则(越级报告要处理好)

9、不要把你的领导放在不利的地方。


1.3.5. 禁忌

1、有些领导或特殊人物的不良习惯放在你身上是致命的。

2、妖魔化对方,包括你的上级。

(经常用类似的思考:这丫就这样,一个SB)

3、立刻回复对方说办不到。特别是在没听完的情况下。

4、别人在与你讨论时,心不在焉。

5、先下主观判断,然后再用对方的话来“验证”自己。

6、处理问题时,沉浸于追究责任与原因。

(详见:项目开发过程中莫争是非)


1.4.  故弄玄虚

1.4.1. 解释

职场生活中经常会有生存压力……

在不懂游戏的领导下,如何显示自己的存在感?让自己显得NB?

我不懂程序,如何让程序员不介入我的游戏设计?

我要立项,公司要我提供产品预估和数据分析……天!游戏还没立项就提供数据,你当我会时间穿越啊?

……

对于许多游戏人来说,这些压力是现实的,如果不能做到,别说施展那些抱负、理想,有时人还没坚持到游戏做完就有可能被开除了。

于是,许多就会这些形式主义,而且让策划工作显得“高大上”的言论开始流行。一段时间之后,当一些厉害的牛人(如史玉柱、丁磊)中了招,于是策划也开始不得不相信了。

……

就这样,那些本来来自厕所、餐桌上的“设计心得”就此转正,真的成了策划的能力考核标准。

……

谣言害死人哪!


1.4.2. 附:一些常见的“故弄玄虚”及相关反驳

1、我的数据模型用的是《魔兽世界》的。

驳:

我至少见过四套自称是《魔兽》的攻防算法,而且全都不一样。

2、SMART、微软商务理论

驳:

国民常打赢共产党了吗?

中国游戏界还是第三世界国家的状态,无论是玩家还是开发商都相当低端。

那些高端的理论和针对用户与中国的国情完全套不上。

现在还是“实用至上”的阶段,成功才是硬道理。

所以许多高中生能做出游戏,赚大钱,而“海龟”在国内却几乎全军覆没。

3、我这套游戏经过了市场调研,X%的用户喜欢这种类型。

驳:

骗谁啊?那数据是你昨天晚上在厕所里编的吧?

中国的市场调查体系还不成熟,还无法真实的反应市场的面目和玩家的需求。

目前提供的数据,只能做到满足“领导的需求”这个阶段。

(一个事实是:市场调查数据通常是编的)

4、我的公式用到了高等函数和XXX理论。

驳:

我做数值这么多年,除了概率,没有任何超过初中数学的内容。

而且数据平衡的最重要的就是避免复杂……你还嫌天下不乱哪?

你想用这些“花花词”混口饭吃我不反对,但别拿项目的生死来开玩笑。

5、我们的用高等商业规律来设计经济系统

驳:

说来也巧,我曾有幸接触过最初散布这个理论的策划。他来自网易。

在经过一番尝试之后,他已经放弃了这个不切实际的想法。

……但在现实中,有太多太多的策划需要“包装”数据这个工作。让他显得“高科技”一点,“玄”一点……这样才能避免上层干预。同时也能体现出自己的价值。

顺便说一句,有人说这个东西最初来自韩国。但现实是,韩国的经济系统和数据策划能力之烂从来没入过中国数据策划的视野。


1.5.  开发中莫缠是非(完)

1.5.1. 说明

经常我们会看到一些团队,明明实力很强,却总是在开发过程中陷入争吵。

无数的团队就是死在这些琐碎的争吵之中。

……

认真是一种素质,但对人不对事的“较真儿”却是项目开发的癌症。

在项目开发过程中遇到问题时,不去想办法解决问题,而是先把责任人找到……解了气再说。

这种情绪化的团队几乎没有成功的可能性。


1.5.2. 解释

1、公说公有理,婆说婆有理,项目开发过程中,很难说清楚是谁对谁错。

2、而且通常情况下,责任越大的人,也越有可能成为指责的对象。

策划因为是主设计师,通常是所有错误的对象。

3、你认为有责任的一方,通常很难承认错误。这是因为在项目开发过程中,每个人都会在超过自己极限的情况工作。

人在压力很大、感觉到吃亏、委屈的时候是不太可能承认错误的。

而在项目开发过程中,这种心理只会越来越强,而不太可能化解。

4、纠缠对错,会让问题公开化、表面化……更准确的说,是激化。

但即使“找到”了问题,但解决不了问题……只会让问题更加恶化……

……


1.5.3. 案例1

我认识一个美术,后来成了著名游戏公司的老板(像素:刘坤)。

坦白的说,这个人是个性情中人。为人没什么心机,做的也是自己喜欢的事情……怎么看这个人都不像是我们所熟悉的“老板”或是“成功人士”。

但这个人就是成功了,而且在国产游戏商业化、同质化严重的今天硬是走出一条道路,成为国内唯一坚持游戏性为核心的公司。

……

我曾问过他管理的秘诀,特别是如何在北京这样一个人人都带着几分“痞味”的地方如何处理好团队矛盾?

他的回答是:“学乾隆”。

说的更清楚一些,就是“装糊涂”。


1.5.4. 案例2

某项目开发过程中,因策划规划不好而陷入泥淖。许多问题耽误了,有些副本在完成后又推翻重做。

整个团队士气低落,一些对策划不满的美术进行发难。项目负责人对此表态:必须把问题解决了,项目组才可以前进。

于是策划部与整个团队矛盾开始激化……最后团队分裂……大部分策划先后离开了这家公司。

之后整个项目陷入了停滞……新的策划对项目改来改去,团队内部吵来吵去……两年后,投资方撤销了对团队的投资。

(我见证了此事的全过程,但隐去了相关人员的名字。)


1.5.5. 忠告

1、在开发过程中,如果你发现某人的问题,可以善意的告诉他。如果他不听,你就必须去尝试包容。

因为你们在同一条船上。

2、当你在团队中发现有人有些习惯让你难以忍受时,通常不是他的问题,是你的包容心出了问题。


1.6.  研发过程中需要谨慎修改策划案(完)

全世界的开发人员,最讨厌的一句话是什么?

就是策划说:

“需求改了”

你可以在网上搜到各种关于这几个字的吐嘈和漫画和一些虚假新闻。

……

许多时,策划修改策划案属于“无奈”之举。毕竟经验不足,考虑的不太周全。但许多时,策划会突发奇想,想到一个“绝妙”的点子。恨不得立刻就放到游戏里去。

更多时,是这帮挨千刀的死策划在玩游戏时,看到了一个好的设计,立刻就想到弄游戏中去。

项目开发过程中修改需求,是天大的事儿。但很多时,这帮混蛋策划就那么带着轻松愉快心情以及对未来的憧憬轻易就做出了决定。

……

策划变更策划案,不单令程序、美术等下游员工一段时间的努力付之东流,更重要的是令团队处于混乱之中。

……

需求的变更,不只意味着工作量的增加,对士气的打击。最可怕的是:

风险!

策划在仓促中做出的决策是有风险。

程序在没按自己成熟的框架下写出的代码是有风险的。

因为策划在项目开发过程中,是没有时间进行深度思考的。所做出的决定通常是仓促而缺乏理性的。

而游戏的设计是一个有机体,当一个需求变更时,会引发连锁反应。

麻烦的是,这些反应当时是不会看到的,需要过一段时间,当游戏开始测试或是做到其它部分时才会各个地方层出不穷的冒出来。

……这时怎么办?再改?

一个项目这么折腾上三四次,就基本上废了。

……

需要说明的是:以上内容说的是“研发”过程,而不是“运营”过程。

在运营阶段,根据玩家的需求和数据进行调整是必要的。


转自:游资网

原文链接

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

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

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

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