需求变更8大原因

为什么会出现需求变更，这是由于需求约束、规则有了新的变化、由于政策发生变化，客户、沟通方式、流程化、标准化的问题等导致。这里在在过去的项目经验中，提出了常见的8大需求变更的原因。

政策发生变化：

指由于国家之间政策变化、行业政策变化，而导致产品底层设计、接口、方案巨大变化，从而产生需求变更。

这里举个某项目的经历，由于过去产品中识别温度，采用了热成像测温模组。由于“美对华芯片禁令”，美国对中国采取芯片出口管制，导致热成像测温模组厂家无法购买美国芯片，库存有限。那么就需要更换有库存的热成像测温模组产家。 由于热成像测温模组不同产家对外提供的接口和参数是不同，以及相关解决方案改变。 这就导致在解决方案、接口都需要进行改变，导致整个研发产品发生需求变更。这样的变更会导致的产品的变动非常的大。

客户产品发生变化：

指在项目需要建立在客户某类产品获取相关数据，为了进行信息化项目，但该产品发生了数据格式变化、数据流程变化，从而产生需求变更。

举个某个项目经验案例。在做某类的客户信息化产品，需要从客户系统获取的财务相关，在调研分析阶段，客户使用了用友的财务软件。在研发阶段的客户由于某种原因，后面改成了金蝶的财务软件。这就导致的前期调用用友相关产品的接口数据就需要重新的进行开发。进而导致的前期开发的一些工作需要重新设计、研究、分析，这造成了进度延误，人工成本增加。

客户人员变化：

指在项目采购方的客户相关项目经理、项目领导发生了人员的变化，导致了产品需求发生了巨大变化，从而导致了项目需求变更。

关于客户领导相关方的发生变化，会出现的一些的新的领导会对原来的项目需求、验收提出新的想法或者变化，这样原因在于新的领导他有其他不同行业的相关方经验。比如有的领导有很多合规性、风险相关方领导工作，而过去项目的领导这块经验薄弱，这就会导致项目中间会提出更多增加数据审核功能研发工作、权限审核、保密协议相关工作需求，比如有的领导的由于比较强的系统性思维和模块化，会对项目前端设计的风格不同。

需求沟通问题：

指在产品经理在需求宣贯中，由于业务深度或者需求不满足SMART原则、CMMI标准化等，研发对需求细节的理解有偏差，从而导致在项目验收阶段发现需求不满足或者偏差很大，从而导致要么需求进行变更后，要么研发进行调整。而这样的问题越往后，那么导致的后期成本越大，这块也是日常出现频率较高。

关于需求沟通导致的需求变更，这里举两个项目案例。

第一个案例讲由于产品和客户沟通需求存在的问题，而导致项目需求变更。

在某ToG项目中，产品经理在和客户进行沟通，由于对客户的需求的重点把握不够，然后回到公司，进行的产品原型设计，由于理解错误，认为自己已经完全把握了需求，在完成客户确认书后，然后让研发展开开发。

这期间产品经理会持续的到客户现场进行确认需求，等到后面进行产品功能上线试点时，发现的需求和客户要求的完全不对。在功能使用、模块设计、在权限管理、用户管理等功能都发现不是客户想要。

这就导致了整个部门20多研发，各个产品需要重新进行研发设计。这所导致产品成本巨大，以及的项目延期。

案例二，关于研讲由于研发和产品需求沟通存在的问题，导致需求变更。

在某自研项目中，产品经理在提到某个的需求，发布了需求PRD文档和相关原型，但PRD文档细节粒度比较粗，研发经理在拿到需求，分配任务，研发人员的未做深入分析、交流，按照自己的想法，直接进行开发。

研发完成后，测试经理拿到研发经理给的开发功能和需求进行测试，等到测试完成后，项目经理、产品经理进行验收时，发现了研发内容和需求不符合，有很大的偏差。这时候导致的了研发进行的调整。

由于客户在等待该产品发布。这就导致的需要跟客户进行变更上线时间，因为赶工的方式，只能完成的项目功能研发，但是的项目测试时间无法满足，无法保证产品上线后的质量。我们指导很多产品如果质量有问题，会到相关品牌造成巨大的影响。

管理制度老套，是指一些公司项目管理流程没有建立起专业化、标准化、体系化，导致项目管理者不能全局把控整个项目，缺乏审核机制、评审机制、规范机制，这就导致了需求变更不断。

上面案例二中其实也提现出了由于的管理制度的问题引发的需求变革，其中产品经理直接输出粗粒度的需求文档，研发人员的未做深入分析、交流，按照自己的想法，直接进行开发。

对于互联网体系很多时候产研阶段只有产品经理、研发人员，这就导致如果开发ToB本地化产品就会有问题，因为客户需求并非来自己产品经理的简单调研，通过标准的SAAS平台产品直接进行的交付。

