从程序员到 CTO 的十年创业血泪总结（八）：原教旨主义 SaaS 与中国特色 2B 软件

曹犟

发布于 2026-01-16 11:24:11

120

前文回顾

在之前的一系列文章中，除了中间插入一篇从程序员到 CTO 的十年创业血泪总结（六）：当大模型遇见 2B 软件之外，基本上按照整个创业的主线过程，把我的一些思考与总结分享给了大家。而神策毕竟是一家 2B 公司，确切说当前定位是一个企业级软件公司，我个人过去十年的经验更多也是在 2B 软件的产品与工程管理上。所以，接下来，则会侧重于分享我在 2B 软件行业的一些经验。

作为一个程序员和软件工程师，在这篇文章中，首先分享一下我在 2B 软件的软件工程管理方面的一些认识与总结。

1.原教旨主义 SaaS 的水土不服

之前在国内环境中提到 2B 软件，不论是投资人还是创业者，亦或是普通大众，都容易将之与 SaaS（Software As A Service），特别是北美 SaaS（我们私下讨论会将之称之为原教旨主义 SaaS）混为一团。而所谓的北美 SaaS，主要有如下这些特点：

采用多租户公有云的部署方式；
收费模式是按照用量计费的订阅制模式；
在销售模式上，以 PLG 自下而上的方式作为切入点，部分产品在切入到企业级市场时才会谨慎地组建销售团队尝试 SLG；
基本只解决客户一个环节的问题，彼此之间有非常好的 API 来进行集成，一起解决客户的全链路问题。

北美 SaaS 不仅占据了这么一个全球最大、利润最丰厚的市场，在收入和估值方面领先全球。同时其商业模式本身，在毛利、客户黏性、收入可预测性、研发效率等各方面都有其先进性，所以在中国 2B 行业兴起时，投资人与从业者也依然愿意去模仿、去追求这种原教旨主义 SaaS 模式。但是正如之前的文章中所提到的那样，在我个人的观察与总结中，全球市场只有北美才是特殊的。原教旨主义北美 SaaS 在其它市场，特别是中国市场，会遇到很明显的水土不服的问题。但因为北美市场足够大，大到超过全球一半以上的市场份额，所以北美 SaaS 厂商并没有多大动力去适配其它市场。

就以中国市场为例，中国 GDP 虽然与美国达到了相近的体量。但中国 GDP 中相当大一部分是国央企，而能够接纳原教旨主义 SaaS 的企业，如互联网公司、跨国零售品牌等类型企业所占的比例却并不高。这个也客观说明，如果完全照搬原教旨主义 SaaS 的模式，在中国只能服务国民经济中相当局限的一部分。

本文暂时不讨论这种情况是否正常，以及十年、二十年后的终局会是什么样子，只是讨论如何应对这种情况。

面对这种局面，企业当然可以有不同的路线选择：

坚持原教旨主义 SaaS 的模式，接纳只能服务部分客群，收入天花板有限的事实。而以出海，或者说商业全球化，作为收入突破客群限制天花板的手段。
不执着于原教旨主义 SaaS 的模式，坚持以客户需求为核心，将国央企等有独特需求的客户也视作自己的目标客户，并且为这类客群去打磨产品、服务和商业模式。

两种路线并没有对错之分，只是不同的商业模式的选择。那么，如果要选择第二种路线，打造“中国特色”的 2B 软件，有哪些特别之处呢？

2.部署方式

原教旨 SaaS 基本都是选择一个特定的公有云，用多租户的模式（多租户指在同一个系统中，能够同时为多个客户也就是租户提供服务）部署整个系统。当然，在这个大的原则下，一般还会有内部开发系统、测试系统、客户尝鲜系统等。在这种部署方式下，软硬件资源，如网络、机器、数据库、操作系统、中间件由乙方（也就是 SaaS 公司）负责选择和提供。乙方也可以很方便地进行系统的运维，在保证质量的情况下，自己决定系统的版本节奏。除此之外，开发和运维也可以充分使用特定公有云的各种设施，大大提升效率。

而面对中国市场的特殊情况，一个中国特色的 2B 软件公司，如果想覆盖所有客群，那么除了提供多租户 SaaS 服务部分市场化程度好的客户之外，还需要提供私有部署的方式。

