目录

案例

1、需求变更的常见原因

2、对待需求变更的思路

3、需求变更的流程

案例

比如说我们项目干到一半儿了，突然有一天，PM过来找你，这个项目的负责人，他说，有一个XX功能，能不能改一下实现方式，或者修改一下这个功能的运作流程，或者是对这个功能加强一下，比如说有一个查询的功能，商品查询。本来预定的商品查询的条件是4个，商品名称，商品编号，品牌，类别。整个咱们的这个系统和代码，都是按照这个预定义的需求去做的，包括这个功能的代码实现，包括这个功能内部的一些运转流程，包括之前设计好的设计模式，都是针对这个需求来的。

结果这个PM跑过来找你说，诶，我发现这个需求好像不太对啊，好像这个功能需要改一改，再做一些加强，商品查询的功能，不能只是按照4个条件来查询，需要支持8个条件，比如商品状态、商品创建人、商品库存、商品好评率，他可能脑洞大开，又要让你加好多的查询条件。

然后这个时候，你一听，如果要改动这个功能的话，可能要增加很多的工作量。那么此时一般来说，RD，思维，一定不是站在产品设计的角度去走的，我们一般都是站在技术实现的角度去考虑的。跟PM是完全不一样的，PM会觉得说增加4个查询条件对运营人员的工作效率可以起到大幅度的提升。但是对于你来说，如果要增加4个查询条件，可能导致多了几天的工期，甚至导致整个项目可能会delay。此时一般你会拒绝他，你会说，不好意思，我不想修改。

但是此时，PM通常会这么说，不就是加几个查询条件吗，很简单的。有什么难的。甚至更有甚者，他提出的需求变更是加4个查询条件以及2个排序条件，支持按照什么什么规则去排序。然后他说很简单的，你就随便改一下，找一个人，花一个小时可能就搞定了。

但是，你作为架构师，你考虑一下，是这么简单吗？首先，加的那4个查询条件，商品状态、商品创建人、商品库存、商品好评率。商品状态、商品创建人，还好说，因为你想一下，这两个字段可能是涵盖在商品的主信息表里，那么直接修改查询商品的条件就可以了。但是问题在于后面两个查询条件，商品库存、商品好评率，这个就不简单了，因为可能是需要将商品跟库存表去关联，然后查询，商品好评率，可能也是一样的额，需要将商品数据跟评论表去关联，然后去查询。而且这里有一些问题，如果仅仅只是修改SQL也就算了，但是这里可能是挺复杂的，如果要做这些关联，你要去评估，索引有没有设计，SQL如果这么做的话，SQL的性能会不会大幅度下降。

甚至，可能评论是放在别的数据库中，微服务里，你还不好直接去查询，可能还要请求别的服务的接口，从别的服务里获取这个数据到自己服务里来拼接，那么此时可能还要涉及到你要跟其他team的人去交流，可能还要让其他team的同学配合着加一个接口。

评估，加4个查询条件：调研和评估（索引的情况，性能的情况，其他服务提供的接口情况）、设计实现方案（详细设计文档）、开发、单元测试、冒烟测试、静态代码扫描、集成测试、系统测试 -> 耗费多少人力，首先负责开发的RD要耗费几天的时间 -> 此时代码修改了，要重新进行集成测试，耗费1个QA+4个RD，5个人重新再小黑屋里回归一遍 -> 耗费QA的时间，将这个功能重新进行功能测试 -> 不是说你就修改了部分代码，就重新测试部分代码就可以了，你只要修改了代码，那么原则上来说，我们又不知道你只是修改了部分代码，我们也不好确认说，你修改的这点代码有没有影响别的代码 -> 各个测试环节，全部进行全量的回归测试

评估完了这个成本之后，你再来告诉PM，你还要不要随便这样子修改需求了？

案例式的方式，带着大家去走了一遍，修改需求的时候，会出现什么样的一个坑爹的情况

1、需求变更的常见原因

（1）不靠谱的原因

PM不靠谱，99%的需求变更的情况，就是PM不靠谱，就是PM在进行产品设计的时候，思考这个产品需求的时候，没有考虑清楚，没有细化所有的需求，没有考虑到各种各样的情况。导致在系统开发到一半的时候，PM来搞这个事后马后炮。一开始的时候，是按照4个条件来查询，8个条件，10个条件，支持所有列双击界面上的列头，都可以按照那个列来排序。PM自己上手，1个小时就可以搞定这个事情。

大家按照PM没有考虑清楚的需求文档就开始做了，结果开发到一半儿，PM反悔了

（2）靠谱的原因

常见于市场竞争态势的变化

比如我们以前开发一个产品，市面上是有几个竞争对手的，BAT现在也开始在做很多产品，对外也都是竞争的。我们有一个大版本，是持续两个月的。结果在做到一半的时候，市场竞争态势出现了变化，就是竞争对手率先推出了新的功能，抢占了一些用户和市场。此时我们的高管就着急了，副总裁级别的人，副总就直接下命令说，必须在这个版本中加入某某某功能，要跟我们的竞对要持平。

我们作为技术人员的价值在哪儿？就是我们开发出来的东西，他一定是要为公司产生直接的经济效益的。节省成本，增加市场占有率，增加用户流量。

对于这种靠谱的原因，那么作为我们RD来说，义不容辞的，有价值观。我印象里有一句话，我之前就是做项目的时候，碰到过几次类似这样的情况，有同事就特别棒，他说的是，上刀山下油锅，都必须把这个东西给做出来。

如果一个RD胡乱按照自己的思维去做事情，完全不考虑公司的利益，那你作为一个RD就没有存在的价值了，可以被公司开除

靠谱原因仅仅占比1%

2、对待需求变更的思路

