编辑导语：对于2B产品经理来说，产品设计架构是很重要的一项工作内容，也是要具备的能力之一。紧接上文，今天本文作者为我们进行了模块详细设计的分析，并且总结了设计后项目管理应该如何运用，以及在设计架构之后作者的一些思考。

咱们紧接着上篇文章继续，从我们第二部分第8点开始，读到这篇文章的小伙伴，如果感兴趣可以结合上篇文章《2B产品设计：2B产品经理做的那些2B事（一）》，这样就会有完整的认识。

8. 产品规划

产品规划其实是一件相对复杂的过程，从宏观的方面来说，包含着我们我们第一部分的所有内容，还有产品的计划、愿景等，涉及到整个产品生命周期。

但是，咱们这里从微观的范围来说明。

首先要和产品的工作计划区分开，这里并不是来简单罗列产品的后续工作计划，工作计划的制定应该是产品设计一开始就完成的。这里主要是写产品功能模块规划，或者说是功能组件分期。

我们需要根据上面的核心业务流程、资金流程等初步规划产品所需要具备的功能模块，然后对主体功能模块的实现进行优先级分类、关联关系说明。

经验总结，建议：

1. 先发散思维，尽可能多的梳理所需要的功能模块及功能，再做减法，筛选出符合产品定位的功能模块。
2. 系统的功能模型应该是一个立体的模型，纵向是一个分层架构，如前台、后台方式分，也可以是XX角色端进行划分。横向是一个个独立的业务模块，里面包含着核心功能或页面。
3. 随着产品设计的推进，后续的需求文档和和原型设计都会对此处进行调整。所以这里是一个主体、浓缩型的模型，主要用来说明清楚各模块的关系。
4. 产品规划是产品定位和功能模块分解的连接器，它既是产品定位的具体表现，也是功能模块分解的雏形，也是后续产品设计的基本指引，所以这块相对比较重要。关系到后续产品详细设计时的方向。

9. 功能模块分解

功能模块的分解将根据产品规划中的功能模块进行详细的拆分，并且需要写出功能详细描述，解释功能是用来做什么的。结合项目管理来看，这里就是创建WBS的过程。

常见的实现的方式可以采用Excel和思维导图，在做这部分的功能时，老文采用的是Excel方式，但是部门中其他的小伙伴有采用思维导图的。关键是要描绘清楚每一个功能的结构。

1）功能模块分解Excel表头：

• 管理系统：当前业务角色端的描述，如商城系统：买家端、卖家端、平台后台等。
• 功能模块：左边或者上方的一级导航菜单。
• 子功能：左边或上方的二级导航菜单。
• 功能说明：子功能包含的大致功能描述，如查询商品详情，查看详情等。
• 责任人：初步对功能模块进行分工，也可以后续进行安排。

2）功能模块分解的意义：

1. 明确了产品架构，提供了一个产品的全貌，明确了产品每个角色端的骨架以及业务场景中每个角色在系统中的基础操作。
2. 功能模块、子功能，能够体现系统的一二级导航菜单结构，通过功能说明，能够初步明确功能的描述，给后续详细需求文档的编写提供一个更立体、丰富的框架。
3. 功能模块的分解可以避免产品设计时模块结构层次混乱的问题，如果不提前提炼，有可能导致后续功能设计时菜单混乱，给用户造成使用困惑。
4. 在大型产品设计时，可能是多个产品经理进行协同，功能模块分解明确了各角色端的功能范围，所以便于后续详细文档编写分配任务，也可更好的划分各功能的职责。
5. 能够提供给项目组（研发）评估项目研发时间的基础，这样在产品产品设计的初期就有一个基础的相对合理的时间概念，至少我们能够粗略的知道研发所需要的工作。
6. 功能模块分解的用途还有很多，但是不同的产品和项目研发习惯不同可能导致的用处不一，但是B端的产品设计强烈建议编写此块内容。同时，也会减少很多拍脑袋的情况出现。

