软件不能运行，谁之过？

     软件是一个包含多道流程的体系，从需求调研开始，一直到发布和验收，任何一个步骤脱节，都不能保证用户得到理想的结果，而软件过程的各个阶段，又不是平铺、并排，按照其处于生命周期的阶段性时间，其重要性逐层递减。是的，一个人鲜有精力从头跟踪到尾，但要保证一个软件的顺畅运行，各个阶段负责人的水平应该保持一致。

     现在，很多公司像我所在的单位一样，各路人马分道行驶，却分工不协调，导致简单问题复杂化。一个新的需求，往往是处于前头、本该严格控制的人没有将业务明确化或者本身并不具备这方面相应的业务能力，又没有明确化的文档下来，结果一层层口头传递，到开发者手中，驴头也已经变成了马面；由于前方过于奉行“上帝论”，没施与用户应该有的压力，让一些得罪不起的客户可以随时的改变他们的需求，辛苦的程序员只能如救火般的去堵枪眼。结果到头来，程序这里一个补丁，那儿一个小段，可读性和可维护大大降低，处于这种状态下，程序员根本不会去考虑程序的性能和占用资源，从而最终的结果是把所有的漏洞都暴露在用户面前，责怪我们的程序稳定性差、功能上又不好扩展；更有甚者，小公司喜欢设立一个“工程部”，派人常驻“用户现场”而不注重研发后的系统测试，而研发阶段的环境和现场的环境肯定不一样，工程人员却是一点也不懂编程技术，在那里完完全全的充当着测试员的角色，发现的问题又不会隔离分析，也不能很完整地传回研发部；这样一来，又要添加一个沟通的角色：项目经理---说来很可笑，我们公司的“项目经理”不偏重软件的质量和进度，不会去做集成测试和系统测试，也不会去了解项目成员的发展要求，他们的主要职责用在跟工程部的人“沟通”，然后反馈、分配新任务，或者下达救急任务；接下来，开发者的新的研发任务被打断甚至搁浅……凡此种种，我们不能说哪个环节的人工作不努力，要我说，最不努力的是领导者，他们对分工不了解，对各个部分人员的权责和工作重心不了解，或者严重点说是用人不当！

     昨天，现场又返回一个问题。单点认证系统不能修改某一个系统的数据，于是查本系统，又查子系统，再查调用的工具包，甚至企图让改工具包的源代码：这是一种饮鸩止渴的行为啊！后来总算是没有去改，而是建议工程人员打开查询分析器去登录数据库（想到可能是防火墙阻止），结果还真应验了。这件事排查花了2个人一天的工作量，而且都是中途停顿其他事来解决的，代价不言而喻了。