【误区】软件开发过程中的合作边界：业务架构 vs 技术实现

见人说人话，见鬼说鬼话

经过多年历练，我已经不再强求合作方提供什么软件工程的标准文档。为了兼容各种知识背景、各种水平的人，我就追求“千人千方”，怎么快速让对方理解怎么来。当然，如果对方实在是专业水平不足，那我就主动建议应用广泛的文档格式。此文提到的 OpenAPI 文档就是我经常用来沟通的工具。

我们尽量讲接地气的大白话，少扯艰涩的理论 =。=

乱象一直存在

任何行业，如果它处于向上发展的阶段，那必然伴随着各种不同程度的推陈出新。即，推翻原来的认知与规范，用新的理念与技术去达成目标。那些被推翻的旧事物本就属于乱象，而新体系在成熟稳定前它本身就是乱象。

如果一个行业逐渐落寞，那么总会有一些行业内的人在垂死挣扎。他们为了榨干这个行业中最后的那点利益，会不断做出违背公序良俗的行为。这也是乱象。

软件行业是一个非常非常年轻的行业。这个行业里充斥着各种乱象。人、组织、理论，反正你能想到的各种层面的事物，都充斥着各种牛鬼蛇神。此外就从分工合作的一个侧面，简单描述一下该行业中“业务架构”和“技术实现”的边界。

“业务架构”和“技术实现”的边界在哪？

通俗地讲，“业务架构”就是需求，就是金主爸爸说要什么；而“技术实现”则是造出金主爸爸要的那个东西。

在软件开发过程中，会有各种各样的干系人。比如，有出钱买产品的客户，有使用产品的用户（买的人不一定是最终用的人），有代表客户提需求的人，有软件公司的老板，有代表软件公司与客户对接的人，有产品经理，有开发经理，有各方面的专业设计人员，有写代码的程序员，有负责交付产品的实施人员，等等等等。

不同角色的人，他们的知识背景和职责千差万别。他们之间的交流也就非常容易陷入“鸡同鸭讲”的尴尬局面。为了让软件过程能顺利开展，就必须制定协作规范，让协作人具备必要的基础知识。

信息流转路径示例

一个典型的信息流转路径（部分）是这样的：
1. 客户的某个高层领导提出办公自动化的愿景；
2. 客户的某个中层领导结合自家业务特征，收集整理了一些对办公软件的需求；
3. 软件公司的客户经理将客户的需求带给了软件公司的产品经理；
4. 产品经理根据自家产品设计理念，针对这些需求提出了相应的解决方案设想；
5. 软件公司的业务架构师、技术架构师、交互设计师等各路大神，根据这些设想提出了可落地的方案；
6. 开发经理将这些研发目标拆解、按优先级排序，然后分配给真正写代码的程序员；
7. 程序员接到这些可落地的小目标后开始实现软件功能。

高层领导

在上述信息路径中，每个角色对“业务架构”和“技术实现”的边界有不同的理解，差了十万八千里。

在客户的高层领导眼里，将办理某项业务的耗时降低50%就是他的需求，也就是所谓的“业务架构”。至于具体从哪些环节入手，来提高效率就属于“技术实现”。“高层”领导不需要关心这些细节，直接丢给下面的“中层”领导就好了。

画外音：可能那个“50%”的目标是“高层领导”和几个“大佬”在饭局上拍脑袋拍出来的。我怎么反而感觉这位领导好敬业呢？他居然对一项具体业务提出要求，也就是说他居然知道自家有这么一条业务线。难道是他还不够“高”？

中层领导

在客户的中层领导眼里，哪些环节需要软件来自动化执行就是他的需求。他整理需求的质量直接影响到软件项目的质量。当然称职的中层领导会始终对一线业务非常熟悉，进能直接上前线成为一线的超级业务员，退能总结提出业务改进方案。更有强者，还能优化公司内部业务架构，领导公司改革，甚至对整个行业加一剂猛药。

