技术人人都是好的需求评审专家- 如何需求评审,需求评审评什么.

父文如何成为一名架构师,架构师成长之路_个人渣记录仅为自己搜索用的博客-CSDN博客_架构师成长之路
相关设计文章 : 人人都是好的软件开发设计师_个人渣记录仅为自己搜索用的博客-CSDN博客
 

 

会向业务“砍需求”的技术同学，该具备哪6点能力？

我的另外两篇,待整理:  关于需求评审和设计 需求评审和分析

如何做需求分析？ - 陈一斌的回答 - 知乎 https://www.zhihu.com/question/20407032/answer/119861996

其他文档: 基于UML的需求分析和系统设计

概要设计要理解流程图和时序图的区别?

  活动图,是总览的节点(无法再拆,也可以拆成子流程. 但是一个就好), 流程图有细化的逻辑判断节点.  时序图里可以含一个节点/结点的内部细节. 

   一个较复杂的需求,概要设计简析

流程复用,策略点的复用.(本质上内含了 实体复用, 抽象父类)

会导致流程模板的嵌套. 例如某个业务流程有很多, 需要依赖某个业务的一个流程.

方案一: 引擎type法. 通过某个type处理不同的业务. 也可以通过异步化解耦.

方案二: 组合法. 另外一个模式是 组合模式. 在入口处先判断业务. 使用不同的业务实体/流程.

企业流程和技术实体流程的关系

为什么要需求评审?

   一个较复杂的需求,概要设计简析

     很多创业公司,都没有需求评审,一句话带过.很多细节都是开发后期,验收后期才发现. 或者是开发和产品共同沟通的结果.这个时候没有需求评审,好处在于开发即产品,一句话后有自己的理解,同时不需要协作返工成本低. 更重要的是创业开城阶段,主方向对就可以了,细节无所谓. 但是不要因此给自己台阶,前期不想清楚,想明白.浪费团队人力和精力.

     但是一旦团队大了,涉及到团队协作,而且涉及到守城,不想看到出问题. 就需要前期充分沟通好. 不仅是大方向,细节也需要双方沟通好.

     虽然需求评审前开发会过一遍. 整理出问题. 但是需求评审还是需要产品,挨个挨个讲过去. 这样开发才能逐个去思考,并且别人的疑问,也能激发出自己的想法. 确保细节被团队充分挖掘,并且在团队内同步. 特别是后期testCase的评审,更能帮助开发.

