作/转载者：mypm.net

　　地球人都知道，中国的企业特多，企业的市场特别大。做好了，就不愁吃喝了。但是，很多人都没想到，企业实行的是自负盈亏，用钱是特别谨慎的，不能走高投入高产出的方式，必须走低投入中产出，甚至是走低投入低产出的方式，必须上量。具体到每个公司时，则必须把以前所做的项目中包含的个性化的内容归纳出来，提取共性，提高项目中可复用的程度。最终使项目能满足起百分之七八十的企业的需求，预留部分容易修改需求给客户，满足客户所谓个性化需求，定制的愿望。如果根据提高复用程度后进行的定制项目部门所产生的成本只占应收款的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 需求的获得：
　　通用项目的需求轮廓的确立应该是这样的：由咨询工程师根据以往的项目，尽可能多的施工企业对业务的需求，提出一套尽可能完整的业务需求；

　　2.2.1 项目经理：
　　根据具体的项目需求提炼公共部分的需求到复用项目中，作为项目奖的考核因素之一；

　　2.2.2 测试、咨询工程师；
　　测试主要是从软件易用性，人性化的角度提出需求，也可以将在测试过程中遇到的需求整理到复用项目中；咨询工程师从业务的角度，或者是在实施过程中从用户中获得的需求提炼到复用项目中。奖励措施，可以是积分制，到年终时，作为年终奖的一部分。

　　2.2.3 公司一线销售人员；
　　在销售前期搜集到的需求提炼到复用项目中，奖励措施，除需求已在复用项目中完成时，邮件通知外，可以是积分制，在销售人员销售了本方案后进行兑现；

　　2.2.4 用户需求德搜集；
　　鼓励用户，特对是老用户，将自己的需求提出到复用项目中。这要求每个项目中都必须有一个功能，方便用户发送需求道复用项目中。需求已在复用项目中完成时，除发送邮件给用户外，还应发送到用户的网络管理员及相关人员中。对工作量不大的修改，应免费给用户进行修改；
　　2.3 项目的建设
　　由于复用项目建设周期长，人员流动在所难免，因此必须文档尽可能规范，尽可能做到新到员工只通过查阅相关文档及代码，即可快速修改。同时，复用项目是通过所做的项目所提炼而成的，而不是将几个项目粘贴在一起的。所以，在提炼项目时，应考虑是否与复用项目融合在一起，复用项目要拆分时，要怎样拆分才是最迅速的。

　　2.3.1 先建菜单
　　根据复用项目的需求，建立相应的菜单；

　　2.3.2 完成页面
　　对已完成的页面，分两部分处理，一部分为演示用的，只满足用户的基本需求的页面；另一部分为销售人员用的，哪些需求是已完成的，哪些需求是可以定制的，用户必较关注的需求等，可以作为销售指导；

　　2.3.3 未完需求
　　连接一个公用页面，显示“本需求真正建设中。。。。。。”，并显示本需求的作用，对应施工单位的业务用例；

　　2.3.4 添加需求页面
　　本页面主要是方便添加需求；
　　2.4 公司制度的改变
　　2.4.1 需求的评审：
　　应有专人负责管理复用项目中的需求管理，到需求数量达到一定程度时或在某个时间范围内（3个月到6个），开会确定需求添加到复用项目的需求；

　　2.4.2 项目与复用项目共享的确定：
　　项目经理在项目需求确定后，通过和复用项目需求的对比，然后通过评审确定项目要实现的复用项目的需求；

　　2.4.3 项目提炼到复用项目中：
　　项目验收后，通过项目的总结，将公用部分提炼到复用项目中，对提炼到的内容作简单的验收，并对复用项目中已完的需求状态作修改；

　　2.4.4 复用项目的拆分：
　　在项目提炼到通用项目后或者是某个子模块比较成熟时，对复用项目进行拆分，以便其他项目能快速采用；
　　3 对销售的引导
　　主要有：项目是以复用项目已确定的模块或需求为主的，可以适当奖励，我们的目标是“质量优先”，因为这对我们的复用项目的用贡献的，而且追求“质量优先”对成本增加不大。而项目不是以复用项目已确定的模块或需求为主的，建议不做，如利润是相当高的，则也是以“成本优先”的原则进行开发。