编辑导语：产品一般都需要搭建强大的内部管理端，常常面临流程长，操作复杂，角色多，多个内部系统联动，与业务用户和开发难以用简短的沟通或者文字说明解释的清楚的问题。而这些内部产品的逻辑很难从竞品处获得参考。对产品经理的工作带来了很大的困难和挑战。面对困难产生的焦虑最好的办法就是“具体”。为了解决这一业务问题，决定要启动的情况下，这篇文章分享给大家怎么做。

做产品一定要明确需求目标和价值，如果仅仅是为了凑需求个数而做需求，还不如不做，宁愿停下来花时间去学习。产品目标就像团队仰望的星空里的北极星，指引大家前进。想清楚为什么做以及目标和价值是最重要的。

然后就是抽象、拆解、归纳业务问题，借助可视化的方法梳理逻辑，定义对象、场景、角色、操作、流程、状态，消息。就像建筑师设计楼房一样，规划用地目的、功能区、钢筋结构、水电走向，这样从0到1形成的产品文档才可解释性强，易于理解。

按照确定目标和价值，抽象问题（定义解决问题的对象），拆解问题（梳理业务及产品流程），归纳问题（将类似模块合成服务），形成需求文档，过程中使用UML的可视化图来可视化逻辑。

基本上以上做到了，产品文档在业务用户和开发同学的视角中就是逻辑清晰，评价优秀的了。产品落地实现，业务发展重构，或新入职同事了解学习，都是宝贵资料。

一、确定目标价值

我们在制定目标前，先思考清楚现有背景下，公司部门的愿景，自身的优劣势，立足的核心差异点，给用户带来的核心价值是什么。价值就是业务的核心诉求，是产品的商业模式决定的。核心的价值可以向：增加“收益”，降低”成本“，防范”风险” 三大方向去思考。最后，在考虑资源的基础上制定以可量化的目标指标去衡量落地效果。

确定好目标之后，分析跟理想的目标状态的差距在哪里，梳理出问题点。再将现实业务问题，转化在系统中解决问题。从0到1解决问题，我们要用到常用的思维：抽象、拆解、归纳。借助UML可视化建模图形会更好的协助产品经理自己理清思路，同时也能直观明确的用图形和文字来传递信息给开发和用户。

UML是一种面向对象的，定义良好、易于表达、功能强大的建模语言。合理、有效地利用几种模型进行思考&设计，能够极大地提高产品工作和沟通效率。

二、抽象

1. 抽象属性及操作+类图

面向对象是对现实世界的理解和高度抽象的方法，能够高效地将现实世界抽象化成简单的模型。把对象按照类型进行抽象，形成一个具有共同属性集合，就是类。

重点提炼：解决问题的类名、属性、操作。

类名：即解决问题主体的名称；

属性：即该类的共同度量属性，每个对象用属性的值描述其特点；

操作：即为类的一个行为或者发生变化的过程。

举例，流量服务平台管理端，需要对每个流量主的每个资源位置按照商务约定规则来计费结算，以实现流量主的流量变现。存在以下几个问题：

• 流量主多：每天的有亿级别的流量的进入，需要给成百上千的流量主计算流量收益
• 单价各异：流量的价格标准，根据平台运营目标，经常变动。即同样流量在不同标准下收益不同
• 审批验收：一旦人工调价，需要提交给老板申请费用审核，才能支付给流量主
• 严谨对账：为了保证对账严谨性，需要能记录每次价格的变动

抽象出”结算计费规则“类，来记录、计算、变更收益。以不变应万变。

策划出类，系统中就可以很便捷的落地对象的”新建“，”列表“场景。

三、拆解

1. 拆解事件状态+状态图

类模型仅能表示系统各部分/模块的静态关系，通过状态模型，可以描述一个实体基于事件反应的动态行为。状态模型描述相应外部发生的操作序列，但是不描述操作做了什么，对什么操作，或者如何实现。状态之间通过事件连接起来就成了状态图。

