作者：王永谦
本文摘自：《中国工业管理软件如何突围？》
供给方——软件服务商现状：
根据公司的经营特点可分为项目型和产品型，本文讨论项目型。
1.项目型软件服务商类型
· 全能型：这种公司是什么项目都做，成功案例企业的类型也是各个行业都有，无所不包。客户只要有需求，该公司就能做。要小心这类企业，人不是万能的，企业也不会是万能的。
· 聚焦型：通常只做某类产品或某些行业，这类公司几年后，通常会转变成为产品型公司。
· 资源整合型：通常只参与大项目，然后将项目分解给分包商，自己是总承包人。公司会有一些产品和IT人员。
· 人脉型：主要是国家/政府/大型企业的项目，公司的主要成员通常是学术权威或者人脉关系极广的人，项目金额通常比较大，利润也比较可观。看该公司的网站客户介绍，客户的相同点很明显。
· 代理开发型：代理其它公司的产品，为客户做二次开发。
· 转手型：公司消息多，公关能力强，项目通常都转交出去，赚取差价。
· 散兵游勇型：有项目就找几个临时人员开发，三天打鱼两天晒网。
2.项目型软件的优缺点
2.1项目型软件的优点
存在即合理。如果项目管控的好，既能保证质量，又能根据客户的实际要求定制，是个不错的选择。通常大企业有钱、有人、有技术，会采用这一方式。
· 一些企业的管理比较特殊，市场上没有现成的产品，只能定制开发。
· 项目型软件最大的优点是适应企业的实际情况，功能不多不少，刚好满足需求。
2.2项目型软件的缺点
·项目型产品无论大小，都是手工作坊形式，只是档次不同：有的是爱马仕，有的是农夫自己编的篮子。其本质是没有社会化大分工，性价比不高，不能提高整个社会的生产率。
通常来说，产品型软件的性价比要远远高于项目型的软件。原因如下：
· 业务经验。要开发产品，软件公司要对行业很熟悉，对业务需求和痛点也有很深的了解。
· 产品聚焦。有问题就不断地完善，因此产品成熟度高，功能更强。
· 规划清晰。开发产品相比较项目而言，规划更加详细，架构考量上也比较深刻，考虑到拓展性需求。
· 代码规划。开发过程中，对于编码的规范、文档、测试、运维相对于项目型软件要好很多。
我们来看看，通常的项目型产品是如何开发出来的。
· 软件公司通常根据项目的大小，派驻若干人员驻场，边梳理需求边开发。
· 客户的需求是匆忙制定的。如果客户经验不足，会影响项目的拓展性。客户IT人员通常不懂业务，客户业务人员也通常不懂IT。即使客户内部对业务和IT都很精通，其需求是不充分的，因为这要花费大量的时间去钻研，但每个人都有其本职工作要做，通常这些需要都是挤时间大家一起拍脑袋想出来的，是副业，因此很多想法太理想化。项目上线以后，会发现软件与其最初的要求背道而驰。
· 客户经常变更需求。由于一开始考虑不周密，客户难免会变更需求。需求变更意味着改代码，增加工作量，易造成甲乙双方矛盾。甲方可能对系统不满意；乙方由于频繁改代码而超出工期，没有赚到应有的利润，最后搞得双方都有怨气，双输。
· 语言的选择。项目制开发公司，通常空余下会什么语言的人，项目就用哪种语言，数据库亦然。因此，有些公司的开发语言多种多样，产品的界面也风格迥异，即使统一规定语言和数据库也难以避免，道理很简单，公司可以在一定时期内保持一种语言，但由于IT技术的不断进步，语言和数据库一定会变化。多语言、多数据库杂乱无章的现象不可避免，这是由项目型业态造成的，不是管理的问题，中国是这样，外国也是这样。且一个项目交付后，软件公司是不大可能主动能给系统迭代升级的。
· 架构的选择。除非客户指定，软件公司通常会选用已有的架构和模块，在此基础之上开发产品，因为这样最经济。软件公司不大可能依据客户业务的特点，仔细选型和搭建构架。
· 代码的质量。由于项目是有时间要求的，代码的质量很难保证，各种嵌套，逻辑混乱。即使给足了时间，也不要期望代码的质量会改善，以交付为目标的项目型软件，必然是以能通过甲方验收为标准的，这对乙方是最理性和最经济的做法。
· 程序员的水平。企业是追求利润最大化的，必然要考虑到员工的薪资，能满足需求就好。所以残酷的现实就是项目开发公司往往留不住优秀的员工，除非能提供非常优厚的报酬。有本事的人不大可能会满足每天没有创造性的劳动，必然会去寻找更好的机会。
· 系统升级。随着系统的使用，甲方总要优化改进。由于项目都是以快速交付为目的的，很多地方都写死了，大概率也没有开发文档，就连开发者本人来修改，估计也要花费很长时间才能看懂原先的逻辑。如果多年以后，公司没有人会当初开发时所使用的语言和数据库，这简直就是一场灾难。
现在还有的软件使用Cobol语言，但会这种语言人真是不多了。系统运行越来越慢，但又没有方法改进，除非彻底换掉该系统，但是这个系统里面还有大量的历史数据，真是两头为难，此类例子屡见不鲜。
还有的软件系统是大学老师带着学生开发的，学生毕业后，升级就非常困难了。
· 系统的稳定性。实现功能的代码量与为预防非正常事情的代码量通常的比值为多少？大约是2：8，甚至是1：9。 写出预防非正常事件的代码通常是优秀开发人员的习惯，同时还要有大量的实践经验。另外，系统测试和客户反馈也是很重要的信息来源。产品型软件经过多年内部测试和外部使用，bug会控制的很好，项目型软件则不会有这样的改进机会。
· 服务水平。应该说绝大部分软件公司都是想服务好客户的，这一点毋庸置疑。但项目型软件公司有没有这个能力才是问题的关键。
我们想着重强调一下，服务水平通常与服务能力更相关，而不是服务态度。甲方对乙方的服务不满意，更多的原因是乙方没有能力服务好。
我们可以脑补一下客户发现bug时的情况。首先公司要安排人记录问题，如果软件公司什么项目都做，项目的种类很多，则客服人员未必能完全理解甲方的问题描述，还得让技术人员再次详查。如果是当初的开发人员已离开或时间久远，还得重新梳理系统逻辑。企业对于bug修复的时间容忍度是相当低的，无法想象生产停顿下来，长时间等待软件的修复。
没有软件可以完全避免bug，但可以做到的是：避免严重问题，降低bug率，快速反应。项目型产品，除非甲方完全知道如何控制软件质量，并且能付得起高昂的价格，否则效果不会太好。
· 失败率。现在我们没有关于项目型产品失败率的统计，但是听到很多关于项目型软件失败和废弃不用的新闻。即使是成熟的ERP软件的失败率都能达到50%，那对于大部分订制化的项目失败率则会更高。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。