第 7 页

我一般都是把我们这个产业的竞争格局现状了解清楚，我们的过去现在，竞争对手的过去现在都了解清楚。然后我去研究我们的客户行业的竞争格局、层次现状。看看这个客户行业盘子，三教九流到底多大多复杂，我们现在是占了多大，我们还能占领哪些客户群。

然后我就研究客户行业目前的挑战、机遇、困境。能解决其中一两个问题，就是咱们的竞争亮点。如果作为软件一点都解决不了这些业务困境，我就思考如何让产品做的更易用。微软不就靠着易用发家的么？

最后我会去研究我们公司现有的研发优势和弱势、实施服务销售的优势和弱势，找到适合我们突破的地方，具体归研发能承担能起作用的事情，我就会去动员做。脱离现实资源现实矛盾现实包袱的改良，是无法做到改良的。

我还关心各种新的技术应用。可能这项技术很久了，但大家都没有想过还能这样用。所以，我常常在媒体上关注这些、思考这些、在论坛上和业界交流这些。对于新的技术，要研究原理，要尝试，但不要冲动引入到商品生产中。我们不是自己在创业在玩在实现自己的梦想。我们承担的是公司所有人都要吃饭的产品。如果有闪失，这么多人以及他们的家庭都要受到影响。这不是闹着玩。

当我研究完业务领域的这些大的框框以后，每逢有业务同事跟我交流客户需求，我总能把这个需求和我的业务框架联系在一起，把这个需求归好类。并且能判断出这个需求是个反趋势的需求，还是个短期眼光的需求，还是个长远发展的需求。

很多人都在抱怨说需求老变化。其实，不是客户需求在变，而是你对客户的需求老是不同思路去理解。我心中有业务框架，有过去，现在，未来，所以能识别出一个需求是稳定的还是临时拍脑门想出来的。有时候，有人向我提一个需求，我会眼睛一亮，对，这个需求符合未来发展，我就会很快加入。所以，我曾经在做实施经理的时候，老是能很容易说服客户，让客户听从我的意见，就是由于我想的比他们还要远还要周全。好多程序员说客户非要某个功能不做不行，就说明这个程序员并没有理解客户。客户并不是那个非要和你作对的人，他只想解决他的问题。可能你不理解他的真正根源问题而且你又提不出更好的方案，所以他要跟你急，要让你必须实现某个功能。

只有你不断游走在业务过去现状未来与技术过去现状未来，你做的架构才是真正的实用、弹性、易用，而且最小成本，不走弯路，不多花开发精力。

我们需要架构，不就是为了达到这个目的么。

18、焦油坑

我有一个以前的同事。过去他总认为能成事的人什么时候都能成事，不能成事的人你再扶他也成不了事。所以他带领人的方法一般是他以身作则，你如果有悟性，你就照着他做，如果你看不出来，那么你就自己一个人玩着去，能玩成什么样玩成什么样。

我主张的是：普通人通过使用一定的方法和规则，做事情虽然无法做到优秀，但也至少能保持一定水准，不会把事情做烂。如果任由普通人自己去想自己去做，这要管理者何用？作为管理软件开发公司，其管理思想，竞争不过管理咨询公司，其技术实力，又没有技术门槛，属于那种规模化生产实施服务的类型。所以，管理软件开发公司要想成长，必须走规模化路线。而规模化路线就需要依靠大量的普通人才，而非个别的英雄。英雄是很难找到大量人才的，而且优秀的人才其成本也高，更约束的无法规模扩张。这和规模化路线有悖。

所以，他带出来的兵都是单兵作战能力很高，都属于那种能救火队员型，有问题冲上去嘁哩喀喳就搞定。领导是很喜欢这样的人才的，因为这样的人是多面手，是特种战士，把一个人随便往哪一扔都能把项目完成的很好，很省成本。但是这样的人才有个特点，没有一年半载，这样的人培养不出来。而且这样的人往往都游兵散勇似的，一遇到必须合作的事情就变扭，老觉得其他人办事都不放心，都觉得别人做的没他预想的那么好，还不如自己一个人都包办了快速且省事。

而我带出来的兵都是团队作战型，每次做事，都需要好几个各自发展专业的人配合，一个人还搞不定。就好像开发的时候用开源的框架，本来只想使用A框架，没想到A框架使用了B框架，B框架使用了C框架，最后软件没多大，倒是框架很大。虽然我都是极力推行四套马车4人一个小组，而且可以看项目进展安排不断调度组合，但终究不如一个特种战士那样自由。但有一个好处就是做事专业，发挥稳定，培养成长快，好招聘好留人团队稳定，薪资成本也低。

隔了这么多年，我的电话也换了，他的电话我也没记住。我们就这样断了联系。

