我如何让不玩游戏的程序员理解开发需求?

发表于2017-01-16
评论31 2.3w浏览

你朋友没吃过榴莲也没吃过臭豆腐,这周你们要一起做榴莲臭豆腐,他是主厨。你如何让他理解这个需求呢?

 

对这类问题,我的解决方法总结起来很简单,并且容易执行:

1.     请他玩要参考的游戏的要参考部分(吃榴莲和臭豆腐)

2.     给他一份“以图为骨,以文字为触手”的策划文档(绘制榴莲臭豆腐食谱)

3.     开会以正确的提问确认需求(请他复述,一起解决疑问)

 

本文中:

游戏策划 = 游戏设计师

知识的诅咒 = 你一旦知道榴莲的味道,就难以想象没吃过榴莲的人心理状态。假设知识是一种病毒,大脑被感染后就很难以未被感染前的状态运作。


01

请他玩游戏

 

为什么要请他玩游戏?口头直接说、文字描述出来不行么?

这个问题涉及到人类大脑的运作方式。

长久以来,我一直在思考这些问题:

理解的本质是什么?

理解和学习是什么关系?

理解和记忆又是什么关系?

 

同时每个人都在说:

“用类比让别人理解”、

“运用基模”、

“要具象化形象化”、

“说人话”……

 

实际上,理解的本质非常简单:新旧概念关联。

 

进一步说,我们只能用对方已有的概念,通过联系、排序、重构,在对方脑中构建新事物,从而完成理解、增加新认知的过程。

 

这其中又引出一个新的问题:

是否存在一种最小概念(元概念),无法再被其他概念所重构?

 

说得通俗一点:

有没有什么概念,是无法很好解释清楚的?

 

《失控》中有这么一段话:

“网络数学不像古典数学,其共同要素是由数千个相互作用的函数所形成的横向因果关系,仅靠研究方程本身很难一窥其特性。各部分间的关联纠缠在一起,试图用数学来描述清楚的话无异于给自己添堵。要想知道方程能产生什么效果的话,唯一的方法就是让方程运行起来,或者用计算机的行话,就是‘执行’方程。”

 

人类的意识、感觉显然是一个复杂的非线性的网络数学系统。

所以,当要人们用“线性逻辑解释

“为什么你觉得她美?”,

“为什么你觉得甜粽子好吃?”,

经常是语焉不详,最终会推给同样虚无缥缈的欲望、本性——兜兜转转,又回到了乱麻中。

 

简而言之:

基于感觉的概念通常是非常底层的、难以被重构的元概念。

 

如果反过来看,元概念也就是我们常说的“直观”。

直观的潜台词是“不需要解释就能理解

在我看来,直观不仅不需要解释,也很难很好解释。

 

比如:

榴莲吃起来像加厚版的奶油——这显然无法传递榴莲臭之精髓。

因为这个臭是“120多种化合物与我们的神经系统所引发的化学风暴,已经是逻辑语言力所不逮之处,因而很难解释好。

而对于吃过榴莲的人而言,榴莲味是一个不需要解释的直观概念。

 

因此我的结论是:

与其通过“概念的联系”让别人理解一个感官概念,不如直接让他体验。

 

因此,每次当我想和程序员说:“目标体验就像XXXX系统那样!”

我都得想一想:他是否玩过XXXX系统?

事实上他有很大概率没有对应的游戏体验——并且这种“元概念”无法通过纯粹的概念联系来理解。

 

所以,解决方案很简单:

“翠花,上游戏!”

 

我们通过“让程序员体验过XXX游戏的X系统(吃过榴莲)”解决了底层概念的构建问题,接下来的交流和需求理解就会容易很多。

 

例如之前要描述一个按钮“Q弹十足的缩放动画”,你可能需要:

·         运动函数和图像

·         文字说明

·         指手画脚比划

而现在你可能只要说“做得和‘打造’按钮的动画一样”——程序员便会立即理解你想要的效果,并发挥自己函数表达的专长为你挑选合适函数。

 

然而,想通过让程序员玩玩游戏就能理解需求还是太Naïve

