华为企业文化种种

---

按：

• 十万这个数量级的（？）还能指望不官僚，那得多厉害。
  
• 后发者都得需要特别努力的
• 向产业链上面攀登同样需要付出极大的努力，成功之后方能获得好回报

---

//z 2012-11-16 18:16:02 IS2120@BG57IV3.T2732865742.K[T21,L818,R26,V597]
曾经的华为往往发一封邮件可以解决的问题，在两三年时间里就变得，发邮件不行，必须还要打个电话催一下；到打一个电话还不行，还要多个电话催才行。这是官僚作风盛行的又一个例子。
加班加点

业界有句话：“华为把女人当男人用，把男人当机器用”，虽然有点戏谑，但不得不说非常精辟。不加班，那就不是华为。尤其是研发部门，如果不加班，按时完成项目是很少见的。华为有永远接不完的单子，你每一天都是都是满负荷的工作，就是这样你还是无法按时完成项目。

除了开发效率低下之外（至于为什么说华为开发效率是低下，我将会有专门一章来深入讨论），一个重要原因就是，华为的市场在和其他公司竞标的时候，别的公司（比如一些国外大公司）要一年完成的项目，华为承诺八个月能完成。这是华为能打败其他公司的一个重要原因。华为越来越看重市场，拿到单子是最重要的，为了能拿到单子，研发要高度配合市场，因为拿到单子是保证营业额每年高速增长的重要条件。长此以往，市场人员的地位越来越高，曾经地位很高的研发人员地位越来越低。

华为的执行力，说到执行力，我估计国内的公司甚至国外的大公司，没有几个执行力是能和华为相比的。在市场部以其他公司短很多的时间接下单子后，华为依然能以极强的执行力来完成给对客户的承诺，及时交付。这就苦了华为的研发部门，为了在短期内完成项目，不得不加班加点。

床垫文化，外界都知道华为有个床垫文化。每个华为员工都有一个床垫，午饭以后，不管男女都齐刷刷地躺到地板上的床垫睡觉。之所以有这个独特现象，是因为晚上要加班，而且要加到很晚，如果没有一个床垫在中午好好躺下（光趴在桌子上打个盹是不够的）睡一觉，你晚上是抗不住的。

床垫文化只不过是加班加点文化一个方面。

有阵子部门有个活动，就是每个员工写一篇介绍自己的文章，写写自己的童年、性格爱好等来介绍自己，以增进团队成员之间的了解。结果几个月下来，我发现一个现象，几乎百分之七八十的程序员文章开头都是类似的“我的童年是在一个……的农村度过的”，原来我们部门七八成的员工都是来自农村。网上有传说华为的研发部门工作太苦，一般只有来自农村的孩子才能忍受。在这次部门活动之后，这个传闻得到了验证。

部门有个每周优秀员工评选，每周由主管评选出两个本周优秀员工，发邮件给整个部门表扬员工的工作表现。经常看到主管对一些新员工这样评价：“某某员工很认同华为的企业文化，工作很努力”。我那时也不理解“认同华为文化”到底是什么意思。

一次一个新员工加班加得劳累过度，病了去医院打点滴，主管高度赞扬了这个员工：“某某工作非常努力，累到去医院，虽然是新员工，但是很认同华为的文化”。这个时候我才理解，什么叫“认同华为文化”，原来就是认同加班加点。

总裁任正非曾经说过华为要任人唯贤、任人唯亲，什么是任人唯亲，就是任那些认同华为企业文化的人。因此华为就算每年的新员工流失率超过30%也不在意，她就是通过这种方式筛选出那些认同华为文化的人。

不过，华为从总裁到最低级的主管，从来都没有承认过“加班加点”就是华为的企业文化。

任正非总常说华为的人均效率很低，只有欧美通信巨头对手的三分之一左右。那么华为凭什么能不断战胜那些欧美通信巨头，扩张自己的市场版图？是技术吗，是管理吗？华为的技术和管理比国内绝大部分公司都要好，但是与这些巨头公司相比还有很大差距。这其中一个重要的原因就是这些竞争对手的员工每周工作四十小时，而华为的员工却不要加班费地每周工作五十六十，有的甚至是七十个小时。

缺乏人性

