行业老兵聊 To B 产品技术：To B 难，难不过做好软件

To B 和 To C 这两个词是国内互联网行业的高频词汇，连普通老百姓也挂在嘴边，但尽管是两个洋文，到谷歌上搜却没几条相关的结果。

正如“互联网公司”这个词在海外找不到恰当的英语单词一样，To B 这个词也有点中国互联网特色的意思。海外的技术企业通常用“企业级软件（Enterprise Software）“来指代 To B 产品，且包括业内常常认为的不太像软件而更像所谓互联网产品的 Salesforce、Workday、ServiceNow 等 SaaS 服务。大概是中国互联网的成功主要体现在平台模式上，to 这个词隐约强调了一种交易或服务的商业模式，也成了 oriented 的简写。

阿里巴巴的 B2B 应该是国内业界最成功的 To B 业务之一，当然其业务不同于我们今天所说的云计算、钉钉、飞书、纷享销客等这类 To B 服务。如果在谷歌上搜索 B2B、B2C 的话，确实能精确命中我们期望的内容，但搜 To B 就不太行。

顺应大家习惯的概念，这里使用 To B 这个词，但讨论的主要是企业级 SaaS 产品。我在钉钉供职期间，常提醒团队不要认为“互联网”比起“软件”有多高大上，看目前市值最高的苹果和微软都不是传统意义的互联网公司。尤其在讨论“可以本地部署的 SaaS 产品”都不愿承认这玩意儿就是软件的时候，就有些大可不必了。做软件不是什么丢人的事，本文就是在探讨软件工程，敞亮一些。

近些年来人人都在讨论 PLG，而把 To B 产品做成和 To C 产品一样易用的理念也几乎成为主流。一些 To B 产品的界面设计越来越趋近于 To C 产品，强调移动端体验，使用口语化和互联网语言的文案。

将 To B 产品的用户体验做成和 To C 产品一样低门槛和傻瓜化是应该的，但另一方面 To B 产品的系统复杂度是永远不可能和 To C 产品一个级别的。这就好比 Excel 尽管很易用，但仍然是极其复杂的，甚至可以直接用来开发三国杀游戏，所以这二者并不矛盾。

我常开玩笑说，To B 产品一个新功能的引入会导致至少九个以上的功能点，因为各种策略的组合，以及管理员的不同维度的汇总需求会自然地增加功能集合的复杂度。另一个玩笑是，To B 产品最终都会变成一个 BI 产品，因为老板总是希望横着看又纵着看，看完部门维度又看级别维度，说不一定弄成 Excel 文件后来做报表还方便些。

我见过很多产品经理将大量精力花在缩短用户链路和功能透出上，比如把二级入口升级成一级入口，但用户容易找得到，但导致了界面不简洁。或者通过并不严谨的数据模型来频繁调整界面元素，让用户觉得困扰。

我认为 To B 产品本来就该有一定的用户教育成本的，产品应该设计得易用，但不能为了简化链路而牺牲其他方面，期望用户拿到以后就像微信或淘宝一样是没有意义的。一个给员工使用的 To B 产品，即便没有相关培训，新员工一定会在同事或者主管的帮助下迅速学会产品，毕竟是吃饭用的家伙。这种学习是一次性的，对公司几乎没有成本，也不会因为单个员工的个体行为造成产品的用户流失。员工在工作中本就还需要大量其他的工具，所以这种“第二次就会了”的情景本身就是工作的日常。

To B 产品的复杂度既是用户的门槛，另一角度看也是展现自身价值和竞争力的舞台。如果觉得自己烧钱搞流量搞不过对手，但是有很强的产品技术能力，那么可能更适合做 To B。

国内的消费互联网是大数据的海洋，所以长期以来 To C 产品的设计很重视用户链路的相关数据，并基于此指导产品设计。这种产品理念也被顺理成章地应用于 To B 产品设计中，看链路漏斗，做 A/B 测试。

