文 / 陈忾 授权GameRes游资网独家发布，请勿转载。
1、触动/想法
国外的大公司通常都有这样一个职务：Creative Dirctor——创意总监。他的一个工作职能就是接收来自各个方面的触动/想法。或者说，他应该是一个思路盒子，用来承载和运作大家的想法。
如果没有，那么就要思考一下，创意应该传递给谁、怎么传递？
触动可能来自于很多很多环节，就一个游戏公司而言，它通常来自于：
- CEO率领的高级管理团队，基于企业运营数字所发现的某个市场的机会或风险；
- CEO率领的高级管理团队，基于自身的信息渠道所发现的某个市场的机会或风险；
- 如果企业里有CIO（首席信息官），他的一个工作职能就是收集归纳市场上的各种信息，并将这些信息传递给企业各个层级的管理者，从而希望管理者们能够有所触动；
- 如果企业里有产品调研小组或部门，则他们的一个工作职能就是系统的分析市场上已有的成功和失败产品，从而期望得到市场的某个趋势变化，从而产生对创造机会和规避风险的想法。产品调研也会被称作评测。
- 中层管理者和基层雇员，基于自己的信息渠道所得到的触动。比如看了《阿凡达》之后所产生的创造一个那样的虚幻世界的念头。这是最基本的触动源点。
典型的触动是什么样的？
“哇！《魔兽世界》的这个随机跨服组队的功能太好了！我们也要有一个！”
对，没错的。这个就是最典型的、最基本的触动了。
它可能有点小，还有更大的触动：
“苹果公司推出的IPAD的市场有xx这么大，每多少个人之中就会有一人拥有一台IPAD。假设这些人里面每多少个人就有玩游戏的需求，那这个市场就有xx那么大。我们现在的技术实力和美术实力都可以驾驭IPAD平台的游戏需求，我们现在需要去调研一下IPAD游戏用户的需求点，好去确定一下我们该如何做。”
2、概念
有了想法之后要进行概念规划。
想法只是一个点，从这个点出发进行工作，任何一个人都会发现无从做起，因为从一个点到底另外一个点——目标——的确是有无穷无尽的途径。
概念就是一个轮廓。注意，我没有说概念是一个范围，因为概念还没有那么清晰。等我们做到需求规划的时候，我们才能说我们得到了一个范围。
那么概念是什么呢？
好了，我们把这个典型的触动拿出来——“哇！《魔兽世界》的这个随机跨服组队的功能太好了！我们也要有一个！”
那么概念阶段要做的事情主要有2个：
- 搞清楚引发你触动的源点是个什么东西——也就是我们要做好分析
- 搞清楚制造这个源点的人是个什么意图——也就是我们要做好推测（如果这个源点不是人创造的而是自然发生的，那么你需要知道自然的规律是什么，是什么真理在发挥作用）
那么基于随机跨服组队的功能，我们先来做做分析，它到底是个什么玩意：
- 随机组队的意思是你不用自己找队友了，而是通过一个功能模块的运作将符合要求的其他玩家同你组建一个队伍。
- 跨服的意思就是这个功能模块不是限定在一个服务器中检索用户的，而是在一个跨越了更多服务器的更大的范围内。
这样就够了么？肯定不够嘛。我们再看看这两句话里面有什么概念还没有被清晰的阐述：
- 符合要求是什么意思？比如有坦克、输出、治疗的铁三角职业定位的要求，有英雄难度还是普通难度的划分，有目标副本是哪个的要求，等等~~
- 更大的范围究竟是个什么范围呢？其实在游戏里面是查不到的，也就是wow的大区划分。跨服的范围就是在本区的多组服务器之内。
- 队伍组成了之后怎么分配战利品啊？按需分配喽。那么按需分配的规则是什么总要分析出来吧。
- 如果组进来的人掉线了怎么办啊、如果组进来一个不会打的人怎么办啊，把踢人的规则分析出来。
- 随机组队进来的人因为没有配合过所以可能战斗力会下降，那么我们怎么提高一下战斗的成功率呢？给一个随机组队的buff吧。这个我们是不能忽略的。
- 想想还有什么细节是遗漏的啊……
一个小小的触动居然有这么复杂的信息隐藏在背后。假设我们已经完成了分析，那么我们就要开始做推测啦。
- 暴雪为什么要设计这样一个随机跨服组队呢？是因为玩家之间组队不方便吗？
- 所有的玩家组队都不方便么？看来不是啊，那几个玩家都是一个公司的，是亲友团，他们上线时间固定，上线之后就组队，人够了就下本。看来不是所有的玩家在组队方面都有困难。那么我们就可以确定组队不方便的玩家应该都是偏休闲向的。
- 你说这群休闲玩家，本来就没啥时间玩了，还不放弃。搞得还得特别照顾他们——你说说为什么暴雪非要照顾休闲玩家呢？自己推测个答案出来。然后你再去分析分析为什么CTM的副本难度要设定得这么高，是否跟你推测出来的照顾休闲玩家的答案冲突呢？
- 继续吧，看来门道还很深的……
3、需求
什么是需求？需求是什么？
- 概念的出发点是“这是什么？”
- 需求的出发点是“我们要什么？”
确定需求是产品诞生环节中最难做的，因为你要开始做取舍了。做取舍是这个世界上很难很痛苦的事情。
最要人命的需求就是：“我们要一个跟魔兽世界的随机跨服组队一样的随机跨服组队功能。”
这样的需求看似很明白，其实烂到极致了。因为隐藏的条件差别太了。
- 你是否有跟魔兽世界一样的程序架构？
- 你是否有跟暴雪实力一致的开发人员？
- 你是否有跟魔兽世界用了5年才积累起来的一样喜好和习惯的玩家？
- 你肯花跟暴雪投入的一样多的时间和资金吗？
- 你是否拥有跟暴雪用了二十年所积累起来的Fans群吗？
所以，只能做取舍。
做取舍的时候就只有一个问题要不停地反复的问自己：“这个真的是我需要的吗？”
如果你能做到每一个细节都问过这个问题并且有了答案，那么你的需求管理就做到位了。
需求的层次
业务需求
说明为什么要从事此项目的开发以及它给客户带来的利益。具体包括业务机遇、业务目标、产品价值以及开发该产品的有关风险。
例子：“用户能有效地纠正文档中的拼写错误。”
用户需求
用户使用产品必须要完成的任务。
例子：“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换的拼错的词。”
功能需求
定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
例子：“如找到并高亮提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。”
需求的构成：
- 商业分析（BA）
- 概念图
- 策划文档
- 静态数值表
- 游戏结构图
- 玩法程序流程图
- UI原型
- 美术需求单
- 美术素材规则
- 程序规格
- 用户行为预测
- 服务器生态预测
4、设计
设计最怕的是什么？——需求不明！
需求怎么会不明呢？
1. 需求方没有在概念层面上做好分析和推测，结果导致自己对自己想要什么还不明白。
2. 需求方已经想明白了他想要的是什么，但是因为语言环境和工作方式的不同，导致他的需求中包含了隐藏起来的信息。
好了，那么做设计之前要做什么啊？就是：
1. 确定需求方的需求是否以经过了概念层面的分析和推测，如果这个工作没有做好，那么设计人员要依靠自己的经验来帮助需求方明确需求。
2. 花时间和精力加深沟通，把需求之中的隐性需求都明确出来。
举例来说吧（我假设的哦，实际情况肯定要更加复杂的）：
迪拜的王子提出了一个需求：“我要建一个七星级的酒店。”
设计师：“在哪呢？”
王子：“海上！”
设计师：“好的，我有填海造陆的经验。您还有什么需求呢？”
王子：“我需要它有一百米高，站在它的上面可以俯视整个海湾。我需要它灯火通明。我还要在它周围建造富豪区，我要让全世界的富翁同我一起感受迪拜的魅力！”
设计师：“这样啊，那我们需要填出更大面积的海，这难不倒我。您还有什么需求么？”
王子：“暂时没有了。你先去设计一个蓝图吧，然后我们再商讨细节。”
设计师就离开了，去做他的设计蓝图。
那么，设计师一共得到了多少隐性需求？我不是搞建筑的，具体真实的情况我可分析不出来，但是我起码知道以下这几个：
1. 安全的需求。这个七星级酒店在填出来的陆地上，所以要从根本上打消顾客担心它的地基不够牢固的顾虑。它在海上，如果来了风暴怎么办？如果发生火灾了怎么办？是否有足够宽阔的道路能够把人疏散出去等等的安全的隐性需求。这些需求是所有建筑都要去考虑的，需求方很可能会不会跟你提到，因为他觉得傻子都会知道。
2. 盈利的需求。我相信迪拜虽然破产了，但是他的王子是具有远见卓识的眼光的，他知道迪拜拥有着什么样的资源，可以用这些资源赚什么钱。我们说，迪拜的那一整条海湾都是一个整体的规划，而不仅仅是那一座七星级的酒店。那么整个发展旅游业的规划之中，为了保证酒店的盈利能力，设计师需要知道顾客从机场出来花多久可以到达酒店，为此他可能需要规划一条从机场到酒店的直达高速路，这条高速路还要能够欣赏到海湾的美景，所以不能弄成地下的。游客对酒店的需求都有什么，都会有什么客人来住，所以一开始就要规划好有多少普通客房、有多少豪华客房、有多少总统套房。当然，这可不是一个设计师就能搞定的，这需要一个庞大的团队来协同工作。
3. 印象的需求。客户满意度方程式是：客户满意度=我们做到的/客户期待的。设计师需要考虑到王子对国家的热爱，对未来的踌躇。所以这个七星级酒店要成为迪拜的形象。因此这个酒店就不能设计的跟普通的摩天大楼似的，它的外形必须是独特的，必须是能够表达迪拜人文历史的，必须是可以成为迪拜人民骄傲的。
如果你真的用了这么多心思去挖掘需求，那么除非这个需求真的是天底下第一次，否则设计应该是没有什么难度的。
比如，我们知道有15种方法可以填出这片陆地。那么我们就从中选择一种吧。再把另外的两个作为后备方案。
比如，我们知道有20种方法可以处理消防隐患，那么我们就从中选择出7种吧，针对局部的特点来从这7种中再选出适合的进行实施。
比如，我们知道有3种在顶层建立直升机平台的方案，那么我们就选出1个来吧，用了照顾那些能够从空中来的富豪。
……诸如此类的，需求在被充分挖掘的情况下，做设计上的取舍就只是“我们能掌控什么就怎样做”的结果了。
需要特别说明的，需求和设计常常被混合在一起处理，是因为我们在分析需求的过程中，其实是需要拿出一些设计方案才能来进行讨论的。比如要先选出几种填海的方法，才能分析我们能要求的是一个怎样的填海结果。
我用图来表示这5个环节的交错情况：
- 触动是独立的。
- 概念是独立的，概念在触动完成之后进行。若概念形成阶段发现触动是需要变更的，则回到触动的环节完成触动，之后根据新的触动进行概念的再造。
- 需求的环节贯穿了需求和设计两个环节。需求在概念之后进行，在设计的环节中还要对需求进行审查Review，在进行开发之前需求需要确定。通常我们在开工之后需求还会变更，但是这样做的后果就是支付更多的成本去调整和修正。因此在完美的方案上，我们要在开发之前结束需求环节。
- 设计牵涉到三个环节，设计的工作在需求阶段就已经开始了，在开发的过程中设计方案也会变更，这都是非常正常的事情，所以设计方案中对于一些细节应该有多个后备可选方案，这样在开发动手之前进行更准确的规划，以及防备措手不及。
- 开发要从设计阶段就开始了，但是必须在需求阶段完成之后，否则就要扛着很大的风险进行了。有些人会用原型法来进行项目管理，这个时候可能从概念阶段就会有开发人员进行原型的制造了。我将原型法看做是概念、需求和设计阶段的一个构成单元，而不将它视作开发的构成单元。更准确的说，你要进行开发了，你的原型应该已经出来了才对。开发要到运营结束的时候才算结束，什么才算运营的结束，就要看你的企业是怎么进行产品的产品生命周期管理（PLC，Product Life Cycle Managenet）了。
5、开发
开发我就只说一个事情——那就是万分强烈的建议您学习和尝试项目管理知识体系来进行开发的管理。
开发是真正符合PMI的项目定义的：为了独特的产品、服务或成果而进行的临时性工作。
开发有明确的起点，有明确的终点。以开发出产品、服务或成果为目标。
开发是这5个环节中所需花费最多成本的地方，为了开发能够正确和顺利，我们都应当把前面4个环节做好。
6、产品验收
产品开发出来之后，在运营之前需要进行成套的产品验收工作。
我并未把验收环节收入产品诞生的步骤之中，因为有这样一种极端情况：“产品生产出来之后就是完美的！”
比如现实世界中有这样一个故事：
美国通用为自己做了一个品牌形象的广告。广告中，一辆汽车在流水线上生产，有400位品质控制人员参与其中。然后，日本丰田针对这个广告也出了自己的一个广告。在广告中，一辆汽车的生产没有任何一位QC人员。
丰田说：“品质是规划出来的，不是检查出来的。”
因此，我所归纳的产品的五个步骤中，并不包含验收环节。这并不表示我不重视验收，尤其是程序代码近乎不可能没有BUG的状况下。
经过以上五个步骤之后，就要进行品质控制QC及公开测试了。
| 
发表于 2015-4-15 18:13:58
