一个产品的业务需求一般具有很多来源，彼此之间可能会产生冲突。业务结构的建立最终需要表现为一种被广泛认可且稳定的形式，但团队各方可能存在利益上的冲突影响到业务结构的稳定性。例如在移动医疗系统开发过程中，对于预约挂号这个常用功能，系统的开发人员、产品经理和医院相关人员可能会存在如下图所示的冲突。
显然，我们可以看到上图中存在一致的地方，但也包含很多相互冲突的业务功能，如产品经理所设想的“为所有医院提供一个统一的预约挂号平台”和医院人员所设想的“应为本院提供一个专有的预约挂号入口”就有根本性的区别。为了解决业务冲突，首先需要明确业务决策的维度。
（1）干系人
所谓干系人（StakeHolder）是指参与到产品规划、设计和实现过程中的个人或组织，它们会根据其利益对结果给予积极或消极的影响。显然，干系人也能影响业务决策，但并不是所有的干系人都对业务决策有显著的影响，干系人管理的首要一点是要识别决策者。围绕干系人的权力和利益，我们可以得出下图中的干系人管理的四象限。
根据上图，我们需要重点管理权力和利益都与产品有较大关联的干系人。管理关系人的基本法则就一条，即频繁的用户参与能够减少期望落差。期望落差是指干系人对产品的期望产品本身所能提供的业务特征不匹配。如果不花精力促使干系人和产品设计开发人员之间达成一致，其后果必然是返工、延期以及降低用户满意度。
（2）组织架构
组织架构对业务决策也有较大影响。在组织结构上，以普遍采用的矩阵式组织（Matrix Organization）架构为例（见下图），它是把职能划分的部门（图中的F）和按产品划分的小组（图中的P）结合起来组成一个矩阵，管理人员（图中的F1）既同原职能部门保持组织与业务上的联系，又参加产品开发小组的工作。在这样的组织结构下，其业务决策的过程就会跟矩阵的类型有直接关系。
矩阵式组织根据上图中的管理人员的权利大小，可以分为强矩阵、弱矩阵和平衡矩阵。对于互联网产品开发，这里的管理人员一般就是指产品经理。在强矩阵中，产品经理拥有较大权利，业务决策通常是按照产品经理自身的影响力所制定；弱矩阵则相反，产品经理权利较小意味着以开发人员为代表的职能团队会有更多话语权，在符合产品整体发展方向的基础上，会提出更多基于技术实现的建议和意见从而影响业务决策。现实中更多的场景是平衡矩阵，即产品经理和开发法人员通过协商达成业务决策上的一致。
另外，业务决策的制定还涉及到产品开发所处的阶段、最高管理层或投资方的期望等因素，同时也受整个组织政治和权利斗争的影响。对技术管理者而言，围绕业务决策所开展的工作在很多时候表现为一种与外部团队进行协商和解决冲突上的能力，我们会在第9章中对如何进行向外管理做进一步展开。
当处在某一个特定组织架构中的干系人在特定阶段对业务结构做出了统一的决策，这仅仅是一个开始。产品的开发和演进是一个变化的过程，业务决策同样也需要变化以适应产品的发展目标。因此业务决策表现为从一个统一到另一个统一的过程，如下图所示。
我们把上图中统一的业务决策称为业务基线（Baseline）。业务基线是干系人认可的一个业务需求集合，通常作为某一具体的计划发布版本的内容。设立业务基线的目的就在于管理产品的变化性，因为基线是不能改变的，想要改变基线就需要根据业务需求的变更和外部环境的变更修订现有基线并形成新的基线，基线的修订过程参考下图。
如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型，或扫描下面的二维码。
我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》，欢迎交流。
