如何处理软件项目中发生的需求变化

在IT行业中，有一个不能忽视的问题。这个问题就是如何面对那些经常在发生变化的业务需求。做IT项目，客户老是喜欢在项目进行过程中修改需求或者增加新需求。诚然，在项目一开始的阶段，客户不清楚自己到底需要怎么样一个系统，往往在项目进行中突然明白或者说清楚自己真正想要个什么样的系统。所以这些在项目过程中提出来的变化需求也并不是客户在无理取闹，反而对客户来说比在项目开始阶段那些双方互相确定的需求更加有意义和重要。

    就我以前的经验和思路，我对这个问题的解决思路基本上是这样的。

首先，变化就意味着风险。我们当然要把这个问题当作项目中风险的一种来处理。那常规的处理方法也就这么几个。风险的量化，风险的监控什么的。实际上判定一种风险对我们的影响程度究竟有多大的时候，我们往往只需要问自己一个问题就可以：新需求发生或者老需求变化时候，我们是否已经习惯处理这样类似的突发事件?我总结了一下，我们以前处理的时候无非也就是这样五种情况。

1．  我们以前解决过，这对我们没什么，很正常的事情。(作战能力强的团队都有资格这么说)

2．  我们没解决过，但公司里其他项目组，产品组好像解决过。有专门的解决方案文档可以查阅。（向公司内部寻找帮助是个好办法，但在中国行不通，我就看见过有人可以解决但就故意不配合你，让你自己解决去，而不给予任何帮助。）

3．  公司里没有这样的解决方案的资料，但是有很多第三方的资源可以利用。（做JAVA的人好像都喜欢，的确我也听说这样一句话：“内事不决问老婆，外事不决问google”）

4．  好像听说过有人解决过，不过记不清楚了。（等于没说，其实就是没办法解决问题）

5．  的确之前没有解决过这样的问题。但可以试一下，可以作点有开创性的工作应该会有成就感。（以积极的态度来看待自己从来没有经历过的工作）

    其实当我们面对一个变化的需求或者新需求时候，可以看看我们是采取上面五种情况里那一种来解决。我认为如果能用前面三种情况解决，基本上我们就可以答应客户去做或者更改需求。如果是后两种，最好还是慎重点为好，特别是最后一种，虽然态度是不错的，但态度有时候并不决定一切。好心办坏事的事情屡见不鲜。

   但是就算这样，并不能算结束了。其次我们还要评估一下需要增加或者修改的需求对客户的重要性问题。对于客户那边的业务人员来说，这样一个需求在他们眼里是怎么样的也决定了我们是否答应他们做这个需求。

    如果系统中没有这样一个功能，业务人员是否会注意？或者他们会注意到没有这么一个功能但觉得并不影响他们使用系统。又或者是一小部分或者一大部分甚至整个系统都需要依赖这个功能，没有它影响很大？这个也是我们在评估的时候需要考虑到的。

    还有一点就是如果我们这个项目团队没有人会完成或者修改这个需求所需要的技术怎么办？因为我是做JAVA的，JAVA的东西是在是太多了，就我看见的技术人员，没有一个人是十八般兵器样样皆精的。所以这也是需要考虑的。这样一个需求所需要用的技术是否是我们需要一段培训时间才能掌握的？或者有可能我们会，但是掌握的不太熟练，需要用一段时间才能达到熟练水平。当然也有可能我们已经很熟练了。或者对我们来说这完全是小菜一碟。

    所以当我们面临这样一个崭新的或者变化的需求，我们要从过去的风险解决经验，对客户业务人员的重要性和技术团队使用技术水平这三方面来评估。

    我以前也是经常这么做的，说老实话我觉的还凑合，基本上不会让客户说闲话。而且有时候我们要顶住客户的无理需求时候，拿这三个做理由往往都能让他们无话可说。毕竟我们讲的出道理为什么不答应做这个新需求。

评论

37 楼 darkewiser 2009-06-15  

中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。

所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。

中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？

因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。

36 楼 seemoon 2009-06-12  