数据在产品设计中有重要参考价值，但如果过分迷信于数据，用力过猛，给 To B 用户带来的负面困扰也会远远大于 To C 产品。To C 产品思路通常认为高频功能应该放前面，但 To B 产品的用户角色是极其丰富多样的，对于某一角色的高频不代表对于另一角色就是高频。即便像 Word 这样的通用软件，“文件”菜单总是放在第一位，几十年来均如此，但“文件”菜单的使用频度却远远低于“编辑”菜单。

对于数据的分析和理解需要严谨，基于统计学，多个维度分析，避免一概而论，个体和共性混淆不清，更注意避免幸存者偏差。对于数据的理解不到位，将因果关系搞反，就成了“火车上的人居然都买到了票”的笑话。

产品经理是人，而我认为人在产品设计中的主观能动性仍然是最主要的因素。数据固然重要，但将决策交给数据和机器，则容易偏离产品设计的初心。有的产品甚至成了所谓的运营驱动，界面搞得很热闹，甚至还有广告位。对于产品团队 KPI 的设置，如果过于简单地下一些数据指标，很容易团队变形走样。产品像是一座高楼，是一个有机体，不是一根根烟囱，也不是一层层蛋糕。如何设计团队的 KPI 考验的是管理者的智慧，从而决定构建这做产品大厦的时候谁来当地基谁来当梁谁来当柱。

相对于 To C 产品，To B 产品的交互更稳定，升级变化更谨慎。按我前面的观点，使用 To B 产品就是要学习的，因此每一次变化都会有一定的成本。这不是说 To B 产品要万年不变，而是要深思熟虑，考虑回报和风险。反过来，同样的道理，如果有充足的理由要改产品，那么也不必过度担心用户找不到原来的功能。

康威定理认为，产品必然是其（人员）组织沟通结构的缩影。有些产品的设计有明显的组织架构痕迹，甚至用户看一级菜单或者 tab 就能猜出其背后团队的组织架构。康威定理是对现状的总结，甚至在一些系统设计中（如微服务）被用于作为基础指导思想，但要警惕这只无形的手始终在影响产品的设计。

团队内部打架的情况不是新鲜事，当一级入口位置或顺序出现内部竞争时，康威定理带来的负面影响就会放大。如前面所说，To B 产品的价值决定了其本身就是复杂的，用户看到的部分是冰山露在水面上的部分，真正的核心是在水下。所有的软件系统从宏观和微观层面看都是分层的，或者说是以堆栈的形式存在，但团队的组织结构却又是树状的。如果层次定义不清晰，而是纯从用户的角度去划分产品模块，容易出现所谓烟囱式的产品设计，支离破碎。

国内互联网行业通常存在一种误区，认为所谓的架构设计是技术问题，不是产品经理关心的事，也很少听说有哪个公司或团队设立产品架构师这一岗位。产品中的用户账号系统，用技术语言叫目录服务，用产品语言叫通讯录，是每个 To B 产品的最核心系统之一，也是层次结构里躺在最底层的那一个系统。用户在写邮件的时候，从网盘选择一个文件作为附件，这个过程中邮件系统和网盘系统的交互是怎样一种依赖关系，不仅仅是个技术问题，也是一个产品架构问题。

创业团队一开始做出的东西都很精致，而规模上去以后就容易变粗糙。一个大型 To B 产品是否是个有机的整体，最终是否能成为一个好的作品，往往取决于其面对康威定理时候所表现的韧性。

看一个复杂 To B 产品是否有设计原则和设计模式，可以看其功能类似的实现和用户操作是否有基本的一致性。举个例子，用户导出一个文件，可能是异步操作等完成后发通知给用户，要考虑文件可能过大要切割，以及临时存储空间和清理的问题。一个有一定复杂度的 To B 产品往往由不同产品经理，甚至不同产品部门负责。产品不同系统的文件导出行为是否能做到一致，需要由统一的设计模式来约束，并有相应的 review 机制。