突然，上个星期五，他给我发了封邮件。说他偶尔看到了我的博客，写的不错（不知道是不是真的不错，反正他以前一直反对我的这种思路），希望我能写些关于需求管理的文章。

我赶快根据他邮件中留给我的联系方式联系到了他。

我问他：你怎么找到我的博客的？

他说：这几年越来越不好做。客户对开发对实施对服务的质量要求越来越高，一个人去现场边修改边实施，客户觉得付那么多钱不合算，怎么着也得派一个团队来实施。但是，团队实施没有人手啊。培养一个人一年都上不了手，对于我们来说团队实施就不合算了。但客户就要团队实施，不团队实施就无法接单。所以，我现在也在找一些如何团队开发实施的文章，无意就找到了你的博客。

我们现在也是文档化管理。从需求调研到需求确认到需求设计到需求开发，每一个环节我们都是和客户文档确认，大家都觉得没有问题了双方看法一致才开发。一开始使用就发现需要修改的东西很多，而不修改又导致客户无法使用下去，最后不断修改，导致实施周期长，结果还跟过去一样，质量也没提高，周期也没有缩短。所以，比较迷茫，是不是哪里做的有问题？你一直挺注重过程管理，看你写了那么多文章，肯定这么多年你一直在研究这方面，所以我估计你有一些好的方法。

我说：我这些天写博客，接到不少网友的评论，他们也强烈希望我能写一篇关于需求管理的文章。我过去也有一些只言片语的积累，所以这次我就准备写一篇以了大家心愿。

当我开始动笔写这篇博客的时候，我脑海里直接的就是《人月神话》中最著名的一段话（不好意思，其实我没有看过人月神话，不知道作者提供了什么解决方法解决需求难题）：

人类史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧去挣脱束缚，到最后它们都沉到了坑底。

这段话描写的栩栩如生，和我们日常遇到的需求困境如出一辙。

中国人的需求很特别，好像事情都特别赶人都特别忙似的，都寥寥数语就以为他的需求已经说清楚而且你也肯定明白了，到底能不能实现，实现后能不能可操作可执行，都是匆匆一个见面一个电话几句MSN几句MAIL然后就等着软件开发出来用。

我看到日本人花费一年的时间反复和客户讨论需求，深入到生产一线天天蹲点，还派人拿专业的测量工具来记录，如拿秒表记录操作的时间，拿摄相机拍摄操作流程，有大量的过程检测指标需要15分钟确认一次，很是认真，然后才设计解决问题的软件功能。对于每个操作的软件界面也是反复和客户确认，如何更容易理解更方便操作。

我见到许多国内项目经理调研没个方法，东一榔头西一棒槌，需求调研像是开座谈会，一屋子人，有干系的人都请来开会。有最终操作用户，有部门管理者，有大老板，有二老板，有计算机室，好几个部门。每个人站的角度，层次都不同，关注的问题重点也不同，眼光长远也不同，有人悲观有人乐观，有人不懂装懂，有人不懂瞎嚷嚷，有的部门影响力大气粗的不行，有的部门比较势力小唯唯诺诺，有的部门不愿意多干就推来推去反正不是他部门的事情，到底是哪个部门的事情需要大领导来定，但可惜大领导没来，有的部门怕自己那点内部发小财被破坏了就故意找各种各样的困难还说的头头是道，于是一帮人叽叽喳喳，没个结论。有时候开会开多了，实在说不过去了，必须要有一个结论，于是每个人的意见都上了需求本，回来一整理，没法弄。

我曾经参与过一个项目就遇到了这样一个情形，最后拖的时间太长，项目主导方认为没什么利益可赚，而客户冲突利益太多，就放弃这个项目了。

“表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当他们相互纠缠和积累在一起的时候，团队的行动就会变得越来越慢。”对于问题的我们很难看到本质，不过，如果我们想解决问题，就必须试图先去了解问题。

这是《人月神话》中的一段话，我从网上找到的，估计那个项目经理很遗憾没有看到这句话。

风水轮流转呀。真不小心，新一轮领导换届，新领导上台。这个项目又被作为领导新政提了出来。（注意，不是政府换届，而是企业领导换届。我从来没有做过政府的单子）这回，项目主导方变成了我们。我成了项目经理。但是，除了这位新领导，过去的那帮人还是那帮人，我仍然要解决这帮人。（我的一位助手笑称这帮人是成事不足败事有余。上一次我是挂名，他是真正参加了上一次的项目每一次开会。这次，我找他做助手，希望他的上一次经验能给我提供帮助）我这次没有像我的助手上次项目一样，让计算机室帮忙到业务部门要这信息那表格。