qaz1234 写道

   我们中国的软件项目有很多都是这样，一开始有个大致的需求，有个功能需求列表，有个系统框框，至于其中的规则、算法、弊病、特殊条件下的业务规则等等，这些对系统最终结果有重要影响的方面，则提及很少或根本不描述。 根源既有开发商的责任，也有甲方客户的责任，不一而足。

主要还是开发商的责任，我们的甲方基本上是不懂技术不懂潮流的人，但是甲方基本上是被以大厂商为代表的“开发商”忽悠晕了的，比如ERP,SOA,SAAS，签合同之前牛b吹大了，做的时候总是糊弄，能推搪的推搪，毫无专业可言，所谓无知者无罪，客户无知，你也无知吗？看看你身边从业的人员，有需求调研需求采集需求管理需求文档编写业务分析很牛的人吗？没有！

qaz1234 写道

    
    虽然第三方的咨询机构，可以在甲方乙方的中间建立问题本身的解决过程的控制逻辑，但由于几家客户认同这笔看来有些额外的费用呢。 立足现在，我认为有两个方面的努力可以尽可能减少由于需求变化所带来的影响。
    1、无非是老话题，建立需求管理及需求跟踪。 但建立体系不是目的，认真执行，严格监控，对需求变更的影响讨论再讨论，沟通再沟通。真正把需求变化，对于客户的影响、对于系统的影响、对于开发商的影响，明确到不能再明确。讨论到客户理解，需求的变化导致哪些问题、增加多少工作量、对系统主题有何本质上的危害和补充。讨论到架构人员理解，我们的基础体系的短板，这些不合理存在的原因、危害和提高改正的可能性。为什么不能看到，害怕改变的原因，其实是因为不具备适应变化的能力。不能适应变化的短板可能来自架构，或者我们的设计思维。 讨论到开发人员理解，我们设计一个模块灵活性、兼容性、适应性的重要，我们曾经引以为豪的某某功能，不能给客户带来他真正有意义的、美好的使用感受和使用价值，我们就还需要提高。
    认识到问题所在，离真理就更近了一步。

还是“专业”，我们不专业，我们懂得一堆道理，要有需求管理，要有变更控制，但是落实呢？执行力呢？也没有！
架构只是问题的一小部分，适应性还来自开发方式，瀑布式的模式国内用得太多，做烂了n多项目，敏捷只成为攻击的标靶，而不是实践，哪来适应性呢？架构只是底层的东西，架构上面是复杂的业务实现，业务实现无法避免调整和重构，测试代码都没有如何适应？单单架构解决不了问题，强调架构的一个极端就是过度设计，镀金，浪费。

qaz1234 写道

    2、从体系角度，设计的模型，更加积木化、平台化、插件化、个性化。不要老想着A功能如何B功能如何，把所有的功能放在一起，统筹看，都有些什么呢？ 只有这些：更快的速度、更稳定的运行、更方便的录入界面（包括导入）、更灵活的业务规则（随时定制特殊业务及其发生地条件）、更多汇总报表挖掘数据KPI（包括垃圾的不能再垃圾的所谓自定义报表？）、更顺畅的工作流程梳理、更高效的业务配合。
    将基础平台进行可定制的积木化，不要限定软件能做什么（虽然你知道它能：输入、计算、存储、显示），抽象了软件的这些基础概念，就像抽象积木为：圆、方、三角、长条、板、挂钩等等， 我们平台不但应该能产生等腰三角形，还可以经过配置产生诸如以下三角形：等腰直角三角形，勾3股4弦5三角形，一条边等于另一个正方形边的三角形，一个像楔子一样长长的窄窄的三角形，一个可以组成矩阵的等边三角形，一个大小支持挖一个中空图案容纳麦当劳赠送的小塑料熊的三角形，一个一面红一面绿的三角形，一个可以在最长边上嵌入磁铁条的三角形，等等。
    不是做不到，而是想不到。 当我们的工具不再是为单一目的而创建，而是具备了实现不同思想，不同功能的时候，当我们软件的功能和适应性，比客户想到的还要多，还要远，我们还惧怕变化吗？在不怕变化进而拥抱变化的基础上，客户的变化要求，就变成了我们检视自己、提高自己的驱动力和持续发展的动力。
    不要指望着我们的软件一开始就恰好适应客户的需要，退一步讲，就算一开始就适应了，我们就能把握未来吗？    
    总结一下，上述两点，一个是提升软件能力，一个是强化管理，也算老生常谈，占大家时间，给大家解闷。

