人人都是产品经理|系统设计:如何确定需求的边界?取决于哪些约束?


编辑导读:针对业务流程而设定的解决方案并不是万能的 , 在系统有限的范围内 , 产品设计需要对边界进行了确定 。 本文作者从边界的概念出发 , 对此展开了梳理和说明 , 与大家分享 。

人人都是产品经理|系统设计:如何确定需求的边界?取决于哪些约束?
本文插图

业务场景与行业的结合往往是最切实际的约束条件 , 同样是电子商务网站 , 有些商品可以线上交易 , 而有些大宗商品却无法突破支付与信任的限制 , 也许普通商品的电子商务网站无需对用户的信用体系做审查 , 但是大宗商品的交易网站就要负起审查的职责 。
大宗商品如棉花、钢铁等 , 买卖的最小单位是批次、规格等 , 牵涉的金额在百万甚至千万不等 , 合同以及订单的履约风险是用户比较关注的情况 。 例如棉花商品的信息与实际合同如下图所示 。

人人都是产品经理|系统设计:如何确定需求的边界?取决于哪些约束?
本文插图


人人都是产品经理|系统设计:如何确定需求的边界?取决于哪些约束?
本文插图

从通用的角度来看 , 针对业务流程而设定的解决方案总是有约束的 , 系统的范围总是有限的;在需求定义阶段 , 对系统的范围进行界定是十分重要的 。
如何确定需求的边界 , 推荐的方式是通过上下文关系图 , 实际上是数据流图中的顶层图 。 相关的思路就是将整个待开发系统理解成一个黑盒 , 然后标识出外部的参与者和系统的交互关系 。
【人人都是产品经理|系统设计:如何确定需求的边界?取决于哪些约束?】而在实际的操作中 , 上下文关系图的应用有两个问题:一个是系统太大 , 不容易一下子梳理出来 。
01 范围 vs 边界
范围和边界需要区分开来 , 范围是指系统涉及哪些内容 , 而边界则是系统与人的职责边界 。 针对这个问题 , 《掌握需求过程》一书中有个精彩的例子 , 如下图

人人都是产品经理|系统设计:如何确定需求的边界?取决于哪些约束?
本文插图

首先来看看这张数据流图 。 这是一个产品销售公司的销售过程示意图;顾客需要买东西时就会打电话给公司销售人员 , 公司销售人员根据供应商的促销数据向顾客报价 , 并根据当前库存量来判断能否响应该顾客的订单;如果顾客接受了这个价格 , 并且也有足够的库存量 , 销售人员就会认为该订单是有效的 , 并将其转给信用核查员;信用核查员根据顾客的历史交易数据以其信用卡的情况来决定该订单是否是安全的 , 然后将审核的结果返还给销售人员;如果审核的结果表示订单是安全的 , 那么销售人员就将订单记录下来而其他环节(诸如收款、物流)将根据这里的订单记录来进行相应的处理
如果该企业打算投资20万–30万开发一个完成覆盖进、销、存管理的软件系统(这个业务流程是必然涉及其中的) ,
那么该如何选择系统的边界 , 例如选择2号边界 , 或者选择2号边界 , 并将与信用卡公司的交互功能去掉 。 如果你选择的是2号边界 , 但用户要求实现3号边界 , 你将如何应对?
02 确定边界
很多时候软件设计者考虑的过于全面 , 总想做一个大而全的系统 , 然而很多时候我们是根据项目的投入和资源来限制边界范围的 , 如果没有项目成本与时间的限制 , 那么确定边界的意义就失去了很多 。
如果系统只是实现“记录订单”的功能 , 那么实际上意味着用户必须手动完成接订单和信用核查的工作 , 系统只是起到了一个电子化的功能 , 换句话说 , 通过某种形式的Excel也能记录大部分的数据 。
这样的系统显然不是一个投入20万-30万的系统所应该采用的边界 , 或许在开发一个通用性的进销存产品(定价在几百元)时就会将边界定义在这里 。


推荐阅读