所谓私有化部署，是软硬件资源由甲方（也就是客户）提供，乙方蜕变为纯粹的软件提供商，将自己的软件安装在甲方的硬件环境中。甲方的硬件环境，可以是各种不同的公有云，可以是自己搭建的私有云，也可以是各种不同年代、不同品牌的物理机。特别的，还有中国特色的信创，是指要乙方的产品适配各种国产的 CPU、操作系统和中间件；而在信创之上，还有难度更高的混部，也即要求乙方将自己的系统部署在甲方的平台上，作为平台的一个特定应用。

在这种协作下，会有很多在多租户 SaaS 下根本不会有的问题。

首先，乙方的开发成本大大提升，不仅不太方便使用公有云的各种设施，还需要在系统层面适配各种不同的软硬件和平台，开发效率相比多租户 SaaS 会大大降低。而这种软硬件多样性，也会导致系统整体的稳定性得不到保障。需要说明的，这种效率和稳定性的降低所带来的成本和风险，甲方也会在事实上承担一部分。

与此同时，由于软硬件是甲方提供的，乙方的各种售后和运维操作也是有各种合规与安全限制。乙方要么花巨大成本提供文档、工具和培训让甲方的运维来获得系统运维能力，要么以低效不便的方式，如 VPN、驻场等来进行运维工作。但不管哪种方式，运维的便利性都是降低的，系统稳定性也因此得不到最好的保障。

除此之外，在这种协作下，乙方提供的不是服务而是纯粹的软件，所以系统是否升级，升级到哪个版本，都是由甲方来决定的。版本的分裂是必然会发生的。因此，一方面甲方不能及时享受到最新的功能特性，一方面乙方也需要维护多个不同的版本分支，不仅开发效率降低，也会带来软件工程管理方面的挑战。

从上面的描述可以看出，如果不考虑合规、安全、可控等收益，私有化部署相比较多租户 SaaS 肯定是一个对甲乙方都不利的选择。当然，在很多客户那里，合规、安全、可控等本身就是最大的收益，对于这一点，在不能改变的时候，坦然接纳事实即可。

只不过唯一让人觉得可惜的是，很多市场化程度很好的客户其实并没有那么强的必须用私有化部署的理由，但是因为市场上有这种选择，并且多个乙方互相内卷式竞争的情况下，也选择了这种方案。这种情况下，甲方自己的利益其实并没有得到最大化。

3.收费模式

原教旨主义 SaaS 的收费模式其实非常明确，就是根据使用的功能点与实际的用量，确定每一个时间周期的收费，然后按照时间周期以预付费或者后付费（通常只针对 KA 客户提供后付费）的方式收取费用。这种名为订阅制收费的模式在回款的确定性、客户续约的决策难度、收入的可预测性、客户的长期经营价值方面都有充足的优势。

而在中国市场中，虽然也有类似于神策这样的公司，针对部分市场化客户，在提供私有化部署的同时尝试按照订阅制收费（算是商业模式上的一种创新）。但是对相当一部分客户群体（以金融等国央企为代表），2B 软件公司还是需要反过来适配客户的预算逻辑，而很难坚持订阅制的收费模式。

这类客户的预算有时候会按照资产采购定价的逻辑来进行。例如，预算的结构大致是企业花 10 万元永久购买了某个软件的使用授权，每年再花 1.5 万元购买软件的维保授权。这一点与订阅制收费是根本性冲突的。当然，还有一些项目中，甚至是软件采购这个逻辑客户都无法接受，只能按照人力外包来立项。所以，明明是一个购买成熟软件的项目，但是往上上报的时候，却要折算成多少个功能点，多少个人天工时，然后按照工时单价来确定项目的总金额。

对于甲方的这类预算要求，2B 软件公司其实是基本没有任何议价能力的，只能对这类客户提供买断制的收费模式，也就是允许客户花费比一年订阅要多一些的钱，获取某个特定功能组合下软件，或者软件的某个版本的永久使用权。之所以会增加对版本的限定，其实也是 2B 公司对于自身权益的保护。客户如果要获取超过买断合同约束范围内的新版本，需要重新付费。而相较之下，订阅制收费模式下，甲方是可以在订阅期间有权利将软件升级到当前的最新版本的。

而对于按照人力外包来进行立项的客户，也只能在报价阶段花费相当多的成本来专门写一些针对性的材料。