画外音：大多数领导都是务虚的，他们早已无法胜任一线业务，又没有合格的业务架构能力。我曾见识过某些超级金融机构内的IT部门领导对软件工程的认知水平之粗浅，提需求这么重要的事，连文字记录都不会提供给乙方。当然这也和乙方自身专业水平垃圾且跪舔甲方有关。

客户经理

至于客户经理，绝大多数就是“传声筒”。客户提啥需求，他都只能原话转给软件公司的技术人员。吹牛打屁他们在行，但对业务和技术的了解就只能打哈哈。遇到对产品细节或背后技术感兴趣的客户，他们就恨不能直接把产品经理、架构师、程序员都拉上，直接跟客户对话。

产品经理

到了产品经理这里，“业务架构”和“技术实现”的边界又会有较大变动。越是专业的产品经理，这个变动会越大。产品经理提出的需求会非常细致，甚至能直接落地。当然，产品经理很可能不是一个人，而是很多人形成的一个组织。这组织完全可以也应当承担全部的业务架构职责。甚至还可以拥有部分交互设计的能力，对技术实现也有基本的认知。如果产品本身就是应用到IT领域的，比如最终用户就是 程序员、软件测试员 或 运维人员，那么这个组织还需具备非常强的IT技术背景，需要有技术架构师加盟。（当然PPT架构师肯定是不行的，他们只能当演员。）一个合格的产品经理（组织）会尽量将业务规则推进到每一个细节，绝不会将模糊不清的事物流转给程序员。否则就是顶着极不稳定的炸弹在裸奔。

当然，放眼整个软件行业，绝大多数产品经理都是不合格的。从各种对产品经理的调侃言论就可见一斑。想想“人人都是产品经理”这句话是从什么时候开始流行的，就知道这个行业是多么的乱。大量的产品经理沦为客户经理一样的“传声筒”，大量的产品经理沦为“啥都知道一点，但又啥都做不好的”的“全栈”。

画外音：我曾见识过真正由资深业务专家来定义产品业务架构的项目。那些风格“老派”、专业能力过硬的产品经理真的有明显的威望，让人对他们的专业心生敬畏。我也曾见识过顶多算个文书助理的产品经理，各方面专业能力都不如一个资深程序员。

程序员眼中 “业务架构” 和 “技术实现” 的边界在哪？

如果你没有正经从事过程序员的工作，有些事实可能会大大颠覆你对“业务架构”边界的认知。在整个软件过程中，程序员是非常特殊的一环。从狭义上来说，程序员是这些角色中唯一真正干活的人。向他们提需求时，必须提供准确的描述，最好是提供业内公认的一些文档。尽量把他们当作“无情的编码机器”。这样才能将你的需求不偏不倚地落地。

举个例子

产品架构

假设有一个产品X。它依赖一个系统A，同时系统B又依赖产品X。直白点讲就是，产品X调用了系统A的一些API，系统B调用了产品A的一些API。它们形成了一个依赖链：系统B -> 产品X -> 系统A。产品X处于这条链路中间，需要两头对接。

问题

那么问题来了，在产品X内部，产品经理需要向程序员提供什么样的信息，才能准确传递 产品X 和 另外两个系统 的业务交互设计？

产品经理咋想的？

绝大部分产品经理都只是用大白话介绍一下这几个系统之间的关系，以及他想要的大致业务效果。甚至很多产品经理只是一句话需求，不会有任何正式的文档。尤其是当这三个系统都属于同一家公司研发时，相当多的产品经理会让程序员自己去找另两个系统的研发人员直接对接：大家都是同事嘛，要多多交流。然后产品经理自己当甩手掌柜。也就是说产品经理不了解这些系统之间的业务运转逻辑细节。几个月后，项目组完全可以把这个产品经理踢开。因为他对业务的了解程度完全不足以支撑产品经理这个职位。