我首先向计算机室要了一份全企业的部门组织结构图。我先看看这个盘子到底多大。我曾经刚出道的时候就遇到一次滑铁卢，半路地杀出来一个部门领导竟然严重影响了项目走向。

这次，我把全体部门都纳入思考范围内，了解我这个项目和各个部门的关系。最后我按项目关系紧密程度把客户各个部门排了一张表，每个部门的负责人的名字，联系电话我都要到，每个负责人的年龄，每个负责人的性格，我通过晚上请计算机室没有结婚的小伙吃羊肉串了解了个一清二楚，谁说话算话，谁比较和事佬，谁比较见风倒，谁和谁不对付。想问问他们大老板是怎么看这个项目的，想达到什么目标，他说他也不清楚。

我先去亲自找最容易配合我的那个部门（我并没有采用聚众开座谈会的形式，而是单个击破法）。但他不是和我这个项目关联最紧密的部门。但他最容易突破。

他和我发了一下午的闷气，有对企业现状的灰心与不满，有对理想做法的想象，希望我能在这次项目中把他的想法全部实现了。

不过这次聊天我也受益匪浅，对这个企业的各种来龙去脉了解了许多，使我在以后的小心翼翼项目推进中避免了很多人为的障碍。

但这不是我这次找他谈的真正目的。他絮叨了一下午，我临走时才说出了我的目的：我需要把他这个部门的报表和单据收集回去。

他很配合，把他的得力干将叫了过来准备安排，我说别了，我跟着他去自己收集，这样我对您的需求也理解的更深更直观一些。

于是，我跟着他的得力干将，一位36-37岁的中年女士一一到每个重要的人的桌边，我和每个人都讲明了我的来意，他们将他们手头的报表和单据全都拿给了我。有EXCEL的，有WORD的，有每月PPT述职报告，有纸张的，有电脑软件上的报表都打印出来，有电脑软件上的数据输入，我就帮他们COPY屏幕打印放到我的U盘上。

我一个人一个人的边收集边问，通过他们给我的表格，我就大致知道了他们的工作岗位内容。

然后，我问：哪些表格是你最常用的。

于是，那个人就帮我挑出了好几张。

然后，我依次把最常用的，次常用的，偶尔用的报表都分了类。

我又提出了问题：哪些报表影响你的考核和奖金工资福利之类？

他又帮我挑出来一些。

我又对着他挑出来的影响他的考核的报表，拿起每一张问他：在这张报表中，你最关注哪几个指标？

他一一指出来。我顺着他的指，边和他交流这些指标的关联关系。

然后我拿着这些指标问他，这些指标是怎么的数据是怎么得来的。

他就帮我从这一堆的电子的、纸张的单据中找了出来，并且解释怎么输入的。

然后我对着每一个单据都问他这个单据的使用频率，是每天、每周、每月、每季还是每半年、每年。是每天（周、月、季、半年、年）的期初做、期末做、还是平时做？哪个频率高？高到什么程度？

这样，我就明白了每个人主要真正做哪些事，怎么做，最后怎么考核，哪些事最重要，哪些事每天做，哪些事频率最高。

常用的功能，重要的功能，性能压力大的功能，稳定性要求高的功能、数据精确要求高功能，易操作性要求高的的功能，就是从这些提问回答中自然浮现出来的。

我的那个助手用笔在笔记本上不断记录，手累的最后回来都说手写的都抽筋，告诉我下次不要这么快，让他好记录全一些。还给我看，为了记得快，字都写的有些现在不认识了，还得靠回忆，整理起来特费劲。我说，行，行，我一定注意。

我们回到宾馆后，先制作了一份草稿，粗略的列出来这个部门的组织结构、人员岗位角色说明、业务流程图、考核报表。第二天，然后针对这次项目，把这次项目相关的详细描述出来，并且把核心业务流程和非核心业务流程分开。

第三天上午，我们又去了那个部门，针对每个报表间的钩稽关系，每张单据录入的每一项录入要求、默认值、必填项、唯一约束、录入校验、单据状态、可选值都做了详细调研。

在交谈中，我们又发现了一些流程，这些流程都是些特殊处理流程。我们也发现了一些异常的操作，是发生特殊业务时候的土处理，我们都如实记录了下来。有时候，你专门问他异常流程的时候，他反而回答不出来。大部分人没有系统性思维，都是以事论事，讲到哪里想到哪里。所以发现异常流程，发现新流程，全靠调研人自己细心发现和甄别。可能，他无意的一句话，你直追着下去就会发现他日常处理的空白和漏洞和矛盾的地方。

第三天下午，我们继续工作，单个人访谈，把每个人工作中认为最想解决的问题都提出来，但只能说5个，能想到哪些就说哪些，我们一一记录。

