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

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

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

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基本结构：SheetxSheet


对比Word的串行结构：


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

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

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

2) 第一章：

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

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

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

2.  一个最高层级的目录（目录层级是否向下展开看具体需求）；

如下图：

• 按顺序和层级展开，并完成该层级下的图片制作（主线）
  

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


和做施工图一样，这里最主要的工作是：制（画）图。

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

工具服务于目的。

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

• 追求敏捷，进度和最大效率。我用起PS更顺手，加上我是需求的发起者，相较于按流程转交给专门的交互设计人员（事实上当时也不够人，尴尬脸），我宁愿撸起袖子自己快速搞定，快速试错，快速验证；
• 广泛的素材提取与利用。虽然Axure强在控件库并提供一定的交互测试，但我对许多游戏的系统信手拈来，它们全是我的素材，在素材提取上，PS当仁不让。通过这种广泛取材组合碰撞的方式，许多新的创意（也是不同的解决方案）被激发，我们从中筛选出适合自己游戏的方案。当然，这离不开对素材性味及其来源的理解，算是发挥了策划自身的优势（图中提取了6个游戏的界面素材）。
  

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

• 通过对控件库进行积累、管理和运用，使整个图形设计更为标准化、模块化（图形本身也是文档的一部分）；
• 为公司积累宝贵的过程资产，这当今游戏市场越来越讲求精品的情况下尤其重要。
  

再次强调，Photoshop、Axure都服务于制图这个目的。

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


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

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

我们依然先看下图：


这些文字有什么要点？

是走马观花，还是事无巨细？

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

用上文的话回答：

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

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

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

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

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

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

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

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

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

03、开会以正确提问确认需求

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

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

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

还有什么不懂的吗？

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

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

”还有什么不懂的吗？“

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

有没有更好的提问方式？

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

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

我发明（也许不是第一个）的这个提问方式，融合了以下几个心理学原理：

• 打破从众心理和麻木心理。类似于在街上突然摔倒需要帮忙，不应喊“来人帮帮我”，而是应该直接指定盯准一个人“你，快来救我！”，此时穿透力更胜覆盖面；
• 给别人当老师是高效的学习方式。我们在讲解知识时，大脑在不断提取和组织信息，会加深我们的学习过程。所以这里我反客为主，让对方来给我讲解他对需求的理解，来确保他确实从我这里学到了我想表达的观点；
• 及时反馈提升沟通效率。如果在表达的过程中有障碍或误解，我们可以立即纠正；其次，自己作为一个倾听者，也可以获取对方对需求的补充意见，并最终达成共识。
  

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

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

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

04、结语

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

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

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

答：

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

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

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

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

*~(￣▽￣)~[] []~(￣▽￣)~*


（蛤？你说你们策划不玩游戏？——能动手就别逼逼了，上，打他……）

via：GAD