10. 核心功能数据建模

从第10点开始，就是产品的详细设计了，如果开始这块的工作，就证明公司已经明确研发此产品。不然后续的文档编写就没有意义了。

核心功能数据建模这个在B端产品设计显得非常有必要，但是需要产品经理有一定的研发思维，最好是有后台开发的经验。因为数据建模是对业务抽象的过程，需要将各业务角色的关系抽象出来，更详细的设计将会和数据库有关系。

B端产品设计时，大家有没有过困惑，明明我的原型已经设计的很好了，详细的需求文档各规则也描述清楚了。

但是，研发小可爱还是觉得看不明白，关系之间依旧不清晰，很有可能是数据建模的工作缺失，或者说文档描述时本身也没有描绘清楚。

老文在做项目经理的时候经常干这个事情，当时产品经理很少做这个工作，但是现在对产品经理的要求已经越来越高了。特别是在某些行业的产品设计时，基本是产品经理的必备素质，如支付系统等底层系统的设计。

常见的实现方式有：ER图、Visio、UML类图等，只要能够描绘清楚对象之间的关系即可，不限于使用什么形式。数据建模的范围取决于产品设计拥有的时间，如果没有很多时间，但是至少需要做核心功能的数据建模。

数据建模的意义：

1. 将客观世界的业务抽象为系统设计时对象与对象之间的关系，通过图形的形式表达，会让沟通变得更加简单，特别是和研发小可爱们的沟通。
2. 数据建模是数据库设计的前置工作，直接影响数据库表结构的设计以及表之间的关系，体现了设计者对业务本质的理解和认知。
3. B端产品注重业务流程的完整性，状态闭环，业务逻辑清晰，数据建模就能够帮助我们做到这点，有时候我们把更多的精力放到了功能设计，页面交互，这点往往我们很容易忽略。
4. 产品经理自己做数据建模能够更好的把握产品的底层逻辑，也掌握了研发过程中的主动权，更好的实现自己设计的产品功能，减少被研发小可爱忽悠的可能。
5. 提高研发小可爱对业务的理解，并且减少后续一些不必要的沟通，提供研发效率，降低开发复杂度。不然后续研发过程中还是会询问你：这两个对象是什么关系？1对1？多对多？
6. 数据建模体现了产品经理对业务的抽象描述能力，也能够提高研发小可爱对你的能力认可度，如何将一个现实的业务场景抽象为一个个数据模型，也是区别一个产品经理设计能力的重要因素。

11. 详细业务流程图

咱们在第04点已经做了“核心业务流程”，为啥此处还需要做详细的业务流程呢？

这体现了产品设计自上而下循序渐进的原则。不同的设计阶段面对的干系人不同，所以表现的形式也不一样。核心业务流程描绘了产品的整体形象，详细业务流程用来细化产品的业务流程。

那详细业务流程是否是越细越好呢？

答案是否定的。在做这块内容时，需要考虑业务稳定性、研发能力、研发习惯、设计时间等因素。不要盲目的扎进去就是干，这样反而会给研发造成架构上的负担。

节奏的把握、表现的形式需要和项目团队磨合，详细的业务流程面对的对象基本就是研发小可爱和测试人员，外部需求方更多的还是关注整体的业务流程。

12. 原型设计和需求文档

关于原型的设计和需求文档设计，这两种能力属于产品经理最基本素质，属于我们在产品详细设计中最后的一环。

关于怎么写？如何写？很多前辈已经做了非常多的总结。老文在此想分享的是，如何在团队中管理好这两个东西，并且提高团队的工作效率。

• 首先：咱们需要制定框架性的需求文档模板（产品类、功能类）、原型组件，制定此事情的时候一定要把握火候，因为产品岗位是一个具有创造性的工作，不能限制的太死板，反而限制了成员的发挥。
• 其次：制定模板之前也需要经过调研，而不是网上寻找的模板，每个公司都会有自己的业务场景和文化。需要从产品团队内部、研发团队、需求方等地方收集得知他们觉得目前产品团队谁的需求文档可读性更好，然后由此人来制定最合适。
• 最后：做好文档的管理及备份，形成组织文化资产。

