信息技术：怎样提高软件项目的复用程度

地球人都知道，中国企业多，企业的市场特别大。完了就不用愁吃喝了。但很多人没想到，企业自负盈亏，用钱特别谨慎。他们不可能高投入高产出，但一定要低投入低产出，甚至低投入低产出，一定要高。到了每个公司，就要总结以往项目中包含的个性化内容，提取共性，提高项目的复用性。最后，项目可以满足70%到80%企业的需求，为客户预留一些容易修改的需求，满足客户所谓的个性化需求和定制化愿望。如果提高复用度后定制项目部的费用只占应收款的40%以下，证明项目复用度的提高是比较成功的。复用程度提高后，可以进行大量的定制项目，项目产生的累积利润是相当客观的。
但是，一定范围的个性化需求项目，很难高度重用。这里主要从项目管理和公司制度管理的角度进行论述，希望能达到抛砖引玉的效果。
很多人在做项目复用，但是失败的也很多。原因总结如下:
1原因总结如下:
1.1销售方式上的问题:
现在的模式是:市场无所谓你开发不开发，可以先说说。反正有了成绩就什么都答应了。这就好比:市场出考题，开发商答，客户评。销售自然喜欢问奇怪的问题，跑题的问题；开发者只能根据考题学习新知识，向客户索要答案等。，增加了成本；如果客户关系到位，要求不严格，客户没有现成答案，一切就过去了；如果客户要求严格，心里有个标准答案，那就麻烦了；【/br/】我们是否有能力对现有模式进行如下修改:开发商划定考试范围，销售人员开出考试题目，开发商随时解答，客户做出判断。即使做到了，总结后出错的概率也会逐渐降低；
1.2只关注项目的弊端；
在参与项目的过程中，我发现了这样一个现象:即使是项目经理本人，也不会从普遍性的角度否定我对具体项目的评论或建议。但这些意见和建议不会落实到具体项目中。原因是要么项目进度紧，要么没必要。反正改不改不影响工程验收。对于一个项目的用户来说，是否有这样的需求是未知的。即使有这样的需求，至少也是验收后才发现，这是维护的问题，与工程无关。不管怎样，只要运气好，侥幸逃脱就行了。
1.3开发者和部门人员对待用户的心态不是以用户为导向的。他们不把用户当人，至少把用户当机器人。
这就是社会做项目的心态:从需求分析说明开始恶意作弊。你签字后我给你做了些东西。如果他们不符合要求，那也没关系。你可以做第二阶段。我先去拿钱！部门的一些开发人员或多或少都有这种想法。我也听说过，对运营负责、繁琐一点比较好，这样用户会觉得技术含量高，有成就感，用的钱也值。用户想改的内容就是不对，用户也帮不了我们。
如果我们的开发者每天都用自己的软件和方案，那么我保证他一定会“后悔”自己当时的所作所为。我们现在的做法是，只要能满足功能需求，细节没必要考虑。现在软件同质化越来越严重，功能都差不多，区别就是细节处理不一样。比如有两家超市，他们的商品在档次、服务态度、口碑等方面完全一样。反正各方面都一样，都能满足人们的购物需求，只是因为一家超市在十字路口，另一家超市离十字路口只有100m。结果十字路口的超市营业额和利润都比另一家超市多很多。软件的细节相当于超市的位置，其重要性可想而知。
举一个开发商“后悔”的例子。在一个BS项目中，后期增加了一个功能，允许用户自己控制权限点的设置。当时开发人员在权限赋值中列出了所有的权限点，当然不会分类。当时我建议权限点适当分类，但开发者觉得没必要。但是在测试的过程中，开发者必须配合，分配大量的权限点。考完试，连他都觉得有必要改一下。这就是当时没有站在用户的角度考虑问题的后果。
2改革建议:
2.1建立一个使用一定范围复用方案的项目，所有项目都必须以这个项目为核心；
2.1.1将对复用项目的贡献作为项目奖的考核指标之一；
您可以将根据项目调查确定的需求与一般项目确定的需求进行比较，确定可从复用项目中提出的内容以及项目对复用项目的贡献，确定项目奖的评价指标。当项目完成后，需要一到两周的时间来整理出能够有助于复用项目的内容。
2.1.2经实践证明，做出的贡献可用于后期项目(3至5)，后期项目应根据节约的成本给予贡献项目一定比例的奖励；
但是，当其他项目通过使用复用项目的模块来节省成本时，应该向提供者支付一定的费用。例如，项目A为一般项目提供了重用附件和重用权限。b .如果项目中不使用再利用附件，再利用权的成本为50人-天。但是，使用重用附件后，重用权限将减少到10个人日。那么项目B要给项目A提供一定的奖励，一个40人日的系数。一个项目只能支付3至5个项目。
2.2需求的获取:
一般项目的需求档案应建立如下:咨询工程师应根据以往项目中尽可能多的施工企业的业务需求，提出一套尽可能完整的业务需求；
2.2.1项目经理:
根据具体的项目需求，将公共部分的需求细化到复用项目中，作为项目奖励的考核因素之一；
2.2.2测试和咨询工程师；
测试主要从软件可用性和人性化的角度提出需求，也可以将测试过程中遇到的需求整理成复用项目；咨询工程师从业务角度或在实现过程中将从用户处获得的需求提炼为复用项目。奖励措施，可以是积分制，年底会作为年终奖的一部分。
2.2.3公司一线销售人员；【/br/】销售前期收集的需求细化到复用项目中，奖励措施，复用项目中需求已经完成的除外，可以是积分制，在销售人员卖出方案后兑现；
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对销售的引导
主要包括:项目基于复用项目的已确定的模块或需求，可以适当给予奖励。我们的目标是“质量优先”，因为它有助于我们复用项目的使用，追求“质量优先”并不会增加多少成本。而不是复用项目已确定的模块或需求，建议不要做。如果利润相当高，也是本着“成本第一”的原则开发的。