产品经理懂点技术（2）：产品经理真的要懂微服务么

iCheer 2023-07-23 15:25:31

康威定律

在上文讲微服务架构的由来时，我们引用了马尔文·康威（Melvin Edward Conway）的一句话

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations

设计系统的架构受制于产生这些设计的组织的沟通结构。

——Conway, 1967.

康威是以为计算机科学家，计算机程序员和黑客，他著名的论文《How Do Committees Invent？》里面的内容被弗雷德·布鲁克斯（Fred Brooks，美国计算机架构师，软件工程师和计算机科学家，以管理IBM的System / 360系列计算机和OS / 360软件的开发而闻名支持包）在他的经典著作《神话人月》（The Mythical Man-Month）中引用了，称其为“康威定律”。

康威定律可谓软件架构设计中的第一定律，总结起来又有四条具体定律，我们主要讲讲其中第一、第三定律。

康威第一定律：

Communication dictates design

组织沟通方式会通过系统设计表达出来

产品经理，产品经理网站

图片：Manu Cornet

组织的沟通方式，包括业务部门的划分、合作流程，如果部门间分工混乱、流程无章可循，那么系统上就只能发现什么问题解决什么问题，不能有效的促进业务的发展。只有解决好组织的沟通方式，大家分工明确、流程清晰，才有更好的工作效率，也才有可能做出一个好的系统。

康威第三定律：

There is a homomorphism from the linear graph of a system to the linear graph of its design organization

线型系统和线型组织架构间有潜在的异质同态特性

笔者补充：homomorphism的中文翻译是同晶（型）的意思。异质同态就是外在不一样，但是本质结构类似或一样的意思。

第三定律是对康威第一定律的具体应用，什么样的组织架构将会决定什么样的系统。反而言之，如果想要一套好的系统，那就得要有一套好的组织架构。

产品经理，产品经理网站

图片：James Lewis、Martin Fowler 翻译：iCheer

产品经理，产品经理网站

图片：James Lewis、Martin Fowler 翻译：iCheer

根据康威定律，我们就知道了，业务的形态最终会影响到系统的架构。而微服务是由业务驱动的，这就意味着业务规划的好坏会直接影响系统架构的好坏，糟糕的系统架构还将拖业务的后腿，甚至进入恶性循环。

业务-产品-研发的工作流

产品经理，产品经理网站

当我们讨论产品方案时，都不能脱离业务，业务是需求最重要的根源，那到底什么是业务呢？

从词语定义来说，业务是指某个行业或者某个职务所做的事情，就叫做“业务”，其参与者是人，未来也可能是电脑、机器（AI、自动化），其目的满足行业、职务的服务对象的需要。

业务方在工作过程中，为了实现更高的产能、获得更高的回报，就会想办法去优化整个业务流程，这就产生了“需求”。只要业务想发展、在发展，需求就会源源不断的产生。

产品经理接触的需求来源，外部是业务的服务对象：用户；内部则是业务的执行方：老板、运营、商务、财务、法务、供应商等。业务方将需求告知产品经理，产品经理经过调研论证，将需求转换为产品方案，输出可以满足业务需求的产品需求文档、原型。

然后，产品将功能的需求提给研发人员，研发最终将这些功能得以实现，于是系统诞生了。业务方使用系统，不断发展扩大，产生更多的新需求，于是以此往复，形成业务-产品-研发的需求链条闭环。

在这个链条闭环里，业务形态、流程决定了系统最终的形态，而系统形态则推动业务的发展。产品是连接业务与系统的纽带，技术并不是在瞎逛，而是根据产品的需求去研发系统，技术研发出来的系统会最终决定业务未来的走向。

微服务与产品经理的工作

业务驱动：

产品经理，产品经理网站

微服务是技术让代码更适应业务发展的产物，是业务驱动下的产物。

微服务的概念需要程序员更了解业务的板块划分和发展方向，代码要随着业务的不断成熟，按照业务结构进行模块化、服务化，才能方便业务的发展壮大，这就要求程序员要“懂点产品”。

如果程序员一味的按照纯粹的技术方案或者自己拍脑袋定的方向做，那随着业务的迭代发展，很容易出现“这个需求做不了”的问题，因为代码被技术方案禁锢住了，无法适应业务的发展，如果要解决，可能就要重构，时间、人力成本将居高不下。

业务驱动的过程，不是一个“理想”、“理性”的过程，代码讲究的是逻辑，是要“不出bug”、“跑得起来”，但是业务的发展是用户、市场需求不断积累的一个过程，很多需求可能是很主观的，甚至有时候是“灵光一闪而过”的。需求存在不确定性，这就让程序员犯难了，那到底要不要按照这个方向做呢？万一做了用不上要推倒重来怎么办？

这时候就体现出了产品经理的作用，对现有业务架构的划分、对新需求的判断和归类，这将直接影响微服务的架构模块。

产品蓝图：

产品经理可以不懂什么是微服务，但应该知道自家产品的功能架构或产品蓝图，这既是产品需求筛选、功能规划的依据，其实也是技术做微服务划分的重要依据。