据华为前总裁李玉琢在他的博客回忆：当他要离开华为回北京与家人团聚安享晚年的时候，任正非为了挽留他，甚至劝他与二十几年的发妻离婚。

这就是华为，为了不影响工作她甚至会让你离婚。为了工作抛弃妻子在华为都是认同的，那么就不用说其他的家庭温情了，更不用说你加班无数没有时间陪家人了。

有段时间，曾经有一个女孩在天涯上发帖，说她男朋友经常加班到12点，一次回家差点被抢劫，以此责备华为没有人性。这个帖子引发了很多类似经常在家苦等男友、丈夫回家到深夜的华为女友、太太们的共鸣，并造成很大的讨论。华为领导为此震怒，要华为员工“管好你们家属的嘴”。华为为了工作是不会在意你的家庭是否和谐的。

在华为，如果你劳累到生病，你也不要觉得自己就怎么样特别，主管也不会因此就会怎么同情你，因为这在华为不是稀有的事情。你不要觉得你无数次加班到半夜或者凌晨几点突然一个电话把你从宾馆叫到运营商定位问题就和累，你可能觉得主管太无情，但这就是华为的情况，所有的人都很累。

但是，华为的缺乏人性和某些血汗工厂的缺乏人性是不一样的。


血汗工厂的缺乏人性是管理者对底层雇员的缺乏人性。而华为的缺乏人性却是主管对雇员的缺乏人性的同时，也对自己缺乏人性，至少华为的每一个主管都是加班加点拼命走过来的。如果说华为只是对底层员工缺乏人性，而高层却轻松逍遥，她是不可能取得现今的成就的。


尤其是华为的创始人任正非，他为了华为是拼命了的，为了华为做了很多牺牲（李玉琢语）。一个五六十岁的老人，患有严重的糖尿病和心脏病，在华为已经取得巨大成功的时候，依然是拼命的工作。他的拼命已经不再是为了名、利和其他世人拼搏所想要获取的东西，他是一个纯粹地为了理想而拼命的人，一个纯粹为了理想而拼命的人是值得敬佩的。


连身患重病、五六十岁的总裁，都为了工作而对自己缺乏关怀，你还能指望你的主管对你怎么样？


这就是华为的缺乏人性，不仅是主管对下属的，也是主管对自己的。




低效的开发模式


这一章我将讨论华为的软件开发模式和国内软件业的一些状况，揭示华为的研发人员不得不加班加点的一个重要原因。


本章很多方面涉及到软件技术，如果不是业内人士可以略过其中某些内容。如果只是把华为的技术管理水平和国内大部分的软件公司相比，可以略过整章内容。


任总裁不是经常华为的人均效率低吗？我就给你分析一下华为的人均效率为什么低！


1、典型状况


华为的软件开发特点就是，在开发初期，为了赶时间加班加点地赶出一个没有经过充分设计、架构糟糕的、编码糟糕的软件系统，快速交付给客户。


软件（尤其是应用软件）不是普通的制造行业产品，在交付（产出）之后还要不断地改动、维护和升级，而且后期维护升级的成本几乎占整个生命周期全部成本的80%。如果前期设计开发的不好，后期维护升级起来非常地困难。


当华为的研发人员为了赶时间交付出一个设计不充分的系统之后，后期维护升级就变的很费力困难，在以后的升级维护过程中又不得不加班加点。在升级维护的时候仍然是重时间而轻质量，走向恶性循环，直到整个系统变成越来越难以维护，成为一个不能自拔的焦油坑。


为此有很多的员工除了在公司里加班之外，还不得不长期出差到局点现场。这种低效率的最高记录就是曾经最多有160人同时在移动的某个局点维护升级一个系统！


这是就是华为的开发特点，一种典型的低效率的开发模式。


曾经参与维护升级过的几个应用系统，共同的特点是设计地很糟糕。比如，JSP页面中充斥着大量大量的业务层甚至是数据层的Java代码，毫无MVC的概念。整个系统业务层数据层不分，或者根本就没有业务层和数据层的概念。后台有些JAVA类甚至大到五千行以上，有些方法的参数个数超过10个！程序依赖了太多的存储过程，大量的业务逻辑放到存储过