（1）对不靠谱的需求变更

第一点

要加强需求评审的意识，就是说作为RD，你在评审产品经理编写的产品设计文档，产品需求文档的时候，你一定一定要仔细看每个环节，仔细的去思考这个产品的每个需求的细节，力求脑子里基本上就知道为了做这个需求，大概技术设计该怎么做。如果在评审需求文档的时候，你感觉可能会有坑，赶紧提出来，给PM提前提意见，让他提前调研和思考清楚，有些功能要不要做。

比如说商品查询的功能，作为一个RD，你要有一定的产品意识，当你工作了很多年之后，做了很多的项目之后，建立起来了比较丰富的工作经验，对待产品的设计，你虽然没设计过，但是你做过很多产品，你培养起来了自己的一种第六感。站在这个第六感的角度，你可以去考虑一下，每个产品需求功能，是否靠谱。比如对于商品查询的功能，你就可以站在产品设计的角度，去考量以下，诶，这个商品查询就4个条件，是不是太少了？这个时候这句话，可能就是你的第六感告诉你的。然后你就要反馈给产品经理，让它重新在考虑一下，说这个商品查询，你再想想，要不要加入更多的查询条件。

也许通过你的很牛的第六感的提议，可以让产品经理提前把一些坑给填了，不至于后面给你挖坑

倒逼产品经理去完善需求文档，你的脑子里，在看完需求文档之后，脑子里基本要建立起来一个流程、概念和意识，就是大体上你都知道系统层面，需要怎么做系统开发，来实现这样的一些需求和功能。那么如果你在脑子里思考技术和系统实现的时候，感觉有些问题，感觉有些需求模模糊糊的，不清不楚的，那么此时就要在需求评审的时候，提出建议，让PM反过来去完善需求文档，细化，重新思考。

我们之前写好了一份需求文档，但是那份需求文档是一定有不够完善的地方的。那么接下来我们做系统的时候，就站在架构师的较多，从需求评审开始，一点一点去评审整个流程，在脑海中去思考这个系统层面怎么去做这个东西。如果感觉有不靠谱的地方，可以记录下来需求评审意见。我们自己模拟自己是产品经理，去完善这个需求文档。

这个大家不要觉得这个事情很虚，这个都是架构师非常重要的软素质。

第二点

如果是在开发过程中，不靠谱PM提出来不靠谱的需求变更，判断出来是99%的情况，直接打回去，作为一个架构师，你要据理力争，否则如果你不断的妥协的话，你就会导致你手下的弟兄，像一群猴儿一样被PM耍的团团转。如果你接受PM提出的不靠谱的需求变更，你手下的弟兄就会各种反复加班，去修改代码，去满足那些乱七八糟的要求。你是在坑你的弟兄。

直接给他打回去，如果他一定要做，让他找产品总监，直接对接你上面的技术总监，让两个总监去PK。

如果打回去之后，因为产品总监过于强势，强行逼迫你的技术总监答应，要改动这个东西，就走后续的需求变更的流程，技术总监审批，delay

（2）对靠谱的需求变更

无条件接受了，但是要说清楚，肯定要走一个需求变更的流程，需要有高层领导，技术总监级别的人，要审批

一旦有需求变更，基本上就意味着，肯定要延期，工期增加了，正常延期，找你的技术总监去审批

3、需求变更的流程

3.1 PM发起需求变更的申请

一份需求变更的申请模板

（1）商品系统-商品管理模块-商品查询功能

（2）原有的需求是

按照4个条件来查询商品，4个条件包括了：商品名称，商品编号，品牌，类别

（3）现在需要将需求改动为

在4个查询条件基础之上，增加4个查询条件，分别是：商品状态、商品创建人、商品库存、商品好评率

同时，在增加4个查询条件的基础之上，需要支持商品列表中的所有字段，都可以支持前端双击列头的时候，会自动进行排序

（4）需求改动的原因

需要支持这样的功能，来辅助商品相关的运营人员去更好的管理商品，在需要的时候可以尽快查出想要查看的商品数据，而且支持商品列表按字段来排序

3.2 需求变更的评估

找具体负责这个需求的同学来评估一下，要为了这个需求做哪些事情，耗费多少人日，从几号到几号，导致项目delay几天

（1）商品系统-商品管理模块-商品查询功能

（2）将这个功能改动为

在4个查询条件基础之上，增加4个查询条件，分别是：商品状态、商品创建人、商品库存、商品好评率

同时，在增加4个查询条件的基础之上，需要支持商品列表中的所有字段，都可以支持前端双击列头的时候，会自动进行排序

（3）需要改动的一个步骤是

调研和评估（索引的情况，性能的情况，其他服务提供的接口情况）：1人/日

设计实现方案（详细设计文档）：1人/日

重新开发：1人/日

单元测试：1人/日

冒烟测试：1人/日

静态代码扫描：1人/日

集成测试：2人/日

系统测试：2人/日

（4）改动持续的时间

从6月5号持续到6月15号

（5）耗费的成本

耗费总人/日是10人/日

（6）对项目进度的影响

导致项目整体delay达到10天

3.3 对需求变更进行审批

架构师负责将这个需求变更的申请和评估报告，提交给技术总监

项目delay是一个大事，轻则影响绩效，重则影响公司业务发展你要被开除

技术总监负责对这个delay的时间进行考评，考量过后，确认通过审批

4、具体去实施这个需求变更

项目管理计划的4张图都要修改，很多任务都要delay，额外加入了一些任务

当前正在进行的本周或者是下周的执行计划里，要修改，加入这个额外的任务

接下来，照着修改过后的项目管理计划，和每周的执行计划，去执行就可以了，就开始干这个额外增加的新需求