202X年项目失败经验教训总结

《202X年项目失败经验教训总结》由会员分享，可在线阅读，更多相关《202X年项目失败经验教训总结（11页珍藏版）》请在金锄头文库上搜索。

1、项目失败经验教训总结关于项目失败经验的教训总结大家了解过多少呢？可 能很多人都不是很清楚，下面就是小编分享的项目失败经验 教训总结范文，一起来看一下吧。先介绍下背景， 项目类型是集换式卡牌游戏， 平台是 SNS。 接手的时候，已经是一个成品了，大约在产品上线一个星期 左右 venjet 作为一名产品策划加入，负责后续部分系统与 数值。游戏的核心玩法不错，作为一个卡牌游戏在SNS平台上也不会显得很重度，所以产品刚上线的时候势头很猛，然而 经过一段时间之后，日渐滑落的DAU说明产品本身和后续的工作都出现了一些问题。以下几点是 venjet 认为今后工作 中需要注意的地方。经验教训 1. 时间 -

2、游戏首日venjet做过最重度的客户端，相对轻度的WebGame然而SNS还是头一遭。SNS游戏比起客户端及 WebGam更轻度， 进入门槛更低。用户可以在 SNS平台的几十几百个游戏应用 中随意挑选，几次点击即可进入一个游戏，连帐号注册这个 步骤都不需要。同时，因为没有较高的进入成品，意味着更 低的忠诚度。在开始的几分钟内，玩家立即就会因为画风不 喜欢，玩过或正在玩同类的游戏，不喜爱的游戏类型，不明 确的操作等等原因离开游戏。与花了几个小时下载的客户端 游戏相比，SNS教低的推广成本与次日留存是成正比的。所以，第一个时间就是游戏首日了，在有限的几分钟内 吸引住玩家，将尝鲜的玩家留住，尝试过适

3、量的游戏内容后 保持足够的兴趣，次日继续进入游戏，这将为接下来的工作 打下坚实的用户数量基础。 前期的努力增加 1%的用户， 可能 可以为后期带来 10%的用户增长。这项内容需要在游戏初期 做好，随着游戏的运营，用户的质量会逐渐的下降，此时做 这项工作，多少有点事倍功半，这也是教训之一。之前游戏首日内容不足的几点：画面精细度不够；用户体验细节上需提高； 新手引导略显生硬，内容过多且说明不足； 新内容的节奏把握不佳； 初期游戏难度过高，有过高挫折的关卡； 兴奋点缺乏引导。经验教训 2. 时间- 游戏七日 除了纯对战类的网游，一般而言网游前期总是会提供玩 家一定时间的“单机”游戏内容。这段时间主要

4、的作用是让 玩家熟知游戏内各个系统与游戏世界，提升自身实力，为将 来的互动内容打下基础。当然，也存在只注重PVE内容的设计，玩家互动的内容只是点缀。通常来说，越轻度的游戏， PVE 的比重越大。我将这部分内容定义为第二个时间： PVE 的七日。一旦过了这个时间，这名玩家就转化成了一名忠实 玩家，进而转化为付费玩家。在这段时间里，既需要给予玩 家新鲜感，兴奋点，让其不断的进行游戏；又不能给予玩家 太多门槛，打断玩家的成长。如何取舍，需要结合项目具体 的设计来看。就之前的项目而言，不足的几点：内容单调， 关卡卡牌布置缺乏新意， 仅仅是难度的提高。 缺乏指导性的成长内容，玩家不知道如何成长。 关卡难

5、度过高，部分关卡挫折感极强。 设计的漏洞导致玩家无法进行游戏。经验教训 3. 还是时间 - 更新时间 以上两个时间的游戏内容虽然重要，但是在项目已上线 的情况下，如果仅花一些时间做调整，所获得的成效不会太 大。而之前一个最大的教训，就是没能把握住第三个时间： 更新时间。 venjet 以往的概念里， 游戏的内容更新最快也得 一个星期吧，往往大版本的更新，那直接奔两三个月而去 啊但是SNS平台不同，前面已经说过，SNS平台的用户忠诚度相对较低，一旦失去新鲜内容的刺激，单纯依靠PVE内容，玩家很快就会流失。因此，SNS 一个理想的更新频率是一周23次，哪怕更新的内容再小，也能明显的看到提升。 而这

