游戏开发过程中需求变化那些事

[原文链接](http://www.bugclosed.com/post/18) : http://www.bugclosed.com/post/18 ## 背景 随着软件项目越来越庞大，为了提高开发效率和有效的质量管控，开发过程中的项目管理越来越重要，流程分工也在不断细化。传统的软件开发过程分大致分为如下几个步骤： 1. 需求提出 2. 可行性分析 2. 需求分析 3. 概要设计 4. 详细设计 5. 编码 6. 测试 7. 集成交付 产品的最终形态和功能都是第一步的需求所决定，“蝴蝶效应”在开发过程中体现特别明显，第一步的需求发生了变化，很可能会导致后面所有步骤都重来一遍。传统的项目管理除了对项目过程的管控，更多的是对需求的管理。传统的软件项目开发过程中会尽力避免需求的变更，甚至在需求确定以后会由需求提出方（合作开发）出具正式的需求文档并盖章确认以示“不再改变“。 传统的软件开发流程是一个工业流程化的模拟过程，最大力度的管理变化，然后进行工序的详细分拆和实施。整个过程中会有大量的各部门（公司）的沟通会议和流程，时间成本极其庞大，动辄数年的版本计划也很常见。 随着互联网的快速发展，市场环境和用户喜好都在急速的变化过程中，动辄数年的产品开发周期已经远远不能满足日新月异的市场形势。互联网产品，特别是游戏类产品，开启了精益开发，小步试错，快速迭代的开发模式，并非从一开始就需要构建一个大而全的完整产品，而是最开始只推出最核心的单一功能，通过不断迭代来完善和调整产品，开发过程中不断收集用户反馈，并将有效反馈意见融合进下一个迭代版本中。 “小步试错，快速迭代”的前提否定了需求的”圣神性“和”不变性“，默认需求是”错“的，是会随时变化的。虽然游戏产品大多数没有了严格意义上的传统软件开发过程中的步骤分工，但是这些步骤所代表的开发内容是存在的，只是因为需要”快速“，各步骤的界限被打破简化融合到了一起。变化的需求依然会导致后续开发个阶段的变化。 ## 需求是怎么产生的 软件产品的需求提出是为了能够做出一个产品来满足目标用户的痛点或者痒点。而痛点/痒点的发现的方法是多种多样，可以经过深入的用户调研，观察到用户的需求，提出一个产品来满足他们的需要；也可以像乔布斯这样，根本不做用户调查，我给你的就已经是最好的。也可能最开始做出了一个产品原型方向，然后经过多次迭代修改后得到了一个受欢迎的产品形态。 具体到游戏产品，产品的方向更多是公司老板或者制作人看好某个游戏细分领域，构造出这个游戏产品的核心玩法，基于该核心玩法，结合各种辅助系统，最后得到一个完整的游戏。 游戏的具体做法是，产品策划根据制作人的宏观构想，首先设计出核心玩法原型，并和程序紧密配合，实现出第一个核心玩法demo。项目主要参与人员（特别是老板，制作人等）体验并头脑风暴，可能经过多次的迭代修改后，得到一个大家都认可的核心玩法demo。核心玩法是游戏的存在的根基，是能够满足玩家对游戏性，可玩性的要求，或者超出玩家的预期。 为了构建一个完整的游戏，需要在核心玩法之外建立各种辅助游戏系统（如角色，等级，成长，装备，任务，副本，好友，工会，组队等等），而游戏开发过程中最大量的需求，即来自这些辅助功能系统。辅助功能系统大多数都有一定程度的同质化，简单粗暴的方法都是copy友商的系统规则和设计，好一点的进行一些微创新，极少数的会有原创功能玩法。无论是copy，微创新还是原创，针对开发（程序，美术）来说，都是任务需求。 ## 需求为什么会变化 世界在不断的发展变化，行业环境在变化，用户的喜好也在变化，唯一不变的就是”变化“本身。如果将游戏功能简单的分成核心玩法和辅助系统两部分，那么需求变化也来自这两部分。 #### 核心玩法变化 核心玩法是游戏存在的根本，理想情况下核心玩法的变化只应该在demo打磨阶段，已经demo确定后，核心玩法就不应当再改变。此时发生的改变的原因是发现核心玩法并不能满足用户的需求，或者有了更好的想法。 #### 辅助系统变化 游戏开发过程中的绝大部分工作量都是集中在辅助系统，大量的辅助系统涉及各种庞杂的逻辑规则，系统交互和设计细节。辅助系统的需求变化主要有一下因素： 1. 有了”更好“的想法：对于同一个功能，策划有了新的更好的想法。 2. 之前规则理解有误：由于文档不细或者沟通理解有偏差，开发和策划对于规则理解不一致，开发过程或者完成后才发现不对导致的需求“变化”。 3. 来自上层的想法改变：上层是指老板或投资人等，他们有自己的想法和理解，要加入到游戏中，导致变化。 4. 来自合作方的变化：游戏的渠道和运营方通常有更大的话语权，他们“更理解市场和用户“，他们会加入自己的想法到游戏中。 4. 来自”新人“的不同想法：项目的新成员，特别是新策划（新制作人）的加入，会导致需求的大量变化。 5. 来自和程序的妥协：开发过程中，程序发现有些功能规则的实现复杂度很高，性价比很低。和策划商量后采用了简化版的替代方案。 6. 美术需求变化：单独说一下美术变化，产品的第一眼看到的总是界面和美术，而每个人都有自己偏好，没有什么绝对的对错，都能发表自己的意见，总会或多或少导致一些变化。 ## 需求变化导致了什么问题 游戏开发过程中，频繁的需求变化，对项目的开发和团队的管理都是有害无益。需求变化可能导致以下问题： 1. 项目开发周期不可控：需求的变化意味着开发工作量和沟通工作的提升，必然导致开发周期delay。又要引入变化，还需要强制按原计划时间完成都是天真的一厢情愿。一厢情愿的事情累计多了之后，会在团队中逐渐产生怨气，从而危害团队。 2. 损害团队士气：古人作战追求，“一鼓作气，再而衰，三而竭”。项目开发也是一样，大家有了相同的任务目标，正兴致勃勃，士气高昂得前进，三番四次的目标修改，会让团队对目标产生迷茫和怀疑，会耗尽团队的士气，从而降低团队生产力，甚至导致团队不稳定。 3. 成员间产生不信任感：项目成功是一个团队合作的结果，成员之间的肝胆相照，相互信任，相互扶持和帮助是项目成功的助推剂。而频繁的需求变化会让组员之前产生不信任感，觉得对方是在给自己挖坑，“既然还会继续变化”，那实现当前需求只是浪费时间。成员之间的质疑产生后会很快导致各种矛盾出现，甚至上升到人员之间的各种冲突。 ## 怎么解决需求变化问题 首先所有团队成员需要明白，绝对的需求不变是不可能的，唯一不变的仅仅是“变化”本身；所谓的控制变化，是尽量让需求变化更小，更可控，即使最终变化来临也使得变化对项目的影响降低到最小。可以从以下方面尝试解决需求的变化问题： #### 构建靠谱团队 所有项目都是由独立个体组成的团队开发完成的，构建一个靠谱团队是任何事情的前提。我所理解的靠谱团队，首先有一个拥有远见卓识，目标坚定，值得信赖和追随的老大；其次，下面有一批各种职能分工都能独当一面，认真负责，坦诚相待，积极上进，相互信任的成员。即使一开始没有这样的团队，也要有目的的一步一步建立起来，并形成一种互信包容，相互扶持的团队氛围。 作为团队管理者，需要挖掘和发挥每个人的优势，让他们能够发挥自己的全部潜能，并不断提高。在项目中不断做出自己的贡献，形成一种成就感和归属感，一旦事情从“要我做”变成了“我要做”的状态后，很多难题都会迎刃而解。“想做一件事情会找到一个方法，不想做一件事情会找到一个理由”，我始终相信一般的项目开发中，并会不会遇到不能解决的世界级难题，绝大部分都是能够很好解决，一旦成员有了自己想去解决问题的心态，解决方法会随之而来。 在这种心态之下，遇到需求变化并不会导致成员的抵抗，而是会让他思考你的变化是否是对项目的一种真正价值提升，并自己深入分析再提出自己的建设性意见，最终在积极讨论的氛围中形成了决议。 #### 统一目标 团队的项目目标是项目完成后的最高追求，所有成员需要对最终目标形成深度共识，只有在共同目标的驱动下才能不断克服过程中遇到的各种困难和分歧。而对于个人的目标，可以是升职加薪，可以是完成一个多少在线用户的项目，或者是达到多少盈利的项目，只要个人目标和团队目标是大方向一致即可。 #### 构建利益共同体 从组织架构和利益分享机制方面，让需求的提出人和实现人成为利益共同体；一荣俱荣，一毁俱毁，团队成员都在一条 船上，个人利益就是共同利益。 #### 充分设计和讨论 项目开发过程中，很多时候为了”快“，导致系统设计和规则逻辑并未想彻底就已经开工。最终做到一半或者快要完成时发现机制有缺陷，需要重新设计，此时的改动可大可小。开发前的充分设计，彻底理解和吃透产品逻辑规则，有利于减少开发中的不稳定因素。 #### 重要信息多次确认 人与人在沟通过中，广泛存在“信息漏斗”现象。假设A有一件事情需要B去做，信息漏斗作用过程如下： 1. A在心里想了一件事情，假设完整度是100%。 2. A找到B，把事情描述给B的过程中，因为表达能力或者语言表意缺陷，只能把80%的事情说出来。 3. B在听A表达的过程中，由于自己注意力分散或主观偏见等因素，只能听到事情的60%。 4. B在理解自己听到内容的过程中，因为自己的知识结构，理解偏差等，又会损失掉20分的信息完整度，得到40%的信息。 5. B在执行的过程中，因为执行力或者其他因素导致偏差，又损失掉20，最终只能得到一个20%的结果。 从以上模拟的“信息漏斗”可以看出，最初A的一个100%完整度的事情交代给B执行出来后，只变成了一个20%的结果，和最初要的东西已经大相径庭。最终A和B在核对最终结果的时候，会出现无穷的争执和矛盾。 为了降低“信息漏斗”带来的影响，需要每一步都对信息进行重复确认，确认信息的丢失降低到最小。同时沟通各方都需要明白“信息漏斗”的存在，当最终出现偏差的时候才能心平气和的继续沟通解决问题，而不是相互指责和推诿。 #### 需求分期 对于优化型的需求，在之前需求已经进入开发阶段的情况下，可以考虑放到下一个迭代周期里面做优化，而不是打乱当前的版本进度，重新设计和实施。同时也给到产品策划一个时间窗口再次沉淀和思考修改的必要性和机制的完整性等细节。 #### 坦诚有效沟通 项目开发的目的是为了共同完成任务，做出一个大家认可的产品。开发过程中无论是产品本身还是涉及开发成员，都会有大量的沟通需要进行。而沟通要能顺利进行且最终富有成效，坦诚是所有前提的前提。只有坦诚沟通，对事不对人，让被沟通人感觉到得到尊重，才能将沟通有效进行下去。把别人当傻子，浮于表面的客套话，忽悠别人的虚情假意都会最终导致信任的消逝，没有了信任，项目失去了根基，所有目标和远景都会变成虚无缥缈的空中楼阁。 ## 需求变化后导致矛盾怎么办 前几部分做好了之后，应该能大幅降低需求变化，即使发生变化也会将影响局限在小范围内。但是如果已经出现反复变化，导致矛盾，有哪些办法呢？ 首先，需要确保成员都理解变化是不可避免的，确保大家对共同目标的认可，都在为达到目标积极的想办法改进，大家的沟通还在一个“频道”上，有了共同的前提，对事不对人，就事论事的讨论分析，都有沟通改善的意愿是事情能够改善的大前提。 其次，坦诚沟通是任何有效沟通的基本要素，“正其心，诚其意”，一旦沟通双方都感觉到了对方的坦诚沟通态度，自己的防备和抵抗情绪就会消减，更容易回归到事情本身。 再次，沟通时要给与对方足够的尊重，任何人都有被得到尊重的需求，”你的心理有没有我“？我们交流的时候，你是否是一种愿意解决问题的态势，这个很重要，中国是人情社会。大部分人对应别人对自己的态度是很在乎的，知道是”你在乎我“的前提下，任何问题都不是问题。 最后，成功能够掩盖所有的的问题，即使问题再多，矛盾再大，当项目的结果是一个巨大的成功，所有问题都会被暂时掩盖，不过通过成功来掩盖问题是暂时的，一旦成功没能延续和复制，问题已经会爆发。 每个人都有自己的解决矛盾的想法和方式，以上是自己的一些思考，不过防范未然才是更好的选择。