至于在采购招标过程中，普遍存在的“最低价中标”，部分乙方投标时什么都承诺，交付时全部做不出来等系统性问题，由于不仅仅是 2B 软件行业存在，所以本文中不做太多的展开讨论。至于在部分客户存在的，要做我 200 万的项目，不仅不预付款，乙方先反过来交 50 万保证金等有趣的情形，则也是整个行业客观存在的事实。

4.从生态合作到端到端闭环

如前文所提到，在北美市场，每一个原教旨 SaaS 软件通常只解决一个细分场景的问题，同时对外提供非常丰富详尽的 API。由客户，也就是甲方自己的 IT 团队，根据具体的需求针对全流程构建完整解决方案。甲方要调用不同的 SaaS 软件解决不同环节的问题，不同环节之间，则通过 SaaS 软件的 API 进行数据和流程的流转。为了达到这个目标，一方面甲方需要有构建、实施整个解决方案的能力，一方面乙方应该有生态协作、开放共赢的生态，而不是想着上下通吃。

而回到中国市场，很多时候上述两个条件都不满足。

一方面，部分甲方没有能力或者也没有意愿，去构建和实施整个解决方案，并承担其中必然具有的风险。IT 团队更倾向于付出固定的成本，由某一个乙方也就是总包方，来解决自己的所有问题。

另一方面，2B 软件的从业者，特别是由于某些原因切入到市场天花板有限的细分市场的互联网巨头，也通常不会满足于一个特定的生态位。大家在过去十年，与投资人一起，都是在讲营收增长、估值增长、团队增长的增长故事。在这个大的叙事逻辑下，乙方自己也会自然而然地向生态位上下游延伸。

因此，在这样的一个市场条件下，中国市场的 2B 软件公司，自然而然会不满足于只解决某个具体生态位、具体流程环节的问题。而是不约而同地开始通过产品加服务的方式，试图去构建和提供端到端的完整解决方案。这条路并存在所谓对错，只是走上这条路，自然就会走向一个团队扩大、软件功能庞杂、事实复杂化的熵增之路。对于企业的内部管理难度、人效提升等，都是一个巨大的挑战。

5.是否要坚持“一套代码打天下”

2B 软件本身是管理最佳实践的具象化。而相比北美有一百多年现代企业管理经验，中国企业开始尝试现代化管理也就是最近小几十年的事情。这也导致同样一个业务流程，在不同客群可能并不一定存在公认的最佳实践。这自然也会导致不同客群在产品需求方面存在巨大差异。除此之外，前文中提到的部署、合规等业务之外的非显性需求，在不同客群之间也存在巨大的差异。

而作为工程师和管理者，自然会觉得，使用同一套产品，去满足不同客群的需求是一个效率最高的方式。过去十年，神策是这么做的，并且一直以“一套产品卖给国内外所有不同行业的客户”为荣。

那么，在这种指导原则下，为了适应不同客群不同的部署要求、合规要求、业务流程要求，甚至是对于产品配色、Logo 的自定义要求。2B 软件企业都不约而同走上了平台化这条路。试图将不同客群的共性需求进行抽象，然后通过对软件进行分层，以类似于插件的方式去满足非共性需求。这也是为什么过去很多 2B 软件公司都提出了 PaaS、云 OS、数据平台等概念，以及为什么低代码平台也曾经认为是中国 2B 灵丹妙药的原因。

不管是哪种概念，核心的指导思想，都是试图通过提高软件的复杂度，来进一步扩大软件本身对于客户需求的覆盖度，从而降低交付的比例。本质上讲，就是将项目上的一部分交付成本转移为研发费用，从而提高单项目毛利。从数学上来讲，如果客户数量足够多，需求共性也足够多，这的确是一种全局效率更高的做法。只不过自然会对产研团队在需求分级、架构设计、工程管理等方面，都有更高的要求。

而如果不追求“一套代码打天下”，那么就是针对不同客群开发不同的软件，代码分支和研发团队都分开。那么，有可能不同软件的研发成本加起来会变高，但是因为对于客群的满足度更好，单个项目的毛利会进一步提升。

当然，这条路极端一点，变成针对不同客户开发不同的软件，实质上就是变成了“软件外包公司”。而软件外包公司长时间处于互联网行业鄙视链的底部，甚至不被认为是互联网企业。在这种情况下，外包公司自然也会在不同项目之间有一些代码级、组件级的复用。

