编辑导语：对于2B产品经理来说，产品设计架构是很重要的一项工作内容，也是要具备的能力之一。紧接上文，今天本文作者为我们进行了模块详细设计的分析，并且总结了设计后项目管理应该如何运用，以及在设计架构之后作者的一些思考。
咱们紧接着上篇文章继续，从我们第二部分第8点开始，读到这篇文章的小伙伴，如果感兴趣可以结合上篇文章《2B产品设计：2B产品经理做的那些2B事（一）》，这样就会有完整的认识。
8.产品规划
产品规划其实是一件相对复杂的过程，从宏观的方面来说，包含着我们我们第一部分的所有内容，还有产品的计划、愿景等，涉及到整个产品生命周期。
但是，咱们这里从微观的范围来说明。
首先要和产品的工作计划区分开，这里并不是来简单罗列产品的后续工作计划，工作计划的制定应该是产品设计一开始就完成的。这里主要是写产品功能模块规划，或者说是功能组件分期。
我们需要根据上面的核心业务流程、资金流程等初步规划产品所需要具备的功能模块，然后对主体功能模块的实现进行优先级分类、关联关系说明。
经验总结，建议：
先发散思维，尽可能多的梳理所需要的功能模块及功能，再做减法，筛选出符合产品定位的功能模块。系统的功能模型应该是一个立体的模型，纵向是一个分层架构，如前台、后台方式分，也可以是XX角色端进行划分。横向是一个个独立的业务模块，里面包含着核心功能或页面。随着产品设计的推进，后续的需求文档和和原型设计都会对此处进行调整。所以这里是一个主体、浓缩型的模型，主要用来说明清楚各模块的关系。产品规划是产品定位和功能模块分解的连接器，它既是产品定位的具体表现，也是功能模块分解的雏形，也是后续产品设计的基本指引，所以这块相对比较重要。关系到后续产品详细设计时的方向。
9.功能模块分解
功能模块的分解将根据产品规划中的功能模块进行详细的拆分，并且需要写出功能详细描述，解释功能是用来做什么的。结合项目管理来看，这里就是创建WBS的过程。
常见的实现的方式可以采用Excel和思维导图，在做这部分的功能时，老文采用的是Excel方式，但是部门中其他的小伙伴有采用思维导图的。关键是要描绘清楚每一个功能的结构。
1）功能模块分解Excel表头：
管理系统：当前业务角色端的描述，如商城系统：买家端、卖家端、平台后台等。功能模块：左边或者上方的一级导航菜单。子功能：左边或上方的二级导航菜单。功能说明：子功能包含的大致功能描述，如查询商品详情，查看详情等。责任人：初步对功能模块进行分工，也可以后续进行安排。2）功能模块分解的意义：
明确了产品架构，提供了一个产品的全貌，明确了产品每个角色端的骨架以及业务场景中每个角色在系统中的基础操作。功能模块、子功能，能够体现系统的一二级导航菜单结构，通过功能说明，能够初步明确功能的描述，给后续详细需求文档的编写提供一个更立体、丰富的框架。功能模块的分解可以避免产品设计时模块结构层次混乱的问题，如果不提前提炼，有可能导致后续功能设计时菜单混乱，给用户造成使用困惑。在大型产品设计时，可能是多个产品经理进行协同，功能模块分解明确了各角色端的功能范围，所以便于后续详细文档编写分配任务，也可更好的划分各功能的职责。能够提供给项目组（研发）评估项目研发时间的基础，这样在产品产品设计的初期就有一个基础的相对合理的时间概念，至少我们能够粗略的知道研发所需要的工作。功能模块分解的用途还有很多，但是不同的产品和项目研发习惯不同可能导致的用处不一，但是B端的产品设计强烈建议编写此块内容。同时，也会减少很多拍脑袋的情况出现。
10.核心功能数据建模
从第10点开始，就是产品的详细设计了，如果开始这块的工作，就证明公司已经明确研发此产品。不然后续的文档编写就没有意义了。
核心功能数据建模这个在B端产品设计显得非常有必要，但是需要产品经理有一定的研发思维，最好是有后台开发的经验。因为数据建模是对业务抽象的过程，需要将各业务角色的关系抽象出来，更详细的设计将会和数据库有关系。
B端产品设计时，大家有没有过困惑，明明我的原型已经设计的很好了，详细的需求文档各规则也描述清楚了。
但是，研发小可爱还是觉得看不明白，关系之间依旧不清晰，很有可能是数据建模的工作缺失，或者说文档描述时本身也没有描绘清楚。
老文在做项目经理的时候经常干这个事情，当时产品经理很少做这个工作，但是现在对产品经理的要求已经越来越高了。特别是在某些行业的产品设计时，基本是产品经理的必备素质，如支付系统等底层系统的设计。
常见的实现方式有：ER图、Visio、UML类图等，只要能够描绘清楚对象之间的关系即可，不限于使用什么形式。数据建模的范围取决于产品设计拥有的时间，如果没有很多时间，但是至少需要做核心功能的数据建模。
数据建模的意义：
将客观世界的业务抽象为系统设计时对象与对象之间的关系，通过图形的形式表达，会让沟通变得更加简单，特别是和研发小可爱们的沟通。数据建模是数据库设计的前置工作，直接影响数据库表结构的设计以及表之间的关系，体现了设计者对业务本质的理解和认知。B端产品注重业务流程的完整性，状态闭环，业务逻辑清晰，数据建模就能够帮助我们做到这点，有时候我们把更多的精力放到了功能设计，页面交互，这点往往我们很容易忽略。产品经理自己做数据建模能够更好的把握产品的底层逻辑，也掌握了研发过程中的主动权，更好的实现自己设计的产品功能，减少被研发小可爱忽悠的可能。提高研发小可爱对业务的理解，并且减少后续一些不必要的沟通，提供研发效率，降低开发复杂度。不然后续研发过程中还是会询问你：这两个对象是什么关系？1对1？多对多？数据建模体现了产品经理对业务的抽象描述能力，也能够提高研发小可爱对你的能力认可度，如何将一个现实的业务场景抽象为一个个数据模型，也是区别一个产品经理设计能力的重要因素。
11.详细业务流程图
咱们在第04点已经做了“核心业务流程”，为啥此处还需要做详细的业务流程呢？
这体现了产品设计自上而下循序渐进的原则。不同的设计阶段面对的干系人不同，所以表现的形式也不一样。核心业务流程描绘了产品的整体形象，详细业务流程用来细化产品的业务流程。
那详细业务流程是否是越细越好呢？
答案是否定的。在做这块内容时，需要考虑业务稳定性、研发能力、研发习惯、设计时间等因素。不要盲目的扎进去就是干，这样反而会给研发造成架构上的负担。
节奏的把握、表现的形式需要和项目团队磨合，详细的业务流程面对的对象基本就是研发小可爱和测试人员，外部需求方更多的还是