一些产品经理会根据部分用户的反馈立即做出产品调整，解决用户问题或痛点，但这种快速的反应往往缺乏深思熟虑，属于被动的见招拆招。如果一个产品长期以这种方式开发，那么迭代越快，导致的碎片化就越快。

我要求产品经理使用维度一致性去检查新的产品设计，即回答以下问题：

1. 是否是在原有维度上扩展，还是引入了新的维度？

2. 如果引入新的维度，该维度上可能存在的元素是哪些？

看个例子，一个网盘里的文件一般通过可编辑、可读等属性实现 ACL 模型来管理文件权限，或者结合 RBAC 模型提供更丰富灵活的权限功能。如果某大客户提出一个“机密文件”的需求，在符合某些规则的情况下才能访问，那么这个功能的引入就是增加了一个新的维度。假如真的要考虑支持机密文件，就要检查该维度对现有各种产品的影响，比如是否有机密邮件、机密聊天、机密项目、机密会议等等，举一反三。尽管客户可能只提出了一个文件是否为机密类型的二元条件，但可能未来扩展成为高、中、低不同等级的机密，或者更细粒度。机密文件的本质是根据对象的属性进行权限判断，实际上已经属于 ABAC 模型的范畴，顺着下去还可以进一步泛化，比如根据创建时间来制定规则等等。

对于引入新维度的设计需要极其谨慎，因为新维度的出现必然影响现有的产品系统，甚至产生全局影响。产品架构师最好能维护一张大图，总结产品中各种维度的现状和未来可能的发展。

人人都知道要搞好竞品调研，而最通俗易懂的竞品利用方式，大家也都懂的。探讨一点反向的方式，产品经理设计一个新功能的时候，要多问一个问题，竞品有么？

对于竞品的分析和调研，要从正向和反向两方面去看。友商有自身的优势和劣势，做与不做的选择是什么。一个功能如果竞品没有，为什么？是友商没想到，没来得及做，还是人家就是不做？

面对大客户需求的时候，竞品现有的产品设计可以被借用来作为产品语言帮助描述需求，降低沟通难成本。另一方面，如果竞品也没有这样的功能，而自身也认为不合理的时候，可以考虑以此作为理由之一来婉拒客户的需求。

定制化需求应该是 To B 产品和技术团队最头疼的事之一。很多团队一开始总是立 flag 不做定制化，后来顶不住前线的压力，或者看重了某大客户的市场传播效应，最后硬着头皮上。定制化一定是亏本的，与 PLG 理念是冲突的。决定要做定制化就一定是在投资未来，要么该需求有朝一日成了多个客户的通用需求，要么财务报表上姑且当作市场推广费用记作运营成本。

常有人问我微软是怎么对待客户的定制化需求的。微软基本上没有定制化需求，包括自家用的 Windows 和 Office 也是和客户的版本一模一样，而且也不赶工期。微软的策略可以这样形容，如果一个需求不满足客户要求导致丢单，微软会去制定相应的产品研发计划来避免丢掉第四到第十个客户。为什么说第十个客户，因为需求需要有足够的通用性和足够大的客户群覆盖。为什么说是第四个客户而不是第二或第三个客户，是要保证产品计划的正常实施而不去为客户而赶工。

To C 产品的用户角色相对单一，且同一用户用角色或类似用户画像覆盖了大量用户，这些用户通常具有相同的操作链路和使用习惯。当这种特性反映到工程实践中，一些技术团队选择聚焦在主链路的测试，甚至依赖线上真实用户的使用来验证功能，搞 Test in Production。

这种工程理念如果沿用到 To B 产品中很可能会出现水土不服的情况，迟早要因为功能 bug 被客户骂。由于 To B 产品角色复杂，客户和用户设置丰富，用户链路组合的复杂度是指数级增加的，而某一链路所覆盖的用户量又显著小于 To C 产品。有的功能可能还是季节性的，甚至是每年或者几年才用一次。

