一系列的产品设计

编辑导语:作为产品经理，大家应该都经历过从业务需求推导产品需求的这个过程。那么，我们如何从业务需求中导出产品需求呢？笔者整理了相关流程，希望对你有所帮助。

注:产品设计属于产品工作的中间环节，前面还有策划等工作。这里的产品设计工作边界是指经过调查分析，如何从0到1设计产品功能，并能指导后续的开发工作。

今天的推文应该是产品设计的第一篇文章。先说如何从业务需求推导出产品需求。

让我们从产品设计流程的基本原则开始:

让我们来看看具体的设计过程，你会看到如何应用这些设计原则。

像往常一样，我们从日常的例子开始。

在企业工作，我们如何获取最常用的OA和ERP系统，以及用户看到的功能菜单和页面？

在淘宝上购物时，我们是如何获得首页、商品详情页、购物车页的？

在上面的两个例子中，使用的系统都属于信息系统的范畴(根据徐峰在《软件需求最佳实践》中对2B系统的分类，除了信息系统还有嵌入式系统)。根据信息工程的定义，信息系统是以处理信息流为目的，由人、数据、流程和界面组成的人机集成系统。这种制度也是人们最常接触到的制度。

这种系统有一个特点，就是把我们生产生活的流程和场景搬到系统里。仔细观察，你会发现上面提到的例子都离不开过程。所以，先把线下的业务流程梳理好，是我们走向线上的第一步。

一、从业务流程到系统流程

完成需求调研分析后的第一步，就是找出业务骨干。企业的内部运作是从公司的战略目标分解为年度经营目标，再分解为各部门的工作目标，这些工作目标的完成是由各部门不同角色的人按照既定的流程来完成的。而且很多工作往往是跨部门协作。

注:信息系统是目标分解后的具体工作。然而，存储在系统中的数据可以反过来帮助制定目标。

一般来说，大多数中小企业都有自己的制度和流程。我们可以要求需求方先提供当前的业务流程。

为了便于理解，我放了两张图。

图1从销售到交付的业务流程图

图2 ERP系统各模块的数据流图

业务流程描述的对象是具体的业务，而系统数据描述的对象是业务背后的数据流。

这里特别提醒一下:业务流程是用于原来的线下实践。当它上线后，经常会发现由于它的一些活动无法上线或无法上线而需要增加一些控制环节，所以经常需要对它进行裁剪和优化。

从业务流程图到系统流程图，是一个从具体到抽象的过程。通过对描述对象的转换，系统流程图剥离了具体的业务，抽象出数据的流动、处理和存储。

例如，图1从业务流程的角度可以分为经销商/直接用户和公海客户。如果用图2中的系统流程图来表示，它们可以统一用客户数据来表示。因为从数据上看，经销商和公海客户都是客户。

你可以问，为什么要这么做？我们1:1直接把业务流程图还原到系统里，是不是很甜？

然后说说这样做的目的。

为了明确目的，我们需要先说说数据和信息的关系:数据是反映客观事物属性的记录，是信息的具体表现形式。数据经过处理后，就变成了信息，如下图所示:

信息系统提取具体业务背后的有效数据，将其加工成信息，去除冗余数据。有了这样的信息系统，数据可以利用，系统效率更高。

抽象完了，我们再来看抽象。如何才能一步一步的恢复并满足原来的业务需求？

二、用户在系统里干什么？

我们可以使用用例图来展示用户希望系统做什么。

图3电子商务系统的用例图

如果你仔细观察，你会发现上图和图1中的业务流程图有一些相似之处。

相似之处:两者都有参与者和活动。

区别:业务流程图主要描述一个业务从开始到结束的活动顺序，而用例图主要描述参与者在系统中要做的一些事情。

可以推断，管理层更重视业务流程图，而高管更重视用例图。

无论是业务流程图还是用例图，都可以将它们的活动粒度逐层分层，先画整体，再画具体部分。

看到这里，你可能会想:业务流程图和用例图有什么关系？

在《有效需求分析》一书中，徐峰指出，用例图是从业务流程图衍生出来的。推导过程如下:业务流程图就是上面说的线下业务的完整活动流程。在联机过程中，我们需要确定哪些活动是系统可实现的？然后用用例图来展示未来系统中各种角色会做什么(系统应该有什么功能)？

注意:用例图根据业务流程图的活动添加了不同用例之间的关系，如下面的图4所示:

无论是借阅还是还书，都包含了先验证读者身份的用例，逾期罚款是还书时可能出现的扩展用例。

