软件产品的技术门槛

Posted 2021-09-04 刘超

我曾经是移动互联网创业者，现在做软件领域的风险投资。我在工作常常遇到一个问题：怎么衡量一个产品的技术门槛。我自己抽象出一个衡量技术门槛的方法论。这个框架对软件产品是最适用的，这是我最熟悉的领域。但这种思考框架对于硬件产品例如芯片、医疗设备、消费电子、机器人也是部分适用的。

首先给技术门槛一个定义。如果竞争对手要做一个跟我们一模一样的产品，他需要雇佣什么员工；他需要克服哪些困难，踩哪些坑，做哪些工作；这个产品打造的过程需要多少钱，多少时间。复刻产品的过程通常就能反映一个产品的技术门槛。

这当然是对技术门槛的窄化定义。因为对手复刻了产品的所有技术面之后不见得会带来一模一样的产品体验。除了技术方面，产品体验往往还有很多其他决定因素：产品中的数据沉淀，数据对算法和模型的改进，例如同样都是短视频推荐，你可能做不到头条那么精准；海量用户使用产品过程中产生的网络效应，例如一个复刻的QQ，但早期没有用户使用和社交关系就没办法冷启动；品牌和价格对用户心态的影响，例如教育产品里面名师效应会更好做付费转化，也会让用户更加认可教育效果。这些因素毫无疑问都是公司的竞争门槛，甚至从长远来看是比单纯的技术门槛更重要的核心竞争力。但这篇文章会更聚焦于单纯的技术门槛本身，这是很多初创公司从0到1最重要的一步。

---

大多数产品的技术门槛由三个方面组成：系统设计（System Design)、工程实现（Engineering）和知识窍门（Know-how）。

系统设计是指系统的架构设计，以及它里面的宏观技术决策。软件系统设计是对复杂事物的抽象，更好的设计代表着更优美的产品体验和更快捷的产品研发。例如我们要设计一个用于医药临床试验的SaaS产品，需要把整个临床试验中的所有参与方、所有流程、所有政策做抽象，形成系统模型和数据模型。这种系统设计既需要设计者非常了解行业，知道各种需求背后的含义，又需要设计者非常有系统设计的经验。良好的系统设计可以适应更多的需求，也可以在后期做更容易的扩展。

复杂系统设计通常要把很多因素放在一起考虑，做出 trade off。常有人说没有完美的系统，因为多种因素互相牵制，满足A就会牺牲B。所以架构设计最大的考验，一是同时处理很多互相制约的因素，按下葫芦起了瓢是很形象的比喻；二是对产品需求要有深刻的理解和预判。产品要定义最重要的使用场景，重要场景在做系统设计的时候被首先满足。同时产品设计者还要考虑产品未来可能的发展方向，提前把扩展性放到系统设计的考虑中来。系统设计和产品设计是同步完成的，找到合适的产品定位，哪些做哪些不做，未来市场会发生什么变化。所有最好的系统设计者通常需要跟最能理解和预判需求的产品经理合作，或者两者干脆合为一人。

工程实现门槛首先来源于工程当中的工作量，用软件工程的术语来说就是人月。例如像 Office、钉钉、数据库这样非常复杂的软件需要很大的工程师团队做非常久的开发。其次是这个软件开发所需要的工程师的稀缺性。复杂系统和算法的实现常常需要非常高明的工程师，并不是随便招募工程师就可以胜任。

Know-how 指的是算法、诀窍、行业洞察。Know-how 门槛本质上是认知的稀缺性。认知稀缺往往是一个事物在新出现时的特点，例如：新的 AI 算法、新的运维方式。新的技术在刚出现时，比较少人掌握，因此有很高的认知门槛。这样的认知稀缺往往是有时间窗口的，随着时间推移认知从最好的技术团队向更广泛的人群普及。例如深度学习在2015年以前都非常稀缺，在2020之后在一线公司里甚至已经开始过剩，但在二三线公司和传统行业仍然稀缺。

软件开发有很多技能领域，有的技术领域是很少有工程师掌握的，这也是一种know-how。通常越接近底层和硬件的软件，其工程师也更为稀缺。例如编译器、操作系统内核、图形图像，他们是比较专深的领域，在市场上有这些技能的工程师非常稀缺。一个需要稀缺技术能力的软件项目显然是门槛更高的。

---

在各种软件产品中，Infrastructure 软件是我非常喜爱的一种高门槛软件。因为他们往往是非常复杂的系统，例如存储系统和数据库。这些系统涉及到很多复杂算法和机制，既有算法 know-how 又有系统设计门槛。很多基础软件的核心系统在早期并不需要特别大的技术团队，但要求早期成员有很高的技术水准。即便是在大公司，也很难用大团队和大预算来加速基础软件的核心研发。因此创业公司如果能够聚齐十人左右的高水平工程师，就基本跟大公司在软件核心研发上形成了平等竞争的局面。

一些离硬件更近的软件有很高的门槛。例如智能网卡里面的软件，因为 FPGA 的人才比较稀缺，曾经做过网卡的人才也很少。

行业应用 SaaS 也有相当的技术门槛。行业 SaaS 的设计需要结合行业 know-how 做非常好的系统设计。另外很多行业设计都有非常丰富的功能，这些也是工程实现的工作量的累积。

---

以上是我衡量软件产品的技术门槛的思考框架。肯定会有不足。欢迎交流探讨。