做 To B 产品的质量保证，自动化测试必不可少。即便手工测试外包再便宜，也不可能靠堆人来追赶指数级增长的复杂度和开发写 bug 的速度。自动化测试不是为了测试新的功能，而是保证添加新代码的时候已有的功能不被破坏，也就是回归测试。除此之外单元测试也会倒逼开发去设计更加抽象和优雅的接口，让代码质量和可复用性更高。

任何系统总是朝着无序的方向发展的，软件的熵增是质量下降的罪魁祸首，而技术团队的职责之一是通过持续的修护和维护来对抗软件的熵增。修复工作的周期越长，带来的成本就越高。软件的 bug 有明显的破窗效应，一个漏洞出现后不去修复，会立刻出现更多的漏洞，而且相互叠加和遮挡，最终引起故障。

几乎每个开发都懂得“面向失败（failure）设计”的大道理，但并非每个人都真正理解失败这个词的意思。代码里的 bug 与光缆被挖掘机挖断是两种本质截然不同的失败，前者是可控的而后者是不可预期的。光缆是别人挖的但 bug 是自己写的，能在上线前干掉的问题就不要留给客户。

每个技术团队都梦想着能达成持续集成持续交付（CI/CD），而且产品和业务团队也希望能快速迭代，恨不得每周都上新功能。但另一方很多团队又嫌写测试代码占用大量时间，不愿意投入，结果就是越想快团队越被动越狼狈，欲速不达。自动化测试是 CI/CD 的前提条件，整个 pipeline 要像无人值守的流水线一样有节奏的跑起来，像地铁时刻那样精准，才可能实现 CI/CD。一旦其中一个环节要人工参与，就不可能顺畅，一定卡壳。

我之前决定重写阿里邮箱的前端和桌面端代码，要求团队一开始就奔着 CI/CD 的目标去。团队最后达成了 90% 以上的自动化覆盖率，甚至包含了 UI 层代码，真正意义上地验证了磨刀不误砍柴工。我的前端团队负责人孟红伦（高级前端专家）还在 InfoQ 全球前端技术大会 GMTC 上分享了《CI/CD 在钉钉前端的实践》。

苹果的产品用户体验好基本是公认的了。除了产品设计之外，所谓体验好的一大原因是觉得质量稳定，bug 很少。作为苹果用户，当看到一个错误消息的时候，一般会觉得是不是自己哪里操作错了，应该很少人会想到去找苹果客服问问怎么回事。反过来，某些产品使用中看到错误提示的时候，却可能趋向于怀疑该产品有 bug，而不是自己操作错了。

这种心理上的差异背后不仅仅影响产品本身在用户心中的形象和口碑。对于技术团队来说，面对外部反馈问题第一时间的反映，也会很大程度上影响团队的工作方式和生产力。当有人反馈说某个地方可能有 bug 的时候，开发工程师心里有没有咯噔一下，然后决定是否要去查问题，是不是赶紧得去查问题。

鉴于目前还没找到个好词，我个人把这一现象姑且称为技术信心。尽管网上都是各种关于程序员说自己代码没 bug 的段子，不同人的底气确实是有差别的。如果一个团队的工程师总是在查问题，一听到问题心里就咯噔，赶紧去看日志，那么可以想象这个团队的生产力不会太高。To B 产品的复杂度会放大这种差别，拉长了看甚至会影响团队的投入产出比。

在一个复杂系统中，“自证清白”是一种技术能力，也是一种合理的工程实践。我经常给团队讲需要我们需要搞一点 finger pointing technology，可以很快且自信说“不是我的问题，肯定是你上游（下游）系统的问题”。尤其在微服务大行其道的今天，快速排除可能性是高效的关键，也符合清晰定义系统接口和输入输出的原则。

