码迷,mamicode.com
首页 > 其他好文 > 详细

需求的有序化和方案的系统化

时间:2020-01-12 21:41:10      阅读:86      评论:0      收藏:0      [点我收藏+]

标签:状态   两种   设计   开放   还需要   很多   变更   没有   归类   

 

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

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!