程中。整个系统几乎看不到面向接口编程的影子，该用设计模式的地方看不到一个设计模式。几乎是到处可以见到copy的重复代码（重复代码是软件万恶之源，Martin Fowler语）。


维护升级这样的系统是极为费力的，布鲁克斯将这样的软件形容为让史前动物不能自拔的焦油坑。


记得有个外包的兄弟对此戏言：华为为什么搞那么严格的信息安全？就是害怕写的这么糟糕的架构和代码流出到外面被人看到了笑话，砸了华为的招牌，原来华为的软件也是写地如此糟糕。


Java是一种非常优雅的面向对象语言。这些应用系统用Java来开发仅仅是因为它是最流行的Web应用系统的开发语言，而不是因为它最有用的特性：面向对象。


Java能够如此流行正是因为其完美的面向对象特点。对接口的完美支持使Java在制定好接口规范后，获得众多厂商的支持。只要是你依赖于接口规范开发出应用系统，可以很容易地替换不同的实现，提高生产率。所以Java的JDBC、Servlet、JDNI、JMS等规范成为应用系统的优秀的开发工具。


在我参与过的那些系统中，当一个Java类被写成超过五千行，当JSP代码中存在着本该在业务层或数据层的代码时，Java已经完全失去了其面向对象功能。


把面向对象语言当成面向过程的语言来使用，是华为很多软件的开发现状也中国几乎所有的软件公司开发现状。


2、再谈面向对象


首先，面向对象不是银弹，不能给你带来数量级的效率提高，但是和面向过程相比，面向对象提供很多方法让你更容易地改善软件的质量，能给你的生产率带来几倍的提高。


软件产品（尤其是应用软件）区别于普通工业产品的最重特点是，它在生命周期之内需要面对不断的变化。如果有一种技术能够充分地拥抱变化，就可以极大的提高软件的生产效率。


软件要做到能够拥抱变化，就必须做到高内聚、低耦合，能够分开软件可变的和不变的部分。后期的维护和升级大部分修改是其可变部分，分开可变和不变部分之后便可以容易的改动，从而有效地提高以后的扩展和维护效率，带来生产率的提高。


面向对象技术是让你可以拥抱变化的技术，它的重要目的就是分开软件的可变和不变部分。它的典型特点是抽象、封装、继承、多态。抽象可以让你提取出共性（不变的部分）到父类（或接口），变的部分在不同的继承中实现。而多态就是让不变的部分（接口或者抽象）和变的部分（多个不同的实现）顺利连接起来工作。封装可以让你封装变化，将变化约束在一个尽量小的范围之内，实现很好的内聚和降低不同模块（类）之间的耦合，减少对其他模块的影响。


如果你能够充分的遵守面向对象的核心原则：面向接口（抽象）编程，就能充分地分开软件的可变和不变部分.面向对象设计和编程，前期必须投入足够的时间去设计，划分出类和接口，完善地处理各个接口和类之间关系，这是一个比较复杂的过程。


费了这么多唇舌专门说了面向对象，并不是说面向过程的语言就无法开发出好的软件，只是面向对象更容易帮你软件的实现拥抱变化。面向对象也只是提高软件质量的多种方法之一。


我重点要讨论的是，为什么我碰到的很多用Java这门面向对象语言开发出来的系统，几乎就没有采用Java的面向对象特性来提高软件的质量？就好像有个电动自行车但是从来不用其电动功能一样，以这个例子来说明华为的开发效率低下的原因。


3、低效开发模式存在的原因


（1）急功近利


软件的前期开发和后期升级维护的成本之比大概是20：80，如是前期多付出一份时间以后将至少（忽略复杂度上升因素）给你节省四倍的时间！


但是华为的主管们不愿意付出足够的时间让程序员设计开发出优秀的软件，不管是在前期的开发还后期的维护升级，华为程序员的时间永远都是不够用的，他们永远都在疲于奔命。


碰到那些设计开发地糟糕的系统，你开始可能会怪前面的人为什么不好好把这个系统设计好一点、代码写地规范一点。