做 To B 人人都讲客户第一，但很多技术团队有个误区，将帮客户查问题和数据修复这类服务式的行为当作客户第一的表现。团队里宣传某技术小哥哥帮客户查问题查到半夜，不知道有没有感动客户还是客户其实在背后骂，反正是感动了自己。真正的客户第一是把高质量的产品交到客户手里，而不是给客户制造问题再去解决问题。

一个团队的技术好不好？回答这个问题不是那么直接，角度和标准太多，也很难将不同领域的团队拿来做比较。如果要用一个简单的指标，技术信心也许可以说明一些问题。

联调几乎是工程师的日常，理所当然的工作内容，但我之前问了团队一个问题，这个词的英文是什么？大家讨论了一阵，排除了几个短语之外，最后说貌似是 debug together 最贴切。看起来是一个人自己不太好 debug，需要 together？这里有个问题，一个人的工作时间和方式对另一个人产生了依赖。而且这个不是系统或接口依赖问题，而是人之间的依赖问题。

联调的首要任务好像是把链路调通，然后貌似就成功了一半。但真实的情形是，代码成功的链路只有一种，出错的情况则可能是十八种。除了唯一成功的那种情况之外，异常和错误代码也是接口定义的核心组成部分，却容易被忽视。一些团队的系统由于种种原因，开发并不清楚自己要调用的接口会返回哪些错误，甚至也不知道自己提供的接口会给上游系统返回哪些错误。仿佛联调通了代码就算差不多写完了，或者写代码就等于 debug，一上来就开始联调。有些代码设计和接口定义，几乎抛弃了现代编程语言和框架所提供的丰富的错误处理支持，只有成功和错误两种状态，至于为什么错误，一定是要去看日志的，生生把 Java 写成了 C。这种过于简单的二元状态用来处理 To B 产品的复杂度就像在用鸟枪打怪兽，总觉得不够用。产品不出错还没感觉，一旦出错就全都是意外情况。

对联调的过度依赖暴露的是系统之间合约不清晰的问题，工程师不是基于规定好的接口定义去开发自己的那部分代码，而是通过全链路的表现来判断自己负责那部分的代码是否按照既定方式执行。这种开发方式一方面影响工程效率，互相拖后腿，另一方影响产品和系统质量。

我和团队说要把自己做成一个黑盒，即便你的兄弟团队可能就坐在你的隔壁，设计系统的时候要把他们当作外公司的人来看待。设计一个复杂系统，“通”是很简单的，而“堵”才是有技术含量和艺术性的，这也是为什么面向对象编程讲究封装和低耦合。

服务端开发的幸福之处是可以各种打日志（log），这种触手可及的方便甚至让一些工程师产生惰性，什么事都通过日志来解决，很少去思考怎么把系统接口设计成完整和自解释的。有开发甚至把 log 当 trace 用，在日志中完整地用英语描述了一遍代码的执行过程，就像打日志不要钱一样。

服务端的业务代码大多都跑在 Linux 上，但搞服务端开发并不需要去查 Linux 的日志，这是因为和 OS 的交互定义得足够清晰，而 OS 内部也有精心设计的层次关系。若回顾下历史，今天的很多 To B 的 SaaS 曾经都是单机软件或者部署在局域网内，而这些软件在开发工程师无法查阅系统日志时也照样稳定地运行。软件的云服务化并不意味着一定要拼命地打日志才能开发出好的 SaaS，而情况恰恰相反，如果一个系统要靠日志才能描述清楚其状态，那几乎可以说明这个系统设计得很糟糕。

当 To B 业务的竞争日趋激烈，某些客户的数据安全及合规要求成为获客的门槛时，一些 SaaS 厂商为了拿下订单，开始将云服务改造成可以在专有云环境甚至客户本地环境部署。接到客户的单后，出身互联网大厂的技术负责人突然一拍大腿，原来我们是在做软件啊！