用上面的话说:感觉的理解是一个网络数学问题,而系统的开发则更接近经典数学问题——换句话说,游戏中某个系统的开发是一个具体的工程问题。

那么,如何解决这个具体的工程问题呢?

 

02

提供一份图文相济的策划文档

 

1)游戏,物种,建筑

游戏本身就是一个物种。

从自然中物种演变的角度去研究游戏,会给我们带来许多启发。

例如自然界中稳定是常态,剧变是偶然——虽然游戏行业一直有人标榜创新,但我认为这是被宣传放大的事实。

经历了上个世纪末到本世纪初的生命大爆发后,各大游戏物种基本成型,后面出现新游戏物种的速度在放慢(例如十年前的MOBA、五年前的COC,都被大众归为新物种,称为类XX游戏)——正如地球最近五亿年也很少有新的物种出现。

虽然游戏物种本身也在经历市场环境的选择:不受欢迎的濒临灭绝,适应市场的大行其道,也因适应环境的需要,其本身也在不断发生变异,但仍改变不了游戏类型特征稳定的事实

次世代全自由MMO

二次元绿色MOBA

基于LBS的真实社交手游?

这些设计师引以为傲的(微)创新,通常只是稳态下的一朵浪花罢了,哪里是什么新物种。

 

但是,游戏形态的稳定没有好的一面吗?

 

《失控》中有这么一段话:

对生物进化的束缚也正是人工进化的希望所在。进化动力学中的每一个负面约束都可以从正面来看待。用来维持旧传统的束缚力可以用来创造新事物。将生物限制在自己的形态内,防止其随意漂移到其他形态的力量,也正是最初使得生物成形的力量。而当某个物种奋力一跃,挣脱原有的稳定态时,同样的内敛性会诱使它进入一个新的内稳态。乍一看这有些奇怪,但的的确确,束缚即创造。

 

实际上,对于大部分游戏设计师而言,游戏形态的稳定是重大利好。

 

这至少允许我们做以下几件事:

·         解剖特定类型的游戏(如果它是不定形的风,我们会难以解构)

·         用工程学的方式构建特定类型的游戏,并获得该类型的特性(构建一个社区类MMORPG给玩家提供持续成长感、稳稳满足感,结果可预期)

·         标准化、批量化的商品让行业得以成型(流水线式生产、分发、营销等)

 

当然,每个游戏设计者对游戏的定义不会完全一样,

有人认为自己是艺术家,做的是艺术品;

有人认为自己是商人,做游戏就为赚钱;

我对它的定义则是“工艺品”。

它既非纯粹的没有审美功能的工程项目,也不是没有实用价值的艺术品。

这种特性,使得游戏设计师和许多方面和建筑师非常相像。

 

作为一个年轻的行业,电子游戏有太多智慧可以从建筑学汲取。

在这里我尝试借助建筑工程解决工艺品中的部分:

我们能否参考建筑施工图文件写出一份类似的游戏施工图文件?

 

我经常在对策划的要求中看到以下关键词:

结构化,清晰,严谨,完整,逻辑

这些词形容的肯定是策划的产出:要么是口头语言,要么是书面文档。

 

令我惊讶的是,苦苦追寻的答案直接就浮现在建筑施工图中——在看到这些建筑图纸时,我脑中一下就想到了这些关键词。

长期的发展使得建筑学在解决建筑工程时精准而优雅;

例如数字会标得很清楚。这点许多策划并不能做到

 

我从建筑图中得到的最重要启发是:

图,图,图。

 

有一句话这么说:能动手,就别逼逼。

在这里,我这么说:能画图,就别逼逼。

 

好的演讲应该有一个主线,

好的需求文档,应该以某个图为主线,让图来完成大部分信息传达工作;

再辅以文字说明,让文字完成细枝末节、极值、容错等情况的处理,成为文档的边界。

 

我认为,这是一个非常好的包容性的策划案架构

 

多年的游戏开发经验告诉我,手机游戏开发和建筑施工最大的区别在于灵活度(本质上来源于项目不确定性程度的差别)。

