前言
工作中，常有人纠结，说我们是做项目好还是做产品更好。都知道我们没有产品，都是做项目的。支持做项目模式的说，我们现在项目挺多，客户也多，不愁没项目，虽然辛苦点，也过得去，产品哪有真么好做的，再说了，产品也没法满足用户的个性化需求啊，不能做产品；支持做产品的说，光做项目太辛苦了，做产品有规模效益，边际成本很低。我们已经做了这么多项目，应该抽象需求，提炼出产品来卖，只要量上去，还用担心收入吗！这确实是个纠结的问题，怎么选择。
在论证这两种方式之前，先给这两种模式下个定义。这两种都是企业信息系统交付模式。这里所说的项目模式，是狭义的模式，是指信息系统的交付，不基于已有的产品或者半产品，所有的项目都是从源码级别，根据客户的需求，重新进行设计，编码和交付。而产品模式是指，基于社会上同类系统的公共需求、设计开出具备特定功能，满足特定需求的软件，作为产品交付给客户使用。
一、先说项目型交付模式。
我们公司90%以上的项目是采取的项目化交付模式。
这种交付模式的过程大体是这样的。拿到项目后，看看之前有没有做过类似的项目，如果自己没做过，就问问部门的其他人，或者公司的其他人。如果有，就把当时的方案拿过来参考参考。然后调研，设计，编码。有类似的项目，就把项目的源码复制过来一份，数据库也拿过来，稍作清理，作为新项目的开发基础。不可避免存在清理不彻底的情况，代码里有很多废代码，数据库中有很多不用的表，甚至还有其他项目的数据。在开发中，碰到新的功能，如果自己之前做过，活且其他人做过，就就把代码复制过来，稍作修改拿过来就用。最终完成交付。
这种方式有什么特点（我们不说优缺点）
1，项目中废代码非常多。
一个个项目复制过来复制过去，清理的不彻底，代码中的多余的代码越积累越多，数据库中的表不用的也越来越多，不用的数据也越来越多，尤其是配置表中，系统表中的数据。谁也不敢删，不知道有用没用。
2，开发人员的体验非常差，给新人起了坏榜样。
项目非常不干净，对有洁癖的人来说，兼职是一种折磨。本来系统开发就是一种比较严谨的事情，这样一弄，这一原则严重被打破，风气被严重污染，从而会影响人员的斗志，影响严谨的开发态度，影响项目的质量。尤其是对新人来说影响更坏，差不多就行，马马虎虎等风气盛行，多余就多余吧，反正也不用他等等。我在带项目的时候，就碰到很多人这种工作态度。这种工作态度职能开发出来能用的系统，开发不出来好的系统。
3，做不出好的系统。
项目没有一个不是时间紧张的，时间紧，设计就会不足，就会仅仅满足当下的要求，没有普遍性。反正是做项目嘛，交付了就ok了。项目的目标是如期交付满足当前用户的要求的系统，而不是一个好的系统。项目好坏的评价标准和产品的评价标准是不一样的。
4，重复的工作。
开发工作重复，本来之前已经做过的东西，职只能从代码级别复用。借用时，还要从代码层面评估是否满足当前需求，不符合，就要打开源码修改，修改就不可避免出错，甚至把之前正确的代码改错了，需要全部重新测试。因为你不能保证拿过来的代码时最新的，是否和数据库版本一致。
5，项目质量难以保证。
时间段，测试不充分，没有经过长期的考验，即便是勉强交付了，运维的成本依然很大，甚至交付n年了，系统仍然不稳定，需要修改。这时候修改的代价就很大了。没有文档，不熟悉代码，当时的开发人员调走了，这都是障碍。
6，模块或者功能无法持续优化
在一个项目上发现了bug，明知道其他项目也存在，但是得不到修改。一是因为其他项目当时并没有暴露出来，再一个也不敢修改，谁能保证修改这个一点，不会有连锁反应，导致其他的问题呢，甚至是雪崩效应呢；其三是没有修改的积极性，不是我的项目我也没有义务说，没有义务去修改。待到同样的问题暴露出来，只能是再重复之前的过程，发现问题，分析问题，定位问题，修改问题，测试问题。因为这个问题并没有记录下来，谁也不知道其他项目上曾经修复过这个问题。
7，后续运维的问题
铁打的硬盘流水的兵。项目交付了，项目组就解散了，谁来维护？也只能是原来的开发人员维护。这就出现了一个问题，我已经调岗了，客户还会打电话给我，原来的部门还会找我让我帮忙，碍于情面，只能帮看看，我现在的工作怎么办，肯定影响我现在的工作，在考核不严格的情况下，成本，时间，就慢慢这样耗光了，但是谁也意识不到问题出在哪里。如果让别人运维、修改代码，问题更大，需要熟悉代码，试着修改，保不住出其他的问题，如履薄冰，战战兢兢。这也导致维护的成本巨大。
我们的成本、时间、人员都被这些事情吞没了，而不自知。就和黑桐一样，吞没人员，时间，成本，激情，战斗力。只剩下无奈，疲惫，应付。
8，工作成果得不到有效的复用
复用是源码及的复用，而且是个人行为，局部行为。并且很多得不到复用，因为我不知道谁做过。源码级的复用，效率是最低的，也是非常靠不住的。
9，很难积累
都是项目，做完就完了。新的项目重头开始，只能部分借鉴历史项目的成果，而且是分散继承。如果沟通不畅，不主动复用和继承，项目上好的东西随着时间的流逝，逐渐丢掉。就像黑瞎子掰棒子，只剩下最后的一个，而且不一定是最大的一个。
10,无效的低水平的个性化
既然是项目，用户就会潜意识中认为是“完全定制系统”，会根据个人的喜好提出一个低质的，无关紧要的个性化要求，在一些无关紧要的地方耗费大量的精力，比如菜单样式，配色，字号，字体等等。而产品化则没有，或者很少这种情况，因为产品是在大量客户应用的基础上的最佳实践总结出来的，是经过时间检验的，能给客户带来实实在在的价值，客户潜意识里也会认同，一般不会在这种细枝末节上提出过分的个性化要求，而是将关注的点集中在业务实现上。如果用户开始在一些不重要的点上，比如菜单样式，提要求时，你就要警惕了。这里的潜台词就是：这家公司在业务功能上不会有让人激动的表现了。
纯项目模式造成的后果就是，几十年如一次，没有改良，一代代人重复着上一代人的故事，艰难前行。
好处
要非说好处，这种交付模式唯一的优点是对人的要求低：不要求复用，不要求抽象提升，不要求全面考虑，不要求代码质量有多高，只要满足当前需求，系统能用即可，从某种意义上讲，可以实现“快速”交付。
这种开发模式，也许做个别项目，交付会非常快，但是他是以局部利益牺牲全局利益，短期利益牺牲长期利益。不是可持续发展的交付模式。
二、我们在来说下做产品的交付模式
现在很多公司都是这种模式，大的ibm，华为，微软，bat等世界知名的企业，小的用友，金蝶等等。你看看哪个公司没产品，而且是一系列的产品。这种交付模式的特点是，一是卖标准产品，二是基于产品做个性化开发，属于半产品。
1、卖标准产品
适合那种需求稳定、有标准，供方驱动的领域，适合工具类，系统类或者应用范围比较小的领域。比如财务软件，报表软件，工作流，即时通软件，游戏，各种中间件等等。这类软件功能稳定，比较标准，或者说用户要求不高，一般是用户适应产品而不是产品迎合用户。这种交付模式，交付周期短，边际成本低，利润高。
2、基于产品的个性化开发。
在产品的基础上，对需求进行差异化分析，看看产品标准功能和用户需求差异有多大，分析差异点，基于产品给出解决方案，通过配置，或者通过功能组合间接解决，如果实在无法解决，进行个性化开发。这种要求产品要提供个性化定制的功能，比如sap，标准功能提供了很多用户入口，也就是个性化嵌入点。
这两种模式，要求产品要可以：
1，产品功能相对完善（满足更多的目标用户）
2，可配置型强（一定程度上满足用户的个性化）
3，提供个性化开发点（在产品基础上个性开发，对产品进行增强）
这种方式的优点
1，交付周期短。因为有产品，产品部分能满足要求的不需要重新开发
2，交付质量高，标准功能，经过实战检验，稳定，bug少
3，能在交付过程中，吸收新的需求，不间断优化系统，使系统越来越强大。
但是也有缺点
1，对开发能力要求比较高
2，对产品的版本控制要求比较高
3，对产品的管理能力，策划能力要高
三、产品还是项目？虚假的命题
从第二种交付模式看，从来就没有单纯的项目交付或者产品交付。
因此开头的问题就是个假命题，不是二选一的问题。有产品，有定制，有标准功能交付，也有个性化开发的项目化交付。但是中心是，一定有一个功能核心 ，也就是产品。这个产品就像滚雪球的最初的小雪球，是核心，越滚越大。有了产品，那么代码的复用，功能的复用，就水到渠成了，再也不是个人行为，而是组织的行为了，也不是偶然的而是必然的了。这才是最有效的复用。
四、从项目化交付到产品化交付
产品化交付，是大势所趋，是解决项目化交付的良药。纯粹的项目交付模式，利润率低，能活下去，但是非常辛苦。员工辛苦，公司艰难。
1，要有进取心，有决心
不能得过且过，论堆的思想，糊糊弄弄就这样了，反正这样也能活，虽然活的不是非常舒坦。
2、要有理想有追求
产品开发就是追求完美，和做项目不一样。做产品才是软件开发的本质，才是真谛。项目只是产品核心之外的壳子，是补充。
3，要有能力
有了产品的思想，还有开发产品的能力。抽象能力，总结能力，设计能力。只有系统的框架做的完美了，可扩展性强了，才能支持不断在交付中进行优化，进行扩展，才能进行个性化开发。而且个性化开发的部分能与产品有机组合在一起，而不是割裂的。
产品的管控能力要非常强。严格管理产品的分化，简历产品优化、良性进化的机制。
从需求搜集，分析，方案设计。哪些功能有普遍意义，可以键入到标准功能中，哪些是个性化的，要有这个辨别能力，这个辨别能力只要有业务专家来担任。要有一批有经验的开发专家，业务专家，共同围绕着产品服务。
结束语
产品研发不容易，产品有局限性，这是一些人反对产品化交付的主要理由之一。"我们项目做得好好的，做产品这么难，也不能100%满足用户的要求，为啥要做产品呢，咱不费那个劲。"
现在火的一塌糊涂的低代码平台，其实就是基于产品的（可复用组件）的典型的应用，使用已经开发的产品化的、功能稳定的应用组件，来组合搭建复杂的应用系统，而不需要编码或者只需要很少的编码。看到这个，你还觉得前面讲的项目化交付还有生存的空间吗？人家用3个月的工期，完成你12个月的交付，而且质量杠杠的，售后运维成本非常低。慢慢地，就会把项目化交付的生存空间挤占掉。
也许有人说，人家xxx，现在早就不提产品，而提服务、解决方案了，你还提产品，过时了。要注意，人家提这个，是在人家经历了产品化之路，积累了大量的产品，积累了大量的业务经验和解决方案之后，有大量的各式各样的产品做支持，所谓服务，解决方案，是产品的组合形成的。人家吃饭，你只看到人家吃第三个烧饼吃饱了，你也想只吃第三个，能坚持一整天？门都没有，想啥呢。