6、个更新速度，不仅需要整个开发团队衔接的很紧密，效 率很高， 就产品策划本身而言， 需要有将设计内容尽量拆分，模块化，并且尽量简单，易于开发和玩家理解。 venjet 在这 个方面没能适应这个节奏，给予了开发的同学们很多较大， 较难的系统，导致功能开发周期较长，DAU流失严重，在这里向他们说一声抱歉。这方面的经验教训，铭记于心。经验教训 4. 摆脱玩家心态一般而言产品策划本身就是游戏玩家，也有自己喜爱的 游戏类型甚至钟情的几款游戏。在游戏设计过程中，玩家心 态将是非常可怕的一件事，将自己认为好玩的，喜欢的系统 加入到游戏中，很可能会与某些游戏系统，甚至整体游戏设 计冲突。“看起来很美“的系统，往

7、往结果十分惨烈。之前 因为较为喜欢某游戏的好友攻防系统，因此在设计好友互动 的时候， 引入了这个系统， 而忽视了游戏本身的类型及受众。 所幸及时刹车，不然会给开发的同学们及玩家带来巨大的麻 烦今后设计每个系统，默念并回顾设计目的一百遍=。=经验教训 5. 小额消耗品 Vs 高价固定资产 之前游戏上线时，所有的消费内容几乎只有卡片，高价 固定的消费内容带来的是较高的ARPPU及不那么高的PR,之后对游戏的商城进行了一次改造，细分了卡片类型，使玩家 购买时更具有目的性，取得了一定的效果。然而在这一个多 月的过程中，消费内容让 venjet 感觉最佳的调整来自于增 加了小额的消耗品，虽然 ARPPU

8、W低了许多，然而 PR取得 了成倍的增长。玩家从付费 0 元到付费 1 元比玩家从付费 1 元到付费 10 元的意义要高出很多。这不仅提高了营收，更 重要的是使游戏朝着更健康的方向发展：不依赖少数高付费 的用户，而是有着大量的中小额付费用户，简而言之，细水 长流。因此，如何合理布置消费点和消费区间也是游戏设计 的一个重要课题。另外，消耗品远比固定资产来的实惠，玩家购买固定资 产后，消费的动力将明显降低，只能通过推出更高性价比或 更强的固定资产来拉动消费，这将压榨游戏的生命周期，并 拉大付费玩家与免费玩家间的差距，这在之前的项目中表现 的十分明显，而消耗品则可以避免这个问题。固定资产不可 少，玩

9、家的成长感及沉没成本主要依赖于它，可以考虑通过 分段消费，将消耗品与固定资产的成长结合，比如，装备强 化 = = 当然，这也是卡牌游戏的软肋 .一个总成本花费100W勺失败项目的小小反省 这个项目 开始到几个月前基本暂停，总共差不多花费 100人月，总成 本应该也差不多是 100W吧。在几个月收获的产品只有一堆中间代码。当然，参与成 员对某些技术还是有进步的。我稍微对项目作一些总结吧。 要想不好了伤疤忘了疼，需要总结经验，不管是成功还是失 败的经验，成功是一个模式， 。没有开始的开始 , 一个噩梦的开始前期没有任何固定的严格项目可行性分析老板指哪儿打哪儿，就算是老板一种模糊的感觉，下属只能全力

10、以赴了。这在我们这类企业里面应该算是很普遍的。当一次回头看，这 100W 算是做了一个可行性的探讨。风险 管理，尤其当你使用一个有新的 /先进/ 陌生的技术，使用一 个陌生技术，风险是很多的，不管宣称它有多先进。如果在项目初期没有进行风险的管理探讨，最后，这些 风险不会凭空消失，一部分会出来， Block 你的项目，毁了 你前面做的工作，最后毁了你的项目。需求，没有远景，没有边界 当项目走了很远的时候，当需求好像无穷无尽的时候。 经验丰富的领导总算想起要做一个边界定义了。如果没有一个边界，需求是做不完的，满天的麻雀，都 想要抓， 团队的人力物力是非常有限的， 对于一个产品来说， 市场也是不会等

11、人的，必须要在规定的时间内出来的软件， 才有可能成为一个成功的软件。需求，脱离用户的需求当需求只是凭空猜测的需求，自然会让人觉得无穷尽， 因为人类想象力总还是比我们能做到的要多的。但是，这带 来的可能不仅仅是没有尽头，脱离用户的需求，仿佛就是在 修炼屠龙绝技。修炼出来是没有市场的。需求，隔靴搔痒的需求如果软件的最终用户是经过培训、积极配合软件开发过 程的，这个软件的成功机率大概可以提高好几成。 可惜的是， 我所看到的很多一部分都不是这样的。 。我所见到的是，用 户代表往往仿佛一开始就是等着验收软件，不想参与详细需 求的制定，大部分都是靠需求采集人员的猜想，猜想往往和 实际有差距，往往只能像挤牙

