产品设计之从业务到产品.docxVIP

产品设计之从业务到产品 注：产品设计属于产品工作的中间环节，在它的前面还有规划等工作，我们这里说的产品设计的工作边界是指从调研分析完，如何从0到1设计出产品功能，并能指导后续的开发工作。 今天这篇推文按理说应该属于产品设计的第一篇，先讲从业务需求如何推导出产品需求。 我们先放上产品设计过程的基本原则： 从具体到抽象 从整体到局部 从高层到底层 下面我们来看看具体的设计过程，你将看到如何运用这些设计原则。 老规矩，我们先从日常的例子说起。 企业办公时，我们最常用的OA，ERP系统，用户看到的一个个功能菜单及页面，是怎么来的？ 淘宝购物时，我们看到的首页、商品详情页、购物车页又是怎么来的？ 上面我们举的这2个例子，所用到系统都属于信息系统这一类（根据徐锋在《软件需求最佳实践》对2B系统的分类，除信息化信息，还有嵌入式系统等）。根据信息工程的定义，信息系统是人、数据、过程和接口的组合，以处理信息流为目的的人机一体化系统。这类系统也是大家最常接触的系统。 这类系统有个特点，把我们生产、生活的流程、场景搬到系统上。仔细观察，你会发现上面说的例子都离不开流程。所以，先梳理清楚线下的业务流程，是我们线上化的第一步。 一、从业务流程到系统流程 完成需求调研与分析后的第一步就是找出业务主干。一家企业的内部运转是由公司战略目标分解为每年的经营目标，由经营目标又拆解为每个部门的工作目标，而完成这些工作目标在每个部门内由不同的角色的人按既定的流程来实现。而有不少工作还常常是跨部门的协作。 注意：信息系统是服务于目标分解后的具体工作。但沉淀于系统中的数据，又反过来可以辅助目标的制定。 一般来说，大部分中小型企业都有自己的制度、流程。我们可以请需求单位先提供现行的业务流程。 为了便于理解，我放上两张图。 图1 一个从线索到交付的业务流程图 图2 ERP系统的各模块的数据流图 业务流程描述的对象是某一具体业务，而系统数据描述的对象是业务背后的数据流。 这里要特别提醒一点：业务流程是用于原本的线下实操，当它要放到线上，往往因为其中的部分活动无法线上化或者线上化时发现需要增加一些管控环节，所以常常需要对其进行一定的裁剪、优化。 从业务流程图到系统流程图，是一个从具体到抽象的过程。通过描述的对象的转化，系统流程图剥离掉具体业务，抽象出数据的流动、加工和存储。 以图1为例，从业务流程来看，分为经销商/直接用户、公海客户，如以图2的系统流程图来表示，可以用客户资料来统一表示。因为从数据的视角来看，经销商、公海客户都是客户。 你可以会疑问，为什么要这样做？我们把业务流程图直接1:1还原到系统上不香吗？ 接着说说这样做的目的。 要讲清楚目的，就需要先说说数据和信息的关系：数据是反映客观事物属性的记录，是信息的具体表现形式。数据经过加工处理之后，才成为信息，如下图： 信息系统是提取了具体业务背后有效的数据，加工成信息，并去掉了冗余的数据。这样的信息系统，数据才有利用的价值，系统效率也更高。 讲完抽象，我们接下来再看看抽象之后，我们又要如何一步步还原、满足原本的业务需求？ 二、用户在系统里干什么？ 我们可以借助用例图来展示用户希望系统能干什么？ 图3 一个电商系统的用例图 你如果认真观察会发现上图和图1的业务流程图有部分相似之处。 相似点：两者都有参与者和活动。 差异点：业务流程图主要描述的是一个业务从开始到结束的活动顺序，而用例图主要描述的是参与者要在系统做的某些事。 由此可以推测，管理层更关注业务流程图，而执行层更关注用例图。 不论是业务流程图还是用例图，它们的活动的粒度都是可以逐步分层的，可以先画整体，再画具体部分。 看到这里，你可能会有疑问：业务流程图和用例图有什么关系？ 徐锋在《有效需求分析》一书中，指出用例图就是从业务流程图推导出来。这个推导的过程是这样的：业务流程图如上面所说是线下一个个业务的完整活动流，在线上化的过程我们要识别哪些活动是系统可实现？然后再通过用例图表示各种角色未来要在系统做什么（系统需具备哪些功能）？ 注意：用例图在业务流程图的活动的基础上，增加了不同用例之间的关系，如下图4： 不论是借书还是还书用例都包含了需要先验证读者身份这个用例，而超期罚款是还书可能发生的扩展用例。 通过用例之间的关系，进一步厘清了未来系统开发过程中的功能关联性。这是原来的业务流程图所没有的。 三、系统应具备哪些功能和内容？ 前面说了业务流程，接下来我们要在业务流程的基础上，继续找出实体。 先解释下什么是实体？ 实体是在实际问题中客观存在的，并且可以相互区别的事物或者概念。可以具体到人、对象、概念、事件。我们这里说的实体是在概念数据模型阶段的高层描述（可以理解为在人的头脑中的一个名词概念，比如“员工”），可对应未来在物理数据模型阶段（指数据库设计）要存储到数据库的信息。