标签：状态 两种 设计 开放 还需要 很多 变更 没有 归类
A 需求的管理需要有序化
用户或业务方的需求可以认为是一个混沌状态，特别是对于B端和后端系统，需求与当前系统的能力匹配不一，有的需求可能只需要改文案即可，有的却要系统重构才能支持。
根据需求的实现难度和与当前系统能力的匹配程度，进行分类过滤，排好优先级，有序进行实现。这样，才能依次实现更多的需求，避免系统主流程发生较大的变更。
B 具体方案设计的系统化
这与需求的有序化是前后呼应的，都是为了避免系统无序内容的增多。
对于一个后端系统，当对多平台进行业务支撑时，会出现两种情况。
情况一：不同平台的需求共性较少，差异点较多。
这时候需要需要首先将其共性进行抽象。
比如，一个需要向用户的微信公众号、APP、手机号发送触达的需求，三种触达的文案各不一样，但其中的用户昵称是相同的。更系统化的方案就是把用户昵称作为一个配置变量，注入到每个平台的触达文案中。
情况二：共性较多，差异点较少。
这时候也需要把差异点进行抽象，形成一个配置项，这个配置项可以直接对不同平台的需求进行设置，无需代码再来判断这个逻辑。
比如，同样一个商品的详情页需要在A平台是红色背景，B平台是绿色背景。如果事先将这个变量做成配置项，只需要一个配置文件，或管理后台对不同平台勾选颜色即可。
2. 系统的开放性
对系统要实现的需求进行有序化归类，类比为做功；要抵抗系统的熵增还需要系统保持开放性，不能是孤立系统。
对于软件系统来说，我认为它的开放性可以理解为系统的拓展性和兼容能力。
比如今天我对系统提一个需求，需要将用户的订单从A状态变成B状态，而C状态是B状态的平行状态。在设计系统的时候，就要考虑直接从A状态到C状态的可能，虽然业务需求当时没有提，但说不准下次的需求就是从A直接到C。
如果系统的兼容性好，设计之初状态机就满足这种情况，后续就不用面对改造系统状态机而带来的诸多麻烦了。
因此，要保持系统的开放性，需要在设计之初多考虑异常流程，以及外部系统接入时预留措施。
3. 保持系统的熵减
从熵增原理我们知道，当一个系统熵增已经很大了，要降低熵是非常困难的。因此，需要时刻关注系统的熵增状态，及时控制、维持低熵状态。
对应到互联网产品设计上，我总结以下两点：
A 需求文档与线上系统的统一
互联网产品迭代频繁，产品经理的需求文档一般是迭代一版单独写一个需求，这样可能会导致迭代太多版之后，线上在跑的方案对应着多份需求文档。这对问题追踪和定位很不利，也不利于产品经理工作的交接。
因此，对于自己负责的较大的系统，一定要经常同步自己的需求文档，使之与线上的版本一样。这样有任何线上bug反馈也可以快速定位，避免需求文档走向熵增的不归路。
B关注系统的冗余程度
虽然系统在设计之初都希望有序有规则，但系统跑久了，总会有很多临时支持的特殊需求，或者当时没有想明白就直接接入系统的逻辑。
这些没有得到很好收归的需求，会导致系统的冗余；时间一长就会量变引起质变，在某个时间点拖垮整个系统。
时刻关注系统的冗余程度，在一定时间段来集中处理这些特殊逻辑是非常有必要的。
标签：状态 两种 设计 开放 还需要 很多 变更 没有 归类
原文地址：https://www.cnblogs.com/wcLT/p/12184809.html