12、膏那样从用户那里得到一些提 示，或者片言只语的判断。往往是经过无数次的往返交流， 需求还是雾里看花。需求采集人员在繁琐中失去耐心，索性 天马行空猜测一番了事，不再去麻烦用户。走到一个陌生的行业 / 领域，需要勇气和资源 走到一个陌生的行业 / 领域，有时候是必须的，就像众 多企业的多元化之路。非常不巧的是，也是众多企业的多元 化之路一样，软件要想进入一个陌生的行业领域，也是一条 艰辛之路。需要的不仅仅是勇气，还需要机遇，所谓东风是 也。但是还需要资源作为支持。如果低估了艰辛程度，可能 就低估里所需的资源。没有必要的资源，也许你走了90%的路了，你要走不完剩下的路，也许你从沙漠中央走到了离沙 漠

13、边界只有数里之遥的边界，没有了那最后的补给，你还是 出不了沙漠。任何风吹草动都可能成为压垮你的最后稻草。没有结束的结束 没有人会承认失败，尤其当没有人要求你这么多的时候。 我们的项目也是，我们几乎听不到有人出来说项目失败了， 我们听到的是延期、暂停、取消等等形容词，但是其实，我们其实应该承认，我们有做了一个失败的项目。过程，没有过程，没有积累从开始到结束，没有开始的开始到没有结束的结束，整 个过程一切都在我们脑海中，剩下几个残缺的需求文档和无 法投入使用的中间代码。或许过不了多久，一切的记忆都会从我们脑海消失，尤 其像这种失败的记忆，我们会自然选择一种选择性失忆。只 不过，我们并没有得到该有教

14、训，花了钱，还是没有买到教 训。如果我们有过程记录，也许我们可以知道，哪一条路径 是走不通的。我们不需要走一条失败的老路。项目的成败是变数多多，既有技术的，也有管理的，也 有关系的，既有自身的，也有客户的，但是只要我们把我们 可以控制的做好了，至少这个项目成功了一半。项目的需要变化是肯定有的，而且变化一般都很频繁， 我们怎么应对客户的这种需求变化呢，以不变应万变。首先 在前期的需求调研要做好，尽可能的替用户考虑，达到功能 质量满足最大化。需求调研前期的目标与范围和需求调 研末期的功能规格说明书都要跟客户签字确认，这样既 能保证我们所理解的需求就是客户所要的，也使得项目末期 跟客户验收时有据可依

15、。根据我自己做项目的经验，由于客 户一般对计算机不是很了解，和他们交流用我们行业的话， 他们根本就不懂，如果用文档也很难把需求写的那么明白， 而且文档很多的话，客户都看烦了，很不直观。如果让客户 一看就可以看出这个就是他们想要的，我个人认为最好的方 式就是做系统原形。系统原形应该在需求分析的时候开发人 员在分析师的指导下完成真实环境中的开发，当然开发只是界面的 功能模拟， 没有底层代码的实现。 这样做的目的有三个好处， 一是客户很直观的看到他们的系统是什么样子的以及怎么 操作，二是这些开发的成果是可以二次利用的，三是可以更 好的激发客户的需求。在项目中期是发生需求变更是很常见的，这时要做好需

16、求变更管理流程。需求变更表，小的变更自己掌握，客户要 求的变更有开发人员和设计人员共同商讨后提交项目经理， 项目经理预估变更损耗工程时间，在一定阶段一起提交给客 户，大的变更直接提交客户，并且要把需求变更对项目产生 的影响让客户知道， 把球尽可能的踢给客户， 让客户在进度、 功能、资源三者中取舍出一个平衡来。 对需求进行分类评级， 关键部分不能改动的做特别确认。同时完成客户签字确认， 当然如果能将这部分写成合同细节中去是最好，但国内的合 同好像都是在打单时是基本上都承诺，也不会到细节，在合 同签订后启动后才发现问题。但合同中可以写明如果需求变 更什么级别的怎么样，多少钱等 ; 签订合同也是一个很高的 技巧，建议把系统的边界及功能范围和解决方案与合同一起 签署，这样客户提出的新功能就可以暂且搁置。当然这就需 要项目经理很高的经验和技巧了，不是光