第一件事是，我们这采购的一个系统出现了非常严重的问题(三方开发公司的问题)。后来规定要求采购系统也要有自己人负责(其实也**，不是自己开发的出事还负责)，当时互联网上算上网站有六个系统，我负责的有四个。结果开会找人负责这个出事系统，其实漏洞补了也不追责，但是所有人都不想负责，大领导也不好硬排，必竟再出事责任大了，又不是自己开发的。后来领导一听互联网上我负责四个，说你把这个负责了吧，其实我也不想负责，但是看领导为难，就接了。

最后，所有互联网系统找专业安全公司测试，然后升级，也没啥事。估计领导觉得我有事敢扛，给我负责了三个核心项目，还有一些核心管理工作，再加上互联网上五个，最后管了8个项目，有天数了数电话，连打带接一天200多个。几个团队加起来管三四十人

第二件事，就是我们系统全国大会演示时，由于我们主管领导想表现自己去演示，人家业部门不同意，要自己演示(成绩大的太有诱惑了)。结果我们主管领导不高兴了，明着又不敢惹业务部门，就难为我们团队，不给资源，要啥没啥就说没有，也不让其它部门配合，想让人家演示不好。这么大个事，如果演示出问题，我也完了，不过我们主管领导也向来不管手下死活，就考虑自己(后来走了，越混越差)。

服务器部署到会场不给，会场又没网。最后我和弟兄们在没有网络、运维部门的配合下，自己用开发的台式机、笔记本、无线路由临时搭的演示环境。业务部门领导在台上演示了一个小时，我提心吊胆了一个小时，生怕机器网络出问题，还好一切非常成功，业务部门大领导十分满意，上级领导要全国推广我们经验，其它省市也认可。

贴吧碰上一弟兄，貌似搞的远程医疗，辅助大夫做手术的系统。结果让他第二天操作，结果这哥们怕系统如果出问题，手术出了人命，自己摊上官司，吓的头一天辞职了，我实在不知道这种人将来能干成啥。当年我当兵时我们组长，系统差点处理错了十几亿资金，人家也没吓成这样。再说，你系统不能辅助了，大夫就不做手术了，人家肯定有预案，你怕出事人家就不怕，咋想的呀，都吓得失去理智了。

当时一朋友搞系统升级，差点上万人工资发不了了，结果人家业务部门早就有预案。通过手工支票给银行发了。

2005年，参与上级大型项目时，上级所招标的公司大部分是Delphi程序员，少部分是Java程序员。实际上当时DeⅠphi工具都要完蛋了，但是人家企业从开发成本和进度考虑，仍用DeⅠphi前台Java后台架构，，好使用这几十人团队，最后效果也不错，公司还省了成本，降低了技术风险，保证了进度。所以软件公司在考虑技术架构时，就是用适合自己情况的技术，不追求最新的，当然也不断的更新，但不是大折腾，不轻易大动，而是逐步改进。所以只选合适的，不选最新的。

一哥们自己开公司，十几人开发团队，十几年前开始用VB做的，到现在2000多个功能了，上万家用户(中小微企业)在用。你让他把VB换成Java和Net，还不得花上千万，全搞新的肯定还不稳定，这些VB程序也经过了十几年验证了，现在用户用的也挺好，根本没有技术革命的紧迫感。所以也一直这么用着，唯一难题就是VB程序员太难找了，现在也是新的项目往Java Web上转，旧的那些还是用VB升级。他这种更注重营销，而现在中小企业信息化太落伍，根本不提技术要求，太高技术也小微企业搞不起。

所以技术选择不应只追求高精尖，而是追求自己能掌控的，能省成本及提升开发效率的。项目经理应该是价值思维驱动，而不是技术思维驱动。新技术能带来价值，并且风险可控才会用到项目中。有些开发人员努力把代码写的通用化，希望代码能在多个功能模块中使用，即提高开发效率，又能提升项目质量，这是超赞的习惯。

因为软件企业的项目经理，多是从程序员一步步干上来的，在系统设计业务规划上，总想把系统设计的更加灵活，可配置，以达到将来适应业务变化不用动代码，改改配置就行。绝大多数行业项目经理常常最后发现，即使改配置适应某些业务，结果配置的时间成本还不如修改代码。还因为配置多，造成系统的性能不好。因为配置多，开发的功能多，开发成本也高。最后的感觉是费了半天劲，效果还不好。

造成这种问题的原因是过度设计，好多灵活性是技术人员想出来的，而不见得是人家业务需要的。有些人琢磨的配置，可能等软件停用了最后也用不上，而且有些行业在发展，你不可能配置。就像末来需求还没有，你想通过配置实现末来功能，怎么可能。我们行业有个顶尖企业，当年控制了某块业务全国大部分市场，后来也想做个能够配置业务的平台。通过整理需求，发现得做500多个配置功能。再后来，发现得2000个配置功能。再后来，不弄了。。。真聪明。

13.搞需求的技巧
有些初入行的兄弟，总觉得代码不好写，框架也挺难等等。实际上软件开发中，最难的是需求获取与分析，如何准确的在用户哪儿获得准确需求，才是项目成功的关键。否则设计的再好，技术再先进，最后不是用户想要的东西，项目也意味着失败。

举个例子，我们一合作企业北京的一家公司，在某行业很有经验，在做某项目时，系统开发二个月，然后被业务部门全盘否定，二个月工作白干，又重新开发的。类似这种大批功能反反复复修改的项目见过太多了，原因就是需求没搞好，细节后边谈。如果是计算机专业学生，学软件工程或项目答理课程，书上又写需求的流程又写文档的格式等等各种理论，最后拿书上知识到实际工作。基本上啥用都没有

怎样搞好需求，首先识别项目主要干系人。你要搞需求，首先要搞清业务单位的组织结构，主要领导是谁，各个机构领导是谁，谁是有经验的业务人员在用这个系统，然后识别对项目有影响的主要因素，其实就是哪儿块业务谁说了算。我们主要是ZF项目，主要领导很关键，但领导不会给你提需求，而是要求。但是满是不了领导的要求，项目不会给钱，肯定失败。上边例子就是，没有了解领导目标，结果领导不满意返工。

有点不好写了，总体意思就是，要时刻想着业务部门领导目标，通过与业务人员沟通业务时，将领导目标融入到方案中，即不能让业务感到带来麻烦，还需将领导目标融入，这里面学问实在太大了，回头发专贴写吧。搞需求的最大难题就是，业务人员是懂业务，但不知道用软件怎么去操作业务，而技术人员不知道业务，更甭提怎么设计系统了。所以，业务与技术要碰出火花才能成功。显然，让业务人员学软件开发不现实，而应该是技术人员去学业务才合理，这也是技术人员身价提升的一种途经。