然后就是公共代码开发人员，一般就一个人。对于企业管理软件的开发，框架的开发和维护，公共代码的开发，高难度的问题跟踪，需要高性能的设计，需要高扩展性的设计，需要高稳定的代码，需要高安全的代码，需要高并发的操作，需要复杂代码重构。需要性能优化，不知道的技术API，都可以寻求这位公共代码开发人员的帮助。他还负责新技术跟踪、新技术介绍、新技术试验。但这个新技术必须是为了改进公司现有产品和现有客户。新技术的跟踪必须上报给技术总监，以防不符合公司目标乱跟踪或跟踪方法和思路不对。对于有利于现有开发的新技术，可以筹备好培训课，由研发部经理安排时间，让公共代码人员给研发部全体人员讲解。如果大家认可这种方法，就需要选择适当的时机在产品中引入。研发部的测试人员，一般也兼任服务部门技术支持人员。如果有服务部门解决不了的技术问题，可以转给他。而且测试人员还兼任配置人员，在产品打包、产品安装测试、产品发布、版本分支管理、源代码备份、历史版本归档方面都由他来管理。兼职是有好多好处的。如果他不兼任技术支持，他就不了解客户是怎么使用的，他测试也是瞎测试。如果他不管理产品打包发布，程序员就会自己私自发布版本。可能版本还有问题，为了修补问题，就赶快修改完再打包一个，但版本号却不改变，引起了一个版本号代码不同错误不同，让服务支持起来很莫名其妙。由测试人员控制产品版本发布，能不能发布，就是测试员说了算。测试员感觉质量没有达到，就有权不发布。很多软件作坊，程序员权力很大，一个老哥从头到尾负责整个项目，项目质量如何，全看这位老哥自己的素质和责任心了。为了不让项目质量和特定人密切相关，使公司研发保持连贯性水准，必须做到分工专业，互相配合互相牵制。一般，研发部也就配1-2名测试人员，根据同时并行的项目和产品开发和开发的强度来定。我们并不生产向国际上的产品那样的质量。我们做行业企业管理软件开发，是在客户质量要求、客户签单额、竞争对手质量水准这三者平衡上做到一个质量的认可。我们无法做到微软那样一比一的开发测试人员比例。研发部所有的产品和项目，都由这1-2名测试人员负责所有的测试工作，包括编写测试案例，编写测试结果，参与项目的需求测试、设计测试。对于研发部的文档方面，如文档的正规化，都由文案来负责。项目经理经常要提交给客户一些文档，而项目经理往往是技术出身，文档工作水平不行，于是文档的正规化、美化、文字校对、空格段落措辞标点符号，都由文案制作。帮助文档，也由文案负责。帮助方面，有版本更新说明帮助、安全配置帮助、系统维护管理帮助、基础数据配置与维护帮助、业务功能操作帮助、软件操作演示视频、产品简介PPT、产品演示版，都由文案来做。为了防止文案不懂产品而写产品帮助，在需求说明书、设计说明书这些文档性的工作上，如果有什么文档体力活之类的工作，也由文案人员来做。文案人员还兼任产品辅助测试，主要是作为一个普通的操作者来测试，在制作演示版的过程中模拟客户流程客户数据来进行操作录入，测试出普通使用中的BUG。一般，一个专业的测试，经常呆在软件的环境中，思维就有一种定势，但实际的用户并不那样操作，但测试人员自身感不到。而文案人员就能充当普通用户来测试。我们招聘文案人员也没有强调会什么软件，文案写的好就OK。他们确实是最普通的用户，他们的困惑和操作手法代表了大量的普通用户。而一个研发部，文案人员也往往是1-2名，随并行的项目数量和规模来定。所以说，一个研发部，一名研发部经理，1-2名开发人员，一名项目经理，一名公共代码开发人员，一名测试，一名文案，也就是5-6人完全符合一个软件作坊的人员数量。有时候团队小了，研发部经理就是项目经理，公共代码开发人员就是主程，这样，一个开发团队也就是3-4人就OK了。但方法照样能用起来。因为我所讲的方法也就是适应于这四套马车的组织架构的。每个人都身兼数职，而且都对自身的提高非常有好处，而不是给他身上堆砌毫不关联的工作内容。每一项职责都是能互相互补的，整体提高他的岗位专业性。作为业务开发组组长，他很大的一个职责就是开发项目的进度和质量管理。手下也就1-2个人，开发人员的素质也就这么高，我们也会经常遇到突然来了个项目的事情或者突然有个过去的项目问题必须开发人员跟踪，所以开发人员也总是会被左抽右调。对于还能保证开发进度正常，业务开发组长确实每天都在监控进度异常，监控每个开发人员目前身上背着的开发任务和开发进展。每天下午5点的时候都要询问一下自己手下这两个人的开发进展。因为有的人不喜欢主动说自己遇到的什么问题，总喜欢自己去到处找答案，弄的延误了正常的开发计划。所以，开发组长必须每天下午5点主动问遇到了什么问题，是不是很棘手，能不能保证进度。如果不能保证，业务开发组长就会想办法，是全小组一起诊断出谋划策呢，还是寻求公共代码开发员呢，还是寻求研发部经理呢。为什么是下午5点？主要因为5：30-6：00就下班了。如果快下班了你才去问，大家早就心思不在这里了，谁都想赶快下班回家，问题就被隔了一夜，留了个不清楚的尾巴。如果在5点钟询问，有了问题，如果此问题业务开发组长有经历，他会很快决定该怎么解决。如果详细听完了此问题的来龙去脉，业务开发组长也无法决定，他已经清楚了问题，他会在晚上思考，第二天一上班来就有了决定。这就一叫一点都不耽误。我们使用的是BUG管理系统来管理开发任务。这并不要紧，谁说BUG管理工具只能管理BUG。我们只需要解决我们的问题而已。当然，我们管理真正BUG的系统是另一套，只不过我们使用的是同一个工具而已，我们当然不会把BUG和任务混在一起。来自需求管理系统中的需求，来自BUG管理系统的BUG，都会被业务开发组长来评估，根据自己团队当前每个人的工作量来适机添加、定优先级、分配任务、调度任务。也根据这个任务分配，哪些任务超期了，哪些任务完工了，哪些任务还没有开工，哪些任务正在进行当中，来判别开发人员的开发进度和工作量。业务开发组长也会每日主动向研发部经理报告进度，简要说明一下现有问题和解决思路。进度列表，当然是从工具中导出的，列明今日关闭的任务，还没有关闭的任务。这样，研发部经理一思考：项目已经开始了这么多天，还有这么多任务没有完成，到期能不能完成，他就会思考是不是要做些调整。对于项目进度，不管客户是不是需要必须在XX月XX日之前上线，我们都会设立一个项目最终结束的日期。而不能让项目随波逐流。这个最终的项目开发结束日期，并不是由业务开发组长排脑门想出来的。我在以前的文章中就有介绍。业务开发组长负责功能点清单整理、功能优先级划分、详细功能说明书编写。而且每编写一块就开始分配任务给开发人员。在业务开发组长划分完功能优先级以后，因为每个功能的复杂性都差不多，如果某个功能复杂，就会再被拆分。业务开发组长就能预估出一个大概的项目开发周期。根据以往的团队经验，也能预估出给集中测试时间和集中文档测试打包发布的时间。这样，整个软件什么时候能最终出来，业务开发组长是有个预估的。如果一个团队是新组建的，每个人的能力还不清楚，预估就会有偏差，需要磨合才能得到经验值。如果磨合，我也会在以后讲到。在实际分配开发人员的时候，就是根据这个总目标完成时间来倒推时间的。这个倒推出来的，有一个每个功能的完成时间周期，而项目经理对于某个特定的开发人员的能力预估也有一个时间，而开发人员自己对完成这个功能自己也有一个预估时间。开发人员怕完不成任务被追究，往往会把完成时间往后放1/3时间，甚至有人想偷懒干自己的活，会更多出自己预估时间一倍，也就是说自己觉得3天能完成，就说6天才能搞定。当然，业务开发组长也不是吃素的。业务开发组长也是开发出身，到底难度多大心里有数。而且业务功能就是业务开发组长设计的，如何实现，会遇到什么难点，自己一清二楚。而且天天管这帮开发人员，谁能力高低谁想偷懒，天天在一个办公室，谁不知道谁。所以，每个任务的时间，都会是业务开发组长在开发人员自己预估的时间基础之上进行调整，获得一个开发人员和业务开发组长都能接受的任务时间段。然后根据每天的进度报告来随时调整这个时间，让开发进度尽量能现实，而不是计划前就定好实际工作中就不能改。对于项目进度的保证，还必须有一个条件，就是：我们不允许开发人员在客户现场开发，我们更不允许开发人员和业务开发组长不在一起。开发人员在客户现场，往往开发进度和功能需求变更容易受客户控制，致使开发团队做的计划和设计都被客户视为扯淡的东西。开发人员不满客户的做法，但在现场又没有办法，只好敷衍答应开发权且应付。本来一个理性的设计，被客户自己自以为是的好做法而推翻。软件什么扩展性啊，兼容性啊，都被扔在了一边。来客户现场，就要听这个特定客户的，你必须口对口服务这个特定客户，你如果和他讲其他客户怎么办，他才不管呢，反正他付了你的钱，在你眼中他必须是你唯一的客户。（客户和女人一样，都希望是男人眼中唯一的女人，但现实的是，世界上都很多女人，而且很多女人都差不多，都要求她所对应的那个男人必须唯一）另外，开发人员在客户现场开发，就无法实现每日构建每日测试。开发，是个团队配合的事情。一个软件，并不是开发人员就能全部完成的（许多老板都这认为有开发人员就行）。缺少了测试，质量就无法保证；缺少了文档，产品就是光秃秃的软件。而许多老板还认为测试和文档可以在代码编写完后可以做，真是对软件质量如何保证一无所知。我们也不允许开发人员和业务开发组长分离。因为在开发当中，设计文档又不是代码，机器运行完就一种结果。每个业务开发组长的文档水平有高低，每个人的思考思路也不同。我们经常会遇到一个现象，就是用邮件、MSN沟通老出误会，而且由于不及时调整，误会越来越大，后来干脆气愤的直接打电话。而打电话呢，有时还不行，你问他理解了么，他说理解了，你根本看不到他的表情，你猜测不到他是真理解了还是假理解了。你以为他理解正确了，他也以为自己理解正确了。你问他进度，他说没有问题。开发出来了，测试人员又有自己的理解，到底这三者理解的是不是一个东西，谁都没个准。只有业务开发组长和团队一起工作在一起，每天能看到实际的软件，能面对面和每个人交流反馈，才不至于代码开发完毕才一看不行。有许多刚当上业务开发组长的朋友，往往和手下搞的很僵硬。手下认为他一天三变，频繁推翻自己的代码，很气愤。而业务开发组组长认为手下的理解能力低，多次讲都讲不清楚，还跟自己顶嘴，还不如自己去开发代码省事。完了，又回到程序员了。我也同样不允许团队出现多种技术。多个技术，会让团队成本升高，每个人都得会多种技术。而我们做企业管理软件，要想上升赚钱，必须大规模一般员工团队低成本开发，这是我和老板都认同的一种思路。所以，我们必须使用最常用最普通的技术。除非没有办法。我曾经有一个手下，怕自己跳槽没有竞争力，于是老学习流行技术。PHP火的时候，他就学PHP。Ruby火的时候，他就学Ruby。如今网游和嵌入、通信、无线很火，他就开始学C。手机开发火的时候就学J2ME。而且他还想有实际的开发经验，以在应聘中说自己拿这门技术做过什么。于是他想尽办法在项目中要引入这些技术。说：用.net，我没法保证性能和稳定性，所以我必须使用VC++。？？唬谁呢？大家都是开发出身，这个借口未免太可笑。我也不允许团队使用最新技术。我们只使用最合适的技术。我们不要客户为不需要的新技术而买单。客户的水平只能管理了SQLSERVER这样的数据库，我们就决不使用Oracle。如果客户要求在unix上运行，我们就使用JAVA开发。我们谨慎的评价和引入框架，都在核心围绕客户能不能简单维护，我们有没有显著好处，我们面临最棘手的问题能不能很好解决。如果只能解决我们不怎么紧急的问题，如果只能解决我们通过人工或管理就能解决的问题，我们就不引入。一切的一切，都围绕速度、成本、质量在寻找解决方法。我们也采取了每日构建每日测试，来保证软件的进度和质量。不每日测试，哪到什么时候才测试。到那个时候测试，会不会出现其他什么不可控的问题，我们都说不清。这种对未来的恐惧，让我们需要把风险控制到最小，到天，而且到今天。今天关闭的任务，明天一测试，就知道问题大不大。有问题的，必须由测试人员登记BUG系统，并且业务开发组长根据目前情况适机把BUG修复当作一项任务来添加。我们也采用了版本管理工具。版本管理工具不仅可以使我们对比源代码差异，找回历史版本，随时打包更新版本，分支每个客户的定制需求，还可以是我们的一个工作的体现。大家经常会听到这样的话：不知道开发部这帮家伙在干吗？是不是故意利用我不懂代码在偷懒。我们到底在干吗？我们能否证明。有的时候确实是，一个问题三两天都解决不了。我们真的不好意思说我们三天就做了一个功能。我们如果解释这般技术难题为什么为什么，老板更是没有兴趣听，他认为你在嘲弄他不懂开发技术故意拿技术问题来骗他。我们能如何证明呢？能拿一些大家都能理解的方法来证明自己呢？所以，我想到了文档数量和尺寸大小，想到了BUG数量，想到了任务数量，想到了需求数量，想到了开发进度报告，想到了版本发布次数，想到源代码归档容量和源代码行数。一个项目开发结束，任务数300多，BUG数量400多，文档尺寸70多M，项目历次讨论开会纪要30M，项目历次方案提交20多M，开发进度报告100多份，帮助文档100多M。这些都能量化都能看得见的东西，让老板觉得确实做了许多事。我们曾经有一个客户，嫌10万块钱买了一张光盘，觉得贵死了。说地摊上一张才5块，你卖我10万。我们于是就把所有的帮助文档都打印了出来，600多页，装订成3本书，印刷好封面交给他。然后把软件装在一个很精美的木制盒子里，客户笑的很开心，把盒子和手册都郑重其事的放在了IT部门的柜子最上面。我想，软件是由代码组成的，确实不容易让客户理解其中的艰辛和付出，所以客户并不认可我们的付出。能拿客户可以理解的方式去讲明白就是解决方法。我一贯遵守的原则就是：要么解决问题，要么闭嘴。如果你想不出解决方法还抱怨影响团队情绪，那么滚蛋，这种人就是团队的毒药。过去，我们讲了业务开发组长如何履行功能设计的职责的一些方法，今天，我们又介绍了业务开发组长在任务分配、软件进度、软件质量保证、工作量化的一些心得，这就是一个开发组组长的份内之事。希望能给被提上开发组长的朋友一些启发，不要把自己定为一个写代码的头儿，那样你不符合国内现状，国内的开发组组长就需要做这些事情。外国怎样怎样那是外国的事情，你也享受不到，这是中国。要么去做，要么老老实实继续当个程序员。27、沙场秋点兵前几个月，公司旁边的写字间又搬进一家公司，好似也是做软件的，而且好像是刚成立的公司，程序员们天天加班，神情很年轻，头发很油，穿着大背心大裤衩人字拖，男的女的都有，经常站在通道里成群的吸烟，或者干脆席地而坐围成一堆开会，都不下食堂吃饭，都订盒饭，中午晚上都是如此，我经常晚上下班，看见他们不时有人捧着一个盒饭从办公室走出来把吃完的饭盒扔进垃圾筒，不知道他们会工作多晚。近来发现，他们开始有人正常下班了。他们也很少聚在一起抽烟开会了。通道里有的只是单个的人在打电话，声音很低，神情普通。偶尔看见他们在外面通道里开会，也是个个神情紧张或肃穆或很累或木然或沉默。我想起了一句话：Boy，Slowly，Slowly。新的产品，新的梦想，大家都很希望能够把多年积累的知识都用上去，做一个业界一飞冲天的产品。但是，这这个新的团队呀。我想起了我刚出道的时候。我现在仍然很庆幸我能经历一个产品的从萌芽规划到实现到销售到规模销售的整个过程，让我看到了一个产品是如何成长起来的，在成长过程中会遇到哪些问题，是如何克服的。很多程序员没有这样的机会，往往一出道，就加入了一家运行N久的公司，团队是现成的，产品是现成的，自己就是做维护开发而已，没有完整经历一个产品生命周期。所以一旦遇到新开发一个产品的时候，就很茫然，不知道如何下手，而且心情很激动，过去一直维护别人的代码了，很多弊病想推翻重做都不行，现在终于自己可以一展身手了，这回要把自己的想法都加进去，不能留有遗憾，不能重蹈覆辙。于是扑入了自己全部的心血，就连睡觉也不踏实，每日心情澎湃。但时间不长，两个多月，各种问题就都来了。新技术、新团队、新产品，一切都是新的，很多交叉出现的问题让解决异常困难，团队也出现了烦躁，看淡，疲惫的情绪，大家想尽快结束，但开发才到中间，正是关键攻坚要命的时候。我刚出道的时候，加入了一个新成立的研发中心，才成立四个月，我是第六人。产品还在规划当中，团队还在建设当中，技术还在学习摸索当中。当时的技术总监做了两件我现在也认为很对的事情：一、他让所有人阅读上一代产品的源代码，整理上一代产品的功能，并且得出上一代产品的功能所映射的客户业务流程。并且要求指出上一代产品业务流程中的漏洞和矛盾。二、他让大家通过改造源代码来学习新技术。他不仅仅让大家整理业务，还要画出来详细的流程图，整理出详细的数据结构。然后安排集中会议让大家讲，讲的时候，以流程图为主，走到哪一步，就进入软件界面讲解，并且讲明背后的数据存取到底是处理了哪些字段标志， 表之间是怎么关联的，到底从哪些表中取出来，表结构设计的有什么不合理的。这次没讲明的，这次提问没有确切答案的，下次继续讲，而不仅仅是讲一回。我发现，很多团队缺乏这种不断追根到底的魄力。总是虎头蛇尾，第一次讲的很起劲，讲的期间出现了自己也没有理解透的东西，领导只是安排下去再去研究一下，但就没有了下文。自己下去了看了一下，认为找到了答案，但就没有再次校验的机会了，于是最应该细究的地方被这样放过了。我们知道，编写程序，往往是最细节差异的地方最容易出现问题，而且很少能被测试到，而且维护代码的程序员往往不清楚这块是干什么的，一旦出现问题很难阅读懂。技术总监还让我们改造源代码。但这个也是有目标的，就是把控件都修改成一个统一的体验风格，没有DB的控件，就去寻找。寻找到了，就把这部分代码摘出来，然后形成我们自己的控件包，力求不要为了一个小小的控件，就安装整个的控件套件包。实在寻找不到，就自己开发控件。学习新技术，我认为这种方法是最好的一种方法。我现在也是这样指导我的下属的。学习新技术，为了怕误导，一是阅读官方的例子，如JAVA的宠物店或.NET的宠物店。但我后来我明白了，不能这么学。因为本来就对新技术陌生，一开始入主的就是这样的代码，那么以后的编写程序的风格就往往会像这些例子一样。其实，我们编写业务应用程序，并不需要这样的架构风格，也不需要秀那么多代码模式。照猫画虎把我们画的很累，还扭转不了已经固有的思维。我们不需要这种看上去很美的代码。学习新技术，第二种方法就是找一个网上开源的什么系统，如某些新技术尝鲜者做了论坛系统或什么什么管理系统。但这种方法也有个弊病，就是他自己写的代码有他自己的风格，而且他还处于尝试期，写这个东西可能是他为了学习这个技术，而非目标是开发这个管理系统。本来咱们对于新技术就是一张白纸，这下被他带到沟里去了。学习新技术，第三种方法就是阅读这个新技术本身的源代码。可惜本来就对新技术不熟悉，而新技术本身的源代码更是复杂，看的云里雾里，吃力看不到进展，欲想放弃。所以，学习新技术，最好是学习基于新技术的第三方的外国开源源代码。他们对新技术理解快理解深入，他们应用新技术不是为了尝试新技术或者秀新技术，他们是为了完成他们的一个实用产品。我们当时为了摘出某个控件，几乎阅读了那个控件套件包的所有源代码，并且理出了源代码的结构思路，否则我们无法确定我们遗漏了什么，会不会有BUG。但是，现在回过头来看，方法是对的，时机却是错的。我们是新团队、新产品、新技术，很多我们尚未了解清楚的，我们却把我们学习新技术后得到的控件应用到了我们以后的正式产品中，并且作为基础应用。这给以后的发展带来了几乎是灾难性的打击，我最后费了好大的劲才算把基础重构并且稳定住，否则基础崩盘了，上面的应用就不可收拾了。所以，我现在都是尽量限制使用新技术。也就是说，不会让新产品、新团队、新技术这三个新都同时出现，风险太大了。而且坚决不使用新技术作为基础技术。我们还犯了一个错误，就是正式开发的时候，我们一上手就开发基础框架。大家都知道一个系统的基础框架的重要性。但是我们却用刚刚学会的新技术开发我们以后业务模块都要深度依赖的基础框架。我想起了某公司一套战略性的大型产品的开发：用的是新技术JAVA，大家都还是新团队，做的也是新产品，全体程序员都已经封闭开发了，居然有人提出了一套自己也未经过商业规模应用验证的基础框架，并且自己实现了一个小DEMO。大家一看这个小DEMO非常有思想，就决定让整套产品线都应用这套基础框架。我想象他们的痛，和我很神似。所以，我现在如果面临新产品、新团队、老技术，我都不会让大家一上手就开发基础框架。去年，我就面临了一个老团队、老技术，但是是全新一代产品的开发。具体情况是这样的，经过几年发展，我们的现有产品渐渐老化，所以决定要开发新一代的产品。上一代的产品是C/S结构，而且是适合单客户使用的。这次，我们要开发B/S结构，而且是适合集团客户使用的。让上一代产品的开发团队继续维护上一代产品。让新一代开发由新的开发团队去执行。所以，我们就招聘了新的团队（当时公司对开发新产品有不同的利益冲突团体，还没有达成一致，招聘新团队既有为新一代产品开发做准备的目的，也有其他的目的，造成这支新团队的打造过程中往往出现两种极端：要么好几个人都管，要么三不管）。刚开始并没有去动手设计与开发新一代系统，而是为客户定制开发了一两个其他IT项目。所以说还算接触了客户行业，大家彼此在一起工作也快八个月了，算是一个老团队。但是这支团队对客户、对现有的产品并不深刻了解，虽然我给团队多次讲解过业务，也让大家分析学习现有产品，阅读现有产品的说明书，根据新的业务模式也组织大家一起分析业务设计功能、编写功能设计说明书，但理解上确实还不够令人满意，大部分人还是似懂非懂。遗憾的是，在老板的规划下，新一代的系统开发必须启动。如果这时候开发基础框架，大家根本不理解以后这个基础框架之上要编写什么样的应用代码，那么这个基础框架就会变成形式，以后的应用代码怎么都觉得这个基础框架没什么用，用起来也是格格不入，不像是螺丝对螺母那样合缝。所以，我先安排团队开发了系统管理工具。这是个没有具体业务的，而且通用的，而且也是基础框架的一部份的开发工作。但是，由于系统管理工具，涉及到了新的组织结构模式，新的权限控制模式，这是大家不太熟悉的。而且编码架构风格和他们以往的开发不太一样。所以开发起来也是疑问不断，需要实时复查代码，实时解答问题。终于开发完毕，我们开了一个总结会。大家都总结了对这次开发的体会，并且讨论出来以后再遇到这样的问题要如何解决，每个人的分工和人员配合流程再次确定，功能和功能的用意再次给大家讲了一次，对于新的编码架构风格再次讲了一次好处和用意。大家都说：如果在开发前就把这些讲清楚了，那么开发就不会遇到这么多问题了。我说：开发前我就是这么讲的，但是大家都不理解。这次经历过来了，就明白了。接下来该怎么办？我说：重新开发一次系统管理工具。时间为期十个工作日。大家都啊了一声。干吗要重新开发，好不容易开发出来就这么废了？我对大家说了我的经历，我说：系统管理工具是基础框架的一部份，是以后用户很常用的工具，而这个工具却是我们在不清晰不熟练的阶段开发的，我们如何能把这么重要的基础功能交付给客户呢？尤其以后这个工具要和需要系统结合，这个工具的数据结构目前还无法支撑以后的众多连接，你们也看到了许多遗憾，我们不能一起步就是个瘸子。大家又问：那过去的代码我们还能用么？我说：你们自己看需要。我既不赞同你们尽量使用过去代码，也不赞同全部重新编码。如果你们想把一个有残疾的代码上改造成一个优秀的代码，我说不可能，过去的很多缺陷会牵绊着你。你为了保留过去的代码，你就会向过去妥协，而把丝丝缺陷带了进来。每个人每个功能都留了一点点小尾巴，那么所有开发的功能总和出来的缺陷就是一个大问题。所以大家自己看着办，先重新写，需要用的时候自己就COPY出来。果然，理解了清晰的功能和功能用意的程序员，开发起来很快，毕竟都写过一次系统管理工具了，也是老技术、老团队了。半个月完成工作。我问：上一次你们编写的系统管理工具代码用了多少？他们回答说：不到20%。明白了思路，重写起来很快，反正没有什么高难度技术。本来想COPY旧代码，发现老有关联，摘不干净，还不如重新写一个来的快。我说：好。咱们下一步就实现一个咱们系统中最简单的也是比较边缘的一个业务子系统。在开发中大家重点发现需要什么公共功能，咱们都提炼出来，就会形成咱们的基础框架的一部份。这个简单的业务子系统开发了出来，我又开了总结会。大家这次都发言热烈：我现在终于发现了系统管理工具和业务子系统之间的关联关系了，他们有很多代码能够共用。由于这次开发业务简单，而且经过上次系统管理工具的开发，开发方法和代码方法都已经熟悉，对于系统管理工具的认识也深刻了许多，所以这次我开发业务系统的时候，还顺便把过去的系统管理工具的代码进行了重构，发现了不少可以共用的部分。我发现，这些基础代码总结了出来之后，好像系统管理工具也是从这些公共代码基础之上开发出来的一个特殊的业务子系统了，所有子系统都依赖这个基础代码框架。过去本来系统管理工具的风格和业务子系统不一致，这次重构，一下子都统一了。我笑的很开心，似乎我过去的心结终于可以解开了。28、代码那些事儿这个是讲软件研发过程管理的系列，目标人群是那些身处研发管理位置或想成为研发管理的人。所以我不希望这个系列中出现代码，也不希望出现和某种技术密切相关的代码技巧。但是没有办法，软件开发过程管理，有个很重要的一环，就是软件代码编写。不编写代码，说的天花乱坠，管理做的再扭，也成为不了软件。最近blog好友到了上限，所以无法加入好友了。于是就加入了N多QQ网友。大多数刚出道一两年，还有不少在校学生，希望认识并聊聊，要和我聊设计模式、OO、SOA，还有人建议我去看看OO和UML的书籍。我确实没有阅读过OO的书籍，我不是一个死钻牛角尖的人。我只是有什么问题，就去找解决问题的方法，能解决我的问题就OK，而不在乎我用的正不正宗，也不在乎我用的是不是OO。可能它是OO的外壳，但是它实质上可能是伪OO，我也不想去深究和区分什么是正宗OO，什么是伪OO。反正能解决我的问题就行。我首先遇上的问题是代码大流水的问题。一个代码3000多行，数不清的if..else。我实在无法分析出这个代码到底实现了什么功能，它复杂的就像一把瑞士军刀，如果军刀里面能出来一支小手电也觉得不奇怪。这段代码我想它就是这样。我想写这段代码的人一定是在学校做惯了《图书馆管理系统》，一个程序文件中实现了所有的功能。所以，经历了痛苦，我就一直要求手下的开发人员，一个函数代码行数不能超过一个屏幕。如果超过一个屏幕，就需要来回滚动。一滚动，就容易把思路滚动的走神，乱了，还得回到上面去重新理逻辑。这种规定，直接导致了一个后果，函数太多了。但是函数间是有关系的。有时候突然需要增加一个参数，但是此函数已经被其他代码调用了，于是为了省事不改动其他代码（当然，他可能已经忘了再哪些地方都调用到了），他就定义了一个全局变量，在函数之间传。新的问题有出来了，全局变量的问题。代码在他一个人手里还好说。被维护了好几手，新手对日益复杂的代码已经不太容易理出头绪，但修改任务是有时间限制的，只能在现有理解水平上工作。这位新手看到这个全局变量的命名，感觉是自己能用的到，就用了，还给赋了值。意向不到的事情发生了，数据库中进了错误的数据，怎么来的，不知道，看代码，处理的都正确，代码没有问题，也不知道怎么出现的。于是禁止大家使用全局变量，能藏到多低的可见级别就藏的多深。但是仍然问题依旧。于是，我们就把这个全局变量封装成属性，给它赋予读和写的函数。不管有多少个地方调用了它，有谁给它乱赋值，这里掐源头，都做好日志和异常保护校验。把所有函数，能变成私有的就变成私有的，需要公共供其他人调用的谨慎的放出来。放出来的函数，一定要做好参数的校验，什么空指针，什么没有初始值，什么非法参数值的，尤其是临界值上下边界，都在门口就挡住，根本不往下执行进行业务处理，否则走的越远引起的问题越大。而且要求每个函数都要做好自己的内存保护工作，自己函数内创建的就要在函数内释放。每个函数要做好异常处理和日志记录。这样，一个样子像OO的类产生了。它可能只遵守了OO所提了封装，它却没有实现OO所提的继承和多态。所以它可能是个伪OO，但它确实解决了我们的问题。封装了类之后，又一个问题产生了。几个类之间不知怎么的，总是你中有我，我中有你，互相调用了。就好像左右手互搏，弄不好就会把自己给捆起来。为了堵住这个问题，规定只能单向依赖，如果发现你必须调用另一个类，另一个类也需要调用这个类，就以一个类为主，另一个类开放事件。这也许就是控制反转，AOP的需求吧（我并没有深入研究AOP，我只记得控制反转这个词，好像是为了解决相互依赖关系问题）。“Don't call us, we'll call you”。但是代码稳定性的问题仍然没有很好解决，测试组也找出了许多BUG，但是一到客户那里运行，还是出了不少BUG。怎么自己运行的时候找不到呢？于是，我们在版本测试的时候、第一个版本小规模放给典型客户的时候，都加了断言。一旦软件出现问题，就立即记录日志，并进行软件中断，而不让错误继续错乱的不按我们预想的代码流程走下去。很多年前，我就惊讶于某公司的软件的质量，怎么折腾操作都没有问题，我常常给我的手下拿这个例子来反衬大家的代码质量。直到我有时随便乱点，居然软件中断退出了，报了一个错误号，我一下子想通了，它用了断言。断言阻止了错误的继续扩散，不让恶果之鞭长袖善舞。于是，我要求开发人员经常性使用断言，很多过去悄然发生的错误，测试员只运行可执行程序无法捕捉到，现在都能明确的捕捉到，在测试阶段就尽可能的消灭了那些过去无法明示的BUG。我过去领导过架构组。架构组的人在2002年的时候，疯狂迷上了UML和设计模式，人手一本《COM本质论》和《设计模式》。我手下有一个新手，就处处是类，处处是抽象，处处是封装，处处是分离，尽量使代码高内聚低耦合。但是这样的的代码太麻烦，他花费了大量的时间，他看自己的代码赏心悦目，别人看他的代码云里雾里，不阅读懂《设计模式》就按照常规理解业务的思路去阅读他的代码根本阅读不懂，不知道他为什么这样写代码，怪异的很。本来，这位想达到可维护性，可阅读性，却真正的失去了可维护性、可阅读性。这和我前几天看我的朋友周爱民写的《大道至简》中写到：有人希望拿UML去统一用户和软件设计者。殊不知UML有多难理解，而UML设计者却认为UML可以描述一切。就这个道理，要理解你的代码还要去读懂《设计模式》，这要求太高了吧。所幸这位新手自己都每次写的累，慢慢的也就懒了，觉得确实需要分离的时候就分离，觉得没什么必要的就懒得做了。用他自嘲的话说就是：被磨平了。其实，依我看，他现在这个代码状态才是刚刚好，即照顾了设计扩展，又照顾了实用。真正的纯OO，纯设计模式，可能只存在于教学和科学，而不在于我们的商业软件开发。我们作为商业开发，强调的是叫座的基础上叫好，所以折中方案是必须的，客户和我们自己两相宜就OK，是否符合正宗，就不在我们的商业开发管理范畴了。这位新手还写了大量的注释。在每个源代码文件头都写上几月几号，XX创建的，这个原代码文件主要是干什么的，还画蛇添足的写上版权所有，公司名称。好像这个代码要开源，或者可能会被其他公司窃取了好表明公司版权。甚至每个函数都写了注释，每个参数是什么意思，每个参数可能出现的值代表什么意思，都写的一清二楚。久而久之，也懒的维护了。代码改动了，参数扩展了，参数状态值有了变化，注释说明却没有跟着改动，让后来看代码的人老误解，还不如不写这些注释。我告诉他：做事不能走极端。要么全写注释，要么不写注释，都是不对的。我只在我认为要小心的地方，或者我自己都觉得很难理解懂的地方我才写注释。否则，我自己都可能会过段时间理解错了。如果某段代码我看看就能看懂，我就不写注释了。咱们做企业管理软件，深入技术又没有，只要代码能把复杂的业务处理描述的逻辑思路清晰就OK。虽然说理解能力不同，我能快速理解了的未必有新手能够理解，但是你看看我的代码你就明白了。这位新手去看我的代码去了。我的代码几乎没有什么难度技术，但代码也是看上去很舒服。他发现了以下几个关键点： 1 代码风格统一，从命名含义，到大小写，到缩进，都一致。每个源代码文件都一致，确实出于一人之手。许多程序员，光自己的代码就有好几种风格，有时心情好，有时心情不好，有时头脑清醒，有时没有休息好，有时敷衍，有时画蛇添足，有时急躁，从代码就能看出来。而我的代码就像稳定运行每天如一日的机器，好似每个源代码都是在同一天敲的。这就叫发挥稳定。这几天要开奥运会了，运动员天天重复练同一个动作，把每个环节都练的精益求精，其目的就是为了在大赛紧张的压力下也能发挥稳定。人在压力下，非常容易发挥失常。如果人老处于这种压力下训练，那么大赛就像平常一样了。2我的代码居然能看出业务流程。函数数量均衡，不像他的代码函数太多，跟踪跳转的很累，也乱了头绪。函数长度也正好在可理解阅读范围内。而且有一个流程控制函数，把流程处理环节串了起来。细深入跟踪某一环节，又发现了更细的流程。每个函数都看起来简单，但整体来看，却实现了复杂的功能。他问我是怎么做到的？我说，我的心中只有业务，业务和代码，我认为只是英语和汉语的区别，表达的是同一个思路。而在你心中，业务是DOC上的文字，代码是你的技术表现，你老需要把业务和代码映射拧在一起，我则不需要。业务流程如何，我的代码流程就是如何。3由于我的程序都是小函数组成的，都有明确报错，所以错误很容易找到，即使出错，也扩散不大，都是小bug，对系统整体没有大影响。他还对我的开发方法不理解，问我为什么要让大家从后台往前台开发，他很不习惯这种方法。他过去开发都是先用开发工具拖拽控件画出界面，然后一个按钮一个按钮的处理业务代码，需要什么字段就在数据库里设计什么表加什么字段。我问他：你为什么要这样做？他说：我不理解需求，无法凭空想象，只能先画出来界面，然后有了直接感觉后就在开发中理解业务，边开发边理解。我问他：那你以前有详细设计说明书没有？他说没有。我又问他：那你以前有人单独设计数据库和开发业务处理中间件组件么？他说没有。我说，问题就在于此。你没有详细设计说明书，所以你看不到一个形象的东西，而咱们现在至少有PPT画的业务界面，也有输入要求说明，也有数据增删改查说明，也有业务描述说明。而且数据库，一个中大型应用，性能、稳定性、可扩展性，都在于数据库的设计和中间件的设计，如果每一个程序员都要从数据库设计到中间件组件开发到前端客户端开发，那么要想保证这个软件的统一整体质量，那有多难。每个程序员需要懂得多少的技术知识才能达到统一的质量要求。所以，让不同技术高度的人做不同难度的事情，把重要的事情掌握在高素质的人的手中，这样质量就不会跑偏到哪里去。企业管理软件，不外乎是数据的增删改查。数据库的视图和存储过程，已经屏蔽了复杂的表之间的关系，提供了统一的业务实体视图和业务实体的增删改操作。这样中间件组件就容易处理业务实体间的流程，到了客户端，就只剩下数据的输入和输出了，真正成了终端。我还经常进行代码复查工作。发现有人的代码出现坏迹象，我就让他整改重构自己的代码。否则，定了规范，光喊口号让大家遵守规范又不检查又不惩罚，谁爱遵守规范？在代码复查的时候，我经常能发现思路局限、想法绕弯、实现缺乏扩展性可变性、缺乏优化、判断有遗漏有风险的代码。我都一一给他们指出，并且告诉更好的方法应该是如何如何。很多网友都问到如何培养开发人员、培训开发人员、提高开发人员技术。我过去所在的公司是每个周五都不定期召开技术培训会。但是慢慢的也流于形式了。我个人感觉，技术培训会是个好事，但最终达到的效果可能是加强了团队的凝聚力和和谐力，有利于团队建设，但是技术提高，并没有给开发人员在实际工作中有应用。因为大家听了也就听了，会一散实际工作中仍然照旧自己的思维习惯，很难落实下来。通过代码复查，这就是真真实实的代码，这就是大家最实在的工作成果和天天接触的东西，很有真实性，不脱离，有针对性。通过这种方法，达到了大家对自己日常写代码的技术技能的提高。这就是我对程序员的培训方法。管理是什么？有网友老跟我讨论企业管理、企业文化、盈利模式、执行力、忠诚度。我不是很喜欢这些空洞抽象的主题，讨论完了也无法解决实际细节问题。而企业的运作，恰恰在于每一步的成功，最终汇合成最终目标的实现，没有脚下的每一步前进，再好的设想也是空想。管理，就在细节当中。代码高手，也在于细节当中。质量、进度、成本、目标、折中，这就是核心。写代码，做管理，道理一样。29、风语者我们公司开始也是没有测试的。公司是创业公司，我空降的时候连卖什么东西都不确定。公司的创业仅仅出于老板对原公司的一口气，觉得还不如自己单干快活，公司要成为什么公司，可能想法很多。咨询？培训？认证？通信？数据挖掘？我从老板的书架上找到过这些书。但是真正卖什么？卖这不好卖，卖那不好卖。误打误撞就进了软件这一行当，但软件这行是否可以持续走，是否要持续走，老板还不确定，如果卖的不好就不做软件了，改做别的，现在是生存阶段，就顾不了许多了，有项目就接上。上面有老板关系搞定，下面有老实的干活人努力加班，项目也就过得去。没想到，软件这条路，居然走下去了，还接了一个大活儿，安装的点很多，涉及的用户很多，从海南到新疆，从深圳到山东枣庄。公司发动了所有实施顾问来测试，只有他们通过，才能去实施。实施顾问大多来自刚刚毕业的应届毕业生，对企业管理，对软件，对行业领域，都一无所知。对测试更是一窍不通。测试并没有分工，每个人都测试软件。也没有什么测试方法，也没有什么测试计划，也不知道该测什么。反正也是对软件不了解，就当是深入学习软件吧。开始并没有测试报告，大家发现问题，就用电话或QQ或邮件，把问题发给开发人员。谁认识那个开发人员，就发给那个开发人员，如果不认识一个开发人员，就发给老板了。报告中尽是不好用，不能用的词汇。但什么功能不好用，是怎么操作导致不好用，不好用的具体表现是什么，都没有。老板急眼了，怎么这么多问题。我说有五个原因： 1很多问题都是每个人都反映了，其实只有一个问题，只不过大家没有分工，都测试，于是都报告 2不少人见一个问题发一个邮件，所以看起来很多。 3有的人测试只是随便乱点乱输入，咱们软件还没有做这种破坏性操作兼容防范。 4不少人不了解功能，不了解行业，不了解业务，本来是对的，按他的理解是错的 5有些人偷懒，今天发的是这些问题反馈，后天又是同样我说，基于现状，我给大家一个测试方法： 1分工测，几个人测试一块功能 2不全部测，只测试那些很常用的重点功能 3不要电话、QQ、邮件来报告给单独的开发人员，给我一个人发就可以了，我来判断衡量安排。也不要随时报告。每天下班的时候来统一发送，由各个测试小组的负责人来汇总自己组内的测试，并且把重复的问题合并掉 4每个测试小组的每天的测试报告要连续在一起，不要今天发今天的测试EXCEL，明天是明天的测试EXCEL，这样没有连贯性 5每个问题，要标好功能模块，有测试人，有测试版本号，有测试时间，有测试操作过程，有测试输入数据，有报错截图 6先测试正常的数据输入，正常的操作流程，是否能全部流程走通，是否数据保存正常，是否保存后的数据还能正确的取出来。那些临界条件测试先不要做。对于功能不易操作、界面不好看、起的窗口标题是否得当，字体是否加粗这些需求不要提。咱们目前阶段的重点是测试问题，不要把需求和找问题混在一起。方法执行下去，问题少了许多。前几天大家还在抱怨这样的软件简直是烂软件，让他们拿给客户，肯定会被客户打死。现在呢，才几天功夫，实施顾问已经觉得可以去实施了。这就是有方法和没方法的区别。第一批客户的实施终于启动了，实施顾问奔向了全国。到了真实的客户那里，才发现自己的测试，自己对软件，对业务的理解是多么的肤浅。过去发现的问题原来都是小儿科，真正复杂的问题根本没有测试到。给客户一讲解，客户一问，发现原来很多功能细节没有理解，不知道怎么给客户解释。于是纷纷打电话回来问。而能回答的人只有我，我成了接线生。我当然不能成为接线生。我一方面仍然要求他们按照过去的测试问题报告流程和方法来报告实施现场中发现的问题，另一方面我自己写了FAQ给实施顾问发出去。但是实施顾问仍然问，一个问题重复的问。我说你看FAQ的第XX行。他说他看了，但没看明白（其实是对客户业务不了解，所以也不明白功能）。我就给他再解释。经过多次解释，我也了解了实施顾问的理解思路和理解层次，于是不断修正FAQ，使FAQ1.0、FAQ1.1.1这样不断发布，几乎天天发布。我现在回过头来想，帮助文件写的好不好，不能你说你自己已经写的很明白了傻瓜才看不懂，不要这样认为，这样根本不解决问题。唯一的方法就是用户理解能力有多低，你就要把帮助写的有多低，让他理解是目的，要不你还能怎样呢，就这样的人，问题还得解决。随着项目的实施，公司渐渐拢回来不少钱，但是面临了一个瓶颈，这个大项目快做完了，以后有什么活能养活现在这么多人呢。所以，最好的做法就是把现在这个项目产生的软件改改，变成一个产品，卖给其他的客户，卖的越多越好。但是，其他客户我们有关系的并不多，所以要想销售给其他客户，必须拿产品说话。于是，研发部陆续加入了专职的测试人员、文案人员、美工人员，旨在提高产品的质量和包装，希望能卖个好价格。所以说，专职的测试人员是这么来的。很多软件公司没有测试人员，其原因就是老板搞定关系，程序员老实干活，项目质量虽然不行，但也能将就把钱结了。既然能赚钱，干嘛要测试人员呢。除非由于质量问题，签不到单子。除非由于质量问题，客户不验收不给尾款。除非公司所有人都测试还是无法达到客户满意的质量。只有这样，才会招聘专职的专业的测试人员。测试人员一来了，开始工作。但怎么开展测试呢？文档在哪里？文档只有很老的设计文档，现在软件和文档已经毫无关系。为什么？原因有二：1都是程序员，谁来专门写文档。为了公司生存，我身兼数职，到处开会做项目经理或做售前，还管开发人员，还有实施人员给我打电话问软件中某个功能怎么回事，我也分身无术。 2都是根据实施人员、客户、销售人员、老板反映的需求和BUG修改。那些BUG和需求EXCEL表格倒是有，但没法作为测试案例编写的根据。测试人员硬着头皮，开始学习软件。帮助在哪里？没有？对，没有，因为没有写帮助文件的人。只有打单的时候讲解的PPT。测试员晕倒。晕完继续学习软件，什么是正确的什么是不正确的，测试人员也不知道，当然也不知道BUG究竟是什么样。软件质量仍然没有改进。老板问：这个测试人员是不是没啥能力？要不要裁掉？我说：不是他能力不行，而是咱们过去为了生存欠了太多东西。我们这会是在补过去的课。现在的文案人员正在补帮助。有了帮助，就有了什么是正确的标准。但现在的问题是，文案人员也不了解软件，她写出来的也是自己猜测，所以我已经分出来一个开发人员做项目经理，他目前专门负责把帮助文档建立起来，但是他开发人员出身不擅长写文档，但他熟知软件，所以只有他们两个人搭配才能搞定。但这种磨合，需要时间。就这样，一边测试人员瞎学习瞎测试，一边项目经理和文案人员不断讲解不断编写不断审核不断修改。测试人员终于可以编写测试案例了。但他对软件也是初步了解。由于几年发展，软件加入了大量客户的需求，很多细节的东西在帮助中也没有看到，测试人员也不知道有这个功能。所以测试来测试去，其测试结果和实施人员的测试没多大区别，都还是在门外转。老板又开始沉不住气了，旁敲侧击想裁掉测试人员，觉得他的存在没多大意义，还是实施人员测试好。但是由于专职测试员的招聘是我提出来的，也是我的直接手下，而且这个测试人员也老实，干活勤勤恳恳，老板实在找不出什么把柄把这位开掉。我说：他来自著名的外包公司，专职做测试，我相信他是专业的。只不过咱们过去缺的太多，所以他想测试，也是巧妇难为无米之炊。咱们可以继续看看。果不其然，测试人员有其独到的软件测试方法、软件理解方法。很快，测试人员对软件的理解不亚于那些多年的实施顾问，也不亚于程序员。找问题也越来越准确，越来越深入。当然，其原因也在于这个团队的成长，有专职的项目经理开始书写现有功能需求修改的设计文档。过去的，没有的，就让它过去，就让它缺失吧，但未来，不要成为过去。现在也有专职的文案，不断在修改帮助，加深了许多。测试人员现在比文案人员理解功能更细，更深入，经常提醒文案人员应该把某句话写进帮助中，否则容易被用户忽略，是个不小心就会绊倒的坑。为了使测试人员更快速的了解客户应用操作方法，更细节的了解特个性的功能，我让测试人员也兼任研发部的技术支持。有服务部的小姑娘无法解决的问题，转到你这里解决。否则，在过去，服务部小姑娘老把电话转给开发人员，本来就几条枪，被客户电话吵的无法安心开发。而且客户发现开发人员接听电话处理问题更有效，所以很多客户都是直接给开发人员打电话，服务部成了虚架子，而开发人员的开发进度被拖累，叫苦不迭。现在有了测试人员兼任技术支持，这下解放了开发人员。开发的质量和速度提高许多。但测试人员并没有做技术支持的经验，过了段时间就来和我诉苦，说现在服务部小姑娘啥也不干，都直接把电话转到他这里来，所以他现在已经无法测试了，成了专职的服务支持人员。如果再这样下去，软件质量无法保证，以后的技术支持压力更重，开发部就会成为开发+服务部门。我给测试人员出了三个方法： 1经常遇到的问题，就做成FAQ。下一次还有小姑娘问，直接让她看FAQ，拒不回答。 2交给他们方法和思路，不替他们亲自做。亲自看着她，让她服务支持客户。一次不会，再继续这样做第二次，必须让她自己亲自会了。 3每个星期六定期培训，疑问解答。并且考试。如有讲过后考试还不会者，扣钱。另外，我也对服务部下了一个考核（当时我已经统管的服务部）：你接待了多少客户问题，解决时间多长，多少个问题转给开发部技术支持了，这些问题的难度级别多高。根据这些指标来衡量服务部小姑娘们的技术解决问题能力。能力差的就辞退。这几招后，服务部的技术支持能力蹭蹭的提高了。真是没有鞭子不干活。测试人员兼任技术支持越做越轻松了。我还把版本管理、打包发布交给了测试人员。起源在于有时候客户报告了某个BUG，程序员一看好改就直接改掉了，改完后就直接联系客户更新了，但是并没有更改软件版本号，也没有做新的打包。于是出现了同一个版本号软件功能表现却不同。而且，由于项目组多了，每个项目组组长都各有各的原因，有时候自己就打了一个包给了客户，随便定个版本号，起的都稀奇古怪，有的叫beta版，有的叫6.0.20050203。这种情形导致了测试人员做测试的时候，开发人员说改了，测试人员说没改。开发人员说已经没有问题了，测试人员说我这里还能重复出来。于是两个人一起查，耗费了两天时间，才查出来测试人员手里的和开发人员手里的不一致。我又下了几招： 1开发人员绝对不能接触客户，不能接听客户电话，也不能解决客户问题，更不能给客户更新 2开发人员不能没有任务分配和设计文档就擅自修改软件，否则记过处分 3大家一致使用版本管理工具、BUG管理工具、需求管理工具、任务管理工具。用工具把项目经理、开发人员、测试人员、文案人员绑定在一起，按固化流程推进流转。 4打包发布统一交给测试人员来做，测试人员来控制是否可以发布，发布的版本号的命名。质量达不到，有权不能发布。现在，我们的测试已经能做边界测试、版本兼容性测试、系统兼容性测试、压力测试、安全测试、集成测试、破坏性测试。也已经在项目中应用全程测试，测试人员主要参与需求验证、设计验证、代码验证、文档验证、打包验证。但是，我们现在还没有实现单元测试，开发人员就这些人，项目却多。而且测试人员没有编程能力。我们也没有做更多的回归测试，毕竟测试人员数量配备太少，而项目并行太多。看机会吧。老板越从软件上赚钱，他才会越舍得投入软件。成本永远嫌多，利润永远嫌少。如果你是一名开发主管，你的老板还没有从你负责的软件中赚钱，而且是很快乐的很大规模的赚钱，而不是他靠他的人际关系和送礼吃饭支撑着，我想，他不会给你一毛钱的。你抱怨也没有用，因为你没有价值，所以投入也是没有意义。先去证明你的价值吧。30、蛋白质女孩我想给大家分享一下关于文案人员，我一下子想起了王文华写过的一篇小说《蛋白质女孩》，因为我们要找的文案就是这个样子。“她日月座是狮子和双鱼，同时会讲日文和法语。她早起，起床后先跑半小时，吃了麦片才去公司。她贤慧，每天做一打火腿三明治，带到公司请同事们吃。她有礼，快递脸上有雨时递上面纸，清洁妇来吸地时抬起椅子。她准时，和你约会前一天打电话确认，第二天寄卡片谢谢你点的果汁。她纯情，爱像宋词唐诗，意境优美对仗工整；个性像阿拉伯文，她知道它的存在却不懂是什么意思。她善良，生理时期还抱起大水桶换饮水器的水，没人注意时还认真做垃圾分类。她负责，影印机塞纸时修理到底，洗完便当后水池一定清理干净。她有礼，咀嚼食物时嘴巴从不张开，交叉的双腿一定用裙子盖起来。她浪漫，最喜欢的电影是' 第凡内早餐' ，失恋后可以好几天不吃饭。她坚强，撞见我在办公桌上和工读生亲密，她还蹲下来为我捡起地上的笔。”这就是蛋白质女孩。如果你要招一个文案，你一定要识别好，否则你很容易招来一个会打字会写诗的女员工，连个秘书的细心、机灵都没有，你和她说三遍，她只是一个劲的点头，但她还是不明白。写出来的东西，重要的关键的一句没说到，写的没有一点企业味道，无条理无格式，像是散文。文案是有了，但对产品一窍不通。她有看不懂设计文档，她又不了解客户行业，她又没有做过实施，客户现实中怎么应用怎么操作有哪些疑问她也不知道，怎么写？能看不能用的文档我见多了，一篇篇帮助写的很是精美，但真遇到问题，啥也帮助不了。为了文案能快速提升她对产品的理解深度，我煞费苦心。首先让她写产品简介。算是让她对产品有一个框架性的认识，对软件的流程，亮点，实用性这些关键点进行一个把握。但写完后，她自己都感觉像白开水，她说我没有感觉到咱们软件的好处，也说不出来软件有什么亮点，而且亮点也不亮，说的勉强。汗！第一次指导失败。我又想了第二招。让她兼任测试员。由于她不了解产品，也不懂技术，正好可以以一个普通用户的心态和操作方法去测试，而且测试的过程中可以深入学习功能，一举两得。结果是：帮助写完了，让实施人员和服务人员一校验，说没有价值，写的这些现在的客户都会，即使新客户，实施人员培训完了，都能掌握。我们要的是实施人员实施完毕不在现场的时候，客户不会操作时，不需要打咱们服务部电话，自己就能知道怎么做。汗！第二次指导失败。我又想了第三招。让她给研发部内部全体人员讲，让大家给她提问并补充她的知识。结果是：小姑娘准备的很紧张，讲的也很紧张，缺乏结构、条理、重心，丢三落四。大家还是很耐心的听完了她的讲解，并给她提了一些建议。我希望她根据大家的反馈再准备讲一次。但是过了两天，小姑娘跟我怯生生的说：我想跟你辞职。我真的很笨，可能我不适合做软件文案。我吃不下饭，睡不好觉，昨天哭了一晚上，我知道您是一位好领导，是为了我好，但我能力不行，我辜负了您的培养。？？压力太大，把小姑娘吓跑了。看来老革命遇到了新问题，我不仅不会培养文案，而且不会调节小姑娘。我赶快向小姑娘道歉，表示我拔苗助长，心太急。我看好她的潜力，我希望她能留下来。我说我可以把你调到服务部去做支持，可能你在那里会成长的更好。小姑娘留了下来，去了服务部。一个月后，我和服务部经理吃饭，我询问这个小姑娘的提升如何？他笑着说：你是不是想让她回去？我早就看出来你是想把人到服务部来锻炼一把就走。可惜，我不放人了。你们这个女孩，心细、老实、有耐心、有韧性，是做服务支持的好苗子啊。不过，小女孩还是回到了开发部。我和她谈心：你希望回到开发部做的第一件事是什么？她说：把FAQ融入到帮助中。我问她：到服务部一个月，你觉得你最大的提升是什么？她回答：客户感觉。我过去写东西言之无物，下笔无神，就是找不到这种感觉。虽然我仍然没有见过真正的客户，没有到过真正的现场，没有看到他们真正的操作，但是从他们的电话中，和给他们做支持的过程中，我理解了他们的思考问题的思路，他们的应用水平，以及他们也是人，活生生的人，在QQ中和电话中也挺逗，不是我过去空洞洞的给钱买单的那个形象。我理解了她说的话，我想，她找到的这种感觉和我们做软件设计时候的拟人法，面向客户场景的设计方法是一致的。我们也是通过模拟客户场景来达到对客户真实的感觉。果然，写出来的帮助有料了许多。但好像还缺少些什么：有一步步的操作截图，有一步步的操作说明，有特殊业务的特殊说明，有FAQ，有重点注意地方的重点标注，内容很丰富，但还是缺东西。我想了想设计文档：有界面草图，有业务流程，有数据流程，有输入要求，有输出要求。对，缺的是输入要求说明和输出要求说明。文案按我的要求，把界面上的每个字段都做了解释，形成一张表格，每个字段一行说明。有这个字段的含义，有什么样的作用，是否为必填，是否有默认值，输入的约束是什么，什么时候是只读的，可能会有几种状态值，如果是下拉选择的参照录入，参照字典是哪个基础数据维护功能可以维护。对于输出报表，报表每个字段的含义，报表每个字段的数据来源，字段与字段之间的钩稽关系是什么，此报表字段还与其他什么报表的什么字段关联。正好实施部门有一次客户实施，我也安排了文案作为辅助实施人员去跟随实施，到客户现场真正锻炼见识一下。回来后，小姑娘写起文档信心百倍，下笔有料。她已经成为了一名合格的文案人员。就连销售部门都想要走她，销售经理一个劲和我说：这个小姑娘心细、踏实、产品也了解，也做过实施到过客户现场，也做过服务支持，文档也做的漂亮，我们销售部给客户做方案正需要这样的人。当然，我就不会放人了。但是我也松了个口：如果销售部需要什么文案，可以让她来帮忙做。她人在开发部是好事，可以持续深入的理解产品发展。如果到了销售部，她可能就缺乏了这种对产品了解的基础，她又不适合做销售，那么她以后就会慢慢既不懂产品又不懂销售，成了销售部的废人了。果然，销售部很多文案，都转来让她帮忙。我过去最头疼的就是开发和销售的结合。开发和销售老打架扯皮，销售部嫌开发部开发的产品无法销售，开发部嫌销售部整天好吃好喝好玩什么产品也不懂大嘴一张只懂吹牛，留下了一屁股屎让开发部擦。现在，我有项目经理充当售前，堵住了销售部的吹牛大嘴。我有文案人员充当客户方案编写，让过去销售部夸大空洞的解决方案有了实质产品感觉。为了打单方便，文案还制作了演示版，里面有模拟真实客户业务的数据，可以达到完整的演示全部流程和报表表现。但是，我还有个问题要交给她。我发现这样一个现象：不管是实施部门、服务部门、销售部门，对产品的了解还只是停留在产品最初的几个版本认知基础上。现在软件已经升级了很多版本，加入了很多细节功能，也修补了很多Bug，但大家都不知道。仍然在按照自己过去的理解讲。虽然每次发布新版本，都有更新变动说明，都有最新的操作说明，也有操作视频，但没有人看。这和我们在网上遇到的很多开发人员一样，网上大喊：冰天雪地360度空翻裸体在线跪求，非得让人明确告诉他去看微软某个文档的第几页第几行才算了结。或许，人都大多如此。其实，我们已经加入了很多特色的功能。其实，我们已经加入了很多处理各种各样情形业务的功能。但很多人告诉客户，仍然是我们做不到，只有让开发部定制开发了。有时候有很尴尬的事情出现：客户兴冲冲的告诉实施人员，我发现你们的软件中有个很好的功能对于我们很实用。实施人员呢，反而不知道那个功能。倒是客户自己研究琢磨出来了。让人汗颜。我交给文案的任务就是：每当新版本发布，你对照你写的更新变动说明，你的操作说明书，你的操作视频，你的演示版，你搞个集中培训。并且你出题，给他们考试，给他们打分。但你给他们做培训的时候，必须有正规的签到表，正规的培训教材，正规的培训PPT，掌握好一节课的时间，掌握好一节课的重点，掌握好一节课的快慢与难易程度的节奏。下了课还必须让他们填写本课的培训反馈。你整天在这里写呀写呀，并不是我的目的。这样的状况，你写个十年又会如何呢？人需要成长。我希望你能成为优秀的咨询顾问或者培训老师，如果有可能，你也会成为优秀的市场人员或销售人员。这是我对文案这个岗位的职业发展期许。但是，机会是需要你去铺垫创造，你去抢机会（你自己铺垫的机会也有可能被别人抢走），你去有能力抓住机会，机会并不是我送给你的，机会是转瞬即逝的，你懂吗？文案小姑娘咬咬嘴唇，坚毅的点点头。这个蛋白质女孩。32、一分钟先生有很多网友特奇怪我为什么能有时间来写博客，甚至还能接受网友的IM交流，问我是怎么做到的。他们都觉得自己每天忙死了，相信我作为部门的头公司的高层，估计更忙的不见人影，怎么回事呢？我总结了总结，在此给大家分享一下。首先，我每天的工作主要干什么？1每日接受开发组长报告给我的进度报告、功能需求设计报告，我来提出调整建议和指导。对于报告的问题，我会给出建议的处理方法。如果需要我出面动手解决，那我就出面。这是每日的例行事务，占了主要的时间。2处理手下员工间的流程配合问题，处理部门间的流程配合问题。一般都是根据现在出现的问题重申和强调过去的流程、职责。如果需要调整流程和职责，就把新的流程和职责重新定义清楚，并且观察几天的执行情况，直到每个人都按照新的流程走。3定期重新回顾这段时间公司业务的开展情况和面临的困难和未来的动态发展，以重新审视自己过去定义的产品战略，不断调整，以适合公司发展变化。根据产品发展战略的调整，然后调整内部每个人的职责和分工。4定期和每个员工在MSN中沟通或面对面沟通，了解他们现在的心理变化、薪水、公司发展看法、职业发展看法，以自己掌握的信息和自己的经验，对每个员工提出指导建议和方向建议。对于没有个人目标的员工，和他一起交流制定一个可见时间内他可以达到的目标。如程序员，我会提出，在6个月内，让你的代码变的比现在稳定，至少要达到你自己心中的满意的稳定程度。然后，我会针对这个目标，时常提醒他，不要让他忘记这个目标，鼓励他一定能达到这个目标。不提醒，人就会渐渐忘记了自己上个月才确定好的目标，甚至由于当前的诱惑和问题，对自己定的目标发生了怀疑或不感兴趣，就失去了目标。5对于每个员工所干的工作，我也会根据他最近出现的问题，及时进行能力方法、技巧的指导。如你应该这样做会更好。对于如何写稳定的代码、高性能的代码等等，对于如何测试找到更深层次的问题等等，都有技巧的指导，而且都是结合他现在所遇到的问题和手头的工作。我不会专门拿出一段时间来专门培训。我都是在日常工作中不断指导，把培训都化在了每日的工作中，尽量做到润物细无声。对于一些新手程序员，我拒绝回答他们的技术问题，我通常会说：把你们报错的那个信息原模原样输入到百度中，你就会找到答案。你也可以查询微软、SUN的联机手册，或者你到CSDN上问、搜索。6我还会平时看IT技术网站、行业网站，思考客户行业发展、IT技术发展。我来研究软件中的管理思想、管理模型、管理业务流程优化、考核评价模型。管理软件、数据分析咨询业务、市场推广，很需要这些模型和文章。每当我研究出一个管理模型，我就会写文章在内部发邮件，给公司老板、高层、员工推广。7偶尔我会跟着实施、咨询团队到客户现场，体会真实的客户应用，和客户面对面交流，交流现在的问题，交流目前的困境和焦虑，交流未来的发展看法，体会客户真实的想法、思考思路，体会客户的真实应用水平。这就是我大概的每日工作内容。我能把时间省出来，最重要是以下几点方法：1由于我经常性思考产品发展战略、盈利模式、管理模型、工作职责、流程制度，所以公司的发展一般都是按照计划和既定流程走的。很多公司也不知道自己做什么才能赚钱，就东一头西一头拉项目，所以也不会有产品发展战略，而一般老板也是销售出身，想不透软件产品如何发展，而技术总监呢，又不懂这些，可能就是个技术牛人而已，甚至连技术牛人都算不上，只能算个一帮人的头儿。我们过去也是没有产品发展战略，但我是职业经理人，我不能让公司东一头西一头的随波逐流，所以我常常思考公司现状，从公司的现在的资源和优势和困境来找一条产品发展路线。就这样不断思考不断尝试不断执行，渐渐的，在我空降公司3年后才找到了现在的清晰的切实可行的产品发展战略。有了切实可行的产品发展战略，随之就有稳定的工作流程与职责，每个人就有了稳定的计划和工作任务。变化少了，自然也就不会老救火了。很多人说忙，就是老出异常，老救火，公司没有稳定清晰的盈利模式，一直处于抓项目的状态，每个项目都没有连贯性，当然也就不需要流程，也不需要职责，有了项目大家一窝蜂加班，没有项目大家闲的要死，这样的状态，即使有流程和职责也是被废掉，根本没有用，执行不了，项目一来就废掉了。2我不会去处理事情。我总是授人以渔。我一直强调方法和流程。如果一发现新异常，没有流程和职责和明确的人负责，我就会立即把这些都补齐，让明确的人去处理，而且有明确的处理流程。如果明确的人没有方法和头绪，我会指导他。但我从不会亲自做。3就是因为有稳定的模式和流程和员工岗位，我就从细节中抽了出来。需求调研、功能设计，有项目经理。开发有开发组长和程序员，测试有测试员、文档有文案人员，实施有实施人员，支持有支持人员，每个事都有专门的处理人员，而且有明确的流程协作。由于我的平时不断的指导，还有他们每日都处理自己专门的事情，所以他们对自己负责的事情越来越经验多，处理起来很快，质量也高。我看到很多公司业务不固定不稳定，人经常被抽调来抽调去，当然经验积累就不深入不专业，工作就不胜任，干活质量和效率都不高。4我这个人很专。我清楚的知道自己的优点和缺点，自己想要走的路。所以我十年，一直在开发岗位，而不是去做项目经理，去做实施，去做售前，去做市场，去做销售等等。很多人尝试了不少工作，但我没有。我知道自己，所以我总是把自己很优秀的方面练的更加优秀，这样我的缺点就非常明显，因为我没有去想着补齐我的缺点，我根本就没有为我的缺点投入任何精力。所以我这个人看起来很简单，同事们都能很容易看出我的优点和缺点，而且我的优