书接上回，在上篇文章中，我们谈到需求评审会中业务和产品经理为何总是打架。今天，我们谈谈，为什么产品经理抓着业务流程不放，总是那么多问题？

接下来，我将概述下B端产品经理的工作，核心的目的有两个：其一、让业务、运营了解产品经理工作。其二、揭示产品经理为何看重且需熟知业务流程。

在业务、产品、研发的工作流程中，从微观层面看，这个流程在运作中主要包含以下几份重要文档，即业务需求文档（MRD）、产品设计文档（PRD）、研发设计开发文档。从宏观层面看，这个流程在运作中主要包含以下几个重要架构，即业务架构、产品架构、信息架构、技术架构，（也可理解为业务流程、产品流程、交互流程、技术架构）。

那么，如何从宏观层面理解他们之间的关系呢？

接下来，我们结合下图，进行详细介绍，如图：

整体流程顺序看，业务首先输出业务架构，然后产品基于业务架构设计产品架构和信息（交互）架构，研发提供技术架构支持，最终共同面向用户。

业务架构：业务架构是产研工作的起点，对整体工作起着决定性作用，十分重要！业务架构包括商业逻辑和业务流程等。其中业务流程最为关键，业务流程要清晰的描述业务场景，即谁，在什么时候，依据什么规则，能做什么事。因此，这个环节的关键点是：人和事！

产品&信息架构：这部分就是产品经理的工作领域。产品架构是指：系统、在什么时候、依据什么规则，做什么事。信息架构是指：创造用户使用媒介，提供优质的交互流程，方便用户使用系统or产品。如：PC端、APP、小程序等等。因此，这个环节的关键点是：系统和事！

产品架构怎么来的呢？

其实很简单，产品经理依据业务流程和规则，再结合系统分工的知识，进行“分类归堆”。

说白了，其实就是产品经理在充分理解业务流程后，进行“人和事”分门别类，这个A系统做，那个B系统做，就是这么简单的流程。

信息架构怎么来的呢？

更简单了，主要就是依据业务流程中“人”在实际中需要哪些操作，再结合交互设计的原则与规范，输出交互流程，一般包括“增删改查”功能。

到此，你就可以理解，为何产品经理在评审中非常重视业务流程的原因了。同样，也就可以理解，为何产品经理团队往往要求产品经理要前置到业务中，甚至被要求比业务还要懂业务了。

最后，浅谈一句产品经理与研发经理之间的争论。其实与业务和产品经理之间境况有异曲同工之妙！主要争论的就是产品经理“分类归堆”对不对。

最后的最后，祝每位业务、产品都能顺利通过评审，取得理想的结果！Good Luck！