怎样提高项目的复用程度？

文章作者 100test 发表时间 2007:03:16 08:54:57
来源 100Test.Com百考试题网

地球人都知道，中国的企业特多，企业的市场特别大。做好了，就不愁吃喝了。但是，很多人都没想到，企业实行的是自负盈亏，用钱是特别谨慎的，不能走高投入高产出的方式，必须走低投入中产出，甚至是走低投入低产出的方式，必须上量。具体到每个公司时，则必须把以前所做的项目中包含的个性化的内容归纳出来，提取共性，提高项目中可复用的程度。最终使项目能满足起百分之七八十的企业的需求，预留部分容易修改需求给客户，满足客户所谓个性化需求，定制的愿望。如果根据提高复用程度后进行的定制项目部门所产生的成本只占应收款的40％以下，则证明项目提高复用程度进行得比较成功。提高复用程度后，又能进行大量得定制项目，则项目所产生的累计.利润，则相当客观。
但是，要将一定范围内但又包含各式各样的个性化需求项目做到复用程度很高，是比较难的。在这里主要从项目管理、公司制度管理的角度进行探讨，希望达到抛砖引玉的功效。
项目复用很多人在做，但失败也很多，归纳其原因如下：
1 原因归纳：
1.1 销售方式上存在的问题：
现在的模式是：市场的根本不管你开发的死活，先接了再说，反正有业绩了，也不管能不能做，什么都答应下来了，根本不管能否验收，能否收回所有款额。这样做就好似是：市场出考题，开发人员做答，客户作评判。自然，销售就喜欢出怪题，偏题；开发人员只能根据考题学习新知识，见招拆招，向客户套答案等等，成本加大；如果客户关系到位，要求不严，客户也没有现成的答案，就一切都过关；如客户要求严格，心中有标准答案，就会麻烦；
我们是否有能力将现有模式修改为：开发人员圈定考试范围，销售人员出考题，开发人员随时作答，客户作评判，即使是做了，归纳总结后，出错的概率会逐渐降低；
1.2 单纯以项目为核心的弊端；
在参与项目的过程中，我发觉这样的一种现象：我针对特定的项目提的意见或建议，从通用性的角度去考虑，即使是项目经理本人也不会否认。但是这些意见和建议是不会落实到特定的项目中。深究其原因，不是项目进度紧就是觉得没必要。反正改不改都不会影响项目的验收。对某个项目的用户而言，是否存在这种需求就是个未知数。即使存在这种需求，最起码到要到验收后才发觉，那就是维护的事情啦，跟项目无关。反正就是抱着侥幸心理，能蒙混过关就行啦。
1.3 开发人员、部门人员中对用户的心态，不是以用户为本，没有将用户当人看，至少是把用户当作机械人。
这是社会做做项目的一种心态：从需求分析说明书就恶意欺骗,你签完字东西我给你做了,不符合要求,不要紧,可以做二期嘛,钱我先到手再说!部门的开发人员或多或少都存在这种想法，我还听说过，什么操作负责一点，繁琐一点那才好，用户才会感觉技术含量高，有成就感，用的钱才值。用户要改的内容，就是不该，用户也拿我们没办法。
如果我们的开发人员天天都使用自己开发的软件、方案，那我保证他绝对会“后悔”当时的做法。我们现在地做法是，只要能满足功能上的需求就行啦，细节问题就没必要考虑啦。现在，软件的同质化越来越严重，功能都大同小异，区别的是细节的处理的不同。举个例子，有两家超市，货品的档次、服务态度、信誉等都一模一样，反正就是各方面都相同，都能满足人民购物的需要，但是仅仅是因为一家超市在十字路口，一家离十字路口只有100米的距离。结果，十字路口的超市就比另一家超市的营业额、利润多很多。软件的细节就相当于超市的位置，其重要性可想而知。
举个开发人员“后悔”的例子吧。在某个BS项目中，在后期增加了一个功能，可以让用户自行控制权限点的设置。当时，开发人员就将所有的权限点列到权限分配中，当然不会去做分类啦。当时，我就建议，将权限点进行适当的分类，开发人员觉得没有这个必要。但在测试过程中，开发人员必须作配合，进行大量的权限点的分配工作。测试完后，连他自己都觉得有必要改。这就是当时没有从用户的角度考虑问题的后果。
2 改革建议：
2.1 建立一个为使用一定范围的复用方案的项目，所有项目都必须以这个项目为核心；
2.1.1 把对复用项目的贡献作为项目奖的考核指标之一；
可以在根据项目调研确定的需求与通用项目已确定的需要做对比，确定可以从复用项目提出的内容以及项目对复用项目的贡献，并确定项目奖的考核指标。当项目完成后，用一周到两周的时间，整理出可以对复用项目贡献的内容。
2.1.2 经实践证明，所作的贡献能用到后来项目中（3到5个），后来项目应根据所节约的成本奖励一定比例到贡献项目中；
但其他项目使用复用项目的模块节约了成本时，应给予提供者一定的报酬。例如，项目A向通用项目提供了复用附件，复用权限的贡献。项目B在未使用复用附件，复用权限时的成本为50人日。但使用了到复用附件，复用权限后降为10人日。那项目B就应该向项目A提供一定的报酬，40人日中的一个系数。项目A只能享受3到5个项目的报酬。
2.2 需求的获得：
通用项目的需求轮廓的确立应该是这样的：由咨询工程师根据以往的项目，尽可能多的施工企业对业务的需求，提出一套尽可能完整的业务需求；