怎样将一个之前未接触过的新业务，转化为研发可以具体开发的详细产品方案呢？本文作者对此进行了分析，一起来看一下吧。

一、构建业务模型

怎么样将一个idea，商业模式拆解为业务模型，这个在之前的文章中已经有详细的说明，可以点击看相关文章：

团队管理2——业务模型拆解（上）

团队管理2——业务模型拆解（下）

总体思路是：

1）有一个ideal之后，运用商业运作模型（商业画布，商业模式运作图，价值链分析）、业务运作模型、财务运作模型能够将以一个项目的各方面做一个整体的评估；

2）我们进一步运用业务模型的拆解方法，可以拆分出这个事情的核心业务及支撑系统，明白这个事情是如何运作的，关键节点是哪些，并据此搭建一个整体性的产品概览。

但这个产品框架是一个比较粗略的方案，比如之前其它文章画的同城配送系统的产品整体概览（已经做过这个系统，然后来写这篇文章，带有天然的理解在里面）。

那怎样将一个之前未接触过的新业务转化为研发可以具体开发的详细产品方案呢，这其实不是一件简单的事情，特别是针对复杂系统，平台类产品的时候。

本文不涉及战略层面的东西，这部分在之前的业务模型拆解中有涉及一部分，另外怎么样去找到一个好的需求点，并评估是否可行也不涉及。

我们将文章限定范围为：产品方向已经确定，业务模式等已确定，我们只需要把这个业务调研清楚，做产品拆解。这样将让我们的精力集中于业务向产品详细方案的转化，业务方向一定要确定，然后才去启动正式的产品详细方案设计工作，要不然产品方案会无止境地变化，无谓地增加各种成本和打击团队的士气。

二、业务转化为产品的难点

业务是依托于用户存在的，这个用户可能是购买商品的客户，也可能是公司内部的管理运营人员。

业务就是由用户发起并执行后有一个结果的活动，这个活动可能是由系统执行，可能由其他人完成，也可能人与系统配合完成。

互联网和信息技术出现之前，业务基本都是在线下进行，现在越来越多业务实现线上化，有些业务整体都是线上（比如抖音、微信、资讯），O2O业务，传统行业，制造业等行业还有很多业务是在线下。

无论是怎样的业务，我们大多以用户为中心进行设计产品，产品在满足用户需求同时，还要让用户在使用过程中感到足够方便和舒适。但另一个方面，满足用户的需求不仅仅只是跟用户打交道，还面临着其他一切为满足用户需求而提供服务的人员和企业，对于这些衍生需求，也是需要满足。

这项工作面临着很多挑战：

1）没考虑到非用户接触的内部业务产品设计：以用户为中心的设计，从用户角度出发的，目标是要让用户的体验好，但可能忽略一些基础支撑性的业务如何设计。

2）没考虑业务流程设计：一项业务需要设计流程。比如，一个订单需要设计用户下单、确认发货、物流送货和用户签收等流程。但以用户为中心的设计，对流程强调得并不多，更多地强调了页面设计和简单的交互设计。

3）遗漏大量逻辑：当系统复杂度很大的时候，只使用流程进行考虑将会很复杂，这将导致会遗漏很多逻辑，特别是多系统之间的交互。

4）缺乏系统性：平台类型的业务产品设计，需要考虑到各系统之间的交互，比如平台类型的订单，会涉及用户、商户、平台，一笔订单中由包含商品、优惠、快递、支付、退款等。很容易对系统考虑不全，导致架构存在问题。

5）未考虑系统的延展性：只关注当时当下的问题，没有考虑到业务发展之后，产品需要怎么来支持，使得产品系统随着业务发展而需要不断的重构。

6）如果有多人协作同一个系统，很容易由于各自的设计思路不一致，绘制原型标准不一致而造成各自闭门造车而最终组装不上的问题。

那需要怎么来应对这些问题呢：

1）梳理流程的时候，采取端到端的方法——也即是从一个活动的开始直到最终结果的整个过程，形成闭环，可以跨越多端（用户端、商家端、平台管理端）、多部门、多操作者，打破产品系统的隔阂和封闭。

2）采用统一的语言体系和标准（如UML，各端口原型及设计标准统一），保证各方的底层设计逻辑、标准、语言统一，这样设计出的东西才统一。

3）从面向过程的设计转为面向对象的设计，应对复杂性、平台型项目设计，更系统全面的考虑问题，就需要把UML，DDD思想运用到从业务到产品设计的过程中，让整个的过程更系统丝滑，实现面向对象，模块化、模型化的产品设计。

三、以业务为中心的设计

1. 整体思路

下图为用户体验要素的5层框架结构：

1. 战略层——确定商业目标，产品目标，用户群体，怎么赚钱等
2. 范围层——为产品功能划定范围，做哪些功能
3. 结构层——思考产品怎么做，包括怎么跟用户交互，怎么组织内容（信息架构）
4. 框架层——思考产品怎么设计，界面设计，导航设计，信息设计
5. 表现层——风格统一，色彩搭配，排版，利用用户的视觉，听觉，触觉，味觉来刺激用户

普通产品经理做得就是范围层，结构层，框架层的东西，表现层一般是UI设计师来。

范围层对应搭产品的框架（功能框架、非功能框架）；

结构层对应做细节（业务流程、业务操作、信息结构）；

框架层对应画界面（交互设计及更详细的信息设计，信息设计来源于信息结构），可以表示为如下图所示：

2. 产品常用的UML图

我们学习的英语、汉语可以被称为语言，这个是显而易见的。我们学习的各种数学符号，也是一种语言，叫数学语言。

怎么理解数学符号也是一种语言呢？比如，我们可以用汉语说“一加一等于二”，但是在实际做计算的时候，我们还是习惯用“1+1=2”来表达。

两者的意思是相同的，但用数字表达更高效、更简洁。

统一建模语言也是语言，该语言可以代替我们的文字描述来表达一项业务，可以对业务进行抽象建模。

建模是对事物的一种抽象表述，其目的是简化现实。也就是将纷繁复杂的业务，进行抽象，让业务更清晰，系统的进行呈现，便于理解。通过建模的方式，我们进一步将业务转化为产品方案。

语言都有语法（使用规则），如英语、汉语等都有语法。数学符号也有语法，如规定加、减、乘、除和括号的用法。UML既然也是语言，那么就有相应的语法，如规定流程图的开始和结束怎么画、判断条件怎么画等。

在所有的UML图中，产品经理需要掌握的是用例图、流程图、状态图、类图这四种图。

挑选一个适合的绘制UML图的工具，将有助于提高工作效率，并展现出专业度。

Microsoft Visio、ProcessOn、亿图图示等软件都能绘制UML图。使用Axure RP软件既能绘制原型图，又能绘制UML图，不用再将UML图进行转移。用Axure RP软件绘制UML图能节省时间，建议使用该软件绘制UML图。

下一篇将介绍具体怎样将业务转化为产品的做法。