在这种情况下，如果我们将给每一个客户开发定制软件也视作研发行为，则研发成本进一步上升，但是交付毛利也会进一步提升。只不过很多时候，这些花在单个客户项目的开发会被视作项目交付的一部分，所以反过来会使得大家认为软件外包公司的毛利要低于 2B 软件公司，这也是软件外包公司不受待见的一个重要原因。

在现在这个时间点，由于中国 2B 软件市场的天花板已经明显浮现，并且国内不同客群之间的需求差异度也实在太大，作为一个工程师，我个人也很难再继续坚持“一套代码打天下”这种做法是最理想的做法。虽然它看起来真的更符合工程师思维，更能发挥优秀程序员的杠杆作用。

稍微插一句，根据我个人当前不算完备的数据与调研，在金融这个特定行业，能够获取稳定利润的通常是软件外包公司。而所谓的“2B 软件企业”，不管规模大小，不管技术实力有多雄厚，都曾经长期处于亏损状态。而在 2C 互联网行业长期存在的，先亏损获取市场地位，再提价获取利润的做法，在 2B 这么一个天花板非常有限的市场是否还能奏效，就是一个见仁见智的问题了。

只不过正如我在从程序员到 CTO 的十年创业血泪总结（六）：当大模型遇见 2B 软件这篇文章中表达的观点，大模型时代，也许直接拷贝复用代码就是最好的复用，中台、平台化等，并不一定是最好的选择。那么，在这个新技术趋势下，中国 2B 软件还一定要坚持一套代码打天下吗？也欢迎大家与我讨论~

6.版本语义与生命周期

如果依然坚持一套代码打天下，也就是同一套软件既可以私有部署，也可以 SaaS，收费上既可以买断，也可以订阅制，那么，在软件版本管理上则也需要做非常精细化的管理。

软件版本是指软件在开发、升级和维护过程中形成的不同迭代状态，用于标识软件的功能、性能、稳定性等方面的变化。它通过版本号体系进行管理，帮助用户和开发团队区分不同阶段的软件形态，同时也便于版本控制、问题追踪和更新推送。版本号一般有四位，例如，此时此刻，我的 macbook pro 上安装的企微版本号如下所示：

版本本来只应该是一个研发团队内部的工程管理问题，但是由于买断制这一收费模式的存在，导致在售卖的时候需要对客户暴露版本号。同时，由于私有部署这种部署方式下，2B 软件公司对于系统的运维管控能力其实相当薄弱。这也导致传统互联网那种，快速迭代、快速试错，在这种模式下会变成一种灾难。这些问题都会要求 2B 软件公司，在版本的迭代管理上面临远超互联网公司想象的难度。

由于大部分读者可能都不会从事中国特色的 2B 软件研发管理工作，所以更多细节不再展开。

在这里简单提供一个神策内部，在多年摸爬滚打踩坑之后，总结形成的当下的一个版本语义的大致示例：

一/二位版本：
- 内部简称“大版本”，是客户买断的基本单位。买断客户在同一个大版本内可以免费升级。
- 通常情况下一年半左右一个版本。
- 每一个大版本通常都需要有足够的价值主张增量，从而吸引客户付费升级。
- 每一个大版本的增量价值主张都需要进行 PMF 和 GTM。
- 大版本上允许进行大的架构变更。
- 需要进行完整的回归测试。
- 大版本需要设置 EOS（End of Service）期限，也即停止修复 bug 和安全漏洞的时间。通常是 GTM 后的 36 个月。如果没有 EOS，则维护老版本的成本将无限蔓延。
三位版本：
- 内部简称中版本。
- 通常情况下一个季度一个中版本。
- 每一个中版本通常都是在大版本的价值主张增量下做具体功能的迭代演进。
- 中版本允许进行元数据变更，不允许进行架构变更。
- 需要进行完整的回归测试。
四位版本：
- 内部简称小版本。
- 通常情况下可以做到一周一个小版本，但是有严重 bug 时发版可以更快，当版本质量稳定时发版也可以更慢。
- 四位版本通常以修复 bug 为主，对于一些客户急需的功能 feature，酌情允许通过四位版本增加。
- 只允许进行二进制变更，不允许进行元数据变更。
- 除了自动化测试之外，只针对变更做针对性测试。