状态：对象的某个条件或状况。所有对象都具有状态，当某个事件发生后，对象的状态发生变化；

事件：对对象的一个时间和空间上的操作，事件触发状态的转移。

举例：流量服务平台通过让流量主创建资源位置，来接入流量。考虑审核和灵活开关设计了多方可操作的状态。

初期需审核：初期需要通过审核才可上线，保证流量接入正常。

多角色参与：需要流量主，审核人，开发等多角色协作操作，同步进度。

灵活开停：流量主接入测试，需要经常开关来控制流量是否接入。同时，运营测发现问题资源位需要及时关停来控制成本。

拆解出状态图，系统中就可以明晰的同步用户对象的状态和操作。

2. 拆解顺序流程+时序图

状态模型能表示状态的转移，但是不能表示有一定次序的操作和状态变化，这时，就需要用时序图来实现角色、对象之间有顺序的流程。构成时序图主要有几个要素：对象、激活、消息、生命线。

生命线：一个对象的底部都绘制了一条垂直虚线，当一个对象向另一个对象发送消息时，此消息开始于发送对象底部的生命线，终止于接收对象底部的生命线。

激活：是时序图中的对象执行一项操作的时期，将对象的生命线拓宽成矩形，表示对象是激活的。

拆解出时序图，实际是对产品服务的业务流程完整的梳理。是一个非常”大局观“的规划。

举例：内容平台的内容变现板块派单模式的流程图，因为涉及资金支付，实现上有多个部门合作，流程长，完善的时序图向开发和用户展示了在产品流程中是如何协作完成一次需求的下达，接收，验收，审批，支付。

3. 拆解场景流转+全景图（自创）

状态模型能表示状态的转移，但是不能表示有一定次序的操作和状态变化，时序图来实现角色、对象之间有顺序的流程,但无法反馈用户操作状态。是否有一种图，能反馈用户角色的操作，及带来的状态反馈？

全景图是笔者在遇到如上问题自创的一种图形，展示了用户对象对一个类的全生命周期操作，从一个场景是如何转化到另外一个场景，特别适合复杂的多角色操作。

拆解出全景图，系统即可以实现权责分明的权限和全流程操作管理。

举例：内容平台的的内容变现板块-派单模式的全景图

四、归纳

1. 归纳统一服务+协作图

当我们的业务逐步发展，要思考将统一的模块整合成规范化服务，避免重复性建设。可复用性的服务建设可以支持产品实现快速的多模式裂变。可用协作图来表现这种复用服务与对接模块的关系，UML中的协作图包括3方面的内容：对象、链、消息，展示了发送和接收消息的各对象结构上的组织。

举例：内容平台的内容变现板块的通用结算模块协作图，统一结算模块经过搭建完成后可以快捷安全的接入多种内容激励模式，年支付金额也达到上亿规模。

五、需求文档的核心模块

• 需求价值/背景
• 需求目标
• 需求内容：需要充分说明：业务流程，属性，角色，操作，状态，转移，权限，指标说明等。辅助UML图例。
• 优先级
• 期望完成时间
• 迭代版本

六、感悟心得

笔者从入职腾讯以来，一直在流量生态部流量产品中心，虽然部门名称有变化，也陆续做过广告平台，内容平台，增长数据平台，但从一入职部门的目标就没有变过：一切以解决问题为目标。的确，产品经理既需要仰望星空，规划制定产品的北极星目标；又要脚踏实地，与团队合作一砖一瓦地拆解问题、解决问题。

本文是作者在做偏平台b端产品的过程中的思考和经验分享，篇幅有限，很多内容这一篇文章无法详细展开，欢迎小伙伴们再@我一起交流学习。

最后，希望我们做的产品能让用户称道，我们撰写的产品文档的每一笔每一划都令人怀念！

作者：izziezhang，腾讯IEG产品策划；公众号：腾讯大讲堂

本文由 @腾讯大讲堂 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议