但是经过仔细观察，你会发现他们是逼不得已的，到处可以看到因为时间压力而不得不草草完工的痕迹。为什么主管不愿意投入足够的时间到设计开发？一是面临着业绩目标的压力，二是短期内能拿到多少单子完成多少项目关系自己能否被提升。华为的营业额每年以百分之四五十的速度增长，这个增长在年初要层层级级的分配到每个项目组。所以每个项目主管都面临着很大的业绩目标压力，他们不得不严重地压缩设计开发时间，以达到目标，同时要想往上爬得快也必须在短期内完成更多业绩。


有什么办法呢，整个华为都处于一种追求营业额高速增长的癫狂状态之中，大家都这么做你不这么做你就可能位子不保，更不要谈晋升了。


就好像国家把GDP做为考核官员的标准，各级官*员为了保住位子或者为了爬得更快，明知道牺牲环境发展经济以后要付出更高的代价，仍然这么去做。


压缩设计开发时间，短期内可以让你完成更多目标，从长远来看却明显地降低了生产率，生产效率大大降低同时项目交付的时间却没有延长，最终苦的是底层员工，他们不得不去加班加点。


这就是一种急功近利的文化，这种文化是导致软件开发模式的最大原因。


另：


反驳一种观点（该观点常常成为项目经理们压缩开发时间的借口），这个观点就是：华为必须先拿到单子才能先活下来。


这种观点在创业初期是成立的，但是当华为在近几年人员规模扩大到几万人、营业额超过几百亿元之后，日子已经过的很滋润，依然还抱着这种论调的经理们恐怕考虑更多的还是自己的官位吧。


（2）管理层观念


掌握华为开发大权的管理者们大部分没有如何才能设计开发出高质量软件的观念。


这些管理者大多采用的是很粗糙的作坊式模式从创业初期走过来的，当这些人做了管理以后就很少再接触技术，他们不了解更好的开发模式能给提升生产率带来多大的影响，往往不愿意接受这些更好的开发模式。越早进入华为人使用的开发模式越落后，这些人后来的官位也是越高。而往往了解最新的更具效率的技术人员职位越低，他们的很多建议不能得到主管的认同。


你可能为了说服主管使用Spring框架来改善系统的整体架构，而不得不苦口婆心、费尽唇舌。


华为只实施CMM的过程中，有五分之一的人因为不适应而来开，这种人员流失是值得的，必须要深刻地改变落后的开发观念，然后才能推行更高效的开发模式。


（3）公司不注重个人技术积累


来华为面试过的大多听过一句话：你不要拘泥于某种技术。华为的特点就是要什么技术就用什么技术，只要能在短期内完成项目，满足功能就行。他可能让一个C++高手在短期内迅速转型使用Java开发出某个项目，然后可能又很快让他改用Delphi开发另外一个项目。这样对于个人技术积累很不利，每种语言都有其独特的地方，经常更换程序员的使用语言，往往是程序员在某种语言上缺少积累，只是掌握了某种语言的语法，无法掌握这门语言的精髓发挥出其最大的威力。


（4）重技术轻业务


华为的软件部门有一个普通的错误心态，就是重业务、轻技术。认为只要深刻地理解了业务，使用什么技术是其次，实现功能就行。这也几乎是中国绝大部分软件公司的心态。这种错误的浮躁的心态导致开发过程中使用技术不深，无法使用出某项技术的最大功效，开发出高质量的软件。


软件技术并不仅仅是让你你实现功能，无数的专家、大师为了提高软件的生产率，持续不断地对软件技术进行改进。只有充分地使用开发技术，才能帮你明显地提高软件生产率。


（5）很多人没有这个能力


在华为可以学到很多技术吗？这句话要一分为二地讲。在华为你有做不完的项目，让你接触到很多技术，可以迅速提高你的技术开发能力。但是这种能力基本就是实现软件功能的能力，不包括设计出优秀的软件的能力。因为无休止的加班让研发人员平时很少有时间看书学习更深的技术理论。仅仅靠摸索实践是不能学习到无数软件大师常年累月在经历过无数项目后总结出来的经验的，必须要去读书、要去学习，这样才能站在巨人的肩膀上。


华为有很多技术理论牛人，有些让我非常佩服。但是有相当多的程序员都是缺少时间去更深入学习技术理论，去学习最新的更高效的开发模式。也看到一些工作多年的资深老员工，实现软件功能的能力想当的强，但是整体的设计却很混乱。


