每日复盘——游戏玩法的开发跟进（二）

每日坚持一篇，反思自己，总结经验。

玩法、系统的跟进，是游戏策划，特别是系统策划在工作中常见的工作内容。一个策划案，从思路提出到设计案形成，经历的是思辨的过程。之后经过程序、美术的工期评估，开始进入制作周期，就进入到执行的过程了。由于游戏开发是艺术和软件研发的综合体，所以在推进过程中，我们经常会遇到延期，功能被迫删除，完成效果不佳，没有时间调优等问题，进而有可能导致完成效果不佳，功能上线延迟等一系列的问题。有没有办法在推进周期中降低这些问题出现的频率，减少研发质量下滑的风险呢？介于今日我开始跟进自己项目版本的功能系统，我决定在这个过程中梳理一下自己的经验，并总结每日的跟进心得。

上一篇的传送门

昨天是项目研发的启动日，我的反思为“排除脑海中不切实际的想法”。今日的总结，我决定从哪些可能存在的风险点入手，谈谈项目流程跟进中那些可能出现的坑，那些需要我们时刻警惕的问题。

坑一：被卡主的节点

并行开发是一个在开发过程中需要无限去靠近的理想值，越接近这个理想值，开发的效率就会越高。网游开发一般都会涉及客户端与服务器，涉及这两者，就意味着期间同一个模块会有很多耦合，交叉的部分。更不用说这期间还有策划的体验调试、配置、美术的资源提供等流程线。当这些流程线交织在一起时，极其容易出现某个人卡主，另外一群人的工作全部卡主的情况。如UI界面迟迟不出，客户端卡主；服务器同步协议接口制作时，客户端卡主等诸多问题（好像被卡主的都是客户端？）。这时，作为项目的负责人——策划，就需要进行及时的协调了。这种协调可以通过如下几种手段推动：

1、分析前提：拆分清楚的功能模块。开发所涉及的功能模块拆分类似于一张导航图，可以让策划明白客户端与服务器实现最终目标，要经历的环节。进而可以从中抽出哪些环节是需要双方联调，或彼此依托的。

2、不断的总结：敏捷开发的三问。昨天我做完成什么？今天我做了什么？谁卡主了我？策划每日可发起会以，让开发小组的同事进行总结。在总结过程中，只谈问题，会后在寻找解决方案。这样可以让开发过程中相互耦合、制约的问题及时的暴露出来，以此让大家调整优先级。优先解决卡点问题，避免互相等待。

3、创造挑战：提前联调的时间点。无论是处于保险，还是为了偷懒，不给自己太多压力。人都会有过少预估的情况，这种情况需要适度的控制，否则在高协作的研发过程中，一个人脚步的放缓会传播到所有人身上。作为产品推动者，一定要给予“能否提前”的压力，让每个人尊重时间节点。以避免出现一环出错，环环出错的问题。

坑二：失控的需求增加

自《人人都能成为产品经理》大火后，人人都想成为产品经理了，这其中就包括你的老板，或者，或者其他人吧。所以我们会发现，在项目研发的过程中，需求会不断的加入，变更和更新。上次文章有提到，奢求游戏研发存在一种从不改变需求的情况，那是不存在的。所以我们需要敏捷迭代，小步试错。但这也并不意味着在项目的研发过程中，我们的需求可以随时变更。因为每一次的变更，或者需求的新增，都有可能使得最初的节点承诺成为一纸空文。这种影响将是灾难性的，当计划完不成时，计划也就没有计划的价值了，截止时间就将变得不可控。所以，有效的辨别需求，控制变更在项目推进过程中也必不可少。同样，面对要新增需求这种想法时，最好先在内心问如下三个问题：

1、我能否拒绝？无论这个需求源于你的老板还是你自己，能否拒绝都是应该放在第一优先级的去考虑的问题。当你能够找到足够充分的理由来证明自己可以拒绝这件事时，都不要在往下想了。有效拒绝是控制需求的第一步。很多问题，往往你放几天，他就不是问题了。

2、这真的可以解决这个问题吗？项目开发就是一个创造问题，解决问题的过程。所以，当你想要为解决某一个问题，而提出一个需求时，一定要看看这个方法是不是真的可以解决这个问题，会不会带来其他更复杂的影响。如果需要评估的关联项过多，那冷静的放下来思考。先思考好了再推动效率会更高。

3、解决这个问题是否会打乱当前研发的节奏？实在无法回避上述两个问题，必须要解决这个问题时（或被动、或主动）。你需要评估的就是这个需求是中间插入，还是放到最后来做会好些。这很难明确的给出标准，毕竟有的需求，是越早改越好的，但是一定要想好，再决定是否插入。这种插入一定不能过于频繁，否则我们就会陷入失控的需求状态了。

游戏开发过程中的坑，想必也是很多产品研发中的坑。作为一个推动者，负责人。我们今天不谈设计，先想想自身推动设计实现的方法。争取在明天做到更好吧！

未经允许不得转载