第四天，我们把我们过去画好的组织结构、人员岗位角色说明、业务流程图，经过昨天的调研，又修改补充了一些，在整理的时候，我们用红圈标好了业务处理漏洞和矛盾的地方，并且对这些地方都提出了改进建议。把他们每个人认为最想解决的问题都考虑进流程和业务单据报表中，建议增加什么流程、建议增加什么单据、建议增加什么报表，谁来做，怎么做，谁来监督，怎么考核。

一份优化好的流程展现出来了。

第五天，我们又去了客户那里。这次，我们组织了部门座谈会。我们给他们整个部门都讲解了我们梳理过的流程现状，给他们说明漏洞和矛盾，给他们说明我们提出的方案。

座谈会非常顺利，全在我们的意料掌控之中。他们非常惊讶我们能在短期内画出这么专业的流程图，其理解透彻度比他们自己还要清楚。而且对他们问题的把握准确，对他们问题的解决思路之巧妙，都不禁赞叹我们。每个人的疑问和建议都融入了我们的流程改进思考之中。客户部门给与了我们很高的评价。

接下来，我并没有把这种方法扩展到其他客户业务部门的调研。而是我把这份调查报告又给了他们大老板演示了一次。他们的大老板从来没见过这样专业的调研，赶快召集各部门头头都来开会，乐的喜笑颜开， 大赞这钱花的值，他们只想到上套软件，没想到上软件讲究这么大，他们自己都没有如此明晰专业的流程图。他们的大老板赶快让我给他也COPY一份，如获珍宝。

有了大老板的肯定，我做一个部门的调研，就给他们的大老板发一个报告邮件。邮件抄送给调研的业务部门负责人。

我所有的调研一帆风顺，各个部门配合极好。上一次项目的扯皮推搡都不见了。

我的助手说：你这个人有点邪门。

我一笑。

19、一个人的战斗

今天早上，有个网友给我发了一条消息：他是一个老产品版本维护开发人员。他应聘到这家公司的时候，这个产品已经卖了4年了。最初的开发者已经都在这4年中不断流失走掉了。他来了，任务就是维护这套软件，而且就他这一个人维护这套代码，有BUG改BUG，有需求就改需求。

虽说这套软件卖了4年，但真不知道是怎么坚持了4年。他接手的时候仍然是BUG百出。代码没有文档，没有注释，连表结构说明都没有。代码莫名其妙，经常横插一句代码，显然是客户报告了某个错误，为了临时解决这个错误而做的针对性处理，但到底是为了修补什么错误，代码也没有说明。所以他也不敢乱动，但还要修改需求，只能硬着头皮来。他也不知道自己修改的代码是否还会引起其他的问题，只能凭空企求千万不要出问题。老板还在到处吹产品很成熟，而他每天都在心惊胆战，害怕这套代码不知道哪天突然崩溃，出了错误自己都收拾不了，那只能自己被K掉。他能想像的出老板发怒的情景：这么稳定的产品你都搞不定。

他希望我能帮助他出出点子。

我想了想，能有机会开发新产品或新项目的程序员是很幸运的，因为没有历史包袱，白纸画画。而现在大部分的软件公司都是拿一套已经有了型的代码到处修改客户化做新项目。真正做一个新项目从头编写这个项目的第一行代码，这样的机会比较少。

对于修改现有代码适应新客户新项目，这种情况非常多，也是大部分没有文档，修改定制没有注释。客户打电话说了一个需求，能技术达到就答应下来修改，修改完就给客户覆盖，根本没有需求管理、版本管理。而这样的代码，还不是一个特定客户一套特定定制化代码，是要给其他客户也更新的。很可能这个客户好使，那个客户使用其他功能的时候就出了错。按下葫芦起了瓢，是很常见的现象。

我问他：现在你改的代码有注释吗？

他回答：没有。自己修改的自己都记得，即使忘了，看看自己写的代码也能回忆起来。所以也没有写。

我问他：那以后他走了，其他人怎么办？

他回答：反正也是一个烂产品，其他人怎么办，他就管不了了，就应该让这套烂代码尽快死亡，省得祸害别人。

我问他：那你找我帮助的目的是什么？

他回答：在我工作的这段期间内，它不要崩溃就可以了。

我无语了。

关于老系统维护这个话题，我和许多开发人员都有过深入的交流探讨。

许多从事开发的网友认为，一个老系统要维护好，必须具备以下关键因素：有责任心、有文档、设计前做好详细的需求分析、要有需求管理、要OO编程、要有专门的测试人员。如果没有这些，干脆推倒重来，如果不让推倒重来，那就赶快跑路，否则就容易当了冤枉替死鬼。

