八部众---走出软件作坊：三五个人十来条枪 如何成为开发正规军（二十三）

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

      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），优化和重构也是很容易做到的。

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

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

      后注：

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

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