B端产品规划

B端业务整体产品规划流程（来自决胜B端）
1.采用自顶向下的设计思路、从抽象到具体逐步展开工作，可分为业务问题诊断阶段、产品整体方案设计阶段、产品细节方案设计阶段，执行并优化解决方案。每阶段涉及到具体到不同的参与人员，如下图所示

2 业务调研
2.1 调研目的
一是梳理业务现状，二是总结业务问题
2.2 调研流程

2.2.1 明确调研目标
有了明确的调研目标，才能朝正确的方向开展，因此这一步很重要。切忌没有目的目标的开始。
2.2.2 选取调研对象
B端业务针对的企业或者组织，又是解决企业的经营问题。所以选择调研对象时一般需包括业务高管、业务经理或负责人、一线业务人员、合作伙伴等。
针对高管，可以了解业务战略定位、战略目标信息；针对业务经理或负责人，可以了解业务的管理思路、经营思路等信息；针对一线业务人员可以获取作业过程、操作过程等信息。
2.2.3 确定调研方法
包含深度访谈、轮岗实习、问卷调查等
2.2.4 执行调研计划
若前期的准备工作做得充足细致，在执行调研的过程中会比较顺利。也更容易掌控调研的节奏，能够把调研者的思路拉回来。
调研时需要有足够的耐心、专注和投入，调研结束后需及时整理素材和资料，以保证获取的信息能够及时、准确的记录下来。
2.2.5 总结归纳输出
调研结束后，需产出一份详细的调研报告，总结业务现状和问题，并确定各个问题的优先级，以便为后续的方案设计和实施提供决策支持。
2.3 业务分析框架
当面对一项业务时不知怎么下手，该如何切入。可参考如下业务分析框架

3 核心业务流程
B端产品经理在面对一项业务时，第一步不是原型设计，而是先梳理该业务的核心流程。
因为首先就进行原型设计，大部分人脑海中对总体业务流程是不清晰、混乱的、甚至有的连流程都还没搞懂。这样必然会造成不断返工的情况，给人一种不专业的感觉。且还浪费了时间，造成效率低下。
而从核心业务流程切入产品设计，是开展整个设计工作的非常好的起点。核心业务流程代表业务的主干脉络，需要思考业务的各个参与方、设计的系统或功能。
4 产品定位
是对产品概括性的陈述和总结，简明扼要地描述产品对业务的支持的范围或总体功能目标。最重要的是说清楚产品对谁提供什么支持。
案例：某公司打算做珠宝平台，希望用户能够实现在线下单购买珠宝首饰。
于是涉及到的产品包含：
商城APP（移动端、公众号、H5）：为用户提供在线下单功能
管理后台（PC端）：为客户提供在线下单购买珠宝的管理系统
5 应用架构设计
指公司所有产品和系统的整体结构和布局。在设计一套新系统时，必须考虑如何和公司现有系统架构融合，不同系统的模块之间如何衔接。以上诉案例为例，公司的架构如下：（来自决胜B端）

6 功能模块设计
明确了应用架构，以及需要新建或改造的系统之后，需要进一步细化，为每个系统设计功能模块。这个系统的应用于哪些业务场景？用户可能在系统中做哪些操作？从而设计出具体的功能模块。设计出的功能模块代表对业务本质诉求的理解和提炼，展现了对业务、系统未来的期望。
在进行功能模块设计时，先梳理出系统的一二级菜单结构，这是系统的骨架。然后在结合业务需求实现每一个具体功能，对骨架不断进行细化。这也体现出自顶而下的设计思路。
若功能设计模块层次混乱，以及后面的功能随意摆放。不仅会对用户造成使用困惑，同时也会导致开发人员编码设计的混乱。这也是造成系统扩展性差的原因之一。