因此手游很难彻底的工程化——用几个月时间给你出一个详尽标准的策划“施工图,然后给程序员做——传统的瀑布式开发正被边缘化,敏捷或者迭代式开发已成为行业主流。

 

与之对应的,策划案也必须能适应这种开发节奏,并能包容需求的变化。

在这里,我假定游戏开发中:

大的需求变化出现的频率很低。也即前面提及的“物种成型

小的需求变化在频繁、持久地发生(有人称为“微创新”);

游戏既不处于一成不变的均衡态,也不处于无法定型的失衡态,而是一直在永不停歇、永不衰落的边缘上冲浪。

 

所以,在我这策划案中,

图形继承了系统的主体架构和灵魂,让它的精髓能被读者理解并记忆;

文字则像是无所不及的分布式触手,行走在广度和深度的边界上,一方面提供足够让程序员得以开展工作的信息具体度,另一方面也在随时承接可能发生的微小变革。

 

2)示例:一个宠物系统策划文档

为了让读者更好理解,下面以我曾写过的一个宠物系统为例进行说明。

 

PS:这里只解决“信息传达和沟通问题。不解决诸如“这个系统有没有必要做?”“具体怎么设计?”“要多少人做多久啥时上线?”“数值怎么投?”“UI怎么画?等问题。

 

策划案背景:

·         给谁看:前后端程序、QA

·         目的:作为开发需求并提供测试验收标准;

·         宠物系统。

 

·         首先,我采用了Excel来呈现文档。

关键词:横向对比,超链接,结构化。

 

两张图可以说明:

Excel基本结构:Sheet x Sheet

 对比Word的串行结构:

我们可以直观地感受到区别:

Sheet天然构成了回溯按钮,再加上可以精确到单元格的超链接——你可以快速从某个层级的节点跳转到任意节点。

Word虽然提供了交叉引用,但我更享受在Excel中一个个模块化的数据库之间穿梭。

 

2) 第一章:

大纲、综述、概述、总览,无论怎么称呼,都要保证:

1.      用几句话说出你最想说的,有助于别人理解、且别人需要知道的文档关键句;

(例如我就喜欢一遍遍说目标,并希望程序员能理解并认同这个目标)

2.      一个最高层级的目录(目录层级是否向下展开看具体需求);

 

如下图:

·         按顺序和层级展开,并完成该层级下的图片制作(主线)

在此我们就可以学习施工图的信息组织方式,这里我以属性界面为例:

和做施工图一样,这里最主要的工作是:制(画)图。

 

制图的过程本身也是我们进行信息组织和设计的过程,用什么工具好?

 

工具服务于目的。

在这里我选择使用Photoshop而不用Axure有两个原因:

·         追求敏捷,进度和最大效率。我用起PS更顺手,加上我是需求的发起者,相较于按流程转交给专门的交互设计人员(事实上当时也不够人,尴尬脸),我宁愿撸起袖子自己快速搞定,快速试错,快速验证;

·         广泛的素材提取与利用。虽然Axure强在控件库并提供一定的交互测试,但我对许多游戏的系统信手拈来,它们全是我的素材,在素材提取上,PS当仁不让。通过这种广泛取材组合碰撞的方式,许多新的创意(也是不同的解决方案)被激发,我们从中筛选出适合自己游戏的方案。当然,这离不开对素材性味及其来源的理解,算是发挥了策划自身的优势(图中提取了6个游戏的界面素材)

 

当然,如果有时间和人手,Axure会是非常好的选择。

·         通过对控件库进行积累、管理和运用,使整个图形设计更为标准化、模块化(图形本身也是文档的一部分);

·         为公司积累宝贵的过程资产,这当今游戏市场越来越讲求精品的情况下尤其重要。


梦幻西游手游的UI设计大量使用Axure

 

再次强调,PhotoshopAxure都服务于制图这个目的。

 

实际工作中策划可以用到的图的种类非常多,因而用来制(静态)图的工具也非常广,这里做个简单列举:

用途&类型

工具

最快速绘制

纸笔

图表、数字转图像

ExcelMATLABPPT

电子绘制,素材组合、加工

PhotoshopSAI、操作系统自带绘图工具

拼界面,测交互

