八部众---走出软件做坊：三五我的十来条枪 如何成为开发正规军（二十三）[转]

这几天在规划新产品，新产品要作什么，两个来源：

      1看看业界最新的产品，先来个海阔天空的头脑风暴。从ipod模式谈到金山与google的合做，从android谈到百度的电子商务，从孙正义的投资校内网到汽车GPS、车载充电、车载MP3。但这些只是引新思路，真正还要落回到本身所在的行业所在的客户。正规的干，和如今业界的标杆比，咱们水平差，和他们用正规的方法交锋，只有输的份儿。因此，从来以少胜多，都是以奇取胜。咱们做为中小企业，把金庸+古龙，或者王朔+鲁迅这样来个改良菜，把其余行业或领域的新产品新模式引进来，或许才能突破现有大佬制定的游戏规则。

      2踏踏实实，仍是要去检索咱们的需求库。历年来，全国客户提出来的数以几千条的需求都记录在其中。小说，就是来源于生活而高于生活。因此，需求就是现实生活，咱们的新产品必须从现实需求中提炼出来。不然就是空谈新产品，而根本没法落实。

      我常常看到很多内地程序员拿Google的开发和国内的开发比。在Google，软件是艺术，你们阅读源代码也阅读的赏心悦目，大骂国内软件业毫无创新。我我的觉得，咱们的积累仍是过短，从业者年龄和经验结构偏低，还没法从现状而创新。另外咱们面临的资金、客户的限制，咱们更是没有多少发挥空地。因此我认同软件工厂作法，大批量高质量低价格快速度的生产。可是，现状是，连能把这种生产模式作的好的软件企业都寥寥无几。大量的软件企业没法实现高质量大批量快速度，低价格也是下降质量克扣员工得来，势必引发客户和员工的反抗而终结低价格。因此，咱们作新产品，也不能抱着科学家研究的思路，而更应该是在资金、时间、人的素质、人的数量、竞争压力、客户现状的框架下的量化可控的研发，有阶段，有目的，有重点的研发。

      要有控制的研发，就要有需求管理工具来管理需求库，能够分类查询、检索、统计。就须要老老实实去回顾需求库。若是须要调研，就须要有方法的调研，从组织结构、过程、考核、优化这几方面来梳理需求，而不是开讨论会。

      有了这么多需求收集回来，你们估计会很晕。由于需求来自全国客户七嘴八舌，有来自豪放的东北，有来自细腻的华东，有的来自客户老板，有的来自部门小经理，有的来自部门小组长，有的来自IT人员，有的来自最终操做者。因此，真是林子大了，什么鸟都能飞出来。我记得我在2000年实施的一家客户，最终用户年龄大，打字不灵，但愿有个语音输入。这就是需求。若是咱们面对这样的需求，咱们确定会说不可能完成。但咱们每每不仔细想如何去解决问题，反而耻笑客户傻瓜，怎么不把年轻的换上岗位。但咱们了解到那位最终用户是一位专业经验很高的人员，岗位没法代替，咱们都闭嘴了，咱们最终仍是解决了问题，但确定不是语音输入。因此，咱们整理分析需求，不能耻笑这条需求确定是用户拍脑门想出来的，那条需求是客户本身笨。到最后，仍是咱们本身愚弄了咱们本身。就如同遇到BUG，总是有程序员说不可能，我机器就不报错，或者说确定不是个人问题，我都检查过了。但最终最终，仍是代码问题。这种现象家常便饭。

      一个软件，对于不一样的人来讲有不一样的要求。若是你把这些需求归类，你每每会获得这些要求特征。

      对于销售来讲，演示的时候稳定、易用、好看、速度快就是关键。

      不少销售并不懂软件，但要买软件，这就是现状（别笑）。咱们要就问题解决问题，耻笑问题也解决不了问题。原本就不懂软件，还不易用，销售根本无法给客户讲清楚本身卖的这个东西到底有什么用。

      若是还不稳定，忽然报出一个英文错误，销售在那么多客户面前更是漏了脸，吹的那么大现实倒是如此，让销售的诚信损失了，必然会到老板那里告一状，以挽回本身打单不利的面子，错全是研发部的问题，那时研发部只有吃不了兜着走了。

      若是软件作的灰不啦叽的，本身都以为没什么出彩的，客户也以为很普通，在价格上就没法提高。而销售，最重要的就是卖一个好价格。软件也实用，也先进，但打单过程当中，给客户演示也就那么短的时间，并且来听的人大可能是之后不实际操做软件的人，对软件到底功能作的多细腻，处理各类复杂业务多么灵活，都根本没法看出来，就看到这个软件很差看。就如同咱们遇到一个女孩，很漂亮，到底心灵如何，尚未那么多时间和机会去了解，但首先感受就不错，愿意去接近。若是遇到一个女孩很普通，从内心一开始就有坎，不是抱着主动去了解的心态，而是怀疑和旁观的心态，就不容易了解一个女孩子。软件，和女孩同样，都一样的道理。

      演示的时候，我每每会看到这样的情形，点下一个查询按钮，10秒钟出不来结果。客户和销售都在等，会议室很静，你们都在盯着屏幕都在等待，但就是不出来结果。销售急了，拼命乱点，更加重了不稳定和性能约束，最终报错不断，或者干脆销售很尴尬的按下Ctrl+Alt+Del。

      对于实施来讲，最重要的就是软件稳定。软件不稳定，客户怕软件使用过程当中出现问题，就不敢放实施人员走。而实施人员上面还有实施总监在管，有项目进度和经费的控制，因此实施总监老催实施人员为何还不回来。实施人员也急呀，今天查报表，明天改数据，老是按下葫芦起了瓢。

     软件稳定的基础上，最令实施人员头疼的就是客户需求的事情。若是每遇到一个需求都须要让程序员搞定，而程序员又少，就把实施人员晾到现场了。实施人员原本就想和客户搞好关系，以但愿可以把项目顺利进行下去。这下，长时间解决不了客户需求，实施人员就交待不下去，固然要给程序员施加压力。这就是开发部每每是软件公司最受攻击的一个部门，销售、实施、支持都攻击开发部。因此，为了能让实施人员现场知足客户需求，开发人员每每想了不少办法。最常想到的就是开发平台。但我见到许多开发平台，简直就是面向开发人员的（什么XML、SQL、流程编辑）。实施人员只懂业务，对计算机软件操做并不娴熟。因此，开发人员必需要给实施人员提供实施人员能用的起来的实施工具。不少软件系统没有实施工具，只有一个光杆软件，孤立无援。

      对于培训来讲，软件易用最关键。你帮助写的再详细，相信看的人都很少（只有咱们可爱的程序员才去勤奋的钻研那些详细的WINDOWS API帮助）。软件易用，培训的工做就轻。

      有不少软件，没有演示版，没有操做视频录像，没有最新版本帮助文件，没有新版本更新说明。就凭一张嘴对着电脑屏幕讲。出了新版本，还不知道哪些功能发生了改变，还照着过去学习的知识讲。客户亲手一操做，发现讲的和看到的不同就有了疑问。培训人员都脸红，本身都不知道怎么使用，也解释不了。因此培训文档对于培训人员来讲也很重要。

      对于支持来讲，软件稳定是第一位的。不然本身的支持电话非打爆不可，那样，支持的工做又累、钱又少还成天郁闷解决不了，还不如不干支持。软件若是不稳定，那么软件必须可跟踪。最怕软件出了问题，客户打来电话就说：软件很差用。这个很差用怎么查问题啊。到底怎么个很差用，报错的界面截图是什么样的，在哪一个模块，怎么操做的，录入了什么数据，报的内部英文错误是什么，版本号是多少，软件打了多少补丁，操做系统是什么版本，操做系统打补丁没，数据库打补丁没，防火墙是怎么设置的，年月日和货币符号设置对不对，打印机设置对不对，本身的IP网络设置对不对。这些内容，最好像WINDOWS同样，出了错，把全部须要跟踪的信息都自动收集起来，而后报出一个提示框，能够发送报告给微软。因此，咱们作了一个日志模块，能够自动截图，自动发送日志，自动记录当时操做的SQL语句，自动记录当时的客户输入数据和点击操做流程。给软件跟踪解决问题加快了许多效率。若是一个个去问用户，用户都不知道这些信息到哪里去收集，再一顿反复解释寻找，解决问题就很慢了。有不少时候，用户因为时间太长有其余事在身，就放弃了解决这个问题，长此以往，因为问题越积累越多，就渐渐不用这个软件了。

      对于支持来讲，软件自动升级也很是重要。咱们每每遇到不少问题都是软件没有打某个漏洞补丁形成的。并且还有不少问题是因为客户端版本不统一形成的。如何能自动的、所有客户端一块儿升级，一发布补丁就自动全国升级，不少问题客户还没来得及发现就被解决了，满意度就上来了。

      对于后续版本开发维护人员来讲，代码容易看懂，代码好修改才是最关键的。程序员想了不少方法：业务开发平台，有意义命名，小函数分割，函数接口灵活，面向对象，设计模式、重构等等。可是，代码仍然愈来愈复杂，愈来愈不容易看懂，愈来愈很差修改。其缘由就是因为每一个客户都提出各类各样的需求，有时不一样客户之间的需求仍是矛盾的，大量的代码实际上是为了处理客户异常业务，还有的是为了堵某个特殊操做发生的BUG，还有的是为了兼容不一样版本之间。这才是代码难阅读难修改的根源。

      对于数据量大性能要求高的应用，性能是很关键的持续改进方面。

      对于安全性要求强的应用，设计安全的方案，编写安全的代码，安全的测试覆盖是很重要的工做。

      对于测试人员来说，软件必须具备可测试性。软件代码写完了，什么样的操做或结果是正确的，什么样的操做和结果是不正确的，没有人告诉他，也没有文档，这就不具备可测试性。这就要求有设计文档，详细写明什么样的操做和结果是正确的。这样就有了可测试可验证的标准。不少软件不稳定，最后加了专职的测试人员也不稳定，其根源不在于测试人员测试方法不对，测试经验不丰富，而在于根本没有测试依据，测试人员只能本身凭经验乱点乱试，根据经验来判断这个结果是正确仍是错误。尤为一些报表，输入条件，数据都出来了，可是数据之间是有关联关系的。但这个关联关系并无设计文档说明，测试人员并不知道，就认为这个功能是好用的。其实这个报表数据是错误的，虽然能正常显示。

      对于文案人员来讲，软件必须能让文案人员编写文档。许多软件没有设计文档，代码开发完毕，让文案人员本身边学习操做边辅助测试边编写文档。文案人员不是设计人员，不是代码编写人员，不是测试人员，是对软件作陌生的人。他自己都对软件不了解，可想他本身写的帮助文档有多大的可帮助性。软件没有帮助文档，其根源就在于没有设计文档。而没有设计文档的根源，在于根本没有编写设计文档的人。谁来编写设计文档？程序员？程序员再写代码。测试人员？文案人员？实施人员？培训人员？到底谁来写这个设计文档。

      我看过许多网友在讨论怎样一个软件才算一个好软件，说了不少方面。可是从现实来讲，咱们真的须要那么多方面吗？

      每每现实一开发，什么好软件的标准都丢了，程序员单枪匹立刻手。还有一些开发团队，但愿能作一个好软件，因而但愿把这些好软件的标准都实现了，最后周期长，在有限的人力和开发时间内没法完成，只好有始无终，最终仍是个烂软件。

      业界有个笑话，就是说微软的软件，从第三个版本才能使用。

      这说明，一个好软件，应该具有好软件的标准，但一个好软件，不是在一个版本就把这些标准所有实现。而是有步骤有重点的实现，逐步达到一个好软件。

      那么，这些好软件的标准就必然须要排个顺序。

      编软件，是为了什么？

      是为了卖。

      怎么才能卖个好价格呢？

      嗯，包装成漂亮的就能卖个好价格。巩俐穿上棉袄也就是个秋菊，村姑化完妆也是个靓女。韩国整容你们有目共睹。

      就是这个思路。

      因此，我并无把软件实用放成第一位。由于新软件研发，你并无很深入理解客户，你假设认定这个需求很实用，到了现实使用发现没法执行下去，这就废了。并且实用不实用，每一个客户的理解是不同的。有人以为电子邮箱很实用，有人以为电子邮箱没有用。就这个状况。因此，我设计软件，每每只设计不超过3个实用亮点，实用亮点多了，咱们开发也周期长成本高难度大客户可能还接受不了，并且过于复杂销售和实施人员没法给客户讲明白。因此有1-2个宣传亮点就OK。在不断销售不断实施过程当中，客户会天然提出来需求，软件就会不断实用起来。

      而后，我就会把软件包装漂亮。专业的销售方案PPT，专业的帮助文档，专业的软件界面，专业的图标，统一的操做，统一的字体，统一的专业词条，统一的对齐，专业的提示（不少软件提示竟然是：“很差意思，出错啦”。真汗~）。这须要美工、文案、界面开发人员三者配合。

     漂亮事后，就是稳定。稳定就须要软件具有可测试性。

     这样，软件就能够出去销售初版了。

     到了软件第二版，客户签单量就上来了。实施工具就要提上开发日程，不然多个项目并行提出来的需求能把程序员的工做排到明年。

      到了软件第三版，这是很关键的阶段。不少软件，生或死就在这个阶段，就看能不能过去这个槛。这个槛正值有部分客户和影响力，但还须要大规模高速扩展的时期，把握不住产品发展策略重点，极可能就渐渐的无声无息了。因此这一阶段主要是在加强现有功能和稳定性的基础上，尽可能使软件易用、易维护。软件必须可跟踪可自动升级，这样才能支持日益扩张的客户群，才能使问题迅速解决，而不是大规模扩散。在这一阶段，不主张多增长功能，这样会使软件复杂性加大，阻碍了大量客户的理解，而大部分客户都是通常客户，而非理念先进的灯塔客户，能让大量的通常客户快速理解到软件的好处和应用操做上手，是很重要的阶段任务。

      到了软件第四版，软件愈来愈复杂，如何兼容，如何容错，如何容易阅读，如何容易修改就成了首要问题。这个版本，重点就是内部代码重构优化。

      到了软件第五版，性能是个问题。过去3-4年积累的数据使系统愈来愈慢。优化性能成为第五版的重点。

      到了软件第六版，因为这么多版本的升级，功能非常复杂了，使本来易用的软件如今变的愈来愈难懂了，究竟是特殊处理的业务。把经常使用功能和很是用功能分开，把正常业务处理和异常业务处理分开，作到组合裁减，一部份不经常使用的功能就渐渐萎缩掉，一部份经常使用的功能作加强。在这一版本，重构易用性成为重点。

      软件到了第七版，就几乎在打补丁了，再也不投入大量人去维护了。软件进入大销售大实施大维护的收割阶段，维护本版本的开发团队在萎缩，下一代产品在酝酿。

      这就是一个软件生命周期中，不一样时期的不一样开发重点。把握好节奏，合适的时机作合适的事情，一点都不浪费投入人力。

      可是咱们要注意，性能是一个结构性的问题。因此虽然在第五版才调整性能，但对于企业管理软件来讲，必须在基础设计的时候就强烈关注数据库设计。由于数据库结构一旦固定就没法更改。从过去的经验来看，只要数据库没有设计缺陷，性能的瓶颈主要在代码上，只要改进代码和功能设计（有些功能设计自己就性能很低，大量的功能集成在一个界面上岂能不慢？），性能是很好解决的。

      对于代码的重构和优化，若是从始到终遵循着函数封装，小函数分割（我曾经碰见过一个3000行的大流水函数，不敢下手，怕一旦修改不知会发生哪些BUG），优化和重构也是很容易作到的。

      网友们讨论了许多，有实用性、稳定性、容错性、性能、可测试、可理解、可修改、可实施、可支持、灵活性、移植性、兼容性、安全性、易用性....。

      但这么多要求，咱们都要有目的分阶段的一步步达到。并且，每每咱们不断补齐上一阶段留下的遗憾，咱们此阶段的努力又会造成下一阶段的遗憾，老是没法达到一个赏心悦目能够笑看江波的软件。可能，世事轮回皆此规律。

      后注：

      八部众为佛经故事。八部分别为八种似人非人，似神非神，似鬼非鬼，似善非善，似恶非恶的种类组成，他们散落在佛界三十三重天，或喜或嗔或怒或思或乐，但种类之间老是互相关联互相矛盾又互相共生，层层迷障没法拈花微笑。

      一个好软件，也是如此多的标准特性，也是如此共生又如此矛盾，颇为神似。