在软件开发中的一大挑战是客户需求的变更，以下一些熟悉的场景每天都在发生：
客户：你看这个页面能不能调整成蓝色，绿色不好看。（蓝色多好，大气！）
乙方：我们统一颜色都是基于绿色的，这块调整成蓝色不好吧。（无力吐槽。。。）
客户：那你先调整成蓝色我看看。（我还是觉得蓝色好看）
乙方：好的，马上给你调。（看我随便瞎调给你看看就知道了）
客户：算了，还是用绿色吧，但是绿色能不能深一点，我们主色调有用这个颜色。（绿色勉强也能接受）
乙方：那统一基色都调整成这样好了。（无力反驳）
客户：可以。（看，好多了吧，还是我有眼光！）
客户：小王啊，这个按钮是啥？不要了，那个菜单我也不要了。（太干扰了，看着不顺眼）
乙方：好的。（还好去掉功能简单！要是增加啥的那就。。。）
客户：还有这里能否增加一个查看详情的，要能打印和导出PDF。（领导肯定喜欢）
乙方：要不导出PDF后再打印，这样打印更好看。（还是逃不脱，能简单就简单吧）
客户：这样太麻烦了，还是在线打印吧。（这不是一样的？为啥还要下载再打印？）
乙方：好的。（咳，还是多了两个功能！）
客户：我们有个数据中台，这些数据都得回传到我们的数据中心。（早上一早突然才想到了）
乙方：我们系统上都有统计汇总，非常全面。（又要对接，一听就头大）
客户：不行，公司有规定的，必须要进数据中心。（我也没办法，过不了的）
乙方：那你们直接从我们这里取数据，我们有详细的接口文档。（我们经验丰富）
客户：我们不主动对接的，需要你们主动传递到我们中台，我发给你文档。（你们做不是更方便嘛！）
乙方：好的。（这文档都发来了。。。）
客户：这里我要增加这些字段，我们业务上有需要。
乙方：好的。（意料之中）
客户：对了，我们有些领导是分管领导。但是主要在A事业部，B事业部是双领导管理。
乙方：啊？你原先不是说都是单线领导的？（这时候突然这样，要死人的）
客户：刚接到的通知，因为并购了新公司，业务变更了，改成事业部了，需要双线领导。（不就是单线变双线领导嘛）。
乙方：那整个结构要大调整的，原来的权限，流程都是按照单线走的。（这时候绝对不能大变动，否则就惨了）
客户：不调整我们就没法用了，这个事业部是我们的核心业务，不用的话，项目就实施不了。你想想办法。（这个我也没办法，计划没有变化快。）
乙方：我们先内部沟通下。（能想什么办法？只能把风险尽量降低到最小）
客户：好的，感谢。（希望尽快调整，项目不能再拖了）
我们姑且不去讨论需求变更怎么管控，怎么管理，又是怎么合理的拒绝。需求的不断变更是项目成功与否的一大拦路虎，假设需求变更通过的情况下，如何解决好才是问题的关键。
其实从以上的对话中，我们可以总结出需求变更的共性，并对这些需求变更进行分类。
为了更好的标明需求变更的性质，对此进行以下四个维度的划分：
1. 难度系数，即为了实现本需求变更，在实现上需要多大的时间和人力成本。
2. 风险系数，为了实现需求变更，可能对系统造成的风险，比如性能，安全，稳定。
3. 重要程度，变更对客户来说非常重要，否则无法使用，有些可能可有可无。
4. 紧急程度，需求变更非常的紧急，需要优先处理。
由此可以对需求变更进行分类管理，以平台化的思想应对，并基于平台制定统一的处理方案：
1. UI样式调整，很多客户都有自己的用色规则和个人喜好，这个是非常常见的需求。因为系统的使用人多，领导也多，意见不一致很正常，所以朝令夕改的情况也时有发生。
难度系数✱
风险程度✱
紧急程度✱
重要程度✱
针对此类需求变更，平台需要支持主题切换，直接平台中在线所见即所得的方式去调整，调整的范围需要分客户级（平台为多租户模式），模块级（多模块），用户级，页面级，尽量简单高效。这种方式可以大大减少开发和发布流程，节省时间，提高稳定性。
2. 功能性的调整，增减功能，有些变更可能看起来很小，但技术风险很大。
难度系数✱✱
风险程度✱✱
紧急程度✱✱✱
重要程度✱✱✱
已有功能的去留无非是通过权限控制，系统配置，元数据方式来实现。考虑到相关的功能会越来越多，平台应以数据的方式来实现对功能的描述（元数据），处理数据就是处理功能的相关特性及去留，增加的功能（或模块）也要以元数据的方式存在，以应对将来可能的需求变更。
3. 权限的调整，按组织架构，按上下级，按团队，按角色等调整各种权限。
难度系数✱✱✱✱
风险系数✱✱✱✱
紧急程度✱✱✱✱
重要程度✱✱✱✱✱
以企业为例，组织架构方式都大同小异，基于RBAC的增强模式可以解决绝大部分问题，采用此的统一架构体系去应对各种需求变更。平台需支持多根树的组织架构（含虚拟部门），多对多的上下级关系，多级角色，团队四个维度去控制各个资源的权限。各种需求通过这四个维度组合去实现，核心思想以不变以万变。
4. 接口对接，包括数据输入，输出，集成等。
难度系数✱✱✱
风险系数✱✱✱
紧急程度✱✱✱
重要程度✱✱✱✱
接口对接分两种：
一，对方接入本平台，需要平台有完善的接口和规范，有详细的文档。后续只需配合调试即可。
二，接入对方系统，标准的接口采用统一的对接子系统，通过平台配置方式来对接，平台要有完善的对接数据监控和错误处理机制。非标准接口采用扩展开发方式注入平台。
5. 结构性调整，加字段，加表，变流程，变关系（一对一，一对多，多对多，树形结构，图）。
难度系数✱✱✱✱✱
风险系数✱✱✱✱✱
紧急程度✱✱✱✱✱
重要程度✱✱✱✱✱
结构性调整是最为复杂的需求变更，搞不好项目直接就崩了。针对这种变更，低代码平台或零代码平台的思想就可以有效应对。通过平台进行操作（可能需要专业人士），外加扩展开发，可以大大的提高效率和系统的稳定性，降低风险。但是这样的平台还不够，还需要能够进行变更的比对和版本管理，回滚机制，结构复用，调整风险智能提示，预发布等，真正实现统一的平台方式来应对各种需求变更。
需求是无穷无尽，如果避免疲于应付，需要有前瞻性，提前做好预案，以不变万变。由此可见并非客户的需求变更都是洪水猛兽，做好准备，随时欢迎客户提出的宝贵意见并悉心采纳。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。