没错，计算机业界一直朝着这条路子走的，组件化，积木，n年前我见过java bean拖拉实现IC类似的图形化组件解决思路，ejb也强调把业务统统组件，现在鼓吹面向服务，你看到软件危机解决了吗？没有。我们不能用三角形，几何图案来简化计算机模拟实现业务这个过程，它不单单是技术问题,我们可以用bruce eckle的shape、rectangle来描述面向对象，但是描述业务，构建数据，实现流程还远远不足，这些只是提供了基础，如砖头、钢材、混凝土，一堆东西，但你不能说这就是大楼。

35 楼 maxpana0177 2009-06-11  

如果公司流程合理 变更管理是最好的处理方式

34 楼 黑暗浪子 2009-06-09  

qaz1234 写道

我们中国的软件项目有很多都是这样，一开始有个大致的需求，有个功能需求列表，有个系统框框，至于其中的规则、算法、弊病、特殊条件下的业务规则等等，这些对系统最终结果有重要影响的方面，则提及很少或根本不描述。 根源既有开发商的责任，也有甲方客户的责任，不一而足。 但遗憾的是这是事实，这就是中国国情。 企业对信息化结果的认识、对信息化过程的理解，目前就发展到了这个阶段，期望企业的判断能力达到IT咨询专家的水准是不现实的。 另一方面，在残酷的竞争的面前，指望IT企业不夸大其词，不迎合客户口味，而改为更阳春白雪式的纯IT正规思路和方法将项目进行下去，也是不靠谱的。  虽然第三方的咨询机构，可以在甲方乙方的中间建立问题本身的解决过程的控制逻辑，但由于几家客户认同这笔看来有些额外的费用呢。 立足现在，我认为有两个方面的努力可以尽可能减少由于需求变化所带来的影响。1、无非是老话题，建立需求管理及需求跟踪。 但建立体系不是目的，认真执行，严格监控，对需求变更的影响讨论再讨论，沟通再沟通。真正把需求变化，对于客户的影响、对于系统的影响、对于开发商的影响，明确到不能再明确。讨论到客户理解，需求的变化导致哪些问题、增加多少工作量、对系统主题有何本质上的危害和补充。讨论到架构人员理解，我们的基础体系的短板，这些不合理存在的原因、危害和提高改正的可能性。为什么不能看到，害怕改变的原因，其实是因为不具备适应变化的能力。不能适应变化的短板可能来自架构，或者我们的设计思维。 讨论到开发人员理解，我们设计一个模块灵活性、兼容性、适应性的重要，我们曾经引以为豪的某某功能，不能给客户带来他真正有意义的、美好的使用感受和使用价值，我们就还需要提高。 认识到问题所在，离真理就更近了一步。 2、从体系角度，设计的模型，更加积木化、平台化、插件化、个性化。不要老想着A功能如何B功能如何，把所有的功能放在一起，统筹看，都有些什么呢？ 只有这些：更快的速度、更稳定的运行、更方便的录入界面（包括导入）、更灵活的业务规则（随时定制特殊业务及其发生地条件）、更多汇总报表挖掘数据KPI（包括垃圾的不能再垃圾的所谓自定义报表？）、更顺畅的工作流程梳理、更高效的业务配合。 将基础平台进行可定制的积木化，不要限定软件能做什么（虽然你知道它能：输入、计算、存储、显示），抽象了软件的这些基础概念，就像抽象积木为：圆、方、三角、长条、板、挂钩等等， 我们平台不但应该能产生等腰三角形，还可以经过配置产生诸如以下三角形：等腰直角三角形，勾3股4弦5三角形，一条边等于另一个正方形边的三角形，一个像楔子一样长长的窄窄的三角形，一个可以组成矩阵的等边三角形，一个大小支持挖一个中空图案容纳麦当劳赠送的小塑料熊的三角形，一个一面红一面绿的三角形，一个可以在最长边上嵌入磁铁条的三角形，等等。 不是做不到，而是想不到。 当我们的工具不再是为单一目的而创建，而是具备了实现不同思想，不同功能的时候，当我们软件的功能和适应性，比客户想到的还要多，还要远，我们还惧怕变化吗？在不怕变化进而拥抱变化的基础上，客户的变化要求，就变成了我们检视自己、提高自己的驱动力和持续发展的动力。不要指望着我们的软件一开始就恰好适应客户的需要，退一步讲，就算一开始就适应了，我们就能把握未来吗？  总结一下，上述两点，一个是提升软件能力，一个是强化管理，也算老生长谈，占大家时间，给大家解闷。

