zoukankan      html  css  js  c++  java
  • 需求的有序化和方案的系统化

    A 需求的管理需要有序化

    用户或业务方的需求可以认为是一个混沌状态,特别是对于B端和后端系统,需求与当前系统的能力匹配不一,有的需求可能只需要改文案即可,有的却要系统重构才能支持。

    根据需求的实现难度和与当前系统能力的匹配程度,进行分类过滤,排好优先级,有序进行实现。这样,才能依次实现更多的需求,避免系统主流程发生较大的变更。

    B 具体方案设计的系统化

    这与需求的有序化是前后呼应的,都是为了避免系统无序内容的增多。

    对于一个后端系统,当对多平台进行业务支撑时,会出现两种情况。

    情况一:不同平台的需求共性较少,差异点较多。

    这时候需要需要首先将其共性进行抽象。

    比如,一个需要向用户的微信公众号、APP、手机号发送触达的需求,三种触达的文案各不一样,但其中的用户昵称是相同的。更系统化的方案就是把用户昵称作为一个配置变量,注入到每个平台的触达文案中。

    情况二:共性较多,差异点较少。

    这时候也需要把差异点进行抽象,形成一个配置项,这个配置项可以直接对不同平台的需求进行设置,无需代码再来判断这个逻辑。

    比如,同样一个商品的详情页需要在A平台是红色背景,B平台是绿色背景。如果事先将这个变量做成配置项,只需要一个配置文件,或管理后台对不同平台勾选颜色即可。

    2. 系统的开放性

    对系统要实现的需求进行有序化归类,类比为做功;要抵抗系统的熵增还需要系统保持开放性,不能是孤立系统。

    对于软件系统来说,我认为它的开放性可以理解为系统的拓展性和兼容能力。

    比如今天我对系统提一个需求,需要将用户的订单从A状态变成B状态,而C状态是B状态的平行状态。在设计系统的时候,就要考虑直接从A状态到C状态的可能,虽然业务需求当时没有提,但说不准下次的需求就是从A直接到C。

    如果系统的兼容性好,设计之初状态机就满足这种情况,后续就不用面对改造系统状态机而带来的诸多麻烦了。

    因此,要保持系统的开放性,需要在设计之初多考虑异常流程,以及外部系统接入时预留措施。

    3. 保持系统的熵减

    从熵增原理我们知道,当一个系统熵增已经很大了,要降低熵是非常困难的。因此,需要时刻关注系统的熵增状态,及时控制、维持低熵状态。

    对应到互联网产品设计上,我总结以下两点:

    A 需求文档与线上系统的统一

    互联网产品迭代频繁,产品经理的需求文档一般是迭代一版单独写一个需求,这样可能会导致迭代太多版之后,线上在跑的方案对应着多份需求文档。这对问题追踪和定位很不利,也不利于产品经理工作的交接。

    因此,对于自己负责的较大的系统,一定要经常同步自己的需求文档,使之与线上的版本一样。这样有任何线上bug反馈也可以快速定位,避免需求文档走向熵增的不归路。

    B关注系统的冗余程度

    虽然系统在设计之初都希望有序有规则,但系统跑久了,总会有很多临时支持的特殊需求,或者当时没有想明白就直接接入系统的逻辑。

    这些没有得到很好收归的需求,会导致系统的冗余;时间一长就会量变引起质变,在某个时间点拖垮整个系统。

    时刻关注系统的冗余程度,在一定时间段来集中处理这些特殊逻辑是非常有必要的。

  • 相关阅读:
    CF1202F You Are Given Some Letters...
    CF1178E Archaeology
    PTA (Advanced Level) 1005 Spell It Right
    PTA (Advanced Level) 1004 Counting Leaves
    Qt5——从零开始的Hello World教程(Qt Creator)
    PTA (Advanced Level) 1003 Emergency
    PTA (Advanced Level) 1002 A+B for Polynomials
    HDU 1272 小希的迷宫
    FZU 2150 Fire Game
    HihoCoder
  • 原文地址:https://www.cnblogs.com/wcLT/p/12184809.html
Copyright © 2011-2022 走看看