大多数产品经理觉得这么做没问题啊。我们一直是这么做的啊，公司不是照样运转。绝大多数产品经理觉得API的事都是技术细节，与业务设计无关。甚至看到“API”这个词就发怵。他们不懂技术啊！

合格的产品经理应该提供啥信息？

我们换个角度来推导一下。

产品X 向 系统B 提供什么样的业务服务？

系统B的研发团队来对接你提供的服务，肯定要先知道你的服务长什么样吧？

你作为产品经理如何准确地描述这些服务，才能让系统B的研发团队知道如何对接？

那当然最起码得提供API签名吧？这可是要落地的，要写代码让机器能够看懂并执行的。自然语言当然不行！

那你说“API签名”这玩意儿太技术化了，我不会啊。能不能让程序员来写啊？他们都是程序员，交流无障碍嘛。

当然可以，而且也应该让真正懂代码的程序员参与到API签名撰写这件事上来。况且程序员也是要照着这个API来实现服务的。

画外音：脱离一线编码的人很难设计出合适的API签名。他们往往会把各种命名设计得非常蹩脚拗口，还经常用错英语单词。即使以前写过几年代码，也不行。即使你一直在写代码，但用的是另一种编程语言，也不行。

但是！准确传达需求的沟通问题还在！你怎么告诉自家程序员这个API签名得体现哪些服务特性？

别再想着用自然语言了！自然语言太难准确表达含义了！这条路早就被业界否定了！

你可以考虑一下用 OpenAPI 文档。虽然它不能代表所有形式的API，但它真的是非常合适的API签名描述工具。它能避免绝大多数歧义，而且简单易学，几乎就是程序员之间的世界语言。用它来表达产品经理的需求真是太合适了。

我们再回到 产品X 和 系统A 之间的对接。

系统A 能提供什么样的服务？当然也最起码要有API签名来辅助描述。

那你作为产品经理，在设计业务架构时，当然要先阅读 系统A 的API签名，才能准确了解它的服务特性。这样你才有可能设计出能落地的业务架构。不然就真的是乱拍自己脑袋了。

然后你是不是得把两个系统之间的业务交互逻辑传达给程序员？那你用什么形式的文档表达？当然最起码要说“调用系统A的 API-1，各参数值如下……”。

这不是很容易理解嘛。供外部系统使用的API设计成啥样 和 调用外部系统的哪些API 对程序员来说都是“业务架构”，都是“需求”，都是得由产品经理自己亲自主导设计调研后确定的。

程序员只需关心自己的一亩三分地？

可能很多人会说，程序员是需要了解业务的，只关心自己的一亩三分地是不可能进步的。

对，是这么回事。但现实不只这一面还有更多更重要的考量点。

了解更多业务知识，承担更多额外的职责，掌握更多业务上的话语权是程序员自己对自己的要求。前述API设计和API调用说明则是一个合格的产品经理必须要做到的。每个人对自己的要求和对别人的要求永远都是不一样的。如果强行糅杂在一起，那就是欺负老实人。就是所谓的的“你和老板谈钱时，老板和你谈理想”。

另外还有更重要的事！几乎所有的事情执行模式都在朝着“分工合作”这个方向持续发展。分工是一切合作的基础。分工是高效的前提条件。一个连边界都搞不清的人，没资格谈合作！

如果你作为领导，作为老板，居然要求自己的下属逆着时代的潮流，都去扮演“全能保姆式”的角色，那你就根本不配有专业的技术人才，那就是你的认知不足以支撑你的职位，那就是你失职！

绝大多数职场人根本不会有意识地去学习一个公司的运营方法。他们一直都是用着小作坊式的混乱管理。他们根本不知道大公司控制运营成本的方法论，根本体会不到大公司体系化作战的高效。绝大多数时候，根本不是你小公司灵活跑得快，而是大公司维度高了好多个层级，根本不屑于降维打击你。你一直专注于游走在灰色地带坑自家员工，人家大有担当，不搞这些见不得光的事。