案例式的讲解
比如说我们项目干到一半儿了，突然有一天，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是一个大事，轻则影响绩效，重则影响公司业务发展你要被开除，p2p领域，数一数二的龙头，XX贷。XX贷出来的一个同学，就是做一个项目，delay了一个月。领导直接二话不说，开除。北邮的硕士，XX贷公司背景也很好，但是背上了项目delay被开除的结果，到很多公司面试都碰壁。离职证明上会写明，由于该员工项目delay，所以公司决定与其解除劳动合同。
技术总监负责对这个delay的时间进行考评，考量过后，确认通过审批
4、具体去实施这个需求变更
项目管理计划的4张图都要修改，很多任务都要delay，额外加入了一些任务
当前正在进行的本周或者是下周的执行计划里，要修改，加入这个额外的任务
接下来，照着修改过后的项目管理计划，和每周的执行计划，去执行就可以了，就开始干这个额外增加的新需求
标签：需求,十七,这个,查询,商品,变更,PM 来源： https://blog.csdn.net/bemavery/article/details/116457437
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。