说的很有道理。就是麻烦格式再编排一下。谢谢。

33 楼 qaz1234 2009-06-08  

   我们中国的软件项目有很多都是这样，一开始有个大致的需求，有个功能需求列表，有个系统框框，至于其中的规则、算法、弊病、特殊条件下的业务规则等等，这些对系统最终结果有重要影响的方面，则提及很少或根本不描述。 根源既有开发商的责任，也有甲方客户的责任，不一而足。
    但遗憾的是这是事实，这就是中国国情。 企业对信息化结果的认识、对信息化过程的理解，目前就发展到了这个阶段，期望企业的判断能力达到IT咨询专家的水准是不现实的。 另一方面，在残酷的竞争的面前，指望IT企业不夸大其词，不迎合客户口味，而改为更阳春白雪式的纯IT正规思路和方法将项目进行下去，也是不靠谱的。 
    虽然第三方的咨询机构，可以在甲方乙方的中间建立问题本身的解决过程的控制逻辑，但由于几家客户认同这笔看来有些额外的费用呢。 立足现在，我认为有两个方面的努力可以尽可能减少由于需求变化所带来的影响。
    1、无非是老话题，建立需求管理及需求跟踪。 但建立体系不是目的，认真执行，严格监控，对需求变更的影响讨论再讨论，沟通再沟通。真正把需求变化，对于客户的影响、对于系统的影响、对于开发商的影响，明确到不能再明确。讨论到客户理解，需求的变化导致哪些问题、增加多少工作量、对系统主题有何本质上的危害和补充。讨论到架构人员理解，我们的基础体系的短板，这些不合理存在的原因、危害和提高改正的可能性。为什么不能看到，害怕改变的原因，其实是因为不具备适应变化的能力。不能适应变化的短板可能来自架构，或者我们的设计思维。 讨论到开发人员理解，我们设计一个模块灵活性、兼容性、适应性的重要，我们曾经引以为豪的某某功能，不能给客户带来他真正有意义的、美好的使用感受和使用价值，我们就还需要提高。
    认识到问题所在，离真理就更近了一步。
    2、从体系角度，设计的模型，更加积木化、平台化、插件化、个性化。不要老想着A功能如何B功能如何，把所有的功能放在一起，统筹看，都有些什么呢？ 只有这些：更快的速度、更稳定的运行、更方便的录入界面（包括导入）、更灵活的业务规则（随时定制特殊业务及其发生地条件）、更多汇总报表挖掘数据KPI（包括垃圾的不能再垃圾的所谓自定义报表？）、更顺畅的工作流程梳理、更高效的业务配合。
    将基础平台进行可定制的积木化，不要限定软件能做什么（虽然你知道它能：输入、计算、存储、显示），抽象了软件的这些基础概念，就像抽象积木为：圆、方、三角、长条、板、挂钩等等， 我们平台不但应该能产生等腰三角形，还可以经过配置产生诸如以下三角形：等腰直角三角形，勾3股4弦5三角形，一条边等于另一个正方形边的三角形，一个像楔子一样长长的窄窄的三角形，一个可以组成矩阵的等边三角形，一个大小支持挖一个中空图案容纳麦当劳赠送的小塑料熊的三角形，一个一面红一面绿的三角形，一个可以在最长边上嵌入磁铁条的三角形，等等。
    不是做不到，而是想不到。 当我们的工具不再是为单一目的而创建，而是具备了实现不同思想，不同功能的时候，当我们软件的功能和适应性，比客户想到的还要多，还要远，我们还惧怕变化吗？在不怕变化进而拥抱变化的基础上，客户的变化要求，就变成了我们检视自己、提高自己的驱动力和持续发展的动力。
    不要指望着我们的软件一开始就恰好适应客户的需要，退一步讲，就算一开始就适应了，我们就能把握未来吗？    
    总结一下，上述两点，一个是提升软件能力，一个是强化管理，也算老生常谈，占大家时间，给大家解闷。