Axure

流程图、简单界面或示意图

Visio

树形结构图、思维导图

XMindMindManager

项目进度图

Project

我没用过但听有人在用的。。。

SketchupSketchAutoCAD、其他数据可视化工具

 

需要记住的一点是:读者只关心你的图,不关心你用什么工具做出了图。

 

·         做出图之后添加文字说明

我们依然先看下图:

 这些文字有什么要点?

是走马观花,还是事无巨细?

项目管理中推崇“渐进明细”,但同时我们也经常听到有人抱怨“策划需求不清晰”,两者如何平衡?

用上文的话回答:

这些文字的具体深入程度,就是我这个文档流动的边界。

它足够具体,具体到能保证程序和测试能据此信息进行工作;

它足够概括,概括到能够随项目进展、可能的变更而不断“进、细”。

也正因如此,我不看好“施工图式、事无巨细”的策划案,因为无法应对变化;

也不赞成“不加维护与修订、过于简略”的策划案,因为这让工作难以进行。

 

如果说图是大部分人都能看懂的话,这些文字则被我称为“面向读者的信息”

回忆一下我们的读者:前端程序员、后端程序员、测试员(当然可能三个角色是同一个人),

不同角色关注的点不一样,但这不意味着我们一定要进一步拆解工作包为更细碎的文字。

 

为了保证我们的文字信息已经足够详细到能让读者开展工作,我们要进行最后一步

 

03

开会以正确提问确认需求

 

开会这个话题是一个巨大的坑,形形色色的话题都可以往里填。

这里我将这个步骤简化为一个情景:

当你给开发人员玩过游戏,看过文档并开会讲解后,通常会问他们一句:

还有什么不懂的吗?

 

然而,这个问题一点都不高效。

想象你去参加一个课程或演讲,如果演讲水平不高(通常如此),演讲后通常会进入提问环节——此时,你会经常看到尴尬的冷场。

 

还有什么不懂的吗?

这个问题每个策划都会问,甚至谁都可以问,如此常见又如此平庸,以至很少有人会去思考:

有没有更好的提问方式?

 

我认为更高效的提问方式是:

XXX(指代人),你给我讲下你怎么理解这个需求的?

 

我发明(也许不是第一个)的这个提问方式,融合了以下几个心理学原理:

·         打破从众心理和麻木心理。类似于在街上突然摔倒需要帮忙,不应喊“来人帮帮我,而是应该直接指定盯准一个人“你,快来救我!,此时穿透力更胜覆盖面;

·         给别人当老师是高效的学习方式。我们在讲解知识时,大脑在不断提取和组织信息,会加深我们的学习过程。所以这里我反客为主,让对方来给我讲解他对需求的理解,来确保他确实从我这里学到了我想表达的观点;

·         及时反馈提升沟通效率。如果在表达的过程中有障碍或误解,我们可以立即纠正;其次,自己作为一个倾听者,也可以获取对方对需求的补充意见,并最终达成共识。

 

会议作为工作的一部分,必然是以结果为导向并讲求效率的。

什么是好的会议结果?——大家理解了参加会议之前没理解的需求,同时需求作为思想得到传播、完善,并在大家心理达成共识。

所以,这也决定了我们向谁提问:谁最不理解需求?谁最常问策划这个要怎么做?——让这个问题来帮助他更好地理解吧。

 

04

结语

 

游戏策划(游戏设计师)有大量的工作要和其他成员配合完成,需求的沟通非常重要。

然而游戏策划通常比常人拥有更多游戏经验,也因而陷入“知识的诅咒”。

 

如何让不玩游戏的程序员理解开发需求?

 

答:

1.    请他玩要参考的游戏的要参考部分

2.      给他一份“以图为骨,以文字为触手”的策划文档

3.     开会以正确提问确认需求

 

希望这答案能对项目组和平做出贡献

*~( ̄▽ ̄)~[] []~( ̄▽ ̄)~*

 

(蛤?你说你们策划不玩游戏?——能动手就别逼逼了,上,打他……)

 


 欢迎来微信找我玩,本人不会撕逼,,,想撕的放过我,,,



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