但现实中，往往维护老系统的就一个人。这是很矛盾的事情。一个软件的开发，往往1-2月就完成，而它的销售、实施、升级周期却长达4-8年。但每个老板好像都认为软件已经开发完毕，修修补补都是小功能，所以一个老系统维护人员就OK了。殊不知白纸好画画，而要在别人的画儿再能点睛成龙就难上加难了。

我在管理运营企业的时候，发现遇到的难题也和维护老系统面临的很类似。都是缺这缺那，部门之间利益冲突，人的素质怎么也提不上来，员工和老板互相做猫和老鼠的游戏，不断博弈薪水和付出劳动力的平衡。总有些公司的历史留下的人留下的势力格局留下的客户印象留下的做事方法不能改变，也无法推翻重来，但公司还要发展还要提高，就必须以目标为中心，不断象骆驼一样挺着风沙干渴饥饿领队前进，有各种困难阻碍都要不断清除，无法根除就想办法平衡与缓解，时而让步时而迂回时而强势时而突然决策突然执行，公司就这样不断持续经营下去。

所以，维护老系统，也要象经营企业一样，不断继承包袱，不断细心剖析问题，剥茧抽丝理清思路，不断改进，才能渐渐从恶性循环走向良性循环，才能把一套烂代码扭转成可持续维护的代码。

我给了他写代码的八个建议：

一、重点把控输入数据的校验。你看见很多横插进来的代码，就是由于输入的漏洞进入，最后引起后续数据处理出错，所以以前的程序员他不截源头，他在最后爆发的地方堵漏洞。现在WINDOWS程序都是消息事件触发式的，还说不准这个流程会走到哪里，他堵得了这个口，其他根本想不到的触发，他能堵住吗？所以，把输入数据的校验，在保存按钮第一步代码写好集中的详细的校验。而且，这块代码要写成函数，不要大流水，省得代码复杂性会让程序加速崩溃。

二、以后的需求再往上加，都写成函数。遇到比较大的IF..ELSE判断，就把其中的代码段再分出一个函数。

三、以后再加功能，尽量不要做成联动触发的。也就是说：保存，最好是单表保存。即使是主从结构的单据，如果客户不强烈反对，也做成先保存主表后再让录入明细表。而且录入明细表要单独的窗口，这样功能和代码都简化了。如查询一张单据，也不要上边是主摘要，下面就是明细联动。这样影响性能。更因为速度可能慢，用户会连续点击多次，触发事件就会乱，莫名其妙的错误就都产生了。最好是双击主摘要，弹出独立的窗口显示明细。

四、你以后写代码，把特殊处理业务和正常处理业务的功能代码分离。就好像你走路，老有人给你下绊子，你就感觉不爽。

五、现有的功能，把不常用的功能做一些隐藏处理，放到一个不起眼的位置。使用的人就会越来越少。到时候就适机真正藏掉，不让它触发了。

