我如何让不玩游戏的程序员理解开发需求?
你朋友没吃过榴莲也没吃过臭豆腐,这周你们要一起做榴莲臭豆腐,他是主厨。你如何让他理解这个需求呢?
对这类问题,我的解决方法总结起来很简单,并且容易执行:
1. 请他玩要参考的游戏的要参考部分(吃榴莲和臭豆腐)
2. 给他一份“以图为骨,以文字为触手”的策划文档(绘制榴莲臭豆腐食谱)
3. 开会以正确的提问确认需求(请他复述,一起解决疑问)
本文中:
游戏策划 = 游戏设计师
知识的诅咒 = 你一旦知道榴莲的味道,就难以想象没吃过榴莲的人心理状态。假设知识是一种病毒,大脑被感染后就很难以未被感染前的状态运作。
01
▼
请他玩游戏
为什么要请他玩游戏?口头直接说、文字描述出来不行么?
这个问题涉及到人类大脑的运作方式。
长久以来,我一直在思考这些问题:
理解的本质是什么?
理解和学习是什么关系?
理解和记忆又是什么关系?
同时每个人都在说:
“用类比让别人理解”、
“运用基模”、
“要具象化形象化”、
“说人话”……
实际上,理解的本质非常简单:新旧概念关联。
进一步说,我们只能用对方已有的概念,通过联系、排序、重构,在对方脑中构建新事物,从而完成理解、增加新认知的过程。
这其中又引出一个新的问题:
是否存在一种最小概念(元概念),无法再被其他概念所重构?
说得通俗一点:
有没有什么概念,是无法很好解释清楚的?
《失控》中有这么一段话:
“网络数学不像古典数学,其共同要素是由数千个相互作用的函数所形成的横向因果关系,仅靠研究方程本身很难一窥其特性。各部分间的关联纠缠在一起,试图用数学来描述清楚的话无异于给自己添堵。要想知道方程能产生什么效果的话,唯一的方法就是让方程运行起来,或者用计算机的行话,就是‘执行’方程。”
人类的意识、感觉显然是一个复杂的非线性的网络数学系统。
所以,当要人们用“线性逻辑”解释
“为什么你觉得她美?”,
“为什么你觉得甜粽子好吃?”,
经常是语焉不详,最终会推给同样虚无缥缈的欲望、本性——兜兜转转,又回到了乱麻中。
简而言之:
基于感觉的概念通常是非常底层的、难以被重构的元概念。
如果反过来看,元概念也就是我们常说的“直观”。
直观的潜台词是“不需要解释就能理解”。
在我看来,直观不仅不需要解释,也很难很好解释。
比如:
”榴莲”吃起来像加厚版的奶油——这显然无法传递榴莲臭之精髓。
因为这个臭是“120多种化合物与我们的神经系统所引发的化学风暴”,已经是逻辑语言力所不逮之处,因而很难解释好。
而对于吃过榴莲的人而言,“榴莲味”是一个不需要解释的直观概念。
因此我的结论是:
与其通过“概念的联系”让别人理解一个感官概念,不如直接让他体验。
因此,每次当我想和程序员说:“目标体验就像XXX的X系统那样!”
我都得想一想:他是否玩过XXX的X系统?
事实上他有很大概率没有对应的游戏体验——并且这种“元概念”无法通过纯粹的概念联系来理解。
所以,解决方案很简单:
“翠花,上游戏!”
我们通过“让程序员体验过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
再次强调,Photoshop、Axure都服务于制图这个目的。
实际工作中策划可以用到的图的种类非常多,因而用来制(静态)图的工具也非常广,这里做个简单列举:
用途&类型 | 工具 |
最快速绘制 | 纸笔 |
图表、数字转图像 | Excel、MATLAB、PPT |
电子绘制,素材组合、加工 | Photoshop、SAI、操作系统自带绘图工具 |
拼界面,测交互 | Axure |
流程图、简单界面或示意图 | Visio |
树形结构图、思维导图 | XMind、MindManager |
项目进度图 | Project |
我没用过但听有人在用的。。。 | Sketchup、Sketch、AutoCAD、其他数据可视化工具 |
需要记住的一点是:读者只关心你的图,不关心你用什么工具做出了图。
· 做出图之后添加文字说明
我们依然先看下图:
这些文字有什么要点?
是走马观花,还是事无巨细?
项目管理中推崇“渐进明细”,但同时我们也经常听到有人抱怨“策划需求不清晰”,两者如何平衡?
用上文的话回答:
这些文字的具体深入程度,就是我这个文档流动的边界。
它足够具体,具体到能保证程序和测试能据此信息进行工作;
它足够概括,概括到能够随项目进展、可能的变更而不断“进、细”。
也正因如此,我不看好“施工图式、事无巨细”的策划案,因为无法应对变化;
也不赞成“不加维护与修订、过于简略”的策划案,因为这让工作难以进行。
如果说图是大部分人都能看懂的话,这些文字则被我称为“面向读者的信息”。
回忆一下我们的读者:前端程序员、后端程序员、测试员(当然可能三个角色是同一个人),
不同角色关注的点不一样,但这不意味着我们一定要进一步拆解工作包为更细碎的文字。
为了保证我们的文字信息已经足够详细到能让读者开展工作,我们要进行最后一步:
03
▼
开会以正确提问确认需求
开会这个话题是一个巨大的坑,形形色色的话题都可以往里填。
这里我将这个步骤简化为一个情景:
当你给开发人员玩过游戏,看过文档并开会讲解后,通常会问他们一句:
还有什么不懂的吗?
然而,这个问题一点都不高效。
想象你去参加一个课程或演讲,如果演讲水平不高(通常如此),演讲后通常会进入提问环节——此时,你会经常看到尴尬的冷场。
”还有什么不懂的吗?“
这个问题每个策划都会问,甚至谁都可以问,如此常见又如此平庸,以至很少有人会去思考:
有没有更好的提问方式?
我认为更高效的提问方式是:
XXX(指代人),你给我讲下你怎么理解这个需求的?
我发明(也许不是第一个)的这个提问方式,融合了以下几个心理学原理:
· 打破从众心理和麻木心理。类似于在街上突然摔倒需要帮忙,不应喊“来人帮帮我”,而是应该直接指定盯准一个人“你,快来救我!”,此时穿透力更胜覆盖面;
· 给别人当老师是高效的学习方式。我们在讲解知识时,大脑在不断提取和组织信息,会加深我们的学习过程。所以这里我反客为主,让对方来给我讲解他对需求的理解,来确保他确实从我这里学到了我想表达的观点;
· 及时反馈提升沟通效率。如果在表达的过程中有障碍或误解,我们可以立即纠正;其次,自己作为一个倾听者,也可以获取对方对需求的补充意见,并最终达成共识。
会议作为工作的一部分,必然是以结果为导向并讲求效率的。
什么是好的会议结果?——大家理解了参加会议之前没理解的需求,同时需求作为思想得到传播、完善,并在大家心理达成共识。
所以,这也决定了我们向谁提问:谁最不理解需求?谁最常问策划这个要怎么做?——让这个问题来帮助他更好地理解吧。
04
▼
结语
游戏策划(游戏设计师)有大量的工作要和其他成员配合完成,需求的沟通非常重要。
然而游戏策划通常比常人拥有更多游戏经验,也因而陷入“知识的诅咒”。
如何让不玩游戏的程序员理解开发需求?
答:
1. 请他玩要参考的游戏的要参考部分
2. 给他一份“以图为骨,以文字为触手”的策划文档
3. 开会以正确提问确认需求
希望这答案能对项目组和平做出贡献
*~( ̄▽ ̄)~[] []~( ̄▽ ̄)~*
(蛤?你说你们策划不玩游戏?——能动手就别逼逼了,上,打他……)
欢迎来微信找我玩,本人不会撕逼,,,想撕的放过我,,,