经验得知一个完整的产品设计需要具备以上要素，但是咱们还是需要根据具体的产品来选择，并不是所有的点都需要写，应该根据产品类型、产品大小、重要程度、写PPT时间等因素进行组合。

以上提供一种B端产品设计时PPT编写的思路，希望与你有所共鸣。

三、设计后：项目管理的运用

设计不仅仅指的是外观和感觉，它还包括运作方式。—— 史蒂夫·乔布斯

在咱们完成产品的设计工作后，接下来将要进入研发阶段，进入研发阶段，产品经理的工作并未结束，我们需要组织协调资源将设计的产品按照要求实现出来。

虽然不需要我们进行编码的工作，但是项目管理工作显得尤为重要，不管公司是否已经有项目经理。产品经理都需要具备这项技能，我们不仅仅需要有改变世界的梦想，还需要有将梦想实现的方案和能力。

关于项目管理，当属于PMP为最经典，还是建议产品经理需要去了解其中的知识体系，下面介绍几个常见且重要的场景：

1. 参与技术方案讨论

技术方案这个节点，产品经理一定需要一起参与，不管研发实现采用什么编程语言。技术方案、架构设计都是软件设计极其重要的一环。

一个产品最开始实施研发时，架构的设计会影响产品后续的可扩展性。在产品的设计中也说明过产品业务模型的抽象，架构设计是将产品设计进一步的抽象，将复杂的业务概念简单化的过程。

举个简单的例子，假设咱们的需求是：我需要一部智能手机。产品经理还需要说清楚手机的颜色、材质、大小、底层系统。

产品经理不仅仅是关注本身的需求，更需要关注实现的业务逻辑、数据、状态、部署方式等事宜。这不仅仅体现自身的专业性，更能够提升沟通和开发的效率。

回归到产品设计上，我们一开始的设计是SaaS模式还是多系统部署模式？状态机如何设计的？是否需要工作流？等等一系列的问题。

如果咱们不去参与到技术方案的设计中来，有可能会导致产品的最终呈现不符合设计要求。只有自己理解了技术方案，我们才能够在研发过程中更好的把握产品的方向。

2. 项目管理工具选择

说起项目管理这件事情，我在做项目经理的时候，说过最多的词就是：拍马屁、真诚、不择手段、以终为始。我们需要掌握拍马屁的精髓和能力，嘴要甜、心要真，协调所有的资源“不择手段”的完成项目。

除此之外，还应该明确知道此项目最终的目标是什么，以终为始倒推出将如何实现它。

项目管理不仅仅是编写一个计划，制定好里程碑即可，实施的过程才是一个磨人的经历。其中采用什么方式进行项目管理也很重要，选择对了工具也会达到事半功倍的效果。

目前市面上已经出现了很多项目管理的工具，如Teambition、Worktile、禅道等，但是这些工具不一定适合你，也许使用Excel、Project更有效。

一旦选择好，需要坚决去执行，不然选择什么工具都效果都不会太好。

以上所说的工具老文都使用过，我觉得一个中小型团队好的方式是：Excel+禅道+白板。并不是成熟的工具不好用，而是适用性的问题，工具的学习成本和维护成本相对比较高。

Excel做计划、禅道管理研发和测试进度、白板用来做看板（故事板）。简单有效，目前不管是钉钉还是企业QQ都已经支持文档多人协同，使得计划的更新更加便利。

总之，不管采用什么形式去实现，执行力一定要够，关键在于灵活应用需求管理的方法。

3. 关键一环：测试用例

测试这一块，研发启动之前容易被产品经理忽略，一些极端情况，可能已经到测试阶段的后期了，产品经理和测试负责人的交流都不多，我认为测试在产品的设计后期是非常重要的一环。