ToB产品的op本地部署产品的往往核心是项目管理为主导。从产研到交付，时刻把控进度、质量、风险、资源、沟通。但思维体系没有发生改变，沿用老套的管理模式，这就会造成需求变更不断，进度不断延期，项目长期无法得到验收。

在管理制度的上，例如传统的央企、上市ToB企业、上市制造企业，对于研发部门常常习惯的思维就是需求分析、产品验证、研发、测试、实施、运维、运营这些阶段，习惯性的使用的线性思维。

即使敏捷思想已经推广很多，但很多时候的企业管理者害怕质量没法把控、觉得手底下的项目管理人员管理素质不够高，而不敢进行达到扩斧的改革。

所以很多所谓敏捷并未真正做到，缺少的Devops导致了从代码构建到测试、运维阶段时间长，缺乏持续试错的基因，导致即使发现需求的有变化，但也不愿意修正，直到最后越来越偏离，而不得不开展需求变更。

关于需求约束变化、需求规则变化，这两个常常是一个变化评率较高的，就是来自于某些需求关于计算、存储、校验、配置发生了改变。

这样的很多时候来自于客户，对于交付型产品，可能是由于产研阶段的产品需求规则发生变化。这样的例子就不再进行列举。

关于专业知识不够所导致的，这里常常是因为的整个项目中缺乏专家，对于一些的复杂的行业类似于财务、税务、法律、运营商、军工等等行业，并不是所谓的新来者就可以颠覆的，往往产品的越专业化，往深度的业务发展，就会发现那些工作5-15年以下的很难解决。

然而由于很多工作者往往只在一个行业工作，按照1万小时候定律确实可以称为细分专家，但是也只是某个部门这个业务的专家，放到整个行业来看还是初级入门阶段。举个例子，在是税务行业，人们都知道如何进行发票开具，开具简单发票，了解到领票、开票、取票、验证、记账等流程。

但是开具差额发票、冲红专用发票多行多折，关于特殊税率如何开具等，再往后，你如何指导你的发票就是真票，再深入你如何指导开票给你不是虚开发票？对于很多做进项抵扣的发票做了税务局抵扣，你后期是要做转出，但你怎么做到防控。

在一次层层的专业知识深度，往往是需要更多的行业，已经不再仅仅局限于发票，而需要关于记账、开票、申报、财报、银行流水、订单情况、企业工厂运行情况、公司高管任职情况等，已经设计到更多行业，而工作仅仅几年，在一个行业积累的经验，在公司进行更深入行业的拓展，对于企业想要解决他们需求，如果产品管理、项目管理者没有更深的业务了解，仅仅只是过去的经验去理解客户、行业的知识，往往只会造成项目需求变更不断。

需求变更8大解决方案

在解决需求变更，自己认为过去的近三十多个项目管理中，要非常关注关于项目要实现的底层逻辑，对于信息的生产、采集、传递、处理、存储、传播和利用。

而贯穿在整个项目生命周期的中，始终是对信息的管理，而不是对所谓的人情世故、关系、过去的经验。而这些环节没有控制好，这就造成了需求变更，项目无法稳定的控制。要建立起自己标准化、流程化。

很多的时候不客气的说一句，很多项目管理即使工作十几年，但是始终未做到如何标准化、流程化，以至于长期处于在于非关键环节上不断投入时间，而在关键工作上始终未投入时间和精力。需求变更不断的原因也在于长期在非关键环节投入过多，关键关键环节忽略、把关不够。

前面我们讲了很很多需求变更原因，这里就看一下需求变更产生成本增加情况。Capers Jones 发表过关于产研阶段中需求变更来带成本变化，我们可以看到项目的成本变更或者需求修正那边产生的成本是指数型增长。

针对需求变更导致项目成本无限上升，那么我们需要如何解决？根据长期相关问题的研究，自己提出解决方案。

这里提出8大解决方案：专家需求调研、专业性需求调研、需求评审把关、FSD文档细化需求、功能验收阶段前移、测试左移、客户持续反馈、会议纪要等文档追踪。

专家需求调研

在产品调研阶段，如果是大型项目，采用的是普通的需求或者产品经理调研，那么在面对的客户是财务经理、技术经理、业务经理、专家、某位政府领导时，在关于一些深入问题提出时，需求人员无法理解客户的意思，那么就会导致需求调研失败。

这里就需要相关的专家，或者对客户需要上某类产品业务非常熟悉的人员，切莫让新员工、对业务领域的不够熟悉的人员进行调研，这会导致一定程度在和团队、领导相关需求出现巨大偏差。

专业性需求调研

在需求调研阶段，一定是要建立专业性的需求调研，切莫带着一个笔记本，只听客户在讲什么，而被客户带入主节奏。我们需要制定专业的调研规范，比如在配置阶段需要客户提供那些数据、提供那些非功能性的前期工作，对于一些数据签订相关保密协议。