六、其实很多时候，你觉得程序很烂，索性破罐子破摔，是由于以前程序员的代码排版可能和你不一样。你喜欢两个空格，人家喜欢三个空格，你就觉得不爽。人家喜欢把{放在最后，你喜欢新开一行。你可以使用代码格式化工具重新排一次版。我看到很多关于老代码维护人员，抱怨变量都是M、N、S、Button1之类，但其实你阅读理解代码，这些并不会使你理解有歧义或读不懂，只不过你不爽而已。理解了这个不爽，你就会心平气和一些，修改代码会更加顺利一些，你越和旧有代码生气，你的工作越乱。（看到这里，相信很多程序员都会会心一笑。真正的根源在于此，老系统无法维护只是借口而已，可能希望老板认为自己的工作很辛苦很复杂而加薪）。真正危害大的是全局变量和大流水代码。所以写代码，要严格避免这两个坏因素。

七、修改需求或BUG的时候，要按照模块来集中修改，而不要挑好改的先改了，不好改的就最后改。按照模块来集中修改，你会通盘考虑所有这些需求和BUG，而不是糊窗户式的补窟窿。

八、我曾经和很多做维护的开发人员都做过交流。他们都觉得一个软件没有文档，没有注释，简直就没法维护。但确实是很多软件没有任何设计文档，连帮助说明都没有，代码也没有注释。而这些软件又出自他们自己之手。也就是说他们一边抱怨没有文档没有注释，一边自己也不做文档不写代码注释，不知道在等谁来专门做。我问他们到底需要什么文档才可以将一个软件维护的越来越好，从一套烂代码扭转到一套良好渐进的代码？他们说要要表结构说明、要详细功能设计书。表结构还好说，可以整理出来，详细设计说明书就不容易出了。

我曾经也维护过别人的代码，也是什么文档都没有，连操作使用帮助都没有，更别提详细设计说明书和表结构，代码当然没有什么注释。我并没有去整理表结构说明。幸亏这个人喜欢数据库上倒弄，写了大量的视图和存储过程。视图中有各个表之间的关系连接，也有各个表中重要字段的中文名。这样我就不需要表结构说明了。因为表结构说明不仅需要需要描述每个表中字段的中文含义，也得描述表之间的关系，这和视图能表达的效果是一样的。所以，我现在也建议开发人员写代码，多写视图，多写存储过程。有的老代码，SQL语句都生写在代码中执行，没有视图。对于这样的老系统维护，就是把这些SQL COPY出来，做成视图，这样就好维护了。

对于详细功能设计书，其实对于程序员来说，其目的是想弄清楚业务流程的来龙去脉细节。光直接看代码是很难弄明白意思的，又没有什么其他文档可以参考，所以只能猜测代码的意思。尤其很多维护人员，很多功能细节都是为了处理某些特殊需求和异常业务的，都是以前的程序员写的，但是以前的程序员已经走了，现在的维护人员连软件中具体的这些细节功能都不知道。当新的实施人员或支持人员反馈回疑问，想问问程序员某个细节功能是怎么回事，程序员都发蒙，嗯，还有这个功能？我也不知道呀。

要解决这个问题，我曾经做过的事情就是组织实施人员写功能操作说明帮助。因为实施人员要给客户去培训讲解，没有帮助说明，只能一张嘴叭叭叭的干说，实施人员是最需要功能操作说明帮助的。但是实施人员认为这个帮助是软件的一部份，而且是开发部开发的软件，开发部最了解功能，所以帮助文档应该开发部写。而开发部认为开发部的职责就是编写代码，你自己培训你连个操作说明都没有，你怎么培训，所以帮助文档应该实施部门自己编写。于是帮助文档谁也没有人写。

归根到底，帮助说明是终究要写的，主要是谁写的问题。谁最有动力写呢？实施人员最有动力，因为这和他们的工作息息相关。而程序员明显没有动力理由。而且实施人员熟悉第一线客户的素质，理解客户的具体操作思路和理解思路，写出来的帮助客户都能理解，帮助文件才能真正为客户服务。很多帮助文档的写作都是从来没有见过客户没有实施培训过没有客户支持服务过，连软件测试都没有做过的纯粹文档人员编写的，可想而知帮助文档到底能对客户有多大的帮助性。

在写帮助说明的时候，我要求实施人员把每个按钮都要点到，每个Grid中的每一个字段的数据来源和数据含义都要说明到，每一张报表中的字段的数据来源和数据含义，每一个明细录入中的字段的数据来源、数据录入要求和数据含义。这一写不要紧，发现了很多隐藏的特殊处理功能。很多功能很多人不了解，因为很多细节功能，都是为某个客户定制的，只有负责实施该家客户的实施人员才知道。于是，实施人员之间互相通气，才算补足了不少功能细节的帮助说明。实在有些功能，都不知道是哪家客户提出来需求，也不知道为什么要这样处理，就留下空白，转给开发人员，让开发人员看看代码是怎么处理的。就这样，一份详细的帮助说明在压力艰难中终于出来了。从此，开发人员理解需求快了许多，当然也就明白了那些过去自认为乱七八糟的代码的含义，心情好了很多，修改代码也轻松了许多。原来，一切都是自己跟自己作怪。不盼望软件工程，不抱怨一穷二白，不幻想增加人手，从现实入手解决自己的问题，发现很多解决方法既简单又有效，根本无须动辄就是团队就是UML就是OO。

另外，我还给了他一些关于需求控制的建议。

需求，是很多方面的。有关于功能的（尤其是每家客户特殊的业务需求），有关于异常错误的、有关于性能的、有关于兼容性的、有关于易用性的、有关于特殊权限的、有关于美观性的。

而需求的来源也是很多方面的，有的是客户计算机室直接打电话，有的是客户业务部门直接打电话，有的是实施人员，有的是支持人员，有的是市场人员，有的是销售人员，有的是老板和客户打单或开会突然想到谈到就直接给开发人员打电话。

而需求的优先级也不一样。有的客户态度强硬，你必须尽快满足他，否则他就给你老板打电话。

而正是这来自四面八方的各种层次各种看法的人的各个方面的需求电话，把程序员就烦的要命，还要去开发。而且很多都是一个电话就认为程序员能开发了。但往往程序员开发完后，客户一看不是自己最想要的，于是再修改。

所以，需求多，其实是一个幻觉。

第一、把需求分类，做个EXCEL表格，量化解决。这个需求管理表格会有下列这些项：客户名称、需求提出人、提出日期、需求关闭时间、功能模块名、客户现在版本号、需求描述、需求分类（需求、BUG）。我在最初没有需求管理系统的时候就使用过这种方法。过去没有使用的时候，我的手下老叫忙死了烦死了。我就让他把现在手头的事情都整理一下给我报个邮件。但一整理，肯定不超过10件事。有些事情是等待客户给资料，有些事情是调试跟踪不出来错误，有些事情是需求模棱两可。我给他一分析，他现在正在进行的事情就两件，而且都是他自己能独立做的，根本不需要别人配合参与的。他忙吗？他瞎忙，或者故意说忙。没有工作效果，就是这样。帐不算不清，话不说不明，就这个道理。

有了这个表格，要定期（可能是一周，可能是一月）给老板一份。这表明你的工作量，让他看看你确实一直很辛苦的在工作，而且干了这么多活。而且，这也能看出你工作的仔细负责态度。

有些程序员不做这个表格，也不给老板报告。很多时候是程序员并没有干那么多活，能推则推，能混则混，能拖就拖。怕自己有一天混不下去，所以心理压力很大，每天不干活却总觉得很累。这种累就是自找的。想必一些程序员看到此会想起自己。

第二、需求描述不清晰是反复修改的罪魁祸首。对于BUG，要有错误报错整个的屏幕截图，千万不要就截那个错误消息框那么一小块。对于需求，是报表需求，要给出表格格式，还有每一项数据的来源，有公式关系的要给出明确的计算公式。对于输入单据需求，要给出单据格式，每一个输入项的要求：可选值、默认值、不可为空、唯一性、约束输入，数字要有小数点后精确度、日期要分辨精度是到日期还是时还是到分。

对于这位网友的现状，我还建议他开始版本管理。

、VSS之类就不必了。因为这是一个人的战斗。连版本都没有概念，一上来就是特正规的工具，大半感觉太麻烦，又退回到最初原始状态，还对版本管理产生了不好的印象，觉得繁琐还没什么用。所以我们有一句话：一管就死，一放就乱。其原因就是缺乏一个中间过渡解决方法。

所以，我建议先把版本意识提上来，按照版本管理的方法走，走顺了就自然接受了正规的版本管理工具。版本管理工具可以分支，也可以合并，可以针对Bug进行补丁发布，而不发布还未完成的新功能，可以发布为某个客户专门定制的版本，也可以回溯历史版本，对比历史差异，源代码安全性也高。

有几个过渡性建议特别实用：

一、有大的修改或没有把握的修改之前，先把代码备份到其他的机器上。备份目录要跟上日期。

二、在大的修改前，先定一个稳定的版本发布出去。很多程序员没有版本这一概念，每天都在持续修改。结果，给客户的，每个都是半成品，有半拉子没有修改完，还自己没有做屏蔽处理。客户不小心用了，产生了错误，再告知千万不能用这个功能，还没有完善。但晚了，错误数据进入了，以后报表平帐就是问题了，又得特殊数据特殊处理了。自己的孽障自己还得解决。

三、即使是琐碎的修改，也要每天或隔天备份一份源代码，别怕代码多，现在的硬盘大的很，而且备份复制一下也就是5分钟的事情。别怕每天备份太烦。我们经常会遇到这个客户让改了，另外客户不让改。一个功能改了又改回去，但过去的源代码没存备份，忘了怎么写了，这时候你就想起代码备份的好处了。尤其现在有不少免费的文件同步或文件自动备份的软件，都能定时做。功能还强大，有些还有些差异备份的功能四、现在有不少文本对比软件，如WinMerge之类。可以对比两个文件的差异，这个功能和版本管理工具中的源代码差异对比一样的效果。

五、如果每次发布新版本，就把从上一版本发布之日之后的关闭的需求列表都单独摘成一个文件，附带到这次新发布的版本之后。这样即使没有人写更新说明文档，根据追溯也能明白这次版本解决了哪些问题和需求。很多程序员没有需求管理表格，版本发布要求写更新说明文档，这才从脑海记忆中想，想的就有些遗漏，甚至错误。好多程序员有过这些的情景：我记得改了呀。真正一翻代码，一点没动。大叫：我的代码怎么没了，我记得我改了呀。

我这些建议，从需求描述、工作量管理、遗留系统代码重构技巧、备份管理、版本管理、更新说明文档一整套说明了一个人如何维护老系统的工作方法，但希望能分享给大家，给大家以帮助。

有方法，你就不是一个人在战斗。

一切皆有可能。

相信自己。

20、累斗累

有时候，我感觉事情就好像大螃蟹，总是一串一串的。

我刚聊过新项目如何收集需求，就有人跟我提老产品升级需求的管理。

有人说：老师，我看了许多IT项目管理的书籍，也讲到需求管理。但他们是需求调研、需求分析、需求确认，好像都是针对新项目的，我们是老产品维护，老板随便打一个电话就让我们添加一个需求功能，我们哪里去做需求调研、需求分析、需求确认这些环节啊。老板说我们一天坐到家里面编程序，根本不了解客户需求。最了解客户的是每天和客户待在一起的实施人员，所以要让实施人员来给我们软件提需求加功能。但是，实施人员那叫什么需求啊，比如说XXX功能不好用，比如说建议更易用一些。老板不相信我们，怕我们把实施人员反映的需求给屏蔽了，专门派了一个人每天收集各个渠道来的需求，每天还要上报给老板，而且还每天向老板要报告，今天修改了多少需求，还有多少需求没有改，没有改的需求什么时候能改完，都要我们开发部给答复。而且，隔几个月，老板就把全公司人员都召集在一起，为软件提需求。一群人坐在一个会议室，每个人都可以提，一个模块一个模块的提。当场打开软件功能，演示，说明，阐述软件应该做成什么样。我们开发人员就跟开批斗会一样，这个标题不要这样叫，那个对齐不对，这里不够明显应该加粗字体或者给一段红色的提示。唉，活得真窝囊，天天修改这些乱七八糟的所谓需求，还要被人追着赶着问进度，还要忍受被所有人都骂开发的什么烂软件。老板也觉得我们水平不行，需求也怠工不修改，两天才修改了3个需求。而且越修改需求越多，软件越不稳定。我们哪还敢提涨工资啊。

我说：你这种情况很普遍。现在很多软件公司都是老板开店，三五个人十来条枪，他有客户关系，卖个软件做个实施赚点钱。公司也不大，如果软件做不好，实施做不好，多年积累的客户关系就以后不好再销售了，这就等于把老板的命根断了。所以老板肯定会盯死软件开发和软件实施。客户使用效果好才能以后有更多的单子做。而且你们作为开发人员，又不接触客户，怎么能理解某个需求的真正意图呢？当然老板的思维逻辑对，你们这样，怎么能理解客户需求呢？当然实施人员最了解，提的需求最有权威。换你做老板都这么想。

我也经历过这段日子。人和人的信任，都是在做事中不断看人试人品人，才能取得信任，才能放权。我的老板也如此。

如何比实施人员更了解客户需求？如何让老板相信我比实施人员更了解客户需求？这也是摆在我面前的一个问题。

我是把产品放在一个产业中看。看竞争对手，看业界标杆，看业内管理专家，所以我对产品的升级完善，是基于产品战略的，是基于盈利模式和竞争力构建的。如何引出更多的盈利增值产品，如何保证产品更有竞争力，是我思考的重点。

而实施人员提的需求，都是和他实施的客户具体业务流程有关。客户就是这样，咱们软件不满足客户这样做，就要改。不改，客户就不满意，实施就推进不下去，实施项目就延期，自己的实施就不力。所以，实施人员为了保护自己的利益，也要开发部必须改。而且一开口就是你从来没有去过现场，你根本不了解客户。

老板信谁？

我不是业界知名管理专家，我也不是业界明星CTO。老板怎么能信我对业界产品竞争的判断呢？

而实施人员，天天真实的和客户待在一起，他们反映的肯定是真实的。

第一轮回合，以开发部门老老实实修改需求为结束。

后来，老板又亲自主导组织了几次实施人员需求会议，什么都可以提，都记下来，让开发人员改，让实施人员监督开发人员修改，确认修改的符合实施人员的要求，并且实施人员负责测试。每次大约都能记个上百条，从要求简化SQLSERVER数据库安装（因为实施顾问都非技术出身，没接触过SQLSERVER之类的产品，用的最多的是EXCEL和WORD，因此用报表设计器给报表格式挪挪位置大部分人都不会）到把界面都换成绿颜色背景（说符合公司形象）。这种局面直到我在各个部门各个环节各个层次应用了多种策略才改变。

过了一段时间，老板看着实施人员都没有事情可干，很奇怪，就问为什么不测试软件？实施人员回答说：开发人员没有改多少需求，我们正在等待他们开发呢。

然后老板就找我，为什么不修改？

我说：程序员一直在修改，但另一方面，我们已经修改了多次，满足需求300多条，但是我们的产品竞争力增强了么？我们的特点在哪里？我们的亮点在哪里？我们的竞争力在哪里？

老板说：不管怎么说，这是客户的需求，客户买了我们的产品，我们就有义务为他们满足需求。

我说：看这条需求，客户要求我们做一套视频会议在我们的管理软件中。

老板说：那你找找网上有没有免费开源的。

我不再争辩。因为我知道，在他心中，做什么产品，叫什么企业管理软件都无所谓，客户需要在ERP中加入游戏，如果理由充分也是可以的。重要的是客户不能得罪。客户关系是他的生存之本，而非产品。