所以，只有人们解决不了来找我时，我才能上场。
这干坐着不是回事。我得自己想辙。
于是，我在忙“公益事务”做活雷锋之余，看到他们在扎堆开会我就主动去旁听。每次我都能提出很独到的见解。并且能帮助他们写公共抽象代码，能帮助他们提高不少工作效率。所以他们非常愿意让我旁听，并且听取我的意见。我也能很快写完让他们用。他们一用，发现果然好用，而且不用他们自己写代码了，功能实现的还非常巧妙公用，性能也好稳定性也好扩展性也好。到后来，每次开会都主动叫我。这样，我的工作就越来越多了。
随着各个业务组不同差异的需求都希望我来帮他们抽象出公共的，我就在思考我手里的这部分代码。我不能今天他们提一个我写一个。他们倒是轻松了，但我手里就好似一盘散沙一样。于是，我不断重构我的公共代码，架构体系框架就这样慢慢成型了。各种各样公共工具，调试工具、优化工具、动态设计工具，凡是能帮助业务开发组人员加快效率的，我都做了工具或写了公共函数DLL。尽量简单易用，不让他们觉得麻烦或不顺手。
过去，各个业务开发组过去是开发人员素质不齐，有人责任心强，有人随意；有人细心，有人粗心；有人理解客户业务深刻，有人理解不深刻。所以开发出来的质量良莠不齐。自从这样做了以后，各个组写的代码少，很多都是我写的公共代码。我的技术好，写的代码质量高，而且是公共的，有错误，一改，大家都没有问题了。所以我们整体的软件产品的产品质量、生产速度都提高了不少。
我发现，大家越找我，各种需求交织在一起，越复杂，我就越需要更深入的学习技术，深刻理解各种技术的差异性和适用领域，去思考各项技术的发展历史、未来趋势，并且自己做DEMO，看能不能更好的解决大家的问题。因此，我的技术能力也越来越高。如果我不去解决这些不去第一线想也想不到的客户需求，我根本就想像不出我某项技术还能这样用。
这就是我的螺旋上升之路。
我那天重翻上个月的《程序员》杂志，看到了我朋友周爱民写的一篇《做人、做事、做架构师-架构师能力模型解析》，他也提到四点，技术能力、业务能力、人际关系、个人内在素质。和我的情况很类似。
有一部分所谓的架构师，技术超深厚，框架堪比Spring之类，但自己一个人闷头写框架不断优化，力竭使用最先进的技术思想，希望把最豪华的设计模式融进去，希望把OSGi融进去，希望把AOP融进去，全无视那些想利用框架减轻自己工作量提高自己工作效率的应用功能开发同事。这是在用公司工资玩技术呢，还是在满足个人技术幻想呢，还是在实验呢？到底在干吗？价值在哪里？
还有的人不会推广自己的框架。不善言辞，就幻想着技术总监能够通过行政命令让大家必须用框架，能不自己写代码就不自己写代码，能交给框架做的就交给框架做。但技术总监号召完了，大家仍然我行我素，各自开发为政，让框架开发者很孤单。
还有的人也不会推广自己的框架，沉迷在自己的理想世界。好不容易技术总监召集大家让大家来听听框架如何应用，但自说自话，满口自己最得意的词汇，听得业务功能开发人员云山雾罩。大家问些问题，如这样的业务开发难题，框架怎么解决？于是，框架开发员就和业务开发员争论了起来。框架开发员觉得这根本就不能答应客户这种变态的需求，而业务开发员说这就是现状。框架开发员说你可以这样这样，业务开发员说这样太麻烦，框架开发员立刻还口这还麻烦？于是双方各执一词，框架也没推广成功。
我手底下有个框架开发员。他的技术渴望很强烈，为了技术难题攻克，可以不吃不睡。并且技术敏感度很强，学习也快。所以当时我感觉他是个程序员的料，就把他拉到我的手下。
但是有个问题，他写出的框架代码，在平时开发业务功能的时候挺麻烦。大家可能需要的是一把铁锹，但是他却给大家N根不同长度不同粗细不同材质的木棍，N个不同形状不同用途的铁锹头。大家会有N种组合。不仅导致他写代码老超任务期，而且也让使用人感觉没多大帮助。使用起来复杂，而且还得配置这个配置哪个，需要注意的地方太多。业务开发组的同事就不愿意用，还不如把代码自己直接写死了得了。
超期还会影响业务功能开发组的使用。本来人家是为了想加快自己的工作效率。你答应好这个星期给业务开发组提供一个功能，但你没有拿出来。就耽误人家进度。你多次拿不出来，人家业务开发组还不如自己开发一个呢，求人不如求己。
我最后警告他：如果你认为自己技术够牛，那么你必须证明你能很快做出来。如果你认为自己技术够牛，最好能牛到，只提供一个函数就解决了他们的问题。别这个代理类，那个聚合类，这个唯一实例类。最好连参数也没有，大家调用一下写一句代码就OK。甚至你做的好，大家都不用调用你的代码，你可以包含在基础框架中，你自己去判断什么时候什么应用需要执行这个动作。如果你认为自己技术够牛，那么在业务功能需求发生变化的时候，你能够保证接口不变的情况下还能适合变化，这才你够牛。别让业务开发组的人跟着你也得改他们自己的代码，那样的设计就很烂了。
小伙听了我的话。进度保证，代码接口简洁。
他说，你真高。我感觉现在我的技术比过去进展飞快。看来人不逼，是不会自己创新更好更快的方法的，老认为自己现有的方法已经不能优化了。我现在发现，很多我过去写的东西还可以做的更好，我准备在开发任务之余优化代码，但肯定保证不影响大家，接口还跟过去一样，我要重构一下。
我对小伙的成长感到欣慰。
但是，小伙还有一个没有逾越的鸿沟。这个问题不解决，我知道，他不会成为一个真正的独立的架构师。
我复查过他的代码，由于他对业务没有深刻理解，所以考虑了N多种情况，给自己以后的修改留下了后路。但也因此代码量大，开发周期长无法适应越来越短的客户需求响应时间，可阅读性不强，功能复杂，稳定性困难。但我从客户行业出发，很多情况他其实都是自己假想的，而且想错了。
我指出了他的问题。他问我该怎么学习业务，他又没有机会到客户一线去实施，也不接听客户电话，客户需求都是业务开发组的人跟他说的。
最了解客户业务的，是在一线做客户咨询、做客户实施的人员。其次是做客户定制化、客户服务支持的人员。最不了解客户的，就是架构组的人员。但恰恰要命的是，架构组的人员做的功能是大家的工作基础，如果基础设计错误，那传递的“牛鞭效应”破坏力就很大。所以，架构必须了解业务。
我了解业务的思路，和我了解技术是一个思路，都是来龙去脉法，研究一项事情的过去、现在、未来，以及和这件事情关联的其他事情，研究方法也如法炮制。
你要制造的是卡车还是轿车，你得明确好。你是要造100万的轿车，还是5万块钱的轿车，也得定好。你是要制造一辆可以自由改装的轿车呢，还是一辆只可以大致改装一些的轿车的，也得定好。这些疑问，都是和咱们面临的客户有关。而我们能面临什么层次的客户，和咱们公司的实力、品牌、组织规模、盈利要求有关。
你如果是一个小公司，想做百万大单只能做的一蹋糊涂。你如果是个大公司，你老去竞争那些5万块的小单，做一个赔一个。所以一个公司的出身就决定了它的竞争地位和它的目标群。我们要为这个目标群服务，所以我们就不要做一个百变金刚的架构。公司有公司的目标，公司招了你给你付工资，就是为了让你为目标客户群服务。如何更快更好更有质量的服务，就是公司的目标。我们就是为了帮助公司实现这个目标。
我一般都是把我们这个产业的竞争格局现状了解清楚，我们的过去现在，竞争对手的过去现在都了解清楚。然后我去研究我们的客户行业的竞争格局、层次现状。看看这个客户行业盘子，三教九流到底多大多复杂，我们现在是占了多大，我们还能占领哪些客户群。
然后我就研究客户行业目前的挑战、机遇、困境。能解决其中一两个问题，就是咱们的竞争亮点。如果作为软件一点都解决不了这些业务困境，我就思考如何让产品做的更易用。微软不就靠着易用发家的么？
最后我会去研究我们公司现有的研发优势和弱势、实施服务销售的优势和弱势，找到适合我们突破的地方，具体归研发能承担能起作用的事情，我就会去动员做。脱离现实资源现实矛盾现实包袱的改良，是无法做到改良的。
我还关心各种新的技术应用。可能这项技术很久了，但大家都没有想过还能这样用。所以，我常常在媒体上关注这些、思考这些、在论坛上和业界交流这些。对于新的技术，要研究原理，要尝试，但不要冲动引入到商品生产中。我们不是自己在创业在玩在实现自己的梦想。我们承担的是公司所有人都要吃饭的产品。如果有闪失，这么多人以及他们的家庭都要受到影响。这不是闹着玩。
当我研究完业务领域的这些大的框框以后，每逢有业务同事跟我交流客户需求，我总能把这个需求和我的业务框架联系在一起，把这个需求归好类。并且能判断出这个需求是个反趋势的需求，还是个短期眼光的需求，还是个长远发展的需求。
很多人都在抱怨说需求老变化。其实，不是客户需求在变，而是你对客户的需求老是不同思路去理解。我心中有业务框架，有过去，现在，未来，所以能识别出一个需求是稳定的还是临时拍脑门想出来的。有时候，有人向我提一个需求，我会眼睛一亮，对，这个需求符合未来发展，我就会很快加入。所以，我曾经在做实施经理的时候，老是能很容易说服客户，让客户听从我的意见，就是由于我想的比他们还要远还要周全。好多程序员说客户非要某个功能不做不行，就说明这个程序员并没有理解客户。客户并不是那个非要和你作对的人，他只想解决他的问题。可能你不理解他的真正根源问题而且你又提不出更好的方案，所以他要跟你急，要让你必须实现某个功能。
只有你不断游走在业务过去现状未来与技术过去现状未来，你做的架构才是真正的实用、弹性、易用，而且最小成本，不走弯路，不多花开发精力。
我们需要架构，不就是为了达到这个目的么。
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中加入游戏，如果理由充分也是可以的。重要的是客户不能得罪。客户关系是他的生存之本，而非产品。
我开始在网上写对行业的观点。因此也有幸结交了许多知名的行业内管理专家。他们称赞我的观点独到，思考有远见。文章也受到不少网友的追捧。
我会把一些我写的文章链接适机转给老板，转给喜欢思考提升的实施顾问。我也会经常把和我思想观点相似的文章链接转发给老板。
老板继续组织全体人员需求讨论大会，但这次他有了转机。虽然仍然是让人统计未完成需求数，老追问什么时候才能完成，但显然他不像过去那样主导与控制整个过程了。他说：你也要跑跑客户，不能老待在家里。
于是，我跟着实施顾问也跑了一些客户，有时候，还带上主力开发一起走访。
过去，开发和实施冲突很大。开发觉得没必要改，实施觉得必须改，最后实在不行就拿出老板来压。而且，客户有自己特殊的业务地方，有能人者还自己想解决方法。而实施人员呢，在现场实施，陷于此境此客户，也觉得客户的解决方法有道理。于是非要开发人员按照那样的方法修改。但开发人员知道，按照那样的方法修改软件，那软件就死住了，这个功能只能给这家客户用了，其他客户没法用。于是开发人员骂实施人员胳膊往外拐，站在客户那方对付自己公司的同事。
但是一走访，开发人员也才认识到客户原来面临这样的问题，客户那样提需求其实是为了解决这样的问题。但很可惜，客户的想法太局限，只为自己这个问题想解决方法。如果开发人员当时在现场，就能明白客户面临的问题根源，就能设计出更好的软件功能来满足。唉，都怪实施人员不分析问题根源，只看表面问题现象，还自以为是提最佳解决方法，还让开发部实现。应该是，你提出你的需求问题，怎么解决是我们开发部自己的事，我们会综合考虑平衡。
我走访客户的目的，主要目的有三：
改善一下老板和实施人员对开发部的认知。他们都认为开发部只是一群不懂客户需求整天做在电脑跟前不用出差说话神叨胡子拉碴的敲代码者。“你们不懂需求”，让这个理由去一边去。
改善一下开发人员和实施人员的冲突。让开发人员也理解理解客户的现状。有些事情是不可改变的，有些事情是人为故意的，我们作为开发，不应该去把软件假设在一个理想的工作环境下，那样的软件是不适合现实使用的。该委曲求全还得做。骂客户管理水平太次，骂客户都是白痴都毫无意义。我对开发内部老说：人家是白痴吗？难道人家买你的软件也是白痴。那岂不是反过来说你的软件谁买谁就是白痴？那岂不是说明你的软件很烂毫无价值么？咱们每个月的工资从哪里来？是老板发给咱们的吗？老板又不是白痴，发钱给咱们？老板的钱也是从客户口袋里掏来的。
了解客户现状，想方法如何去引导与影响客户。客户面临最急需的问题是什么？客户对软件的认知程度如何？客户把软件价值认为成什么样？客户认为这套软件应该是干什么的？（有的客户认为我们的软件应该带上QQ）。实施人员是怎么给客户讲解软件中的管理思想的？实施人员是如何培训客户的？
走访回来之后，我做了两件事情：
发表了一篇我的走访感受。发到网上，也发给老板，也发给实施人员。老板看了以后说了一句话：“看来走访走访很有必要，以后要多做”。老板、实施、开发，之间的关系改善了许多。
把走访过程中确实应该改进的需求安排给开发人员。由于开发人员也是切身体会，很快就改了出来。实施人员说这个功能做的不错，很实用。
第二回合，开发、实施，平手。
然后，我又把业界知名专家的一篇文章中提到的评价模型内嵌到软件中。过去，我们虽然在产品PPT中老是宣称自己的管理思想，但在软件中很难看到落实。所以，实施人员在实施过程中只能讲操作。而操作，客户觉得还不如一个EXCEL好输入好修改好查询好统计，所以客户希望软件修改成这样修改成那样。反正，客户现有系统解决不了的问题就都提出来。而现在，终于有了一个可以讲可以量化的管理模型。这套评价模型成了这个软件的核心亮点。客户为了应用这套评价模型，也乐意录入数据，维护数据。
第三回合，开发胜出。
然后我提出了需求管理系统，WEB型。不管谁在外面实施，或者是老板突然提出，或者是销售提出，都录入到需求管理系统中。把需求分类，分优先级，量化安排开发计划，有的放矢吸收需求改进软件。
我还提出，每年召开用户需求会议。邀请有思路有积极改进想法的客户参会。大家面对面交流共同问题，共同需求，共同探讨未来行业机遇挑战，共同寻找解决方法。
引领客户，引领老板和实施人员对产品，对业界，对未来，对竞争的认知提高。
在我的影响下，公司的IT咨询业务、IT教育业务、IT服务业务、IT整合业务、IT产品发展战略、集成合作伙伴，都逐渐专业化的发展了起来，给公司提供了越来越的盈利模式与收入渠道。
、设计模式、接口？！和客户一点无关？那客户为什么要给我们钱？那老板为什么要给开发部钱呢？那开发部存在的意义在哪里？翻译成代码？就这点意义？还要月薪上万？凭什么？
你的价值在哪里？
21、我要飞的更高
又到了半年，公司这几天要开半年会。
老板让我做一下总结报告，对上半年的研发成果、下半年的研发计划、明年要做什么新产品的规划，希望我都能谈到。
对上半年做了哪些工作，这些都有工作记录，也有项目管理系统，也有Bug管理系统，也有版本升级发布，所以很容易总结出来。
下半年做什么，有需求管理系统，客户的需求都排着。共性的、希望做的更专业更深入的模块也在详细设计之中。对于扩展支持更多的客户组织模式、远程管理模式、更低层次和更高层次的客户，分离更清晰的高级版、标准版、简化版也已经有规划。并且根据定位不同，已经规划了不同的产品形象策略、宣传策略、销售策略、定价策略、实施策略、服务策略。
对现有产品线进行深化、扩展，这都是没有问题的。但明年要做什么新产品，是最难的。
因为新产品的研发，有很多影响因素。
我们在行业信息化深耕了多年，已经有一定的知名度。因此，我们有时候想接到某一个项目，但该项目的客户负责人（都是老关系熟人了）就笑着跟我们说：你们又不是做硬件的，啥钱都想赚啊。
但是，我们确实想赚取更多的钱，扩展更多的可销售的产品和服务项目，而不仅仅就把我们定位在软件开发和IT服务、IT咨询。因为行业内的客户数是一定的、大中小的客户数量是很明确的，行业内的竞争对手都按照自己的实力大小，已经占领了属于自己开拓的那层客户，并且在产品层次、销售模式、实施模式、服务模式都做了匹配。我们当然想扩展我们的客户层次，逐步上中下客户都通吃，并且在产品线上，各种IT产品和IT服务都涉及。只有这样，才能保证我们每年都能业绩提升。否则今年是这个销售额，明年还是这样的销售额，没个发展老原地踏步，这样干公司就没劲了。
所以，这个已经定了型的公司形象就容易阻碍公司新业务开展。公司没有鲜明形象吧，客户不清楚你到底是个干嘛的公司，到底能干嘛，到底什么做的专业。真正通过多年做产品做客户，让客户有了定位，反而客户认为你就是干这个擅长，其他你就不行。就如同百度要进军电子商务，业界很多人都说百度不可能成功，因为他是做搜索引擎的，它又不了解电子商务。
我不同意这种观点。很多人的思维是守阵地型，觉得自己有多大能量就考虑多大的事。但是做企业，守阵地是守不住的，你不攻打别人，别人就要主动来吃掉你的份额。我一贯的思维都是，先放大眼光，放眼整个IT行业，整个客户行业，甚至是和客户行业相关联的上下游行业。能不能做到还没论证呢就否认说不能，这种人无法引领公司产品成长。先研究，说不定还能做到。一旦成功，就可以获利颇丰。当然，我也会考虑风险，不会让公司要么赔死要么赚死，我是职业经理人，我要保持平衡发展。老板可以大刀阔斧进行革命，但我只能曲线救国。
公司现有产品体系，公司现在的客户群，都是需要照顾的地方。新的发展，不能与过去完全隔离，否则就容易把过去积累的优势都浪费掉。当然，有句话说：最大的优点就是最大的缺点。优势就成了前进所无法抛弃的包袱。
公司现在的人的技术素质是否能达到，如果想做的事情确实挺好，公司愿不愿去提供更高的薪水来招聘人。是自己独立研究开发，还是通过合作先代理别人的产品进行销售维护在别人的基础上进行扩展，还是请外脑顾问进行指导。合作者是否理解深刻意图，能否在利益上达成一致，未来分道扬镳的时候是否能好聚好散，都有很多沟坎，都需要拿捏到位。
公司现在的资金如何，公司现在的业务销售是否具有可持续性。这也是需要考虑的事情。一项新产品的研发，是需要花费很多时间来跟踪收集研究，做尝试，做推广，逐渐在客户群众树立影响力逐渐扎根逐渐认可，是相当长的时间。在新产品还无法代替现有产品的盈利地位之前，必须能保证现有产品销售稳定性。否则大家都要喝西北风了。
竞争对手现状如何？它的产品、它的研发、它的销售。不能造成自己在这里抽调资源研发，竞争对手在那里攻击，还没出来，就先死掉了。我常常想到一个玩《红色警戒》游戏的场景：你的电力系统被敌人偷袭，你赶快造一个新电厂，还没有成型，就被敌人摧毁。
在研发当中，更要验证对未来综合竞争力的提升。不能是单独的产品，而无法成为一条产品线或产品体系，就不容易利用现有的销售、客户、实施网络进行落地。必须与现有产品形成互补。就好像我们下跳棋：既要给自己留下路，而且同时这颗棋子还能成为对手的绊脚石。如果我们既不是行业中的第一或第二，还要防止行业领头羊打击新兴模式，在你还没有成气候的时候就灭掉你这个新模式，让你失去新产品发展的土壤和环境。
这都是很宏观的一些环境考虑。决定我们的方向。
很多网友可能觉得不需要考虑这些，屁股决定脑袋，这是老板的事情。很多所谓的技术总监其实在老板眼中就是个带项目的头。也有的技术总监，老板认为他是技术总监，但他自己却把自己定位成一个项目经理。
但我们处于行业管理软件这个领域。这个领域，客户数量是一定的，客户行业发展也就那么快。你必须追随客户行业的发展。如果客户行业好多年都没有变革，机遇与挑战变动不是太大，整个行业环境趋于稳定，那么信息化也就是夯实。你想引领先进模式，客户还不走，你也就走不动。
行业管理软件领域，不如现在火热的互联网行业、网游行业。QQ、百度、盛大、征途、阿里巴巴、51.com争奇斗艳，风投不断，成长迅速，日夜吸金，快速上市。几乎5年，就能把一个创业公司膨胀到一个上市公司。而行业管理软件领域，往往随着客户行业发展而发展，销售额一直不高不低，撑不死饿不死。所以我们也一直在寻找和互联网、虚拟产品、网上营销相结合。我们也在跟踪现在火热的技术，如SAAS、Open API、SOA、BPEL、DSL。我们也在跟踪行业内先进的管理专家发表的观点和思想。只有盈利模式+先进技术+先进管理，才可能成就新一代的产品。所以，我一直在这三个方面进行跟踪研究交流。
我们更要考虑的是我们传统模式和流行模式结合在一起的新产品新模式，到底面对什么样的客户，市场容量多大，可能会有什么样的竞争对手进入，我们会有什么危险，我们如何应对，会吃掉多少市场容量，未来我们最大可能占多大容量，这样的容量值不值得我们做。我们做需要多少资金投入，需要多少钱来推广，需要多少时间达到我们的盈利点，在达到我们盈利点之前我们如何防御性发展。
摸清了我们自己的优势、困境、竞争地位、未来目标、未来业界位置，摸清了行业业界现状、未来影响，摸清了竞争对手，摸清了现在流行的盈利模式，摸清了未来更加敏捷的技术，我们才能给我们的产品定一个位置。新产品必须与公司的实力和战略相结合。老板的想法你不了解，你自己一个人瞎琢磨新产品的研发，很可能想法很好也未来很可能成功，但不符合老板的观点，没走出第一步就壮士未捷身先死了。
知道了做什么，能不能做，做完有多大好处，这个饼画完，并且画的能把老板和销售总监说动心了，就要落实怎么做了。
我仍然采取的是标杆法。
我承认自己是个保守的创新派，所以只能做职业经理人。开创性的，在我的位置，我的角色，也决定我不能做开创新的事情。这是个鸡生蛋蛋生鸡的问题。是由于做职业经理人而不能有开创的自由度和支持度，还是由于自己做了多年职业经理人而无法有开创性的胆略和思考眼光？
我想起张树新在瀛海威艰难的时候的一段话：天上下着雪，雪很厚，前面什么也看不见，很黑，我们开着车摸索前行，不知道路走的对不对。
我想这种创新的模式和产品我是不可能做的。所以我要做的其实就是金庸+古龙，形成温瑞安这样的模式。这就是创新。
我先剖析行业标杆老大的产品。所以，我常常跟踪分析SAP、用友、金蝶这些标杆企业的产品，学习他们的架构、产品气质、实施模式、咨询模式、服务模式、销售模式、市场模式。
虽然他们都是做通用企业管理软件的，但是每个细分的行业管理软件领域发展有快慢不同。所以借鉴他们，就能在自己这个所定位的行业领域取得先机。有句话：我不期望比刘翔跑的快，但我只要比你跑的快就OK。
只比客户前进半步。这是做产品的很重要的指导原则。你可以想的远，很好的前景和盈利模式使你心情荡漾，但真正做起事一定要只比客户前进半步。你可以想的功能策划的功能很多，但一开始推出第一版的时候，一定要突出特色功能，而不要把你的想法全盘托出。一个新出现的东西，本来大家就抱着试探怀疑检测的态度，一打开产品密密麻麻的功能，客户就会感觉深陷森林之中，到处走都走不出去，就很压抑了。而且这样复杂的深入的开发，周期长成本高控制管理难度高，很容易没有被竞争对手攻击，自己就内乱先倒了。而且客户还不买账。
经过把行业标杆的功能进行遍历列清后，细化到它们能支持的国际化、网络化、多组织模式化、权限控制程度、功能菜单、控制参数、基础字典、输入窗口、输出报表、统计、组合查询、特殊业务处理模式等等，然后对比优缺点。整合出一份吸收优点的特性列表。
我们还会遍历我们的需求管理系统，把客户的反馈加入进来。研究竞争对手产品，把优秀功能加入。这样就结合了既站的高，也能落地现状。
然后在这份优点之上，再加入我们看好的新的赢利模式、新的行业管理模型、新的技术模式，形成我们自己的未来产品框架。这个产品框架不是散点，这个软件中拉一个亮点，那一个软件中拉一个亮点，而是要具有新的高度、新的视角，对行业企业组织、业务流程进行审视、形成有组织、有流程、有层次的管理信息化体系。
只有自己能讲通了，并且自己能说服自己，才能给研发内部扩散你的产品规划体系，从行业客户发展过去、现在、未来变化，现在竞争对手、咱们的竞争地位，讲到现在的新兴赢利模式、新兴敏捷技术、咱们的战略发展思路，说的头头是道，才能让你自己的研发手下相信你的判断正确，思路深远，才能形成目标一致。
获得公司内部最多人支持是一件非常重要的事情。尤其一件新的产品。到底行不行，大家首先就有疑问。抱着怀疑的态度看事情，没有问题也有了问题。
需要认同的人上下左右有四类：上有老板，下有手下，左有客户，右有营销部门和实施部门和支持服务部门。缺了谁的配合都干不成。
首先要获得自己下属的认同，这是最容易认同的人。这是你的群众基础，在你势单力薄的时候，他们就是你的拥护者和同声者。
然后是获得老板的赞同。没有老板的赞同，你和你的手下想做都不能做。老板不会给你任何时间和资源做的。想让老板赞同，你必须所有的思考都要按照老板的思考方法去给他讲，不能你按你自己的思路讲，那样行不通。另外，你的想法一定是以可以帮助老板赚取更多的钱为唯一目标，而不是其他和老板切身利益无关的目标。那样的事情，老板不感兴趣。很多人说我遇到慧眼识人的老板，其实没有，我只是能帮助他赚取更多的钱而已。这样的人，谁不想要啊。（有人想拿着老板的工资，敷衍老板的做事，干自己的事或者积累自己的客户、技术、朋友等等，这样的人，老板自然不喜欢）然后是获得客户的支持。我走访客户时候，和客户老板经常会谈到现在的行业发展、行业挑战、新兴行业机会、互联网新型模式。和客户中层经理谈的就是管理监督、流程、评价模型。
客户是给老板钱的人，老板是给我们钱的人，而营销部门在乎的是好不好卖，能不能大卖，能不能赚更多的提成，而且卖完后没有后遗症（小心自己多年维护的客户关系被毁了）。而实施部门在乎的是东西好不好让客户接受，能不能很快培训完上线走人。而支持服务部门只在乎以后别出问题就行，工作越少越好，但也不能没有BUG，否则他们就没有多大用处了。
得到者多助，失道者寡助。上下左右逢源，你才能成功。
否则，你就是个项目经理---干活人的头儿。
22、波、波、波
这几天，去了一趟罗布泊。
为什么去罗布泊？
因为罗布泊没有办公室、没有客户、没有员工、没有邮件、没有电话。大沙漠中一望无际还是沙漠，地表温度接近60度，人很渺小，人的生命也很脆弱，唯一能做的就是找个凉快地方躺下保存体力、保存好水和食物。就这样，在路上，可以有很空的心去思考。（让我想到《商道》中的戒盈杯）帮助一个公司做大。过去是求生存，有什么项目就逮什么项目，不管能不能做了，人员素质能不能达到，有单就收，生存比任何诚信、质量、企业文化都重要。
终于几年来业务模式、收入、团队都稳定了，但未来如何走就摆在了面前。33%的税、办公写字楼租金、员工工资三险一金、销售费用、出差费用、办公费用，不管你有没有单子，这些就要支付。即使今天下班公司关门，钱还在哗哗的流，尤其员工多了，每月的流水费用就在上百万。而每月能够拿回超过100万的销售单子给员工发工资，并且还能处理每个月的租金、销售费用、出差费用、水电互联网服务器复印机打印机传真机等等等等，都是一个未知数。而下个月的单子是否能成功，更是未知数。而下个月的费用却要照常发生。
于是，我把这几年所做过的所有项目都整理了一番，目前的产品也整理了一番，现在流行的可被风投的业务模式也梳理了一番，希望得到能继承过去还能结合未来发展的良好盈利模式。
我手头也有需求管理系统和BUG管理工具，关于产品的增强，有N多的方面。但增强了会如何？我要的是能大规模销售（对等员工的薪水和素质，理解能力和销售能力有限，不能销售带有高深管理理念的产品，员工无法理解软件中含盖的管理理念，当然也无法传递给客户）；我也需要能大规模实施培训，大规模服务支持（如果需要一个员工花费半年的学习才能胜任岗位，这样的时间成本和人力成本就非常高了，不利于大规模扩张，因为可用人的数量跟不上规模）。而且产品能具有普遍适用性，涵盖尽可能多的客户群。
我们都知道，做新软件研发，是很消耗资金的。所以，我们都尽量使每一个产品都能生命周期尽可能的长。
在过去的几年中，我把软件分离为简化版、标准版、高级版，分别对应那些IT信息化水平和信息化理念层次不同的客户。
对于低级用户，就塑造产品成为一个电子化功能工具，你可以用纸张手工代替，你也可以用EXCEL代替，但这个电子化的管理软件（可以称它为MIS）可能比纸张手工和EXCEL更好一些，所以价格也便宜。在销售队伍的配备、产品宣传、产品包装、定价、实施方法、实施团队配备、服务方法、服务团队配备上都有很大差异。对于中端客户，就会嵌入可量化的管理模型。管理理念是一个很缥缈的东西，你说你这个管理软件管理思想先进，你凭什么，你拿出来真凭实据看。所以，给从未做过管理也不懂管理的普通员工讲通管理方法，并且让他们传递给客户，这种思路是不靠谱的。所以需要可量化的管理模型。输入数据，经过模型计划，就得到有价值的输出。这个模型是创新的，有价值的。很多管理软件遭到最终用户的使用，就是由于最终使用者并未感觉到软件给他自己本人带来了什么明显效果，反而只是一个数据录入者，供管理者分析决策用，而他又不清楚管理者有什么用，就觉得天天很累的输入数据没有意义。所以，需要有可量化的管理模型，是很好给员工传递的，员工给客户传递的时候也不会走样，客户也感觉录入数据有了意义，皆大欢喜。
对于高端客户，就需要给软件注入管理方法。如何更有效的管理生产，如何更有效的管理销售，如何更有效的管理服务。而这种管理方法，是普通员工所无法理解并传递的。所以这类客户，就需要咨询式销售，与之跟随的产品市场宣传、实施、服务都不一样。
我们很容易从这里例子联想到中国移动。就一个打电话，很简单的功能，还需要把客户区分为全球通、动感地带、神州行。全球通选择了王石作为代言人，“我能”的宣传口号寓意了企业领导者掌控企业的信心和霸气。而动感地带选择了周杰伦，我的地盘我做主，很嘻哈。而神州行选择了葛优，我看行，整个一个精打细算的老百姓。大家如果解除过中国移动的客户杂志，你会发现全球通、动感地带的杂志内容截然不同。这就是客户细分。
我们的软件产品也需要客户细分。否则低端客户觉得产品复杂，高端客户觉得小儿科，我们两头客户都得罪了。
这几天的罗布泊之行，公司管理团队做了很多交流，对未来产品发展和盈利模式和销售模式和现有员工素质都做了综合讨论。要不要开发新产品，什么时间开发，市场目标客户群多大，潜在竞争对手是哪些，我们如何防御，我们的盈利模式怎样，他们会占有多大的市场份额，我们最终可能会占多大，值不值得我们做，我们现有的资金和人才是否匹配我们去开发新产品，我们的困境和发展是否是新产品能解决的，在我们投入人力和资金研发的时候，哪些业务和人员来支撑发展，竞争对手如果发动进攻我们如何防御。我们一定不能一边忍着挨打一边研发，那样很可能我们没有尝到新产品的好处就自己先死了。
新的产品而且要与现有产品形成增强的核心竞争力。就像微软，虽然是世界软件帝国霸主，虽然微软的产品线有上百条，但微软主要营收也仅仅是在于四个产品：Windows、SQLSERVER、Office、VisualStudio。四个产品有机结合，互相增强，使微软整个产品战略整体推进。别的公司也生产微软类似的产品，但整合性不好，或者只是生产某一类产品，就无法形成整合竞争力。我们经常会说一句话：用了微软的东西，就得什么技术都得用微软的，否则就配合不力。可见微软的产品整合竞争力多强。我们做产品也需要这种产品体系。像金山词霸、毒霸、影霸，虽然都是消费类软件，通用性强，受众广泛，但几个产品并没有形成整合的竞争力，全是单点，在翻译、杀毒、多媒体播放各个领域都面临着强大的竞争对手，无法形成自己的整合竞争力，所以一直前进的很辛苦。我们做企业管理软件，就是不断产生主打产品，几个主打产品互相结合，并且这几个主打产品还能扩展形成相关的小的子系统，这样每个主打产品其实都是一个产品群，几个产品群互相结合，这种解决方案就很威力强大了。所以我们做产品规划的时候，都要思考新产品与老产品的关系，最好形成整合互补关系，而不是代替的关系，更不能形成互相不关系的关系。
我们不赞成跳跃式产品规划，看什么有前途就去做。因为一个公司在行业中有固有的形象和影响力，客户认为你就是IBM而非DELL而非迪斯尼，当然苹果转变不成通用。这就是企业气质，和人的性格一样，有些人永远无法成为管理者，有人永远无法成为软件开发高手。有网友提到蓝海战略。第一，蓝海不是那么容易寻找的，但公司需要每天开张销售。第二，寻找到的蓝海往往与现在无法结合，看着好却无法去做，做企业不能乱做，有可为有不可为，今天看搜索不错就去做搜索，明天看地图不错就去做地图，后天看网游不错就做网游，这类企业活不长。你如果在这样的企业工作，你能适应不断转变的要求么，你是一个搞搜索开发的，你能很快转去做网游吗？所以，产品战略规划，最难的就是继承过去，结合过去，还要面向未来。很多程序员有个毛病就是老喜欢推翻别人的代码自己重写一次，这种程序员能力是很低的，高的程序员都是如庖丁解牛一般，在看似复杂关联的环境下还能游刃有余。
产品规划，我们尽量促使产品成为消费类软件或基础类软件。所谓消费类软件，就是每个人都需要，每个人都得装一套。所谓基础类软件，如中间件、数据库、阿里巴巴平台等等都是基础类软件，上面可以插入或扩展许多合作伙伴的产品，形成了强大的产业链。这种产业链就类似整合产品核心竞争力，互相结合整体推进，就强大的很。大家研发产品的时候一定要记得这两个关键点：整合产品竞争力、基础类软件与合作伙伴。
其实做产品，都有一定的产品周期。我这10年来，经历了两代产品的研发。第一年开始提上日程，解决要不要研发的事情。要不要研发就涉及到我上述提到的那么多问题，不商量定，新研发或许刚开个头就被下马了。而且要不要研发，需要全体人的支持和老板的坚决决定，否则有些利益团体给老板吹风，本来研发就是需要大量的人和资金，需要长时间研发、推广、销售才能看到效果，如果目前一面临点小困难，就很容易让老板动摇，就把新研发砍掉了，大家都去忙于应付目前的困难。所以，很多公司没有新研发，都是随着客户的项目来完成产品的实现。这样必然留下这个项目的缺陷和局限。所以，大家也总是忙于应付困难，而且困难总是一个接一个，怎么也解决不完，而无暇顾及未来发展研发。
解决了要不要研发的事情，就需要把人和资金和时间都抽出来。需要的人，现有的员工无法达到，就看是招聘还是与其它公司合作，还是做代理先下水探探路？另外，抽取出来现有员工，他过去的职能就需要相应能力的人顶上。这个交接能否顺利交接，都需要时间。而时间就会引起变动，新的异常又会出现，到底去救火还是抽刀断水？
把人布局好，才能规划产品。所以一个产品的研发，往往是立项、筹备就花费一年，设计、开发、测试、文案，为新产品而匹配的市场、销售、咨询、实施、支持团队的打造这些都需要花费1-2年的时间。
而产品一出来，需要花费大量的资金来做宣传。宣传了还不一定能起个水花。这个阶段的销售收入，根本无法承担公司主要收入来源，还处于投入大于产出期。一小部分客户才知道，很多客户还不知道。即使这一小部分知道了，许多人还在观望，希望看看别人应用的效果。好不容易有先锋客户愿意尝试，但由于为了推广，销售单子就必须低价推行，否则人家觉得风险太高。等做出来几个典型的成功案例，可以带其他潜在客户进行现场参观的时候，一年已经不知不觉过去。
一年多的销售攻势和市场攻势，还有实施成功案例的支撑，终于有数量的客户签单了，他们看到了应用的成功案例，开始应用，但远还未到大斗收金的阶段，这才是开始投入产出刚刚能持平的一年。不要乐观，这个阶段很危险。因为灯塔客户的实施，只是个别。如果失败了，影响也就那么大。再挑选一些客户，还是能东山再起的。到了这个阶段，可能是销售硬顶着劲花费了大量手段强挤出来单子，最后却被做砸了，这时候影响就大了。因为这类客户不是灯塔客户。灯塔客户很先锋，知道尝试是有可能失败的，失败了也在情理之中。但这一阶段的客户，都是想尝鲜但又怕烫手的主儿，一旦失败，很容易传播其他更谨慎的客户，说他们的产品不行，不能尝啊。这就，没有后来了，半路地夭折了。
在第五个年头，终于迎来了收割年。大规模的销售、实施都展开了，团队也磨合成熟了，做事也有固定流程和模式了。如何低成本、有质量、大规模的实施成了关键思考点。这个时候，看着销售势头挺好，往往年底一算账，成本也高，最后没捞到几个子儿。
在第六个年头，多年的媳妇熬成了婆，销售收入节节高，开始资金补仓。第七、第八年都在延续、持平，不断升级维护、做相关周边功能的开发。那些怀疑者、守旧者都也随大流购买了软件。但危机已经暗浮。一个市场，往往目标客户数是一定的，软件这个东西也不是像矿泉水一样天天喝完还得继续买。鱼总有打尽的一天，做维护服务和升级服务，也只是把鱼养起来慢慢吃，但总是吃的少，现在的服务费用还无法支撑公司主流收入。
我们运作产品，就是希望推广期尽量的短，销售期越长越好。通过细分客户群，通过新业务功能的增加，通过关联产品的开发，我们不断延续。可能，换了一个新的界面风格，改进的性能，改进了稳定性，就可以发布一个重要的版本，做个市场秀。市场这个东西不能冷了，一冷了再想炒热就比较难。不延续做，客户就容易遗忘。就如同可口可乐，如果一年不做广告，就在渠道默默的铺货，很多消费者都奇怪可口可乐是否要倒闭了，种种猜测就让消费者购买产生迟疑影响了销售。
在销售好的时候，大家都觉得产品肯定还能火好几年，反对下一代产品研发的人很多。
而真正的下一代研发，其实最好在产品第七年就开始启动研究立项。这样，老的产品在推出8-10后，慢慢进入衰落期，下一代产品就能成为新的现金牛，继续带领公司营收创新高。
研发的早了，推出来市场接受不了，不仅花费大量市场费用而无起色，就连员工和公司高层都觉得没有希望。本来好好的一个产品，就这样被停掉了。研发的晚了呢，人家竞争对手已经推出，我们才匆忙跟随，很容易新产品不优秀，老产品在衰老，几个回合就全军覆没。所以做公司，真是每日如履薄冰，随时都有覆没的危险。
关于新产品的研发，一定要有这个产品生命周期的视野。要从产业、竞争环境、国家环境、客户行业、技术发展多个角度去思考产品规划。在产品8-10年的生命周期内，每一年的产品完善重点，每一年的市场、销售、定价、实施、服务策略都需要不断调整，而且要针对不同产品层次不同客户层次调整所有策略。
很多人问我是怎么研发一套可扩展的架构。我说，你不了解这个架构最后的演化未来，不了解这个架构的生命周期，那么你就无法研发可扩展的架构。我们是做企业管理软件，不是做一个百变金刚的企业业务开发平台。架构所应用的产品，它的生命周期是3年，5年，还是10年，还是20年，决定了架构的要求。而且客户行业未来的8-10年的变化会如何。而客户行业往往受中国政策和发展变化影响很大。所以我也喜欢看《经济新闻联播》之类的节目，也阅读《中国经营报》这样的报纸。我一般也就能看到3年，5年都看不到。这样的素质，把握一个8-10年生命周期的产品，确实需要不断的升级自己的知识面和眼光层次，以保证自己能不断调整，不断滚动这3年的步长眼光。
这就是一个CTO需要做的产品生命周期规划。大局规划，细处入手，客户最关键的需求实现。大规划、大研发，既耗资金又不容易掌控这么庞大的团队又不容易控制这么长的研发周期。而技术总监，可能重点关注于这个产品的实现执行组织。而CTO，就需要在客户、产业、技术、盈利模式方面能有长远并且综合的产品战略。CTO和技术总监的关系类似于国家主席与国家总理之间的拍档关系，一个负责产品战略，一个负责产品实现执行。
波、波、波，我想起产品生命周期，老想到这个声音。这个声音来自于我曾经痴迷的《街头霸王》。里面的KEN一样，会连续发出白色的气功波，几个连环组合就把对手打倒在地，一波接着一波。我希望，产品波也是如此。
23、八部众
这几天在规划新产品，新产品要做什么，两个来源：
看看业界最新的产品，先来个海阔天空的头脑风暴。从ipod模式谈到金山与google的合作，从android谈到百度的电子商务，从孙正义的投资校内网到汽车GPS、车载充电、车载MP3。但这些只是引新思路，真正还要落回到自己所在的行业所在的客户。正规的干，和现在业界的标杆比，我们水平差，和他们用正规的方法交锋，只有输的份儿。所以，历来以少胜多，都是以奇取胜。我们作为中小企业，把金庸+古龙，或者王朔+鲁迅这样来个改良菜，把其他行业或领域的新产品新模式引进来，或许才能突破现有大佬制定的游戏规则。
踏踏实实，还是要去检索我们的需求库。历年来，全国客户提出来的数以几千条的需求都记录在其中。小说，就是来源于生活而高于生活。所以，需求就是现实生活，我们的新产品必须从现实需求中提炼出来。否则就是空谈新产品，而根本无法落实。
我经常看到不少内地程序员拿Google的开发和国内的开发比。在Google，软件是艺术，大家阅读源代码也阅读的赏心悦目，大骂国内软件业毫无创新。我个人以为，我们的积累还是太短，从业者年龄和经验结构偏低，还无法从现状而创新。另外我们面临的资金、客户的限制，我们更是没有多少发挥空地。所以我认同软件工厂做法，大批量高质量低价格快速度的生产。但是，现状是，连能把这种生产模式做的好的软件企业都寥寥无几。大量的软件企业无法实现高质量大批量快速度，低价格也是降低质量克扣员工得来，势必引起客户和员工的反抗而终结低价格。所以，我们做新产品，也不能抱着科学家研究的思路，而更应该是在资金、时间、人的素质、人的数量、竞争压力、客户现状的框架下的量化可控的研发，有阶段，有目的，有重点的研发。
要有控制的研发，就要有需求管理工具来管理需求库，可以分类查询、检索、统计。就需要老老实实去回顾需求库。如果需要调研，就需要有方法的调研，从组织结构、过程、考核、优化这几方面来梳理需求，而不是开讨论会。
有了这么多需求收集回来，大家估计会很晕。因为需求来自全国客户七嘴八舌，有来自豪放的东北，有来自细腻的华东，有的来自客户老板，有的来自部门小经理，有的来自部门小组长，有的来自IT人员，有的来自最终操作者。所以，真是林子大了，什么鸟都能飞出来。我记得我在2000年实施的一家客户，最终用户年龄大，打字不灵，希望有个语音输入。这就是需求。如果我们面对这样的需求，我们肯定会说不可能完成。但我们往往不仔细想如何去解决问题，反而耻笑客户傻瓜，怎么不把年轻的换上岗位。但我们了解到那位最终用户是一位专业经验很高的人员，岗位无法代替，我们都闭嘴了，我们最终还是解决了问题，但肯定不是语音输入。所以，我们整理分析需求，不能耻笑这条需求肯定是用户拍脑门想出来的，那条需求是客户自己笨。到最后，还是我们自己愚弄了我们自己。就如同遇到BUG，老是有程序员说不可能，我机器就不报错，或者说肯定不是我的问题，我都检查过了。但最终最终，还是代码问题。这种现象屡见不鲜。
一个软件，对于不同的人来说有不同的要求。如果你把这些需求归类，你往往会得到这些要求特征。
对于销售来说，演示的时候稳定、易用、好看、速度快就是关键。
很多销售并不懂软件，但要买软件，这就是现状（别笑）。我们要就问题解决问题，耻笑问题也解决不了问题。本来就不懂软件，还不易用，销售根本没法给客户讲清楚自己卖的这个东西到底有什么用。
如果还不稳定，突然报出一个英文错误，销售在那么多客户面前更是漏了脸，吹的那么大现实却是如此，让销售的诚信损失了，必然会到老板那里告一状，以挽回自己打单不利的面子，错全是研发部的问题，那时研发部只有吃不了兜着走了。
如果软件做的灰不啦叽的，自己都觉得没什么出彩的，客户也觉得很普通，在价格上就无法提升。而销售，最重要的就是卖一个好价格。软件也实用，也先进，但打单过程中，给客户演示也就那么短的时间，而且来听的人大多是以后不实际操作软件的人，对软件到底功能做的多细腻，处理各种复杂业务多么灵活，都根本无法看出来，就看到这个软件不好看。就如同我们遇到一个女孩，很漂亮，到底心灵如何，还没有那么多时间和机会去了解，但首先感觉就不错，愿意去接近。如果遇到一个女孩很普通，从心里一开始就有坎，不是抱着主动去了解的心态，而是怀疑和旁观的心态，就不容易了解一个女孩子。软件，和女孩一样，都同样的道理。
演示的时候，我往往会看到这样的情形，点下一个查询按钮，10秒钟出不来结果。客户和销售都在等，会议室很静，大家都在盯着屏幕都在等待，但就是不出来结果。销售急了，拼命乱点，更加剧了不稳定和性能约束，最终报错不断，或者干脆销售很尴尬的按下Ctrl+Alt+Del。
对于实施来说，最重要的就是软件稳定。软件不稳定，客户怕软件使用过程中出现问题，就不敢放实施人员走。而实施人员上面还有实施总监在管，有项目进度和经费的控制，所以实施总监老催实施人员为什么还不回来。实施人员也急呀，今天查报表，明天改数据，总是按下葫芦起了瓢。
软件稳定的基础上，最令实施人员头疼的就是客户需求的事情。如果每遇到一个需求都需要让程序员搞定，而程序员又少，就把实施人员晾到现场了。实施人员本来就想和客户搞好关系，以希望能够把项目顺利进行下去。这下，长时间解决不了客户需求，实施人员就交待不下去，当然要给程序员施加压力。这就是开发部往往是软件公司最受攻击的一个部门，销售、实施、支持都攻击开发部。所以，为了能让实施人员现场满足客户需求，开发人员往往想了很多办法。最常想到的就是开发平台。但我见到许多开发平台，简直就是面向开发人员的（什么XML、SQL、流程编辑）。实施人员只懂业务，对计算机软件操作并不娴熟。所以，开发人员必须要给实施人员提供实施人员能用的起来的实施工具。很多软件系统没有实施工具，只有一个光杆软件，孤立无援。
对于培训来说，软件易用最关键。你帮助写的再详细，相信看的人都不多（只有我们可爱的程序员才去勤奋的钻研那些详细的WINDOWS API帮助）。软件易用，培训的工作就轻。
有很多软件，没有演示版，没有操作视频录像，没有最新版本帮助文件，没有新版本更新说明。就凭一张嘴对着电脑屏幕讲。出了新版本，还不知道哪些功能发生了改变，还照着过去学习的知识讲。客户亲手一操作，发现讲的和看到的不一样就有了疑问。培训人员都脸红，自己都不知道怎么使用，也解释不了。所以培训文档对于培训人员来说也很重要。
对于支持来说，软件稳定是第一位的。否则自己的支持电话非打爆不可，那样，支持的工作又累、钱又少还整天郁闷解决不了，还不如不干支持。软件如果不稳定，那么软件必须可跟踪。最怕软件出了问题，客户打来电话就说：软件不好用。这个不好用怎么查问题啊。到底怎么个不好用，报错的界面截图是什么样的，在哪个模块，怎么操作的，录入了什么数据，报的内部英文错误是什么，版本号是多少，软件打了多少补丁，操作系统是什么版本，操作系统打补丁没，数据库打补丁没，防火墙是怎么设置的，年月日和货币符号设置对不对，打印机设置对不对，自己的IP网络设置对不对。这些内容，最好像WINDOWS一样，出了错，把所有需要跟踪的信息都自动收集起来，然后报出一个提示框，可以发送报告给微软。所以，我们做了一个日志模块，可以自动截图，自动发送日志，自动记录当时操作的SQL语句，自动记录当时的客户输入数据和点击操作流程。给软件跟踪解决问题加快了许多效率。如果一个个去问用户，用户都不知道这些信息到哪里去收集，再一顿反复解释寻找，解决问题就很慢了。有很多时候，用户由于时间太长有其他事在身，就放弃了解决这个问题，久而久之，由于问题越积累越多，就渐渐不用这个软件了。
对于支持来说，软件自动升级也非常重要。我们往往遇到很多问题都是软件没有打某个漏洞补丁造成的。而且还有很多问题是由于客户端版本不统一造成的。如何能自动的、全部客户端一起升级，一发布补丁就自动全国升级，很多问题客户还没来得及发现就被解决了，满意度就上来了。
对于后续版本开发维护人员来说，代码容易看懂，代码好修改才是最关键的。程序员想了很多方法：业务开发平台，有意义命名，小函数分割，函数接口灵活，面向对象，设计模式、重构等等。但是，代码仍然越来越复杂，越来越不容易看懂，越来越不好修改。其原因就是由于每个客户都提出各种各样的需求，有时不同客户之间的需求还是矛盾的，大量的代码其实是为了处理客户异常业务，还有的是为了堵某个特殊操作发生的BUG，还有的是为了兼容不同版本之间。这才是代码难阅读难修改的根源。
对于数据量大性能要求高的应用，性能是很关键的持续改进方面。
对于安全性要求强的应用，设计安全的方案，编写安全的代码，安全的测试覆盖是很重要的工作。
对于测试人员来讲，软件必须具有可测试性。软件代码写完了，什么样的操作或结果是正确的，什么样的操作和结果是不正确的，没有人告诉他，也没有文档，这就不具有可测试性。这就要求有设计文档，详细写明什么样的操作和结果是正确的。这样就有了可测试可验证的标准。很多软件不稳定，最后加了专职的测试人员也不稳定，其根源不在于测试人员测试方法不对，测试经验不丰富，而在于根本没有测试依据，测试人员只能自己凭经验乱点乱试，根据经验来判断这个结果是正确还是错误。尤其一些报表，输入条件，数据都出来了，但是数据之间是有关联关系的。但这个关联关系并没有设计文档说明，测试人员并不知道，就认为这个功能是好用的。其实这个报表数据是错误的，虽然能正常显示。
对于文案人员来说，软件必须能让文案人员编写文档。许多软件没有设计文档，代码开发完毕，让文案人员自己边学习操作边辅助测试边编写文档。文案人员不是设计人员，不是代码编写人员，不是测试人员，是对软件做陌生的人。他本身都对软件不了解，可想他自己写的帮助文档有多大的可帮助性。软件没有帮助文档，其根源就在于没有设计文档。而没有设计文档的根源，在于根本没有编写设计文档的人。谁来编写设计文档？程序员？程序员再写代码。测试人员？文案人员？实施人员？培训人员？到底谁来写这个设计文档。
我看过许多网友在讨论怎样一个软件才算一个好软件，说了很多方面。但是从现实来说，我们真的需要那么多方面吗？
往往现实一开发，什么好软件的标准都丢了，程序员单枪匹马上手。还有一些开发团队，希望能做一个好软件，于是希望把这些好软件的标准都实现了，最后周期长，在有限的人力和开发时间内无法完成，只好虎头蛇尾，最终还是个烂软件。
业界有个笑话，就是说微软的软件，从第三个版本才能使用。
这说明，一个好软件，应该具备好软件的标准，但一个好软件，不是在一个版本就把这些标准全部实现。而是有步骤有重点的实现，逐步达到一个好软件。
那么，这些好软件的标准就必然需要排个顺序。
编软件，是为了什么？
是为了卖。
怎么才能卖个好价格呢？
嗯，包装成漂亮的就能卖个好价格。巩俐穿上棉袄也就是个秋菊，村姑化完妆也是个靓女。韩国整容大家有目共睹。
就是这个思路。
所以，我并没有把软件实用放成第一位。因为新软件研发，你并没有很深刻理解客户，你假设认定这个需求很实用，到了现实使用发现无法执行下去，这就废了。而且实用不实用，每个客户的理解是不一样的。有人觉得电子邮箱很实用，有人觉得电子邮箱没有用。就这个情况。所以，我设计软件，往往只设计不超过3个实用亮点，实用亮点多了，我们开发也周期长成本高难度大客户可能还接受不了，而且过于复杂销售和实施人员无法给客户讲明白。所以有1-2个宣传亮点就OK。在不断销售不断实施过程中，客户会自然提出来需求，软件就会不断实用起来。
然后，我就会把软件包装漂亮。专业的销售方案PPT，专业的帮助文档，专业的软件界面，专业的图标，统一的操作，统一的字体，统一的专业词条，统一的对齐，专业的提示（很多软件提示居然是：“不好意思，出错啦”。真汗~）。这需要美工、文案、界面开发人员三者配合。
漂亮过后，就是稳定。稳定就需要软件具备可测试性。
这样，软件就可以出去销售第一版了。
到了软件第二版，客户签单量就上来了。实施工具就要提上开发日程，否则多个项目并行提出来的需求能把程序员的工作排到明年。
到了软件第三版，客户签单量更大，老客户也用了1-2年了。服务的压力上来了。所以软件必须可跟踪可自动升级，在持续不断增加实用功能，增强功能稳定性的基础上，这是软件第三版的重点。
到了软件第四版，软件越来越复杂，如何兼容，如何容错，如何容易阅读，如何容易修改就成了首要问题。这个版本，重点就是内部代码重构优化。
到了软件第五版，性能是个问题。过去3-4年积累的数据使系统越来越慢。优化性能成为第五版的重点。
到了软件第六版，由于这么多版本的升级，功能很是复杂了，使原本易用的软件现在变的越来越难懂了，到底是特殊处理的业务。把常用功能和非常用功能分开，把正常业务处理和异常业务处理分开，做到组合裁减，一部份不常用的功能就渐渐萎缩掉，一部份常用的功能做增强。在这一版本，重构易用性成为重点。
软件到了第七版，就几乎在打补丁了，不再投入大量人去维护了。软件进入大销售大实施大维护的收割阶段，维护本版本的开发团队在萎缩，下一代产品在酝酿。
这就是一个软件生命周期中，不同时期的不同开发重点。把握好节奏，合适的时机做合适的事情，一点都不浪费投入人力。
但是我们要注意，性能是一个结构性的问题。所以虽然在第五版才调整性能，但对于企业管理软件来说，必须在基础设计的时候就强烈关注数据库设计。因为数据库结构一旦固定就无法更改。从过去的经验来看，只要数据库没有设计缺陷，性能的瓶颈主要在代码上，只要改进代码和功能设计（有些功能设计本身就性能很低，大量的功能集成在一个界面上岂能不慢？），性能是很好解决的。
对于代码的重构和优化，如果从始到终遵循着函数封装，小函数分割（我曾经遇见过一个3000行的大流水函数，不敢下手，怕一旦修改不知会发生哪些BUG），优化和重构也是很容易做到的。
网友们讨论了许多，有实用性、稳定性、容错性、性能、可测试、可理解、可修改、可实施、可支持、灵活性、移植性、兼容性、安全性、易用性....。
但这么多要求，我们都要有目的分阶段的一步步达到。而且，往往我们不断补齐上一阶段留下的遗憾，我们此阶段的努力又会形成下一阶段的遗憾，总是无法达到一个赏心悦目可以笑看江波的软件。可能，世事轮回皆此规律。
后注：
八部众为佛经故事。八部分别为八种似人非人，似神非神，似鬼非鬼，似善非善，似恶非恶的种类组成，他们散落在佛界三十三重天，或喜或嗔或怒或思或乐，但种类之间总是互相关联互相矛盾又互相共生，层层迷障无法拈花微笑。
一个好软件，也是如此多的标准特性，也是如此共生又如此矛盾，颇为神似。
24、葵花点穴手
我的手下经常会面临这样一个问题：客户必须让咱们按他们的需求改，您看怎么办？
这种情景大家可能很熟悉，一个业务处理，可以这样处理，也可以那样处理。你的软件采用了你的处理方法，客户采用了客户自己的处理方法。两种方法平风秋色，没有优劣。但客户用惯了自己的方法，所以必须让软件改成客户自己的方法。
不改吧。没有理由，因为两种方案都差不多，但客户就是客户，客户占上风，否则就不验收不给尾款。改吧，又有什么意义？这家客户习惯了这种方法，下一家客户又不适应这家客户的方法怎么办？到一家改一家？
这都成了什么事。
我也深被这种问题困扰，至今没有好的解决方法。但我仍然力求找到一些方法去改善。我就是这样一个人，能改善一点就改善一点，量变就会发生质变（当然，做这样的管理者需要时时观察细致分析研发过程中的问题）。我这几天看丰田管理方法，丰田连一个工人的左右手空闲和手臂抬高高度和次数都做了细致分析。因为手臂抬高高度和次数决定了这个工人的有效的工作时间和工作强度，我们工作的时候如果老需要不断扭脖
子，我相信很快就会得颈椎病。
一个软件，经过多年的发展，不断的客户实施，加入了很多客户的需求。我们返回头可能会发现这样一个现象：我们走的太多，我们甚至忘了我们为什么要走。当时当景，我们觉得客户说的在理，不修改就说不过去，于是做了修改，但天长日久的修改积累，我们发现软件主要要解决的问题已经被无数的功能左延伸右扩展，已经不是一个能一句话说清楚到底干什么的软件了。所以，做企业管理软件有句笑话：ERP是个筐，什么都敢往里装。
说不清楚一个软件到底是干什么的，是个很大的问题。销售给客户说不明白，老员工给新员工说不明白（甚至新员工不知道这个软件有什么价值，没什么存在的意义），渐渐的，整个员工群体都在糊里糊涂的工作，反正有这个产品在，就打电话销售跟单呗，客户问什么都说软件都有都能满足。研发呢，客户有需求就修改。实施呢，签了单子就去实施，有什么软件功能就教用户怎么使，然后尽量让他使起来，管他需要不需要，管他急需不急需，管他合适不合适。支持呢，有问题就回答。大家都在做一天和尚撞一天钟。
我想到了曾经看过的微软的一种方法：
对于什么目标市场的客户（一定要精确描述好你的目标市场，千万别用什么中小型企业之类的词语）而言，你的什么产品或服务（针对这类目标客户，你提供了相应的什么产品或服务，这个产品或服务一定要与你的目标客户匹配），提供了什么主要价值（要精确，千万不要说提高了管理水平。管理这个东西很模糊，就类似这个企业管理水平低，到底指的是什么），因为你的这个产品或服务提供了什么独到之处（一定要独到，否则人家为什么买你们，而不是买别人的）。
这是微软的一个产品定位方法。
还有一种我自己总结的方法：干什么，用什么。
例如，杀毒，用瑞星。聊天，用QQ。看新闻，上新浪。写文章，用WORD。就这么定位清楚。我们知道，QQ有很多功能，不仅仅是聊天，新浪也不仅仅是新闻。但我们能把我们的企业管理软件也讲的这么清楚就非常好了。记帐，用XX软件。记录进销存，用XX软件。但偏偏这个世界发明了几个很高的词，还云里雾里解释了很多，越解释让客户听的越摸不着头脑。如：SCM、ERP、CRM、Web2.0、SOA。而做企业管理软件，却又往往要
遇到这几个词。落实下的产品到底是不是SCM、ERP、CRM、Web2.0、SOA，自己和客户谁都不明白，只能是客户目前有什么需求（这个需求可能根本不属于这些范畴）就做什么需求。
为了防止软件成为大杂烩（想起了猫扑，我一直不知道这个网是干什么的，只好把它定位于搞怪集中地，但好像也不对。年轻人的门户，好像也不对。），我经常用微软的方法和我自己的那个简单方法来校验产品，定期给大家传达，让大家渐渐模糊的产品印象又清晰重点起来。
我们也会经常一起讨论，我们的产品最适合什么样的客户，第二适合的客户是什么样的客户，第三适合的客户是什么样的客户。由此不断校正我们的目标客户群，调整我们的营销策略、销售策略、定价策略、服务策略、需求定制策略。
我们在描述最适合什么样的客户的时候，为了描述精确，用的方法是拟人法。
我们不会泛泛而谈，我们会从现在的客户群中找出最适合的已经购买使用了我们产品的客户。一一描述他们的组织结构、企业文化、老板性格、老板管理风格、中间干部的管理流程、考核方法。不过，往往我们无法找出一个完美客户，能把我们的软件各个功能都是用的很好的客户，于是我们就拼凑，把各个功能使用优秀的客户分别挑出来，然后都按照组织结构、企业文化、老板性格...等等这些方面来描述，然后把他们综合在一起，一个“完美”的最佳客户就出来了。
我们在讨论期间，为了深刻的体会，往往都把这些客户的公司名称，城市（中国真是差异很大，东北人，浙江人，广东人，截然不同），用户姓名，部门，年龄，性别，婚姻状况，从业经历，性格，如何思考问题，他讨厌什么，他喜欢什么，他关注什么，家乡，什么学校毕业，计算机水平，工作环境，每天大部分基本在干什么事都描述下来。如，我们老说：XX公司的XX，老喜欢反对别人的意见，不管别人是对是错，总要说出自己的意见，显得自己很独特。还老爱用手那样捋一下头发。唉，他也是三十五六岁的人了，但还是个小头
儿，老觉得自己满腹经纶老板不赏识。
这样，一个活灵活现的形象就出来了。我们大家的讨论就有了基础。省得老有人提：不可能有这样的事情，谁傻蛋了这么想。但一说到现实具体例子，大家就都明白了，确实是林子大了，什么鸟都能飞出来。（可能也有鸟人）
我们以后去做销售、实施的时候，就把当前这个客户和我们设计的这个最佳客户进行对比，很快就能分析出这个客户最适合使用哪部分，它的优点在哪里，它的缺点在哪里，它的差距多大，从什么方面去提升。所以做销售，总是很快能把握住客户的兴奋点，做实施的时候也很快能根据客户的关注重点来突破和提升。其实这种方法，在业界有个很标准的名字，叫“标杆法”。
我们描述完最佳客户，我们就要去列举这个最佳客户的需求。我们到底要解决这个最佳客户的什么问题？
一个企业的经营，都有一本难念的经。每个阶段都有烦恼，小有小的压力，大有大的臃肿，中不溜还上不上下不下难受。各个方面都会有问题，从老板的管理风格，到企业财务核算，到企业财务报销，到企业考核，到招聘培训，到销售到服务，涉及到各个层次各个角度。真要数落问题，每个公司数完后都觉得这个公司没救了，但事实上这样的公司还活的好好的。所以，看事情要平和，你眼睛老盯着灰暗，你会觉得真个世界都太黑暗了，你活着太痛苦了，这就不对了。这真是自己跟自己过不去（有句笑话：饿你两天，你啥也不黑暗
了，能吃个窝头也感动的痛哭流涕）。
所以，如果我们真要去解决企业这么多问题，我们也不是万能公司，也没有能力解决。我们只能解决我们擅长解决的问题。但是我们擅长解决的问题，真的是企业现在急需的吗？这又是一个问题。解决了也不疼不痒，那企业怎会买单？
所以，我们把企业急需，而且我们擅长的，而且我们的解决方法是我们的目标客户能够执行的（别想出一个解决方法，但要人要钱要时间，哪里有这么充分的条件？这样的解决方法说明就不可行），而且解决后能有明显效果（很多东西是长期才能看出效果，这类问题的解决就比较痛苦，我们不希望这么做，这样会使观望的客户的投资购买延迟），而且客户愿意为这样的解决方法买单，而且买单的金额符合我们的盈利目标（我们也不是雷锋）。
经过这样一筛选，确实剩不下几个急需解决的问题点了。有时候大家讨论偏了，还会讨论到什么点都不剩了，于是停下来，重新过，不要讨论的那么极端。然后大家在这些问题点上统一认同。我们做营销，就是针对这些问题点提出我们的解决方案。我们的软件发展导向，也是趋向解决这几个重点问题点。这样，我们的营销和产品就是统一的。就不会出现我们老看到的一些现象：营销说的是一个东西，拿到手是另一个东西。
全公司同一个思路，同一个目标，这是最厉害的。（这让我想起了，有人曾经想UML把客户、设计、开发、测试都串在一起）。在软件公司中，把营销、销售、开发、实施、服务想串在一起也是非常困难的，大家对客户的体验是不一样的，关注的重点也是不一样的。所以，用这种方法来描述客户，描述客户问题，全公司的认识就统一了（当然，那些技术至上者除外，他们可能只想借公司资源把自己练成高高手，我直到现在也不明白练成高高手而不能解决客户问题到底是为了什么要练。我过去深入学习组件技术，搭建业务平台架构，学习数据库技术，皆为解决客户手头急需的问题。客户其实只想解决问题而已，什么技术都无所谓，只要能解决了，最好是越简单越好的解决方法）。
25、文档知多少
去年，我们要让软件开发团队管理上台阶。
我们由于处于企业管理软件开发领域，而对日外包大部分接的单子都是管理软件之类的单子，但是人家的项目管理、进度、质量都比我们好，如果他们再配合管理咨询公司作为合作伙伴，再加上大规模的服务呼叫中心，像我们之类岂有出路？
于是我们就想到了引入对日外包的开发过程管理。
大家一想起对日外包，就想到了大量的文档和大量的代码工人，想到了详细设计说明书甚至到函数级、伪代码级。
要不要引入的时候，我们内部也做了争论。觉得对日外包，人家接的单子额比国内客户大，所以也能招聘大规模的员工，而且对日外包，日本人是很理性的看待项目周期的（国内客户要求一个月开发完上线），而且日本人都做了半年到一年的调研和设计分析（国内调研几乎只是一个上午，坐在一起瞎聊，根本不成方法）。所以对日外包不适合咱们。咱们没有钱招聘一定数量的人（即使我们只需要普通员工，而不是人才，我们也没多余的钱），当然我们也无法分离那么多专职的项目管理、开发、测试、文档、配置管理岗位。我们的客户对于软件的认知决定了我们无法在调研、设计上下太多功夫（单子额就那么大，客户认为软件就值那么多钱，当然无须对软件生产各个环节进行重视）。
不过，我还是坚持进行引入。是骡子是马，咱们拉出来遛遛。还没遛，就说不行。这不是小时候的小马过河了么？
引了进来，合作伙伴给我们派了一位质量控制部的人员。
一入手，发现有个很关键的问题，方法的源头。
因为对日外包，都是接单生产，主要是编码、测试，保证生产进度和质量要求。但编码之前的所有环节，对日外包公司并不清楚。他们只知道拿人家给的设计书开始coding，设计书怎么来的，前面环节产生过哪些文档，不清楚。
幸亏我们过去有系统的调研方法，从调研描述现状、然后分析优化的组织结构、工作流程、考核报表、岗位职责四大块来描述需求。客户优化后的流程、工具中包含手工纸张信息、EXCEL信息、软件信息。
把这些转变为软件中的功能、权限、报表也一气呵成。组织结构和岗位职责决定了功能点和功能权限、工作流程决定了软件流程、工作流程中使用的纸张信息、EXCEL信息、软件信息就是数据输入，报表就是数据输出。这就是一个企业管理软件的四大块：组织权限、输入、处理流程、输出。
所以说，企业管理软件的开发是有方法和规律的，比较容易，就连最难的调研和需求管理也有方法。所以企业管理软件的开发，现在主要集中在大规模开发团队的组织、任务调度、人员培训（大规模的开发，必然需要的是一般素质的人员，而非高级人才，否则不可能有那么多资金来实现大规模开发）、大规模开发团队的质量和进度（人多了，各个层次各个水平的人都有，理解都不同，如何保证质量和进度是很关键的，否则很容易项目预算失控。一般素质的人多了，对于管理的要求是很高的，很容易成为乌合之众，只消耗不产出）。我特羡慕KFC，不管我们在大江南北哪里，迟到的KFC是一样的口味和品质，享受的服务和环境也差不多，这很难。那么多店，而且都是授权店而非自主经营店，那么多一般员工，而且员工流失和临时员工也非常多，居然能保证一样，管理水平实在了得。所以我经常学习KFC和丰田，如何使一般员工大规模配合工作。
对于企业管理软件开发过程中的文档，我们一般有需求分析说明书，其编写格式和思路，和我们的需求调研方法一致，也就是说，我们的需求调研的结果，落实到纸面，就有需求分析说明书，另外还有一份需求调研报告，是偏向于项目过程叙述的。
需求分析说明书回来，研发部内部会进行大家一起学习理解，然后讨论。
讨论主要由：需求调研人、业务组组长、测试组组长来参加。一个个的过流程。因为在需求调研期间，去的只是调研人，可能有想不全的地方。如果这样就直接进行开发，无疑会有很多漏洞。这样给开发、测试，都带来了返工修改，给项目管理也带来了项目进度、任务分配的调整，计划的打乱也间接影响了质量管理。
根据大家讨论补充后的需求分析说明书，就比较容易得到我们下面环节的文档。
首先我们会出功能点文档。
我们会把需求分析说明书中的业务功能都列出来清单，属于组织结构建立、组织角色、权限分配、登陆验证、基础数据维护之类的都归类到系统功能中。系统管理，各个企业管理软件差不多，我们又有公共的系统管理模块，就不需要重新发明轮子了。所以，我们主要重点是分析业务功能。
根据需求分析说明书中的每个流程，都先提出来成为一个功能点。然后针对现在整理出来的功能点，再一个个对照流程，如果这个流程复杂，就拆分，把这个功能点拆成几个复杂性和预估工作量差不多的功能点。经过这样的拆分，就形成了最终的功能点文档。
而功能点之间，根据上述方法的拆分，就形成了功能群。
功能点就成为功能权限控制的最小单位。功能群就成了软件菜单中的一项。几个相关联的功能群就成为了一个业务子系统。
就这样的方法，使子系统-功能菜单-功能点（可能是某个功能窗口上的功能按钮）三级分开，与组织结构-员工-角色-用户-权限结合。一个软件，未来会成为什么样子，大框架就出来了。
做功能点清单，就类似于跑马圈地，这个项目到底多大，我先把项目边界框起来，而不要让这个项目无边无界，那自然也不会有可落实的项目进度和项目管理。知道了项目最大做到多大，就能决定是亏是赚，是做还是不做，能不能做了，有可用的时间和人力来做否。
然后，我们会根据功能点清单，为每一个功能进行优先级的标示。我们通常会把优先级分为三级。这就意味着一个项目，大致分为三个阶段。一级是必须要做的，即使延期也要做，必须调度多加人手多加班也要完成。一级做完后，如果有时间，就把二级完成。如果时间超期，有适度的尽量去完成二级，可以延期，但也要根据预算和时间。如果适当延期也无法完成，我们会给客户去上线实施，变实施边并行开发，使实施团队和开发团队进行并行工作。所以，二级也是重要的功能。三级就是如果时间用完，三级的功能就要舍弃掉不开发。
一般是，按功能的重要性来划分优先级，我们在之前已经讲过，我们调研需求的时候，就把常用业务和异常业务分开，把每天做的业务，和每周、每月、每季、每年做的业务分开。几个结合特别紧密的，互相关联的，我们也会把他们划分在同一个优先级，需要单独开发的基础数据维护界面，我们也会放在同一个优先级。这样，只要我们项目到期，或者我们迫于竞争突变，我们会随时推出一个可以完整使用的系统。虽然这个系统可能功能简陋，但可以完整处理整个常用业务流程，而不会造成中断，无法处理下去。
很多开发团队，开发的方法是先字典功能，然后是业务功能，然后是报表。这种开发方法就导致了很多业务系统，客户上线使用了，光输入数据，没有输出，业务系统成了一个闷葫芦，用户得不到使用价值，可能只是减轻了工作量，加快了工作效率，提高了部门间的自动配合。更有甚者，业务功能开发了一半，到处都是断路，走不下去，无法成为一个完整的系统，就是个半成品，上不上下不下，无法适应竞争变化。
我们开始针对功能点清单编写我们的功能设计说明书。
我们是按照优先级来编写功能设计说明书的。我们并不会把功能设计说明书都编写完毕后才开始编码。而是，我们先把优先级为一的详细功能设计编写出来，就开始开发。二级的功能编写会在开发人员进行一级功能编码的时候并行。
功能详细设计说明书由业务开发组的组长来编写，属于系统类功能或公共类的功能，都归给公共代码人员来编写，需要复杂的算法，高性能，高安全，高数据量，需求一直未确定最终解决方案的未来未知变化的接口，也都由公共代码人员来编写。所以，一个开发团队，有高技术的公共代码人员，有深刻理解业务的业务开发组组长，有普通的coding人员。业务开发组的组长一般由熟悉客户业务，编码经验较多但技术能力一般、踏实细心负责适合团队管理的人担任。
功能设计说明书，根据每个功能点详细展开描述。一般一个功能点由一个EXCEL文档来详细描述。
EXCEL文档第一个sheet中是版本信息，每次修改都有变更记录。第二个sheet是页面布局。我们通常会用PPT或开发工具建立个界面草图，然后贴上去。第三个sheet是页面上面的每个字段的说明，如默认值、不可为空、输入约束、主键唯一、输入长度、参照录入等等。第四个sheet，如果有必要，可以用VISIO画出业务流程图。第五个sheet是关于运行要求，如易用性、安全性、性能、数据量、并发性，这几个特性都分为高中低三个等级。另外，对运行的操作系统、内存都做了最低要求。一个功能，必须考虑它的用户的计算机水平，否则功能很实用，但就操作不习惯，客户非要改成客户习惯的方法，我们经常会面临这样的要求。与其那样让客户赶着我们，还不如我们自己提前在设计的时候就要求我们自己。我们在需求调研的阶段会调研客户的信息化现状，如IT维护人员能力，信息化应用能力，客户老板对信息化认知理解，最终用户信息化操作能力。
我经常看见不少客户没有IT维护人员，不知道有服务器这一说法，更不知道什么是SQLSERVER，也不知道备份。对于信息化的理解就是上套软件，装个XP还不知道WINDOWS要升级（很多上网的机器连XP SP2都不装，什么防火墙放木马的都没有），就知道装个瑞星杀毒，天天抱怨机器超慢。一看机器，也确实是老了，2002年的机器，128M内存。而且操作者打字和鼠标都不灵光，让他双击或鼠标右键，他根本不理解。跟他电话里说打开某个功能菜单，他很莫名其妙电脑中怎么会有菜单？如果你的软件是基于.net的，他连.net 运行时都不知道到哪里去下载。所以我们的软件需要在什么硬件上什么基础软件上运行，数据量多大仍然可以运行流畅，我们的软件要达到的易用操作程度，要达到的易用维护程度等等，我们必须在设计期考虑到。
很多做软件开发的，尤其不注重这方面，所以我在这里重点强调啰嗦一下。大家不要耻笑用户，大家的工资都是他们给咱们的，而不是老板。用户不是计算机高手，他们不懂双击、滚动、鼠标右键很正常。我们的衣食父母，我们要好好对待。我们不要和我们的钱作对。
EXCEL功能设计文档到此，其实还缺一块。就是数据操作流程。
我们先不编写数据操作流程。我们会先交给测试组的人员来校验这个功能点的详细设计，是否和需求流程和需求要求吻合，不符合的地方就整改。
整改后的功能设计文档，算是和需求说明文档一致，设计正确。这时候才涉及到具体的实现说明。
我们会让公共代码人员出界面输入输出和业务流程图中整理出数据结构。我们为什么不让业务开发组的组长来整理表结构，就是由于业务开发组的组长熟知业务却对技术并不精通。数据结构很影响未来的性能、扩展，所以应该由公共代码人员来设计表结构，并且建立视图和存储过程。
公共代码人员为了考虑性能和扩展，表结构的设计可能就被打散成多个表，而不是业务开发组长自然理解的存储结构。所以公共代码人员建立了视图，保证在视图的层面上让业务代码开发组的人看到的是一个自然的业务实体数据结构，根本无须理解内部的表结构之间的关联关系。而且有存储过程来保证如何无须知道表之间的关联关系就可以增删改数据。
从这种分工配合来看，我们采取的是从后到前的开发方法。先有数据层，有基础表结构、视图、存储过程，然后基于视图和存储过程进行业务流程代码开发，最终由普通的业务开发人员进行界面拖控件绘制界面。所以业务开发人员既不熟悉业务，也不熟悉技术。
公共代码人员把设计完毕的数据结构交给业务开发组组长，组长来编写每个功能的数据增删改查操作文档。增加这部分文档到EXCEL中，成为第六个sheet。
我没有研究过测试驱动。我一直提倡的是全程测试，从需求到设计到代码到文档到打包，都要经过测试。只有每个环节都能保证正确，结果才会正确。如果到了代码编写完后才发现了不对，甚至是需求一开始就理解的不对或有矛盾流程，这就糟糕了。许多人喊需求总变，项目进度无法保证，不仅仅是没有配备需求调研人、业务开发组组长、测试人，更是研发流程方法上有问题，没有采取全程测试。
文档编写完毕一个整块（不是全部的一级功能编写完毕后），我们就会交付给业务开发组去开发。具体开发人员任务安排，由业务开发组组长来决定。需要由公共开发人员来开发的，业务开发组组长都会根据自己的开发计划和公共开发人员的任务列表（我们用需求管理系统来安排每个人的开发任务），告知公共开发人员预期的实现完毕时间。
这样，公共开发和业务开发在并行，设计编写和功能开发在并行，设计和设计测试在并行，代码和代码测试在并行（我们采取的是版本管理和每日构建）。这样的情形就跟流水线工作一样，颇有点像丰田的流水线生产，一旦发现某个环节出现问题，理解集中人力来解决，而不会让这个问题的这个人延期钻牛角尖，否则，所有的项目进度管理都成了一句空话。没有了实质的进度，也就没有了实质的项目预算管理。那到底能不能赚钱，真成了一个鬼才知道的问题。
很多朋友在开发当中没有写过文档，一旦有想法要正规化研发管理，就动辄要求全程文档，这文档，那文档，把开发人员累的，最后产品质量和产品进度都没有保证。一看试验失败，就全盘否定编写文档，再回归到一无所有的状况。真是走两个极端。
希望这篇文章能够给大家以平和的心态看待编写文档。我们并不是为了正规才编写文档，我们写的每一个文档都有作用。我们也在力求能少写就少写，根据团队的、客户的磨合理解共识程度，哪个文档或哪个环节不需要写，我们就砍掉。
我们并不在乎正规不正规，我们也并不在乎我们看上去很美，那没有用。我们只是商业开发，我们要的是可控，在有限的人力资源、合同额、合同周期内交付出客户认可的质量产品（不是高质量，是客户能接受的质量，我们从来不为没有利益回报的东西多付出）。
26、狮面人
好多人都说：你这个方法根本就不是三五个人十来条枪的方法，项目经理，公共代码开发员，测试员，文档员，那得多少人的公司才能配得齐这样的团队。
嗯。其实，我们的团队也不怎么大，我们本身也是一个很典型的中小企业。
一般，都是一个产品或一个项目，由一名业务开发组长、一名主程、一名辅程组成。如果项目简单，基本就是一名业务开发组长和一名主程构成。如果业务开发组长的开发实力也能和主程相当，而且刻苦努力，不仅协调做的好，需求设计做的好，代码开发也做的好，那么比较中型的项目也是这两个人组成。有几个产品，就会有几个这样配对的开发团队。
研发部其他的人就剩下项目经理、公共代码开发、测试员、文档员这些角色了。
一般，研发部会有一到两名项目经理。我们老承接一些大的合作开发集成项目，老需要有人去客户现场去和其他合作伙伴一起开会，讨论，方案提交、工作量报告、工作进度报告。总需要有人去跑这些项目协调会。另外，销售打单的时候，客户总会提出一些技术性的问题或某个需求能不能做的问题，销售也模棱两可，不知道能做还是不能做，于是总会拉上一名项目经理。关于产品的、技术的、开发周期、工作量估算、项目团队组成的PPT和方案由研发部的项目经理来做，关于价格和商务条件上的由销售来做。在打单过程中需要讲解产品或回答客户产品疑问，都让这名项目经理来兼任售前支持。对于项目型的，项目经理有时还担任需求调研经理，使用需求调研方法产出需求说明书。不过，需求调研，有时也是业务开发组长来做。主要看业务开发组长在客户面前的沟通力。因为业务开发组长是开发人员出身，但技术一般，业务知识很熟，管理能力差不多够管理个1-2人，工作年限长一些工作经验也多一些，但有些人比较内向，不适合和客户调研沟通，就不做需求调研。所以谁来做，看具体人。不过按职责来，项目经理和业务开发组长都要能做需求调研。