通过用例之间的关系，进一步明确了未来系统开发过程中的功能关联性。这是原来的业务流程图所没有的。

三、系统应具备哪些功能和内容？

谈了业务流程，我们将继续找出基于业务流程的实体。

先解释一下什么是实体？

实体是实际问题中客观存在的、可以相互区分的事物或概念。可以具体到人、物、概念、事件。这里说的实体是概念数据模型阶段的高层描述(可以理解为人们心目中的名词概念，比如“员工”)，可以对应未来物理数据模型阶段(指数据库设计)要存储在数据库中的信息。

关于找实体的方法，建议通过上面提到的业务流程图找实体。实体一般在过程中的每个活动的名词上。比如“下单”这个活动，这里的“订单”就是我们说的实体。

这些实体是存储在未来系统构造中的有用信息。

为了表达实体及其关系，我们可以使用ER图。我是从【人人都是产品经理】找到作者小狼分享的ER图的:

图5是买家订单ER图，下面是买家的属性。

通过这个ER图，我们可以看到下单的业务流程，这个流程涉及到五个实体:买家、商品、交易订单、子订单(比如不同商家破单)、支付信息。该图还显示了这些实体之间的关系。例如，一个买家可能有多个订单。最后还看到了每个实体的属性信息。

通过ER图，为后面的数据库设计提供了设计基础。

从ER图到数据库设计，是一个从高层到低层的设计过程。

四、用户与系统到底如何互动？

当初我们对信息系统的定义提到，信息系统是以处理信息流为目的的人机一体化系统。然后我们来看参与者和系统之间的信息交互。

这里我们将使用一个叫做序列图的工具。

图6学生在系统中查询成绩时与系统的信息流。

上图可以直观地反映学生的角色，以及不同物理对象之间的信息流(发送消息、接收消息、处理消息、返回消息)的顺序。

一般什么时候需要序列图？

根据我个人的经验，当两个系统需要接口时，用序列图来说明它们之间的信息传递顺序是一个很好的方法。

图7用户通过企业微信登录第三方系统时序图

从上图可以看出，信息在各个系统之间流动，各个系统传递和获取什么信息一目了然。

五、开发前的可视化呈现

前面的步骤都是为最终的系统原型设计做准备。如果不经过前面的分析环节，直接进行原型设计，很可能会做出一个臃肿、没有逻辑、没有系统的系统。

在这里，让我们把上面完成的分析工作串起来:

通过系统流程图，我们可以划分出这套系统应该由哪些大模块组成？通过用例图，我们可以分析出系统应该具备哪些功能？这些功能间有什么内在联系？通过ER图，我们可以分析出系统的功能背后的数据实体，可指导未来数据库要如何设计（功能页面大概有哪些信息？）通过时序图，我们可以解决跨系统的接口开发存在的责任不清的问题。信息流在各个系统应如何流转？

这时，当我们用它来进行原型设计时，真是手到擒来。卡卡，像老虎一样凶猛的操作。可以登陆一个功能页面。

图8电子商务网站主页的原型

我不知道。有没有发现，从业务需求到产品需求的整个过程中，我们并没有谈到类、方法等与开发直接相关的术语？

这是我最不想和我的产品经理同事说的话。UML是一种系统建模工具，独立于任何编程语言。

在《软件工程》一书中，详细介绍了UML。它不仅仅是一套工具，更是一种设计理念。

产品经理可以使用UML完成概念设计(理解为概要设计)，设计师可以通过UML完成解释性设计(对应于详细设计)，开发人员可以通过UML完成实现开发。

在过程中，我不提倡产品经理使用UML类图、对象图等与设计开发相关的工具图。一方面，如上所述，每个人都在做不同层次的工作；另一方面，你不知道工具的真正用途，只知其形不知其神，这会误导你的下游伙伴。

以上思路同样适用于最终的原型图(图中只使用了黑、白、灰)。一个产品经理没有美工基础，却要输出所谓的高保真原型，反而给下游的美工带来了很多麻烦(因为你想当然的用各种五颜六色的配色，其他美工不知道怎么收拾你的烂摊子)。

祝你在职业道路上一帆风顺。这已经是80%以上的人了。不要乱搞所谓的跨界，我们已经有足够的体量了，不要乱搞。

作者:追梦人，微信官方账号:豆芽启蒙

本文由@追梦人原创发布。每个人都是产品经理。未经许可，禁止复制。

来自Unsplash的图像，基于CC0协议。