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

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

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

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

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

      后注:

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

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

你可能感兴趣的:(开发)