32 楼 loki_lee 2009-06-07  

客户是不懂技术的（大多，即使懂，也很一般），这时候他们认为哪个应该有和必须有是和原需求与技术无关的，客户认为你必须考虑他的需求，而他是不会替你考虑的

31 楼 lovit 2009-06-05  

zzsczz 写道

做项目就象战斗

客户就是敌人

做需求分析就是侦察兵

售前/沟通 的就是 谈判专家

设计者就是参谋

编码人员就是步兵  只是消耗品和炮灰

前3种人的责任很大


什么叫需求变化?
你忽悠摆平敌人就可以少消耗炮灰.
敌人牵着你的鼻子走就可以拖垮你.

需求中有合理需求: 做需求分析的要了解业务,设计可性的流程,然后靠强大的忽悠摆平客户

不合理的需求就是敌人的吹毛求p ,或者拿你寻开心．．．．．

所以不是需求变不变，而是人行不行，搞不搞得定客户。

说得很幽默，，但也很在理。。。

30 楼 黑暗浪子 2009-06-05  

zzsczz 写道

东风吹　战鼓雷　　
这个世界谁怕谁？

找准位子　　摆正心态

做炮灰有炮灰的快乐，机器用永远比人好伺候．
．

被上司给穿小鞋实在混得不开心不会当逃兵么？反正山头多？哪个大王口碑好多打听？

在管理者面前，技术牛人永远是优势的．做人不要太贱，该发飙就发飙．．像团棉花才会被修理．．．．

。、。
面试时候人家问你为什么跳槽这么频繁，难道回答一句：良禽择木而栖。人家就会请你？
有时候稳定也是人家招聘的一条条件。况且再现在大环境如此不好的情况下，走出去又有风险，又不一定能保障你自己的利益。
我是很理解开发人员心理，可是有些猎头和HR甚至老板都是不理解的。

29 楼 zzsczz 2009-06-04  

东风吹　战鼓雷　　
这个世界谁怕谁？

找准位子　　摆正心态

做炮灰有炮灰的快乐，机器用永远比人好伺候．
．

被上司给穿小鞋实在混得不开心不会当逃兵么？反正山头多？哪个大王口碑好多打听？

在管理者面前，技术牛人永远是优势的．做人不要太贱，该发飙就发飙．．像团棉花才会被修理．．．．

28 楼 黑暗浪子 2009-06-04  

中国IT项目就是像楼上说的那样做的，因此中国IT行业就是一个混混和吹牛者赚大钱，掌大权的行业。最苦的还是技术人员，因为只是炮灰，该要你死的时候就要你死～

27 楼 zzsczz 2009-06-04  

实在不行拿２套方案

一套陪客户玩　　ppt或flash实现远景目标　就是画个大饼子

一套给用户操作　　能用就行．．

当然背后公关就是少不了了

大家都爽了　等着死线的到来．．

26 楼 zzsczz 2009-06-04  

做项目就象战斗

客户就是敌人

做需求分析就是侦察兵

售前/沟通 的就是 谈判专家

设计者就是参谋

编码人员就是步兵  只是消耗品和炮灰

前3种人的责任很大


什么叫需求变化?
你忽悠摆平敌人就可以少消耗炮灰.
敌人牵着你的鼻子走就可以拖垮你.

需求中有合理需求: 做需求分析的要了解业务,设计可性的流程,然后靠强大的忽悠摆平客户

不合理的需求就是敌人的吹毛求p ,或者拿你寻开心．．．．．

所以不是需求变不变，而是人行不行，搞不搞得定客户。

25 楼 黑暗浪子 2009-05-28  

lovit 写道

黑暗浪子 写道

lovit 写道

开发灵活的软件系统，以不变应万变。

