对中国自发产生的软件企业的思考
1. 中国软件企业真正少了什么？
我想大家都认为跨国企业与我们的中国软件企业是不同的，不仅仅在于其资本的多少，也不在于其对于员工的待遇和福利，就像大家不会认为中国软件企业不过是资本少一点，待遇差一点，业务范围小一点的跨国企业一样。（当然，我相信有很多人确实是这样认为的，那么我想先请您读完我的文章，然后我非常诚恳的请求您对于我的观点其中的错误之处进行批评。）
那么，既然我们人人都认为跨国企业和中国软件企业是不同的，那么跨国企业和中国软件企业真正的不同之处究竟在什么地方呢？究竟是什么导致我们会认为跨国企业和中国软件企业是有着本质区别的呢？
首先，我想请各位根据我日常工作中所遇到的种种问题，来跟我一起思考一下，回想一下，在您的公司里，是如何处理以下这些很琐碎平凡的工作的呢？
以下的问题基本是从担当基本工作的技术人员的角度来问，作为各级Leader和Manager的话，把问题反过来问即可。
你如何得到工作的指示？通过口头、mail、书面还是别的方式？是否每次都是通过固定的方式？对于一项工作，你是否只需要得到一次指示就已经能够基本明确自己所应该做的事情？
你从谁那里得到工作的指示？从固定的一个leader还是可能各级leader都可能给你指示？
当你的工作出现疏漏和错误的时候，谁可能对你进行指正？同样，是固定的一个leader还是凡是你的上级都有可能？
你的工作的成果如何汇报？汇报给谁？通过什么方式汇报？您的项目组的所有工作成果，包括所有的文档，代码，以及相关资料，是如何存放的？
当你在工作中遇到问题的时候，解决问题的方法是什么？是否会有人和你一起关心这个问题？是否会有人能够对你提供指导和帮助？
工作成果有没有定义？不同阶段的工作成果有没有各自的定义？是不是所有人都采用相同的途径，方式进行交流？有没有区分正式的信息发布和私下的讨论？格式、规范由谁发布？指定的格式、规范，leader提出的工作中的要求，是否都能够得到贯彻实施？
工作指示的周期是多长？你可以计划到多久以后的工作？当您的项目组面对一项工作任务的时候，你是否在整个工作周期当中的每个时刻，都清楚的知道自己所负责的任务以及应当担负的责任？你是否有过今天不知道明天应该做什么，这周不知道下周应当做什么的时候？你是否有过工作一大堆，却不知道到底谁负责哪个部分，自己又不知道该做哪些工作的时候？
您的公司如何来产生中层的各级Leader和Project Manager？是主要通过招聘手段，还是领导单纯根据工作业绩来进行任命？或是其他的手段？对于中层管理人员的产生，有没有有意识、有目的的培养方式存在？
我知道我问的这些问题琐碎而平凡，然而我并不认为这些问题因此就不重要，因此就没有什么真正的意义？恰恰相反，我认为在目前的情势下，正是类似这些琐碎而平凡的问题，才是最重要的，最值得我们关注和体验的。当然，如果对上面所有的问题，您都有明确并且您觉得完全合理的实际工作方法来作为答案，那么恭喜您正在一家优秀而有前途的企业工作，也请您不必在拙文上浪费时间，以下我的种种理论，对您已经没有什么用处了。
目前，软件工程的种种方法以及过程改进可谓软件业界的显学，恰如经济学之于中国一样。我认为种种对于软件工程的讨论和关注是非常重要的，先哲与大师们的著述与讨论，国内先行者们的实践和争论，都是非常重要的，他们代表了软件发展的先进方向，也是我们前进的必然道路。
然而，我认为，最重要的，并不是这些。而恰恰是上面我所关注的那些简单、琐碎而又平凡，你每天都在实践都在进行的事情。
因为再伟大的理论也要通过这样平凡的工作来实现，再了不起的方法也要通过一点一滴的实践来验证。实际上，长久以来，我认为我们就是缺乏了对这些构成整个软件开发的细小的沙粒的关注。也正因为如此，尽管现在先进的软件工程方法在持续的引进，我们已经可以在理论上与国际先进水平基本保持同步，然而却几乎没有听到任何一例对于先进理论，先进方法的成功实践。大家听到的，讨论的，却大都是在自己实际的工作中引进软件工程方法履步维艰，无法成功的故事；大都是软件工程无法适合中国实践，或是为什么不适合中国实践的问题。
为什么软件工程和过程改进代表了软件开发的先进方向，却无法在我们的工作中得到验证和实践？其关键也就在于我们工作和实践中那一点一滴的方法和态度。大家都知道淮橘北枳的故事，南方的橘子树移植到北方便会变成枳，结的果子便不那么好吃，原因只在气候和水土的变化；同样，本来很好的软件工程和过程改进，到了我们中国，同样会因为本地的实际状况而发生改变。
实际上，我认为，对于软件工程和过程改进的讨论和研究，对于目前我们大多数的软件开发人员来说，只是一种空中楼阁。那些被讨论的东西都是很好很好的，但是，那时国外的先哲与大师们在已经有着成熟有经验的人员队伍，有着管理比较现代化的企业的基础之上，对于如何达到“更好”的一种讨论。而对于我们目前的实践来说，我们尚无法达到大师们理论的起点，连“好”都尚未达到，又如何实现“更好”？（对于这一点，我相信有相当读者会有不同意见。同上，再读完本文之后，我诚恳的请您提出批评。）
而我们之所以连“好”都尚未达到，便是因为我在前面所问的细小问题。而所有这一切细小问题所指向的根源，其实都只是一个，那就是：缺少规则。
缺少规则，其实这个是老生常谈，并且这个问题也并非为我们软件行业独享。缺少规则，其实是我们中国的一种传统或者说特点。这其实是我们同老外们的一个本质区别，如果不认识到这一点，那么是绝对不可能搞明白为什么外国的好东西到了我们这里就是实行不了的，因为最根本的做事情的方法和规则都变了，你怎么可能还期望所有的一切恰如理论和书本上描述的一样完美？
但是我知道看到这里很多朋友要提出异议了，是的，我们大多数的企业当中并非不重视规则，实际上，就以我刚刚离开的甲公司为例，公司的管理者们给我的印象是，在管理者的主观愿望上，绝对是极其重视管理的，并且，采用了各种各样的方法来加强公司的管理工作。
但是，遗憾的是，我认为，绝大多数人，可以从甲公司的管理者们推广到大多数管理者，并没有意识的问题的关键所在。
我所说的缺少规则，并不是说我们在工作中没有规则。实际上，每个公司都有自己不在少数的种种规章、制度，种种工作规程。但是，这些规程、制度当中，又有多少是管理者们真正根据自己心底的需要，真正根据科学的管理方法而制定出来的呢？又有多少不过是简单的抄袭书本，抄袭别的公司，或是仅仅为了对付当前的工作情势，为了应付差事而制订的呢？正如当前我们热衷于讨论软件工程而不是每一个细小的工作实践方法一样，相当多的管理者，容易把规则，把管理当作一种形而上的东西，虽然喜欢制订各种规则，但出发点往往都是为了解决一时的工作需要，为了看起来先进或是好看，并且总是认为一旦有了规则，就万事大吉了，就觉得本公司，本项目组已经实行了先进的管理方法。
在这里，我敢大胆的说一句，大多数的公司，他们制定规则之前，并没有根据自己的实际状况，也没有从每个开发人员工作的实际出发，并没有在制定规则之前，弄明白自己真正需要的究竟是什么，自己制订的规则，究竟对公司有益还是有害，能够促进工作还是拖累工作，也没有搞明白，自己制订的规则，是否符合实际，是否真的能够，并且是否真的会被员工实践下去。
我所说的缺少规则，并不是指的我们缺少成文的，白纸黑字的规则。我所说的规则含义远远大于这些，我所说的规则，指的是我们为了完成一项工作，从头到尾，我们所应该遵循的种种工作方法和手段。正是这些方法和手段，决定了我们的一项工作，是高效率的完成还是低效率的完成，决定了我们这些程序员们，是每天能够正常的工作还能够保证进度，还是加班无数却最后只能看着项目垮掉。
你不信？好，那么就让我们回到一开始我问的那些问题上吧，让我们来一个一个的分析一下，究竟这些细小的方方面面，究竟会对我们的工作产生什么样的影响。
1. 你如何得到工作的指示？通过口头、mail、书面还是别的方式？是否每次都是通过固定的方式？对于一项工作，你是否只需要得到一次指示就已经能够基本明确自己所应该做的事情？
你从谁那里得到工作的指示？从固定的一个leader还是可能各级leader都可能给你指示？
当你的工作出现疏漏和错误的时候，谁可能对你进行指正？同样，是固定的一个leader还是凡是你的上级都有可能？
评论：此处的问题讨论的其实是软件开发过程中工作指示的流通成本问题。我想每个Leader都会希望自己对于下属的工作指示能够得到正确、及时的贯彻执行，而每个开发人员也都会希望上级的指示明确、具体，不要朝令夕改，不会误导自己到错误的方向。这其实也就是希望工作指示的流通成本能够降到最低。但是，您有没有想过，该如何保证将工作指示的流通成本降到最低呢？工作指示的流通中，是否需要一定的规则呢？
让我们来看一下工作指示方面的坏典型。
上级给予的工作指示：某某，把这份代码看一下；某某，把那份文档完成；某某，去配合某某完成某事...等等。
这样的工作指示有什么不对？我认为，一个好的工作指示，至少应当明确的包含指示的对象，工作的内容，对于工作的要求，在工作中所负担的责任，完成的期限，最后的成果体现为什么等等方面的内容，才是一个合格的，好的工作指示。同时，最好以文字方式发布。对于工作指示的含糊不清，不仅会导致下属完成工作时的迷惑，也会导致Leader对于工作状况的把握不清。因为提出一个明确的工作指示的前提是Leader本身对于该项工作已经进行过思考，比较清楚明了，这样才能要求的明确，如果事先不经过自己思考，只是简单的命令下属，要下属去思考，那么到最后自己也只能是对整个工作保持一种浑浑噩噩的状态。总之，只有清楚明确的发布工作指示，才能保证工作担当者顺利、高效的完成工作，保证Leader对于工作的监控和掌握。
至于工作上多头指挥，即每个比你大的人都可能让你做事情，对你由所要求所带来的坏处，相信有很多人都会有切身体会，在此不再赘述。
因此，建立工作指示流通的规则，我相信可以对提高我们的工作效率起到事半功倍的作用。
2.你的工作的成果如何汇报？汇报给谁？通过什么方式汇报？您的项目组的所有工作成果，包括所有的文档，代码，以及相关资料，是如何存放的？
工作成果有没有定义？不同阶段的工作成果有没有各自的定义？是不是所有人都采用相同的途径，方式进行交流？有没有区分正式的信息发布和私下的讨论？格式、规范由谁发布？指定的格式、规范，leader提出的工作中的要求，是否都能够得到贯彻实施？
评论：此处的问题讨论的是软件开发过程中各个角色之间的交流成本问题。我们都知道，开发过程中的各个角色之间进行交流是需要成本的，不经过必要的沟通，任意两个人之间几乎是不可能明了对方的意思的。同样，我们肯定也希望把这种成本降到最低。而如果在沟通和交流中，没有每个人都可以遵循的简单、明确的规则，又如何能期望做到这一点？让我们来看一些坏的例子。
你有没有遇到过这样的情况，一分由你负责的文档或者代码，一份由你搜集的资料，你已经按时按要求完成，并且已经提交给你的Leader，甚至你的Leader已经将其发布到全体了，可是不论是你的Leader还是你的同事，在遇到问题的时候却好像从来没有收到过一样，总是不停的跑来问你原本文档或资料中已经说清楚的问题，或者干脆一遍又一遍要求你重复发送你的工作成果？
而你呢？当你需要别人的工作成果的时候，你又是怎么做的？你能很轻易的找到自己所需要的东西吗？还是要问上一大圈人才能得到自己需要的东西？
你有没有过一个问题，一件事情，已经按照要求向大家解释清楚，却总是有人表示他不知道因而不断的来要你解释？
你有没有过Leader正式发布了对于工作的某种规范和要求，结果你辛辛苦苦的按照要求完成了自己的工作，却发现大家都没有按照规范来做？你又有没有过某个普通同事随便发了一封mail或者随便提到工作要按照某个标准，你以为只是他个人的意见可到头来却发现对于工作成果的考核却完全按照这个标准进行？
你有没有过辛辛苦苦的完成一项工作，满心以为完成了要求的任务，却发现实际上你还差了若干份文档没有完成？又有没有过花费了巨大的时间和精力，完成了一项繁复的工作，到头来却发现其实只要完成其中一部分就可以了？
我相信以上我列举的种种情况，诸位肯定和我一样，至少遇到过其中一种或几种。至于其中的坏处，应该不用我说了吧？只要各位想想自己当时的气愤、沮丧、失望，以及其所带来的对于工作延误，自然就可以明白如果我们没有一个简单、规范的交流规则，会给工作带来什么样的影响。
以上我提出的问题其实只是软件开发过程中有关沟通的一小部分，我相信各位只要稍加思考，就会在减少沟通成本方面和我达成共识。实际上，我认为在大部分的时候，我们只是很难意识到问题的存在而已，并非我们不重视这些问题。一旦我们意识到了它的存在，那么离解决问题也就不远了。
3. 当你在工作中遇到问题的时候，解决问题的方法是什么？是否会有人和你一起关心这个问题？是否会有人能够对你提供指导和帮助？
工作指示的周期是多长？你可以计划到多久以后的工作？当您的项目组面对一项工作任务的时候，你是否在整个工作周期当中的每个时刻，都清楚的知道自己所负责的任务以及应当担负的责任？你是否有过今天不知道明天应该做什么，这周不知道下周应当做什么的时候？你是否有过工作一大堆，却不知道到底谁负责哪个部分，自己又不知道该做哪些工作的时候？
评论：此处讨论的其实是工作要按照一定的规则来完成的问题。
一个项目的开发，一个mile stone的达成，究竟应当按照或者说，是否需要按照一定的规则来完成？我想恐怕很少有人思考过或者意识到了这个问题。
在我们的工作当中，每一个具体的步骤，都应当是一级一级计划、分派下来，最后由开发人员使用计算机来完成。也就是说，身为Leader，必须能够清楚明确的对下属的工作进行安排，并且通过这种安排，最终达成上级交给的工作目标。在这个过程当中，不仅Leader自身要清楚每一个步骤，更重要的是必须确保担当实际工作的开发人员也清楚自身的任务和责任。如果Leader缺乏这个意识的话，就容易导致工作完成状况极不明确，一大堆事情，却不知道先完成哪个，后完成哪个，工作做到了什么地方都不清楚，在开始的时候工作不饱满，到了最后才发现来不及了，于是再全组赶工。实际上，我认为，计划不明确，工作分派不清楚，是导致项目末期大量加班的最主要原因。
同时，关于工作中的Trouble Shooting问题，该如何解决？我们都知道，实际情况永远不会按照计划进行，Trouble Shooting实际上只是所有计划外情形中的一个而已。
这里需不需要规则？让我们回想一下我们写程序的时候，对于所有的exception情况，你是会一一捕捉并按照一定的错误处理规范加以处理，还是任由其自生自灭，不理不睬？我想在实践当中，一个错误处理混乱，没有规程的程序，我们肯定不会认为它是一个好的程序。那么，我们在对待软件开发过程中的计划外情况，是否也应该建立起一个良好的处理规范呢？
而计划外情况也仍旧只是软件开发过程中的一个方面而已，实际上，我们对于整个软件开发过程当中，每一个方面工作的完成，都应当遵循明确合理的规则。当然，这些问题基本上是在软件工程讨论的范畴里的，相信大家结合自己对于软件工程的思考和实践，会有比我更深的体会。
4. 您的公司如何来产生中层的各级Leader和Project Manager？是主要通过招聘手段，还是领导单纯根据工作业绩来进行任命？或是其他的手段？对于中层管理人员的产生，有没有有意识、有目的的培养方式存在？
评论：此处讨论的是您的公司中管理方式、管理方法的规则。在此对这个问题暂时不讨论，后面对此进行专门论述。
以上讨论了四个方面的规则，这四个方面也只是整个软件开发中很小的几个部分而已。只要各位稍加思考，就会在各位自己的实践中找到更多更重要的需要规则的地方。
因此，我认为，当前我们最需要的，实际我们每个最基本的开发人员所最渴望的，并不是软件工程的种种方法和理论，而是在软件开发过程当中，在每天的日常工作当中，点点滴滴的规则。我甚至认为，之所以软件工程会成为显学，会成为广大开发人员关注和渴望的东西，就是因为如果实行软件工程，能够在客观上建立起相当的规则，让大家在实践中有所依靠。而我们的软件工程实践总是无法成功，也从侧面说明了规则的缺乏，已经到了一个何等严重的地步。不然，我们该如何解释，为什么在国外，软件工程的发起和实行总是自上向下，由公司的管理者发起并得到成功实践，而在国内，呼声却总是自下向上，要基层开发人员自发推行，并且总是得不到成功？
因此，规则，这就是我们大多数的中国软件企业，我相信也包括大多数的国有企业，所真正缺少的东西。
那么，我们该如何建立规则？什么样的规则才是好的？为什么中国软件企业即使有着良好的建立规则主观愿望，实际中却仍然缺乏规则？我们又该如何保证规则的切实实行？有了好的规则，是否就能够为程序员个人以及软件企业带来美好的希望？
不论你是否赞同我的观点，我都诚恳的邀请你和我一起来对这些问题进行思考和回答。
