系统代码看起来都写完了。但是如何让客户用起来，是一个很大的问题。产品不管是正式发版，还是项目编码结束，到客户能够接受，都有一个很长的时间摆在那里。代码完成之后，还有部署、实施、维护、突发问题解决等一堆问题。偶称这些问题为“代码后”问题。
这几年，见了很多这种“代码后”的问题，也解决了不少。总结起来，大致有这些（基本上和业务无关）：
1、 Server环境的问题。如：RAC、Linux、win2003、DTC、LoadBalance等。
2、 客户端环境的问题：如RAC、Win2003、防火墙、诸如3721这种垃圾的各种小插件。
3、 软件框架问题
4、 性能问题：这个就很多了，不列举了。
5、 程序在现场发生问题，但是开发人员在家里没有思路，不知道该如何模拟现场环境、该如何抓到有用的数据、该如何分析。
上述问题随环境变化非常明显，建立一定的知识储备是必需的。但是，我们无法把所有场景下的问题都考虑到。我们能否改变一下这种情形？如，建立一个组织统一处理？建立某种机制？还是别的？
当然，如金蝶最近说的快速实施，这其实是从产品质量的角度来考虑的。但是我相信，他也解决不了上述的问题。质量好总是相对的，各种未知、复杂的环境，总是会接踵而来。
也许，建立这么一个应急组织，会好些？在公司，几乎有1/3的时间在处理这些问题
这几年，见了很多这种“代码后”的问题，也解决了不少。总结起来，大致有这些（基本上和业务无关）：
1、 Server环境的问题。如：RAC、Linux、win2003、DTC、LoadBalance等。
2、 客户端环境的问题：如RAC、Win2003、防火墙、诸如3721这种垃圾的各种小插件。
3、 软件框架问题
4、 性能问题：这个就很多了，不列举了。
5、 程序在现场发生问题，但是开发人员在家里没有思路，不知道该如何模拟现场环境、该如何抓到有用的数据、该如何分析。
上述问题随环境变化非常明显，建立一定的知识储备是必需的。但是，我们无法把所有场景下的问题都考虑到。我们能否改变一下这种情形？如，建立一个组织统一处理？建立某种机制？还是别的？
当然，如金蝶最近说的快速实施，这其实是从产品质量的角度来考虑的。但是我相信，他也解决不了上述的问题。质量好总是相对的，各种未知、复杂的环境，总是会接踵而来。
也许，建立这么一个应急组织，会好些？在公司，几乎有1/3的时间在处理这些问题