何谓你说的“灵活”？有啥高见。说出来听听。

    一般经常变化的，不是一般的门户类网站或电子商务类网站，往往是一些管理系统，这些系统需求总是变，是因为新的业务特性或公司内部战略调整等，当然也不排除其它原因，我们目前发现在最好解决方法是开发可配置的系统，解决大部份的一般性业务需求，其它复杂的业务需求再进行定制开发。

以前也经历过开发可配置系统的经历，问题是在有时候客户反映他们想配置的不是我们的系统里允许让他配置的。
这时候还是属于需求变更，那不还是要重新在搞？
我个人认为敏捷管理论中让一个业务专家陪同开发过程是明智的，这让开发人员随时知道客户真正的需求是什么。
可惜这引出另外一个有中国特色的管理问题，那就是客户没有这样一个“业务专家”的角色。结果还是我们这里出这么一个人，东西作出来还是客户这个不满意，那个不满意。唉，中国客户的确很难搞，特别是吃公家饭的那些~~

24 楼 lovit 2009-05-28  

黑暗浪子 写道

lovit 写道

开发灵活的软件系统，以不变应万变。

何谓你说的“灵活”？有啥高见。说出来听听。

    一般经常变化的，不是一般的门户类网站或电子商务类网站，往往是一些管理系统，这些系统需求总是变，是因为新的业务特性或公司内部战略调整等，当然也不排除其它原因，我们目前发现在最好解决方法是开发可配置的系统，解决大部份的一般性业务需求，其它复杂的业务需求再进行定制开发。

23 楼 黑暗浪子 2009-05-27  

lovit 写道

开发灵活的软件系统，以不变应万变。

何谓你说的“灵活”？有啥高见。说出来听听。

22 楼 lovit 2009-05-27  

开发灵活的软件系统，以不变应万变。

21 楼 黑暗浪子 2009-05-27  

tech_java 写道

我原来是做产品的，产品和项目有点不太一样。我们接触的人都是自己人，比如现场用服、市场等。
一般来说会按照这样的程式来做。
1、先审查需求，值不值得做。
2、值得做谁来做，现场还是总部基线版本
3、如果总部来做，就开始分析需求，看看多大的工作量
4、如果工作量太大，就和现场或者市场商量，这个需求有多紧急。
5、如果工作量不大，Ok，提个需求变更，加入到当前计划中。
6、如果工作量大，现场又很紧急，那么开始需求评审，需要多少人，多少工作量。可接受范围内，加班搞定。
7、如果工作量实在太大，人力又不足，进入下个版本计划，一般来说我们一个月一个小版本，三个月一个大版本

第七条是好办法，可惜有些老板会问“为什么工作量这么大，还没做怎么知道工作量大？这点人不够吗？已经够多了”
这时候你怎么办?

20 楼 tech_java 2009-05-27  

我原来是做产品的，产品和项目有点不太一样。我们接触的人都是自己人，比如现场用服、市场等。
一般来说会按照这样的程式来做。
1、先审查需求，值不值得做。
2、值得做谁来做，现场还是总部基线版本
3、如果总部来做，就开始分析需求，看看多大的工作量
4、如果工作量太大，就和现场或者市场商量，这个需求有多紧急。
5、如果工作量不大，Ok，提个需求变更，加入到当前计划中。
6、如果工作量大，现场又很紧急，那么开始需求评审，需要多少人，多少工作量。可接受范围内，加班搞定。
7、如果工作量实在太大，人力又不足，进入下个版本计划，一般来说我们一个月一个小版本，三个月一个大版本

19 楼 JavaInActoin 2009-05-25  

需求其实并没有变化，需要变化的是软件，软件一直没能反应真实需求，刚开始相差甚远，经过不断的软件变化，软件接近真实需求。所以解决“需求变化”的方法就是让业务专家和用户来参与定义软件，逐步验证软件是否符合需求，尽早获得真实需求。

18 楼 yangyi 2009-05-25  

这个问题我觉得就是通过原型与客户对话，然后修改原型，并根据最后确定的原型核算出成本
当然了，我是按照纯技术的角度说的，不过谈起需求，就不是纯技术那么简单了吧，所以...