（6）对廉价劳力形成依赖心理


目前，华为的技术和管理和大部分国内公司相比是比较先进，但是和国外巨头相比仍然有很大差距，那么华为到底靠什么不断打败这些巨头，占领他们的城池？


恐怕最大的因素还是中国便宜的劳动力，IT产业最大的成本并不是原材料成本而是人力成本。中国的程序员受的教育不比那些国外程序员的差，智商不比他们低，能力不必他们差；而且华为的程序员还“自愿”大量的加班（每周工作50到70小时，加班10到30小时）。但是中国的程序员拿的人民币，欧美的程序员拿的是欧元、美元。如果你的人力成本对手的五分之一，你还何愁不胜对手。


这是华为一个极大的优势，但是长期以往也让华为的管理者们对这种优势形成一种依赖，有了这种依赖心理就缺乏了去改进开发效率的动力！


如果华为的目标胜过国内大部分的公司，现在做的足够了；如果要打败那些巨头，还要不断地提高的自己开发效率！



4、打破CMM神话


CMM流程为改善华为的软件开发带来了明显的效果，实施CMM是华为提高开发管理的重要阶段。但是CMM流程却有很多自身的局限性不利于应用软件的开发。


技术人员都知道，应用软件的新需求变化不断，尤其是电信行业的软件，大家也都知道中国的运营商是非常强势的，动不动就给你提出新的需求，而且华为的很多软件周期长，多达四五年。这些特点就要华为的软件系统必须能够面对、拥抱层出不穷的变化。


CMM流程是典型瀑布式开发流程，所谓瀑布式流程就是整个流程从需求、设计、开发、测试像瀑布一样按部就班一泻而下，不能回头。这就导致了它不易于面对变化。CMM流程的最初目的是为了那种超大行的项目，比如超过1000人年的航天项目，这种项目的特点就是先开发出硬件，然后再开发相应的软件，软件的需求很少改变。采用瀑布流程的CMM无疑是适合这种的超大型项目的，用一套完整的文档来规范开发的流程，控制整个项目的进度和风险。但是商业应用软件和这种软件项目有很的不同，他要面对不断变化的新需求。


CMM的另一个特点就是它能控制整个项目的进度、减少缺陷率、控制风险，却对提高软件的架构和设计质量鞭长莫及.CMM文档众多，却没有规范软件设计结构的。


CMM过多的文档也成为开发过程的累赘，如果你在第一个版本完成所有的文档，在后续版本开发增加新功能的时候，就要从上到下又更新从需求、设计、开发、测试的所有文档，相当繁琐。所以虽然华为的CMM最多的已经达到CMMI或5级，但是大量的项目的文档都没有及时更新和当前软件的版本相对应，越往后这些文档越是形同虚设。研发人员加班加点连编码的时间都不够，还有谁来得及管这些文档。


CMM的以上几个特点导致它很不适应商业应用软件的开发。


个人认为近几年逐渐流行的敏捷软件开发非常适合华为的电信应用软件开发，敏捷开发是目前最能面对变化、拥抱变化的开发流程。


首先，它采用了不断迭代的开发流程，有助于不断增加新的功能。


其次，敏捷开发是唯一把面向对象开发原则做为开发指导的流程，这可以让你很好地提高软件的架构和设计的质量，达


到能够拥抱变化，易于维护、扩展，这个优点是大多数软件工程流程所没有的。


再次，敏捷开发没有过多的文档，只有在代码不能说明问题的时候才回去写文档，这就为研发人员减少很多的负担。


还有，敏捷开发非常适合中小型规模的商业应用软件的开发，相比CMM的全套流程对开发中小型规模的应用软件来说非常繁琐。


另外，敏捷开发主张每周高效地工作40小时，不搞疲劳战，所有的程序员可能都喜欢这一点，但是这点估计不会为华为的主管们所接受。


CMM流程有很多优点，采用了CMM比以前没有流程的时候是个很大的进步，但是其众多的缺点让他不适合应用软件（尤其是中小型的）的开发，最好能借鉴、引入敏捷开发的优点，加以改造，形成更适合应用软件开发的流程。
//z 2012-11-16 18:16:02 IS2120@BG57IV3.T2732865742.K[T21,L818,R26,V597]