对于一些需要客户进行申请工作需要让客户提前申请，确定哪些方案时可以申请通过的，避免后期需要赶工重新建立。关于流程化、规范化，需要的是从公司的产品萃取相关经验，然后落实调研流程化、标准化。

需求评审把关

关于需求评审把关。往往需要我们要花时间在这个阶段，过去看到很多项目在规划、评审阶段时间往往花个几个小时，只有产品、部门经理闭门评审，最后导致的需求无法落地。

因为评审需要的是的技术是否可行、需求复杂度进行评估，时间是否可以，相关需求是否影响其他功能。有时候很多人觉得产品经理、部门经理什么都清楚，在即在上市公司的多年经验发现，大多数是什么都不清楚，甚至是一堆糊涂账。

在传统企业往往测试人员对产品的各功能非常详细，但是测试人员专业度又往往不够，在于功能之间的关系、功能和架构关系。而要做到的对产品的把控，就需要需求或产品、项目经理、技术经理、测试经理、质量经理等共同的开会进行评审。

项目经理千万不要把自己看成只是做进度管理、质量管理、项目监督这些角色，而是要做到规划、组织、监督、引导等。从项目管理往项目CEO的标准进行发展。

FSD文档细化需求

关于FSD文档细化，这快就是围绕着目标、实现过程、验收而要做的事，对于一个功能需求，要把目标写详细，把验收结果写清楚，把实现的过程的写清楚。FSD文档细化到什么程度，就决定了后期后期的变更有多少。

自己过去做过技术管理，会关注产品的架构设计流程，那么对于产品的需求如何多个平台进行交互，自己会把数据架构、技术架构给梳理出来，对于一些数据流向，会把数据架构、流程梳理在FSD文档中之中，从而在产研阶段杜绝相关问题的发生。

对于FSD文档的有时候编写起来可能时间上会的落后研发，但是整个工作是还有另外一个好处就是提高质量，因为测试可以依托FSD的文档进行的测试用例编写，而不是靠人工去问，去问的这个操作，研发还需要去解释，但没有书面化的东西，会让质量工作下降。

功能验收阶段前移

关于功能提前验收。敏捷思想已经在国内有推广多年了，但是一遇到的功能要在开发完成一个需求的后，就要进行验收，就非常反感，觉得天天都验收很拒绝。

但是真正再实施过程中，会发现的其实并不会占用太多的时间，并且在完成这样的制度后，在发现研发已经偏离了需求的可以及时进行调整修改，因为此时研发的思维还对刚写过的功能是比较熟悉的，修改起来也会速度较快，一旦时间越久，研发人员还需要回头再来熟悉和测试的代码流程，时间反而会增加。

有时候因为一些需求在研发过程中发生变更，即使有相关的沟通，但是还是会的发现研发并没有关注到这些变更，通过提前验证功能工作，可以保证的该工作。

测试左移

测试左移、需求变更左移。关于测试左移，是由于我们已经知道在后期只要发生变更，发现错误修复，那么我们就需要提前开展测试左移工作，只要测试完成的功能，修复，那么功能就是可用运行的，我们可以通过的再和客户进行的反馈、演示相关功能，以便客户变更可以的得到提前的发生，而避免后期的由于某些需求变更导致时间成本无限上升。

客户持续反馈

持续演示和客户反馈。如果按照传统的方法，开发完成、测试完成、交付、演示，那么客户再提出各种需求变更，那么产品将会很难。

这点在某运营商工作的项目经验积累了相关经验，那就是拿原型持续的给客户进行演示，客户其实就和看PPT一样，没有提出需求的想法，只有实际可以使用的产品，客户在录入数据后，在使用过程中会提出各类的需求，由于是需求不断变更，采用的方式就是不断进行测试左移、客户反馈，从而让客户对我们能力的和专业性产生一定的信任。客户的需求的变更不要认为是为难我们，而是由于想要真正想通过系统解决他们真实的问题，如果只是通过一两次的沟通就可以把需求的聊明白，把产品上线了，那么这种项目也就不是项目了。

会议纪要等文档追踪

关于会议纪要等文档追踪。这就需要我们经常的供应商、客户的相关方多开会沟通，要时刻对的产品的情况进行的开会并且对做好会议纪要，并且持续跟踪。

例如芯片库存缺少问题，要时刻跟踪的，避免影响的生产。对于客户相关方领导情况的要去深入了解，如果发生人员变更要及时的做好风险应对策略，因为人员变动往往也会有信息过来。如果遇到信息知识记录到大脑，而不是做文档化，及时分享、沟通，者都会出现很大的问题。

这里针对的需求变更的8大原因，做了对应的解决方案，归纳如下。