笔者按：此文写于春节英伦旅行期间，但考虑到春节喜庆气氛，一直未发。因为直面问题的文字多少会让人不太高兴。但是，发现问题，分析问题，解决问题的方法，是我们提升整体能力的必由之路，时刻保持自省心亦是个人素质修养之必须。另，“七宗罪”为戏称而已，软件研发之误，尚不到“罪”的地步，诸位千万不要对号入座。
经常会被人问到一个问题，也经常自问同样一个问题，就是我们的行业为什么出不了精品软件？我对精品软件的界定，首先是实用，即能解决当前警务实践中的实际问题；其次是好用，直接的使用者，特别是基层的民警感觉使用起来很方便；最后是耐用，两三年不到就换个系统换个平台但还是做原来同样的工作，这种事我们这些年也没有少干。如果还要加上一点，就是要受众广、影响大。放眼世界，美国有著名的ComStat系统，还要研发总部位于英国的I2等，都是享有盛誉的警用软件，近年国内也做了不少引入消化吸收的工作，但是实际上的效果可能远远低于预期，难道真的是“橘生南方为橘橘生北方为枳”，为什么我们这些年花了不少钱，投了不少人，就是没有能搞出几个能称之为“伟大”的软件呢？带着这个大问题，结合春节期间的英伦之旅，大致想到了一些原因，姑且戏称为“七宗罪”。
第一宗罪：无休无止的创新。“创新”这两个字绝对是近几年最红火的一个词，其实这个词红火的背后并不单单因为是李克强总理提出“万众创新”一说，近年来，创新一词在处于“上升期”的某些领导眼中就是一块极好的“敲门砖”，是“政绩”的最佳体现方式，其实，实现创新的方式很多，从技术体系，到管理机制，但是，在绝大多数人眼里，创新就是要出新的东西，就是要搞跟别人不一样的东西，实在创不了新，那我们就“翻新”，反正不能拾前人牙慧，更不能拾旁人牙慧。殊不知，一个成熟的软件最好是经过不同单位的应用，经过不同使用者的实践才能“磨砺”出来。如前面讲到的I2，主要客户包括英国所有的警察组织、欧盟成员的公检法机构、国际刑警组织(Interpol)、欧洲刑警组织(Europol)、美国联邦调查局(FBI)及中央情报局(CIA)、加拿大皇家骑警(RCMP)，甚至还包括VISA国际及万事达欧洲等商业组织。
第二宗罪：朝令夕改的需求。这是所有行业软件研发者都非常惧怕的一个问题，就是需求在不断的修改。需求不是不能改，而是不能随意改，特别是涉及到系统框架等一些基础性功能，更不能说改就改，你看过建筑设计院的设计师站在新建的大楼下直接指挥建筑工人打桩砌墙吗？需求的问题，究其根源有三：其一，建设方不知何为软件需求，提出的都是实在的需要和要求，根本和软件工程中的需求不在一个频道上；其二，主导建设方需求的不是实际应用者，而是工作指导者，说白了，就是挥手的提出一堆要求，最后是干活的在用。统计、报表、流程控制等管理型的成分过重；其三，现场办公“前后排”式开发，前排坐着写代码的码农，后边就直接坐着负责项目的甲方代表，两人对着屏幕改代码，改好明天领导就要看。第二天领导一看，不行啊，不是我想的那样啊，两排人接着再改，这个领导过了，后面还有更大的领导等着……
第三宗罪：名存实亡的标准。如果说安全和共享是一对博弈的宿敌，那标准和共享就应该是一对最亲密的战友，没有标准的落地，特别是技术标准作为基础，数据的大范围共享就是一句空话，但是，目前各类技术标准在软件研发的过程中，基础性地位明显不足，拿最基础的数据项标准来说，很多并不是没有国标、行标，但研发单位就是不去执行，因为反正没有人监督，怎么方便怎么办。更不要谈执行什么管理标准和服务标准了。诚然，标准与现实应用相比，的确具有一定的滞后性，因为它是在总结现有经验的基础形成的固定规范，但是在长期的信息化建设中，我们已经积累相当数量的标准，所以现在最重要的事对现有标准的执行。无论是负责业务需求的甲方，还是具体研发的乙方，一定要记好一句话，对标准的尊重程度决定着你的软件的高度。
第四宗罪：不计成本的突击。突击开发，似乎已经成为行业软件研发的一种常态，突击，就是意味着打破的原先的开发计划。突击的最大动力，无非就是以下几种：“有领导马上来视察……”、“重要的会议即将召开……”、“再不完成就要被考核扣分……”。突击的前夜，一般还会有一番豪言壮语：我们这次不惜一切代价，确保按时完成任务……，所有的研发，都会有一个成本，这个成本不单单是钱，在进入项目建设的实施阶段，这个成本主要的是人力与智力的投入，突击往往会打破成本与收益这一平衡，结果一般是重界面效果，重美化展示，重最终实现，而忽视了常规的过程控制，忽略了需要良好的操作用户体验……突击的最终结果，一般是在领导视察后、会议结束后，要么成为“鸡肋”——食之无味，弃之可惜，要么就是干脆重新“回炉”。
第五宗罪：徒有其表的关隘。软件研发有很多控制的“关口”，所谓项目的过程控制，就是要把握住这些关口，至少目前有两大关口我们急需强化，第一是功能测试，第二就是项目验收。首先说功能测试，严格的测试，是应该按照分权的原则，引入第三方来开展，即时没有第三方，至少也要由专门的人员来测试，但在实际研发中，一般就是软件开发者测试一下，好一点的由需求提出者进行测试，还有就是普遍的由最终使用者来测试了，这种测试的方式，显而易见很难发现问题，很多问题在应用中此起彼伏也就是常事了。其次说项目验收，政府项目有其特殊性，这种特殊性决定了项目验收的程式化，程式化带来的后果之一就是重程序、轻实体，当程序合法成为项目验收的第一要务，软件应用的实际效果评估就会是往后站站了。
第六宗罪：众里寻他的文档。“要写文档、写文档、写文档“，重要的事情一定要说三遍，不但跟需求提出者说，还要跟设计人员说，跟代码员说，跟测试者说，跟推广者说……现实情况是：需求提出者会有很多口头需求，可能今天提一点明天提一点；软件设计者（一般是公司高管）也会说一大堆，可能也是说了就过了；来视察的各级领导，会从宏观上提一些很好的要求，还有实际的应用者，可能会提出一堆使用意见。所有这些都不是坏事，经常说的一句话，我们不怕提意见提想法，就怕没有人落笔。因为一旦落笔，不但会十分确定你的想法，更会在落笔过程中经过再一次的慎重考虑，所以，只要写出来的文档都会是有价值的文档，哪怕只有很短的一段文字。我甚至在某个场合对研发人员说过这么一句话，“写代码和写文档的精力之比是1:3”。
第七宗罪：无可奈何的招标。本来不想写这个话题，因为前面这些问题多少有一些解决途径，项目招标的问题的确很大很棘手，非简单的几句言语能够讲的清楚，目前的招标体制的确有一些弊端，特别是体现在无法控制低价中标的情况下，甲乙双方有不可能特别的“顶真“。低价中标就为后期的项目实施埋下了“祸根”。但是，现在又提不出更好的方式来进行优胜劣汰，在某种程度上，“项目运作”成为一个甲乙双方必须要一起“煎熬”的过程。在这个过程中，考验双方经手人员更多的是“良心”与“责任”。
以上七点，乃多年历经甲乙双方位置的一些心得而已，无论诸位臧否，余皆一笑了之。今夜旅居大英博物馆隔壁有时间成此拙文，也属机缘巧合，最后引诗一首为尾：
巴山楚水凄凉地，二十三年弃置身。
怀旧空吟闻笛赋，到乡翻似烂柯人。
沉舟侧畔千帆过，病树前头万木春。
今日听君歌一曲，暂凭杯酒长精神。
声明：本文非火星眼原创，转自中哲思维
赞赏