7 演进蓝图设计
通过绘制系统的功能模块图，可以明确业务和系统的规划脉络。将能想到的功能模块都列出来，这是一个做加法的过程。但不可能一次实现全部功能，而要根据业务优先级，拆分成几期来实现，所以接下来是做减法。
8 数据建模
指对业务特点归纳并设计对应的底层数据模型的过程。常用ER图呈现业务数据建模的结果。数据建模涉及到数据库表结构的设计，而数据库表结构的设计又决定了系统的扩展性，最后决定了产品的可扩展性。所以建议先去学习软件开发技术或者一门编程语言，不要求精通，但明白软件工作的结构思维确实益处较大。
9 流程与角色
对各功能模块功能涉及到的功能进行绘制流程图，即涉及到哪些主体（角色），主体之间有哪些操作。
流程图主要涉及到的查看对象为业务人员及研发人员。为了便于大家理解，针对业务人员，可绘制“人人交互模式”的流程图，针对研发人员可绘制“人机交互模式”的流程图。对于人机交互模式的流程图，遵循以下两点原则：
原则一：一个页面定义一个操作
原则二：和后端服务器的交互定义为一个操作
绘制流程图主体思想：表达出做了什么，而不是关心所有的功能。
10 界面设计
即原型设计。重点在于表述清界面上的功能点，而非交互及UI效果。
11 数据埋点
主要用于对业务进行用户行为分析、产品分析、产品改善的重要参来源。一般接入第三方平台，如百度统计、Google Analytis、神策、诸葛IO。
工具使用方法，一般是将一小段唯一的JS代码片段注入应用中的一个公共JS文件（或公共的HTML代码片段），工作量较少，部署方便。如果需要更加精细地监控按钮点击等行为，则需要针对每一个交互事件插入更有针对性的代码片段。
12 权限管理
直接反映出产品经理对业务体系中岗位和流程理解的深度。合理及有前瞻性的权限设计不仅体现出对业务的理解，还反映出对整个行业的预测。这直接关系到数据库的设计。
软件权限包含两部分：
1、功能权限：即对各个角色可以操作的界面、按钮等，例如管理员可进行新增、删除、修改等操作，而运营人员只能进行查看数据、无法做修改。
2、数据权限：指各个角色在各页面中能看到的数据范围，例如总公司可以查看各分公司所有订单，而分公司只能查看本分公司的订单数据。
经典的权限管理模型为RBAC模型，即每个用户都要被赋予一个或多个系统角色，每个系统角色都对应一个明确的权限集合，包括对菜单、页面元素等资源的访问和操作权限。（可自行查看此模型）
13 文档编写
根据受众者、及公司实际情况进行编写。网上模板很多，思路都大同小异，可自行搜索。
14 技术方案
产品经理是否需要懂技术一直比较受争议，但懂技术的产品经理肯定是有好处的，能够更好的与开发人员沟通、能够一定程度上避免被开发人员忽悠；能够避免产品的过度设计；能够避免技术的过度设计；能够预测需求的可行性
当进入技术方案设计环节，产品经理是否需要关注技术方案，并参与技术讨论呢？一般情况下不需要，但出现下面两种情况，产品经理必须参与技术方案的探讨。
1、 产品方案和技术方案相互影响：有些技术选型问题会直接影响产品方案的设计，或者产品方案直接决定了技术方案，此时需要和技术负责人谈论清楚。
2、 技术方案可能导致项目风险。
15 项目管理与实施
项目管理主要作用在按照产品需求与设计方案保持项目按时、高质量的交互上线。
项目管理中肯定会遇到很多突发情况，此时事先应该做好相应的预防方案及现场及时解决。但项目过程中出现的大部分问题，在于工作拆分的不细致、不合理、模糊不清、界限不明导致延期。此时可采取如下措施。
1、 细化工作、明确交互。将工作细化拆解，并明确每一个细化事项的责任人、交付物、时间点、保证对每一个细节的掌控，也就保证了对项目的掌控。
2、 通过机制把控进度。
a) 开展定期会议：定期将项目的各方参与人员聚在一起，回顾上一次会议以来的进展、遇到的困难、下一次会议之前的计划。
b) 形成日报或周报：需要形成项目日报或周报，并发给项目的所有相关人员。除了通报进度、进展情况，项目日报或周报还有一个重要的作用，就是警示风险，让相关人员知晓，并推动责任负责人去解决问题。
3、 保持足够的责任心。
16 运营管理
不管公司是否有运营人员，产品经理都需要抽出时间参与运营工作，这样能够更好的了解业务、加深对业务的理解及对用户、市场、行业的认知。
经常性的查看运营数据，如果足够细致或之前有一定的数据基础，可以发现非表象问题。从而可以对业务进行更合理的设计。
17 迭代优化
先收集需求，然后判断需求，最后进行需求设计。
判断需求可遵循以下原则：
1、 需求背后真正的问题是什么？
2、 问题是否有简单快速的解法？
3、 问题的影响面有多大？如果只是个案，是否值得投入精力去研究？
4、 如果是共性问题，优先级和紧急程度如何？