每个软件公司的老板，都怀揣着一个共同而又远大的梦想——将他们的创意和技术转化为具有广泛市场影响力的产品。这个梦想不仅是对个人才华的认可，更是对团队辛勤付出的最好回馈。然而，这个梦想的实现之路，却往往充满了荆棘与挑战。产品化，意味着将一个创意或者技术从原始的、零散的状态，打造成一个功能完善、用户体验良好的产品，并推向市场，获得用户的认可。这其中的每一个环节，都需要老板和团队付出极大的努力。他们需要深入了解市场需求，挖掘用户的痛点，不断优化产品功能，提升用户体验。同时，他们还需要面对激烈的市场竞争，以及不断变化的技术环境。尽管路很难，但每一位软件公司的老板都选择了坚持。他们相信，只要心中有梦，脚下有路，就一定能够克服一切困难，实现产品化的梦想。他们鼓励团队不断创新，勇于尝试，不断挑战自我。他们自己也以身作则，用自己的行动和决心感染着每一个团队成员。
不过很多软件公司的老板们都跌倒在“60%”这个数字上，为啥是60%，因为在常规情况下，产品复用度达到60%以上可以被认为是一个比较不错的水平。复用度达到60%意味着产品的核心功能和组件能够在多个项目或场景中重复利用，减少了重复开发和维护的工作量。这有助于提高开发效率，降低成本，并加速产品上市时间。
然而对60%这个数字，大部分老板的追求终究是被错付了，理想中的60%复用度，跟产品实际呈现的效果是不一样的！这个不一样会让人经历3个悲催的阶段：
1、狂喜，以为产品达到要求了，快速铺开市场
2、煎熬，发现做产品比原来做项目还不挣钱，做的多亏的多，每个项目都延期
3、绝望，产品到底怎么了。
接下来我会来带着大家，深度分析这60%数字背后的原因：
一：“只有40%的功能要改”与“所有的功能都要调整40%”的区别
这两种情况在软件开发类项目中存在显著的区别，主要体现在以下几个方面：
1、影响范围与工作量
“只有40%的功能要改”：这意味着在产品或项目的功能集合中，仅有部分功能需要进行修改或优化。这通常意味着工作量相对集中，团队可以专注于这些特定功能进行改进，而不需要考虑其他功能。这种情况下的修改可能更为深入，但范围有限。
“所有的功能都要调整40%”：这涉及到产品中的所有功能，每个功能都需要进行一定程度的修改或调整。尽管每个功能的修改可能不如前一种情况深入，但由于涉及的范围广，总体工作量可能更大。此外，这种全局性的调整可能带来更高的复杂性和风险，因为需要确保各个功能之间的协调和一致性。
2、风险与复杂性
在“只有40%的功能要改”的情况下，由于修改的范围有限，因此风险相对较低。团队可以更加专注于这些功能，减少对其他功能的影响。然而，在“所有的功能都要调整40%”的情况下，由于全局性的修改，可能涉及到更多的依赖关系和交互逻辑，因此风险较高。这要求团队具备更强的项目管理能力和技术实力，以确保修改的顺利进行。
3、质量影响
这种大规模的调整往往伴随着极高的风险，因为需要确保在修改的过程中不破坏其他功能的稳定性和完整性。同时，由于涉及到产品的所有功能，测试和验证的工作量也会非常大，需要确保每一个修改后的功能都能正常工作，并且没有引入新的问题。
综上所述，“只有40%的功能要改”与“所有的功能都要调整40%”在影响范围、工作量、风险与复杂性以及用户影响与市场响应等方面存在显著差异。
二：我们先来看个故事，产品化给公司带来更大的负担
某服装行业的软件产品公司。该公司认识到项目制无法取得规模效应和成本优势，在公司成立产品研发团队专注在产品和共性需求的研发上，同时成立交付团队。交付团队的工作方式是，在实施客户项目的时候，先拷贝一个标品的分支，然后在这个分支上。客户的个性化占比在40%以上主要表现为：
1、70%页面都需要按客户的要求进行调整，虽然调整不大但也投入了大量的精力在页面的调整与联调联试上。
2、业务主流程看似相识，但逻辑又有差异，在产品实现的时候没有考虑为这些逻辑差异预留扩展机制，需要项目成员进行大量改造。
3、客户环境老系统集成工作量大。导致的结果就是：看似有标品却没有降低对实施人员的要求，同时增加了不同版本的维护成本，标品升级带来的新特性无法给到客户。
分析该故事的表现，我们不难发现这背后的核心原因：
1、项目交付：对项目交付的人员要求高，工作量大。而且每个点改的时候还要考虑原来的代码，无形加大复杂度。
2、售后维护：在客户变多以后，因为定制化逻辑直接修改产品，导致产品有很多版本，维护成本更高。
3、产品研发：额外增加了产研团队，并没有带来项目交付的成本。同时调查发现产研团队40%的精力在跟项目实施团队评审项目需求，判断需求是否应该有产研团队去支持。项目对需求完善时间要求紧，每天盯着研发进度，经常问“这个需求什么时候支持，我们等着用”。该产研部门的研发抱怨产品节奏乱，无法按照自身节奏进行迭代，被项目推着走，没有时间思考，人手不足，加班多，工作压力大……
三：如何才能达到软件公司老板的梦想
如果要真正达到60%的功能复用，我们需要换一个思路，同时解决上述故事中面临的三个核心问题：项目交付、售后维护、产品研发。
在2017-2019年我在阿里云负责零售行业中台项目交付的时候，因为项目预期达不到，虽然不是项目上不了线、交付不了，也碰到了60%的陷阱。这让我深深地开始思考，如何把互联网技术与业务的最佳实践产品化的输出。当时我组织了10余人技术骨干开始调研国外的软件公司，包括Salesforce、NetSuite、Odoo等等。得出的结论是：在数字化时代，中国在互联网化的应用、技术的领先毋庸置疑，但在软件的工程化、产品化输出方面仍有许多改进的空间。我们当时有句话：“不说跟美国、德国比，在软件工程化领域就连比利时都比不上”。也是在这时，我了解到了Odoo——一个国外非常优秀的开源ERP厂商，全球ERP用户数量排名第一，百级别员工服务全球客户。Odoo的工程化能力和商业模式深深吸引了我，它是软件行业典型的产品制胜和长期主义者的胜利之一。它倡导的“每个需求都是一个独立的模块”的工程化理念，也被我结合到了数式Oinone产品中。
在数字化时代中国软件将接棒世界，而数式Oinone也要接棒Odoo，把数字化业务与技术的最佳实践赋能给企业，帮助企业数字化转型不走弯路！
可以说数式Oinone结合互联网技术最佳实践、传统软件的工程化理念，以及低代码设计思路。同时我们立志以效能工具为基础，做软件公司背后的软件公司。那么数式Oinone如何帮助软件公司真正做到产品研发、项目交付、售后维护三个维度同时提效，如何帮助软件公司从项目制真正迈向产品化呢？
1、数式Oinone提出的基于互联网架构的低代码平台，它采用无一体的设计。首先，oinone屏蔽了互联网架构带来的复杂性。其次，同样以元数据为基础，以模型为驱动，但是元数据的生成方式有两种：一种是使用无代码设计器（与经典低代码相同），另一种是通过代码来描述元数据。通过使用代码来描述元数据，可以无缝地与代码衔接，并在不改变研发习惯的情况下降低门槛、提高效率，并进行工程化管理。
低无一体不仅仅是指两种模式的结合，还包括两种模式的融合应用方式。具体来说，这种融合应用方式可以分为两种情况：
a.当开发核心产品时，主要采用低代码开发，无代码设计器作为辅助。这种方式可以提高开发效率和代码质量，同时保证产品的快速迭代和升级。
b.当需要满足个性化或非产品支持的需求时，主要采用无代码设计器，低代码作为辅助。这种方式可以快速地满足客户需求，并且避免对产品的核心代码产生影响。
简单来说，低代码模式适用于产品的迭代升级，而无代码设计器则适用于满足个性化和非产品支撑的额外需求。低代码和无代码模式在整个软件生命周期中都有各自的价值，在不同场景下可以相互融合，发挥最大的优势。
2、另外数式Oinone具备核心四大特性，绝对站在软件公司的角度出发，期望为行业带来改变，为伙伴提供支撑，为客户创造价值。
a、面向软件公司，每个需求都是一个独立的模块
这一特性与众多软件公司产生了共鸣。在今天，软件公司所面对的客户都有着众多的个性化需求。传统的做法往往是基于标品直接修改，这不仅导致软件公司需要维护多个不同的客户版本，成本高昂，而且客户也无法享受到未来升级带来的新特性。最终，由于版本落后，甚至可能导致客户流失。而我们能在不改变标品的情况下，通过新的模块利用平台的继承、扩展、重载等特性来实现对标品数据、逻辑、交互的修改，从而确保标品与个性化需求的和谐共存。
b、场景不受限制，帮不了忙的领域绝不添乱
当前，许多人对低代码或无代码的使用感受颇为复杂。简单的需求易于实现，但复杂需求要么需要厂商支持，甚至付出高昂成本也未必能满足。而Oinone遵循被集成原则，在无法满足需求时绝不添乱。用户可以以最熟悉的方式开发，甚至利用平台的扩展性将自己对平台的个性化改造沉淀到Oinone平台中，从而构建出属于企业专有的低代码平台。
c、系统性能不受限制，即应用级的扩容能力
我们在性能上真正实现了按应用级别的扩容。相较于市面上的低代码平台，无论是单体还是所谓的平台式微服务架构，其核心问题在于一个应用的问题可能拖累整个平台。以金网为例，他们曾选择了一家友商的低代码平台，但由于一个应用性能问题，导致所有应用无法访问。而我们真正具备按应用级别扩容的能力，这一特性还带来了另一个好处，即能实现应用级的隔离，避免一个应用问题导致整个平台崩溃。
d、为可分可合，即满足企业发展预期，又兼顾当下成本
即单体与分布式之间的灵活部署策略。在当前的技术选型潮流中，许多企业往往被潮流裹挟，盲目追求最先进的技术。以阿里推广中台为例，客户曾疑惑为何性能提升的同时机器资源却增多。这实则是客户对业务发展的预期与当前业务规模之间的矛盾体现。在数字化转型的热潮中，客户对未来业务的发展预期极高，渴望采用最先进的技术。然而，大部分软件公司对此矛盾视而不见，一味追求微服务分布式架构的入门标准。我们深刻理解这一矛盾，并为此推出了数式Oinone首创的可分可合架构设计。在客户业务规模较小时，我们提供单体部署方案；随着业务规模的扩大，我们又能按模块进行分布式部署，既满足了客户对未来的预期，又兼顾了当下的成本效益。这种需求认知正逐渐增强，正如近期一篇关于“微服务转单体，成本降低90%”的文章所引发的热议。许多软件公司尚未意识到这一问题，一旦意识到，想要支持这一特性却发现底层设计存在缺陷，整改绝非一蹴而就。
