[原]我们到底在定制什么
标签：
| 发表时间：2014-03-28 02:48 | 作者：david_lv
出处：http://blog.csdn.net/david_lv
我们到底在定制什么
谈企业信息化，二次开发是避免不了的。关于二次开发的费用、进度、质量都是大家吐槽的问题。但大家或许没有总结过、当然由于定制大多为软件商黑箱所以也不好分析，所以虽吐槽但也无可奈何。
我是出身软件商，既做过研发最高领导人，每周还有个雷打不动的动作就是：过费用/计划/质量超标的项目、代码复查/BUG分析。通过这些项目分析/代码分析/BUG分析来反推是我们软件研发内部哪里出了问题：是人能力不行？架构问题？工具模板问题？上下游前后台协作问题？寻找问题根源以打七寸。
问题分析多了日子久了就发现很多问题是一而再再而三的，都有规律和分类，我们只不过是在原地绕圈而以。那我今天作为深喉就给大家揭露揭露，大家也对照对照自己之前提过的二次开发需求看看是不是我说的这么回事。
一、查询统计类
这是我们最常见的二次开发需求。这里面出的最多的问题就是口径不一致/计算公式不一致。客户提A就修改A，发现B报表也有这个信息，但B报表没提我就不修改。发现了就再提需求再改。
查询统计类还常见的问题就是用原始业务数据做综合统计报表。这不仅影响业务生产系统的性能，而且统计报表不稳定，经常受业务系统的特殊业务操作而篡改历史数据（撤销、反结、负退）等等。所以搞综合统计报表我们的正道是用商业智能的技术。但很多CIO一提商业智能就头大，而且要新购买一个系统，就想凑合。CIO凑合，定制开发人员也跟着凑合，有的综合统计报表写了500行SQL（性能又问题而且再修改还不好修改出了错误还不好调试），有的综合统计报表干脆用SQL写不出来的（程序员用代码+SQL混合搞个报表功能）。
二、性能调整类
由于产品开发时、定制开发时都有限的人力有限的时间赶着做业务功能了，这些性能啊、兼容性啊、可集成性啊、安全性啊等非功能要求都没人管了。数据量一上来/用户一多了性能就有了问题。所以哪个功能点有性能问题就优化哪块。等后来优化了A然后B就慢了，优化了B连带C就莫名其妙慢了的时候，这样修改就不行了，又得从架构整盘考虑了，这就小问题积累成大工程了，这又是一次大的定制优化项目。
有的性能调整还不是动动参数改改索引这么简单的，有时需要复杂的负载均衡、查询分离这些架构级的大方案。但你购买的那个版本的平台不支持这些特性，那就又是大定制啊。
三、移植类
1、把A客户曾经提过的需求定制过的代码，在B客户处再改一次，因为B提的需求和A提的需求差不多，但B客户并不知道之前已经开发过了
2、把高版本产品中的某些业务功能移植到客户当前版本
四、对外集成类
对外集成需要有这几个层面的集成：门户集成、业务逻辑算法集成、工作流引擎集成、消息引擎集成、主数据集成、数据同步分发。但经常会出现的是：平台提供的某些集成技术不支持、没有对外集成接口/没有支持多种主流集成技术。所以要集成，只能修改平台、再升级平台，升级平台还得考虑上面所有子系统的兼容性，这就工程量大了去了，想起这样搞就觉得风险极大。
为了防止风险被憋大，所以很多CIO在IT建设中期就开始选型独立的IT集成平台。但发现每个核心业务系统都有所谓的平台，但都不完善，而独立的IT集成平台和他们这些平台又不好整合，因为他们各自的业务系统和他们的平台绑的很死，所以还是N多平台共存，整体系统格局更复杂。
五、对内跨版本集成类
怎么还有个对内集成。这就说到了企业购买子系统（模块）是分年购买分年上线的，所以即使是同一个软件供应商，N个子系统也是不同的版本。要让不同版本的子系统还能连在一起流畅贯通，这就难了。因为有的新版本上确实有很好的功能特性是客户最需要的，但新版本的各个子系统也是业务模型完整体系的，要把其中一个新子系统抽出来给旧版本子系统配上，这有时连业务模型业务流程都走不通。这就如同要把杨贵妃的嘴、西施的眼非要堆在一个脸上一样。但这么离谱的事情居然我们很多CIO都在干。当然一番大修改了。
如果这个软件供应商平时就没怎么注意各个版本的业务模型向下兼容性、各个子系统的接口边界、以及接口的向下兼容性，那...，大家就知道定制开发工作量有多大了。
六、平台加固类
安全：这个东西是个一般看不见一般也不发生的事情，所以很多CIO是口头重视但在选型评分、日常运维方面都没有对安全做太多照顾。很多IT业务系统在研发时对安全架构并不看重，都奔着发布新功能去了。一旦说要加固系统安全，完，因为安全是遍布各层各个模块的，系统需要再很多层的关键口上加安全控制，所以一整安全项目也是大定制项目。
运维：很多平台光注重产品开发工具、定制开发工具的支持，对应用运维、技术运维没啥考虑。但系统上的时间长了，运维正规化就要提到日程上了。这样就需要加强平台对于应用运维技术运维的支撑，这还需要大定制，哪能那么容易给外围按个服务工具就行的。
七、功能完善类
有些子系统吧，虽然已经开发出品了许多年，但购买人少啊，所以磨合的人少。有的客户就购买了，一用发现还不成熟，这就改吧。
八、BUG类
1、项目BUG：很多BUG是出在了传递上。企业业务部门-企业IT部门-一线实施顾问-二次开发项目经理-二次开发系统设计员-二次开发程序员-测试人员-实施人员。很多需求经过讨论来讨论去、打回/完善/变更再到设计再到开发再到更新，这都多少道手了。这中间N多细节被漏掉/被扭曲理解了。只能发现一处修改一处
2、产品BUG：有的客户购买的是某一版本的子系统，新的版本已经修复了某些BUG，但客户的系统已经被定制修改过了，产品补丁包不能直接给客户升级了，那就不升级了（升级成本/升级风险）。直到客户发现了某个问题再修复，这又成了二次开发了。
3、数据BUG：有时候是客户业务部门录入的异常数据，有时候是EXCEL导入的异常数据，有时候是软件BUG引发的异常数据，要重新清洗数据、修正数据、校验数据，这都需要占开发工作量（其实这个活是技术运维部门的活）
九、攒出来的定制需求
怎么说是攒出来的呢？因为我们把定制开发高峰分为三个期：实施期、推广期、服务交接期。往往实施期要做业务流程梳理/需求调研/蓝图规划，在没有实际使用前总是只能指指点点提出一些零碎的需求，这些需求就会被集中开发一次。等试点实施过后要大面积推广了就会发现更多人的更多需求，这又会攒一批集中修改一次。等都上线使用了，这就要进入漫漫的持续运维期了，实施要和服务交接、客户一看实施结束了要撤场了就急了，于是最后一大波需求又来了。看似每个需求都不大，但需求攒起来就够设计/开发/测试个20多天。
所以我们软件公司内部也分两个团队，一个是专门做小需求小BUG修复小优化，一个组专门做重大修改。这样让小的需求交付快，让重大大范围修改保证稳定质量。
我作为CTO每月都进行定制需求工作量统计，发现小于2天的定制需求占了90%之多，即使是那些大的需求修改，那也是我上述说的一些重大方案（往往涉及到平台架构的调整或综合统计分析需求）。
十、反思
我说了这么多定制开发，你是不是发现你过去提的大量需求很多都在此范围内。
我其实想真正探讨的是：我们每个企业是否真的业务很个性很特殊？因为我从定制需求统计分析上来看，没看出多少真正业务上很特殊很个性的定制需求。这个问题很值得各位CIO深思。我们到底在定制什么呢？
谈企业信息化，二次开发是避免不了的。关于二次开发的费用、进度、质量都是大家吐槽的问题。但大家或许没有总结过、当然由于定制大多为软件商黑箱所以也不好分析，所以虽吐槽但也无可奈何。
我是出身软件商，既做过研发最高领导人，每周还有个雷打不动的动作就是：过费用/计划/质量超标的项目、代码复查/BUG分析。通过这些项目分析/代码分析/BUG分析来反推是我们软件研发内部哪里出了问题：是人能力不行？架构问题？工具模板问题？上下游前后台协作问题？寻找问题根源以打七寸。
问题分析多了日子久了就发现很多问题是一而再再而三的，都有规律和分类，我们只不过是在原地绕圈而以。那我今天作为深喉就给大家揭露揭露，大家也对照对照自己之前提过的二次开发需求看看是不是我说的这么回事。
一、查询统计类
这是我们最常见的二次开发需求。这里面出的最多的问题就是口径不一致/计算公式不一致。客户提A就修改A，发现B报表也有这个信息，但B报表没提我就不修改。发现了就再提需求再改。
查询统计类还常见的问题就是用原始业务数据做综合统计报表。这不仅影响业务生产系统的性能，而且统计报表不稳定，经常受业务系统的特殊业务操作而篡改历史数据（撤销、反结、负退）等等。所以搞综合统计报表我们的正道是用商业智能的技术。但很多CIO一提商业智能就头大，而且要新购买一个系统，就想凑合。CIO凑合，定制开发人员也跟着凑合，有的综合统计报表写了500行SQL（性能又问题而且再修改还不好修改出了错误还不好调试），有的综合统计报表干脆用SQL写不出来的（程序员用代码+SQL混合搞个报表功能）。
二、性能调整类
由于产品开发时、定制开发时都有限的人力有限的时间赶着做业务功能了，这些性能啊、兼容性啊、可集成性啊、安全性啊等非功能要求都没人管了。数据量一上来/用户一多了性能就有了问题。所以哪个功能点有性能问题就优化哪块。等后来优化了A然后B就慢了，优化了B连带C就莫名其妙慢了的时候，这样修改就不行了，又得从架构整盘考虑了，这就小问题积累成大工程了，这又是一次大的定制优化项目。
有的性能调整还不是动动参数改改索引这么简单的，有时需要复杂的负载均衡、查询分离这些架构级的大方案。但你购买的那个版本的平台不支持这些特性，那就又是大定制啊。
三、移植类
1、把A客户曾经提过的需求定制过的代码，在B客户处再改一次，因为B提的需求和A提的需求差不多，但B客户并不知道之前已经开发过了
2、把高版本产品中的某些业务功能移植到客户当前版本
四、对外集成类
对外集成需要有这几个层面的集成：门户集成、业务逻辑算法集成、工作流引擎集成、消息引擎集成、主数据集成、数据同步分发。但经常会出现的是：平台提供的某些集成技术不支持、没有对外集成接口/没有支持多种主流集成技术。所以要集成，只能修改平台、再升级平台，升级平台还得考虑上面所有子系统的兼容性，这就工程量大了去了，想起这样搞就觉得风险极大。
为了防止风险被憋大，所以很多CIO在IT建设中期就开始选型独立的IT集成平台。但发现每个核心业务系统都有所谓的平台，但都不完善，而独立的IT集成平台和他们这些平台又不好整合，因为他们各自的业务系统和他们的平台绑的很死，所以还是N多平台共存，整体系统格局更复杂。
五、对内跨版本集成类
怎么还有个对内集成。这就说到了企业购买子系统（模块）是分年购买分年上线的，所以即使是同一个软件供应商，N个子系统也是不同的版本。要让不同版本的子系统还能连在一起流畅贯通，这就难了。因为有的新版本上确实有很好的功能特性是客户最需要的，但新版本的各个子系统也是业务模型完整体系的，要把其中一个新子系统抽出来给旧版本子系统配上，这有时连业务模型业务流程都走不通。这就如同要把杨贵妃的嘴、西施的眼非要堆在一个脸上一样。但这么离谱的事情居然我们很多CIO都在干。当然一番大修改了。
如果这个软件供应商平时就没怎么注意各个版本的业务模型向下兼容性、各个子系统的接口边界、以及接口的向下兼容性，那...，大家就知道定制开发工作量有多大了。
六、平台加固类
安全：这个东西是个一般看不见一般也不发生的事情，所以很多CIO是口头重视但在选型评分、日常运维方面都没有对安全做太多照顾。很多IT业务系统在研发时对安全架构并不看重，都奔着发布新功能去了。一旦说要加固系统安全，完，因为安全是遍布各层各个模块的，系统需要再很多层的关键口上加安全控制，所以一整安全项目也是大定制项目。
运维：很多平台光注重产品开发工具、定制开发工具的支持，对应用运维、技术运维没啥考虑。但系统上的时间长了，运维正规化就要提到日程上了。这样就需要加强平台对于应用运维技术运维的支撑，这还需要大定制，哪能那么容易给外围按个服务工具就行的。
七、功能完善类
有些子系统吧，虽然已经开发出品了许多年，但购买人少啊，所以磨合的人少。有的客户就购买了，一用发现还不成熟，这就改吧。
八、BUG类
1、项目BUG：很多BUG是出在了传递上。企业业务部门-企业IT部门-一线实施顾问-二次开发项目经理-二次开发系统设计员-二次开发程序员-测试人员-实施人员。很多需求经过讨论来讨论去、打回/完善/变更再到设计再到开发再到更新，这都多少道手了。这中间N多细节被漏掉/被扭曲理解了。只能发现一处修改一处
2、产品BUG：有的客户购买的是某一版本的子系统，新的版本已经修复了某些BUG，但客户的系统已经被定制修改过了，产品补丁包不能直接给客户升级了，那就不升级了（升级成本/升级风险）。直到客户发现了某个问题再修复，这又成了二次开发了。
3、数据BUG：有时候是客户业务部门录入的异常数据，有时候是EXCEL导入的异常数据，有时候是软件BUG引发的异常数据，要重新清洗数据、修正数据、校验数据，这都需要占开发工作量（其实这个活是技术运维部门的活）
九、攒出来的定制需求
怎么说是攒出来的呢？因为我们把定制开发高峰分为三个期：实施期、推广期、服务交接期。往往实施期要做业务流程梳理/需求调研/蓝图规划，在没有实际使用前总是只能指指点点提出一些零碎的需求，这些需求就会被集中开发一次。等试点实施过后要大面积推广了就会发现更多人的更多需求，这又会攒一批集中修改一次。等都上线使用了，这就要进入漫漫的持续运维期了，实施要和服务交接、客户一看实施结束了要撤场了就急了，于是最后一大波需求又来了。看似每个需求都不大，但需求攒起来就够设计/开发/测试个20多天。
所以我们软件公司内部也分两个团队，一个是专门做小需求小BUG修复小优化，一个组专门做重大修改。这样让小的需求交付快，让重大大范围修改保证稳定质量。
我作为CTO每月都进行定制需求工作量统计，发现小于2天的定制需求占了90%之多，即使是那些大的需求修改，那也是我上述说的一些重大方案（往往涉及到平台架构的调整或综合统计分析需求）。
十、反思
我说了这么多定制开发，你是不是发现你过去提的大量需求很多都在此范围内。
我其实想真正探讨的是：我们每个企业是否真的业务很个性很特殊？因为我从定制需求统计分析上来看，没看出多少真正业务上很特殊很个性的定制需求。这个问题很值得各位CIO深思。我们到底在定制什么呢？
作者：david_lv 发表于2014-3-27 18:48:37 原文链接
阅读：44 评论：0 查看评论