我相信大部分公司的流程也是在产品经理进行需求评审后，测试工程师开始编写测试用例。如果没有及时安排测试工程师跟进的话，作为这个产品的负责人应该积极主动的去协调资源。

老文都是在产品设计阶段就提前和领导或测试部负责人沟通，提前预定资源。

除了资源的协调之外，及时关注测试用例的编写以及质量也是产品经理在项目管理中关键的一环。因为测试用例一定程度上映射出产品的设计思路，反映出测试工程师对产品的理解。

不仅仅可以通过测试用例检验产品的设计，特别是核心流程的测试用例。还可以及时与测试工程师保持统一沟通，保障研发输出的质量。

测试用例的review，在很多产品经理的工作中容易被忽略，老文以前也不是很重视这块，直到在设计完某个产品时，及时关注了这块，才发现自己的产品设计还有很多的需要提高。

因为测试工程师编写测试用例的时候，某些功能还是会出现理解上的不清晰。也就是这次的关注，最终产品上线后输出的功能质量、页面交互比之前的有明显的提高，系统上线之后BUG率有明显的下降。

四、蓦然回首：一些思考

1. 积极主动去做产品版本迭代规划
2. 为什么上线后总被吐槽？
3. 紧紧抓住种子用户
4. 参与市场和运营工作

产品上线后，产品设计方面的工作算是告一段落了，接下来我们需要及时并合理的安排下一阶段的工作，这需要产品经理控制版本迭代规划的节奏。

咱们应该做团队的发动机，而不是被动的去接受安排。

一个完美的产品，除了灵感之外，还需要不断地去打磨，版本迭代规划就是这个打磨的过程。版本迭代的规划一定要自己来做，不要任由项目经理或研发负责人去发挥，不然产品将走向一个根本不可控制的方向。

产品上线之后，将会面临着很多问题，有系统本身不成熟的问题，也会有各干系人（客户、运营等）的困惑和吐槽。研发的问题其实并不复杂，及时沟通解决即可。

老文刚刚开始带团队的时候，每次上线一个新的功能都会面临着市场和运营人员的吐槽。

当时我非常困惑，着实产品小伙伴们也在用心的在设计产品，出来的质量也还不错，为啥就得不到大家的认可呢？

核心的原因有两个：

1. 第一：产品设计阶段他们的参与度不够，没有得到重视；
2. 第二：产品上线后，给他们的支持不够。

面对客户时，我们是否编写了简单易理解的用户手册？面对运营时，系统是否提供了运营功能？是否提供了简要的运营手册？这些都是B端产品经理需要去思考的问题。

B端产品的第一个客户，作为产品经理一定要积极参与，产品的各个流程，收集用户的反馈，及时解决用户的问题和疑惑。我们需要主动的走向一线市场，参与地推人员的工作。

这样可以收集到一手信息，B端产品的客户很多来源于老带旧，在一个行业中口口相传而来。种子用户都是愿意付出成本来和配合，希望通过一个系统解决企业的问题。

最后，说到B端产品的运营，老文公司目前采用的是“地推+线上运营”结合的方式进行。我认为其中打动客户意愿的有一下几点值得思考：

1. 第一：客户对企业或者产品的品牌信任度很重要，直接影响到客户购买的决策链。积极进行品牌建设，并帮助客户建议认知，形成强信任度。
2. 第二：地推团队能否抓住企业客户购买的关键因素，B端产品并非是免费就一定有人使用，因为一个企业启用一套系统，也需要很多的使用或替换成本。
3. 第三：找到能够认知到自身企业存在某些问题的老板，并且合适的时候推出你的产品，并能够真正帮助到他们。
4. 第四：产品本身需要具备解决问题的能力和价值，让客户在使用过程中真实的感受到价值和效率提升。

上周老文第一次在人人都是产品经理上遇到催更的小可爱，所以将原本文章的架构进行了一定的精简，此系列就此结束吧，一路前行，一路思考，很感动对大家有所帮助。

本文由 @老文 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。