在阿里随便抓一个服务端 P7 都是世界顶尖的高可用高并发系统专家，设计开发的系统能抗住双十一那样的流量，但 To B 产品的技术挑战却不仅仅在这些方面。To B 产品要高确定性、高质量、高可靠，出现脏数据的危害在某些情况下甚至超过系统不可用。功能降级是高可用系统设计中的一种常用手段，在系统资源吃紧时候屏蔽一些功能，甚至牺牲一些用户，在 To C 上是可以接受的，但放到 To B 场景里面，这样的设计就要极其谨慎，因为 SaaS 服务的 SLA 所包含的条款可能不仅仅是可用性，搞不好还得赔钱。

相比 To C 互联网的架构，软件产品的架构往往更加注重高内聚和低耦合，而做到这两点是需要思考和投入的。系统既可能由开发工程师团队来运维，也要准备好可能交给第三方或者客户来运维。比如前面提到的日志，假如只有开发自己看得懂日志的内容，那这种部署的灵活性就很会很差。客户的环境可能缺少某种中间件，或者由于合规原因只能使用某一家厂商的产品。这些额外的需求和限制，是互联网 To C 产品中几乎不会遇到的问题，但这也是 To B 技术团队比拼技术实力的时候。一些架构设计上的考量和原则，完全可以去参考和借鉴一下经典软件系统的设计思想和实践。

Linux、MySQL、Kafka 等这些大家用来开发互联网系统的优秀产品，也都是一个个 To B 软件。SaaS 相对于 MySQL 来说是应用程序，而 MySQL 相对于 Linux 来说也是应用程序，开发 CRM 和开发 OS 的工程理念是一样的，因此从本质上讲并没有根本的差别。有的服务端技术小哥能迅速实现一个漂亮的微服务系统，接口定义得很整齐，却写不出一个好的 SDK 给其他人用，很可能是放不下心中的那朵云。经常有后端开发讨论单元化，其实单元化不就是软件化吗？无论软件是运行在客户端还是服务端，最本质的东西是一样的，也是几十年来不变的那些东西。

无论是 To B 还是 To C，产品经理都是核心的发动机角色，产品经理犯一个错误可能把连带其他职能的整个综合团队带到沟里去。大学里是没有产品经理这门专业的，而如张小龙、周鸿祎等知名的产品经理的代表凑巧又都是技术出身的，所以业内总在讨论到底产品经理需要什么样的技能和素质。

都说 To C 的产品经理需要懂用户，洞悉人性，有很强的同理心，那 To B 的产品经理是不是翻译客户的需求就搞定了？我认为 To B 产品经理的同理心是最重要的素质之一，不仅要深刻理解的不同用户角色如何使用产品，还要理解同一角色的不同用户的认知和使用差异。同理心意味着社会阅历，也意味着不是越年轻越好。

产品经理的职责是用软件来描述真实的世界，所以抽象能力和逻辑思维是最核心的专业能力，而这并非开发写代码时候才需要的能力。产品经理和开发的区别只是开发用某种编程语言，而产品经理用接近人类自然语言的抽象语言来描述产品逻辑。这里说的是“接近”，因为在某些情况下自然语言并不是最理想的工具，需要用交互图、UML 图、甚至伪代码来描述。

我给经理提团队的要求是纵向能看到用户故事，横向能看到系统分层。我不希望 To B 产品经理只会用交互图来描述产品设计，而把图背后的一切通通丢给开发去搞定。我希望产品经理都是 3D 型的，而不是纸片型的。开放能力是 To B 产品的核心竞争力之一，理论上设计任何用户功能的时候要考虑对应的开发 API 的设计，所以开放接口的其实应该是产品设计文档的一部分，而不是技术设计文档的一部分。如果一个产品文档上有流程图和对象 OR 关系图，甚至还有开放接口的描述，那肯定可以说明文档作者是经过了深思熟虑的。