需求分析和需求评审不一样. 需求分析应该是产品做, 把用户场景和需求转换为产品需求/功能(why,how的过程 如何做需求分析？ - 陈一斌的回答 - 知乎 https://www.zhihu.com/question/20407032/answer/119861996)

什么是需求评审?

    1. 感知,认知 : 看产品的设计,了解需求宏观流程,理解用例(操作), 理解产品ui展示(数据).

    2. 反馈: 补全产品设计

 为什么需要需求评审?

   从技术设计的角度来提出疑问,补全产品设计,避免技术task过少,导致工期delay.

    至于抓主线流程,还是陷入本文的几个评审细节,阅读者自行判断.

   

   虽然需求分析是产品的能力, 但是产品可能更关注与怎么解决用户的场景问题,  很多细节闭环上可能会缺失考虑. 开发是细节, 涉及到项目时间计划. 故需求评审是开发的能力,要挖掘出产品没有关注到细节点.

   开发和产品一个很大的区别时是开发对点比较关注，相对来说比较细，深。产品会想的广，考虑到各种流程 (可惜很多产品都没有这种能力, 不能状态下的, 多用户同时,操作等case , 可能最好也不要如此, 会导致产品陷入细节. ) 。所以产品最好把相关变更的功能点给考虑到，不要被太多的细枝末节打扰。

    开发思考时可以学习产品采用MECE——相互独立、完全穷尽的思维方式去遍历，类似与脑图，分层然后不停深入。

    第一层，人，第二层流程，第三层同一个流程的不同情况。

    测试和产品思维逻辑差不多，但测试要面向语言和程序运行。

前功能和后功能之间(写,操作)

   流程和流程的杂糅，即前面行为导致后面的行为。

          举例子：下单的时候，乘客选择不使用券，支付的时候不应该给他自动绑定上。

             产品描述了下单和支付的两个逻辑。输出和结果。

             开发者，需要详细设计时，代金券id=-1 代表乘客选择了不使用券。概要设计时是否需要描述 

各个状态之间ui如何展示,是否有哪些操作

写功能和查询功能之间 - 单人写读,多人写读.

      数据流向。页面上有的数据来自于哪里，哪个页面上有哪些数据要展示。     例子: 会议室日程锁定状态. 类似于电影票锁定状态. 增加了这个状态后另外一个人读怎么展示,我自己读怎么呈现.

   

 

不过过度设计: 

   统计性需求不要评审,设计进去. 产品会关注下单时间，但我们可能会保存接单时间，支付时间等等。 

投入和需求之间的权衡

    注意是权衡,而不是质疑产品逻辑(这样子也能更好地和产品处理好关系). 一般实现复杂了,用户操作和逻辑上也会显得复杂.( 这些需求可能往往是站在平台侧引入的,产品自high的方案.)

 举例,爽约金和等候费.  一开始,支付了等候费后,又有一笔爽约金(通过大数据安全分析计算判断用户是否需要支付爽约金)需要支付. 订单状态又要重新开启,或者说进入爽约金支付状态.或者用另外一个字段. 这样子会导致一个订单有多次支付,整个实体关系发生本质变化,从1对1,到1对多,代码也带来巨大变化,投入非常高.

 状态一定不能有回环.不然无法区分处于第一次和第二次处于该状态的情况.

案例2:  现金支付可以用券.  如何给司机展示入账流水和相关信息.

首先: 1.帐户变动金额要显示. 其次,显示怎么算出来的.  每个人分了多少钱. 这里面要包含司机.

代码设计上的多想一步,功能复杂性:

两个系统的状态边界要理清. 前置性条件要明确.状态要清洗.

末尾状态结束时必须要先通知下游系统生成衍生类(最好是同步调用). 有时候两个状态是独立的,大单服务结束和支付是独立的.

一切通过"版本号"的设计都是 反模式. 可以通过新版本新增support字段来实现. 

状态如何设计

  例如一个审批,内部有很多流程,是否需要显示给用户. 一般情况下不需要,但是饿了么/美团外卖的送货员的进度要展示给用户,避免用户等待漫长,而且快递员会和用户打交道,能感知到这个实体. 另外后台查询时,条件可能会很多. 前台的状态设计和后台的状态设计不同. 存储可能都需要备份.

  怎么设计. 一般后台的需要重新拷贝一份,更甚至变成大宽表或者搜索引擎,用于查询. 还有一种呢反过来,推给C端展示,例如广告业务系统推给检索端,最终呈现给用户.

状态机最好要引入.

另外对状态的修改必须要封装成方法(分层),外部不能直接调用. Dao层的代码外部都不能调用的. java本身编译支持有限.只能通过规范和ide插件,maven插件实现.

谁调用谁由架构师决定.

思考多种设计.

 1. 硬件视频会议

    人扫码切换硬件入会. 一个需求两种实现方案.

   1.1 硬件和人是两个uid. 但是从用户角度(需求)角度,用户其实期望"某某人通过某某社会入会",标题显示的是某某人的硬件名.  技术上可以包装对,对用户是同一个人. 如果只是从技术角度想的话,这就是两个人.

   2.2 另外一个实现方式就是 硬件的uid就是人的uid. 只是在不同设备上登录而已. 动态登录,绑定的时候登录. 可能会有很多安全问题.

需求评审前做什么?

   特别是跨团队. 1.先和对方沟通,对方产品接下需求,周知给技术. 2. 技术初步沟通,价值上可行,方案上大概需要哪些依赖方,是否已经提供,整体排期多不多, 对出对接的技术方案,前端跨域,身份校验和系统上下行交互上可行 3.产品出马,交互ui,细节逻辑拉在一起做需求评审.

另外两篇文章: 

   需求拆分到设计流程总览 需求拆分到设计流程总览_个人渣记录仅为自己搜索用的博客-CSDN博客

  业务系统中最核心的状态设计,异常 case. (系统设计)

外部协作项目流程

1. 初审

   1. 交互图,双方产品,定稿
      双方技术owner初审,给出意见. (一起或者各自,有时间点,有纪要)

      1. 状态流程

      2. 各状态下的增,改,删,查交互设计.

      3. 多角色交互的逻辑.

2. 交互和需求评审( 产品约会  有哪些角色,有哪些action,角色数(1-N 还是有限),action数(1-n 还是有限),多个角色是否存在角色互换,同角色之间,不同角色之间问题. 每个action下信息呈现是什么样的. 还有就是价值确认,这个action和信息呈现是否有意义,至于为什么要做这些信息呈现,是价值,解决的问题.在立项阶段做掉.  2.1 主流程 2.2 状态设计 ,交互也需要根据状态来画交互稿-人人都是交互师,通过不同的角色的展现需求,交互需求. 2.3 异常case 不同角色的并发冲突(例如会议预订:采用预抢占产品思路,产品交互和设计上都更复杂,还是采用后报错产品思路.),测试人员素养-人人都是测试专家)
   交互图,各状态,需求评审一审(最好双方技术相关人员到场,一起评审,面基), 反馈评审意见

   1. 状态流程

   2. 各状态下的增,改,删,查交互设计.

   3. 多角色交互的逻辑.

   4. 各角色的查看逻辑

每个流程走查后的状态.
           交互图 二审(如有必要)

          一期角色交互不清晰

              1. 业务状态不清楚,各状态的交互不清晰.

              2. 交互需要定稿

   技术评审( 技术owner约会 , 系统设计金字塔, 安全,稳定性等. 人人都是技术人)

1. 出模块交互时序图,参数,字段,技术方案评审. (双方服务端,端,一起评审沟通)
2. pc和手机技术评审分开.
3. 这个时间后,出task和时间点. 明确时间点,aone上标识总联调时间点, 服务端上线时间点,端封版时间点.

变更

1. 一旦交互主动变更,对应的时间点就需要变更,早会,钉钉po周知.

项目角度要求, 按迭代走:

1. 有wiki (开发维护,需求稿 需求审批后由提供)

1. 1. 需求交互锁定, . 测试依赖该交互进行设计.

1. 1. 交互图(边界时序图),字段

1. 1. 接口文档,细节字段.

1. 有时间轴.

1. 1. 联调时间点

1. 1. 发布时间点.

1. 1. 灰度时间点

1. 晚会:

1. 1. 同步时间轴(服务端必须在场)

1. 1. 一起对焦现有问题

1. 1. 临时依赖进来的必须,添加进依赖

1. 发布安排:

1. 1. 依赖方,发布顺序, 服务端灰度时间点, 全量发布时间点.