To B 产品的核心竞争力在于产品能力，而不是表层的用户交互。微软的产品开发速度是出了名的慢的，但几乎只用了半年多时间就能开发出 Teams，其原因是微软早就具备了 Teams 所需要的产品能力，无论是聊天、视频会议还是文档，微软一直都是领先者。Teams 只不过是之前 Office 365 众多套件产品的一个重新组合下的 App 而已，换句话就相当于是把 Skype for Business 的窗口拉大了，所以轻松超越 Slack 是必然的。做几个 App 是很简单的事，而难的是构建冰山在水面下看不到的产品能力，所以 To B 产品经理一定要搞清楚自己的产出是什么。

计算机不是神，代码不是仙丹，产品的流程和逻辑的设计都和代码都没有什么关系。曾经有一位产品经理设计了一个运营用的游戏，房间里可以支持最多一万人抢金币，而其中任何一个人在某一刻获得的金币会影响其他所有玩家手中获得的金币数，同时任何一位用户加入或者离开也会影响其他所有人，而游戏又要求所有用户的金币数实时刷新。我看了需求后问了一个问题，想象一下体育场里有一万个人，每人拿着一张卡且上面有个分数，有工作人员拿着喇叭指挥所有人到工作人员那里去登记并修改卡片上的分数，任何人一改其他人都要去改。我问说即便有很多的工作人员，要怎么设计这个活动才能避免里面的人不是一直在排队等待。这位产品经理回去想了一阵子后意识到这个设计是有问题的，就算计算机 CPU 飞快，硬盘和网络吞吐量巨大，这个游戏都玩不起来。作为产品经理，不要以为程序员有魔法能让什么都很快很流畅。把除代码之外的事都提前想好了，才是开发眼中靠谱的产品经理。

一个 To B 企业和团队的组织架构如何设计，这个问题层次有点高，以我的水平不敢造次胡乱瞎扯。在此尝试探讨一个常被提及的问题，产品和系统之间的依赖和相似性引起的协同问题，要怎样调整组织架构来解决。

如果 A 产品和 B 产品类似，或者 X 系统依赖了 Y 系统，很直观的做法是将负责这些产品和系统的团队放在一起，由同一位负责人来管理。但实际操作时会遇到问题，A 的一部分和 B 很类似，但 A 的另一部分又和 C 很类似。但处于现实原因又不可能将 ABC 三个团队放在一个主管下面，而且这样的问题还有传递性，环环相扣。如果单纯按照产品系统来进行组织设计，做组织架构调整时候可能会陷入一种永远调整不完，按下葫芦浮起瓢的尴尬境地。好不容易调整得差不多了，又到了下一次调整的时间，龙头动一下要很久才能把龙尾也摆直了，给组织带来了不必要的内耗。

我个人的观点是，组织架构的设计主要要看业务与人才的考量，而应通过技术手段来消除系统相似度和耦合度带来的困扰。To B 的产品和技术很复杂，系统之间的交互是图状模型，现实中很难做到完美的划分。既然如此，是不是可以换一种思路，把系统交互的因素降低到最低，尽可能消除部门墙。在设计产品和系统时，假如都能把自身的职责和接口定义清楚，那么不管上游下游系统是不是在一个部门内，至少从技术上就能做到不依赖组织架构。如前面提到的例子，调用你系统的团队可能在隔壁，也可能在另一个城市，甚至可能根本不是一个公司的。如果能尽量消除这种差异，那么做组织架构设计时就少了很多障碍，从而更好地帮助组织架构升级。

微软的所有产品把自身的开放 API 通过 Microsoft Graph 统一网关提供给开发者，以此来促进开发者生态的繁荣。而更重要的是，内部一方系统的交互也是通过这个平台完成的，遵从了一方即三方的原则。在这样的原则下，部门负责人可以更多聚焦在客户需求上，而不是把精力浪费在所谓的内部系统与外部系统的讨论中。微软还有一个很好的例子，用户要使用 Word 并不是一定要下载 Word 的 App，而可以通过 OneDrive、Teams、Outlook、SharePoint、Offce.com 等任何一个 App 和网页版，而这些部门也不用去争吵到底是谁的用户。海外一些 IT 公司做到了所有部门代码向全公司开放，甚至有的公司使用巨大的 mono repo，本质上也是把技术因素所带来的协同障碍降低到最低。开放不仅仅是个产品技术问题，也是一个理念和管理问题。

技术为业务服务，但如果技术即是业务，那么也不要让生产关系阻碍了生产力的发展。技术团队是否有话语权，是否能够聚焦打造产品和技术壁垒，也是组织架构设计的关键。

人说互联网唯快不破，也有张小龙突击开发微信的成功案例，这句话放在 To C 互联网上是真理，但放在 To B 产品里容易成为坑。To C 互联网要建设交易平台，要打造关系链，用户粘性是一切商业模式的基础，抢占先机至关重要。反观 To B 领域的 SaaS，这个逻辑是很不一样的。在 To B 里面我们已经看到了无数后起之秀的成功案例，有的后浪把前浪拍的死死的。这种现象的核心原因是 To B 产品通常靠产品能力取胜，而不一定在于产品上有多少用户。

To B 产品的数据属于客户而不是厂商，所以客户在决定是否使用和何时使用某产品时处于完全的主导地位，这就不是一个简单的快和慢的问题。一些 To B 的厂商故意给客户数据迁移设置产品和技术门槛，希望以此留住客户，我认为这是短视的表现。我同团队强调过，如果客户要来我们铺着红地毯欢迎，如果客户要走我们也铺着红地毯把客户送走。数据迁移能力本身就是产品能力和开放能力的表现之一，而一些客户在选择厂商时候本身就会考虑是否能安全地讲数据迁移走。在这个逻辑下，在某个产品功能上比对手快并不一定会带来明显的优势，甚至还会帮对手承担试错成本。

文章前面讲了那么多观点，但如果不给产品和研发足够的时间来把这些事情做好，都是白扯。从工程角度讲，任何产品都应该追求快速迭代，因为这关乎效率和成本，但前提一定是以高效的方式来迭代。假如一味追求上线时间，打乱开发节奏，甚至跳过一些必要的步骤，抢来的时间还不够被后面填坑浪费的。

既然选择做 To B，就选择了长期主义，看微软、AWS、SAP、Salesforce 都是几十年经营的成果。当下最耀眼的 Open AI，也是耕耘多年才开花结果的，不同于国内互联网行业普遍赚快钱的心理。微软的 Teams 虽然比 Slack 晚了几年才出来，但轻松超越，核心原因在于微软沉淀了多年的产品和技术能力，而这些都不是一朝一夕就能构建的。一位行业前辈说过，To B 产品一旦推出就要准备好支持客户二十年，否则就不要随意上线。做 To B，不要高估一年能做的事，也不要低估十年所能做的事。

IT 行业是一个必须持续创新的行业，不创新一定会死，但创新不是搞机会主义。To C 互联网常常讲试错，通过快速迭代来寻找机会点。To B 产品成功的关键是踏实做事，打造有匠心的产品。最近十年貌似并没有见到一个 To B 产品因为什么灵光一闪的 idea 的突然获得成功的，而那种 idea 也往往没有什么门槛，可以被对手轻松照搬和超越。那种觉得自己有一个前无古人后无来者的绝对创新想法的，往往是危险的浪费资源信号。

创新往往是朴素的，是相对的。由于企业基因和文化的差异，绩效评估方式的不同，一件在 A 公司做很容易的事，拿到 B 公司来可能就是登天的难度。如果一个人能在自身企业和组织的大框架下拓展一定的空间来完成一件在这个组织不容易做的事，我认为这就已经是巨大的创新了。

虞雷，微软 Azure Identity 首席总监、前阿里资深技术专家、钉钉产品技术总监、阿里邮箱总经理、前 Office 365 首席工程师。