对华为系统软件的战略思考(下)–（10）华为研发

最新推荐文章于 2017-06-05 04:40:16 发布

weixin_34032621

最新推荐文章于 2017-06-05 04:40:16 发布

阅读量216

点赞数

原文链接：https://my.oschina.net/mavericsoung/blog/138008

版权

2019独角兽企业重金招聘Python工程师标准>>>

10. 华为研发

从前面各章节的数据分析，读者可以初步得出这样的结论，华为的研发实力是薄弱的。这个薄弱是相对于其的年营业额收入，其员工规模，其正在竞争的公司。

通常而言，华为负责的研发部门就是其”华为中央研究部(院)”。其总部在深圳。在各地有其分部，如北京的北研所等等。。。。。。

笔者2006年6月5日写的“华为猜想”一文中，对华为的技术管理方面做过一些分析。结论是：华为的技术管理基本上是不可控制的，是被市场和客户问题牵着鼻子走的。基本上没有引导市场的自主能力。文章中一些节选如下：

“。。。虽然华为在2005年的营业额已达到50亿美金(5Billion Dollars)，但从公开的数据分析，我们可以看出，拥有几万员工的华为其营利利润的比率并不是很高。虽然华为已经认识到仅仅通过廉价的研发人员和廉价的产品价格是行不通的，但目前华为基本上无后力可发。研发的创新性基本上层次不高。因此，华为，虽然在人员上，销售上，已经貌似一个国际性的大公司，但是在公司地位(Credit)，市场和销售上，基本上目前仍然是一个小公司作坊的性质—没有技术和市场主导能力来影响客户，而是被客户所挤压，为了获取底利润的订单，拼命的压低研发R&D的成本，从而能够维护其营业额的持续性增长。胡新宇就是在这样的环境下的工程师。理论而言，当一个高科技公司成长到数万之众，年营业额达到五十亿美金，公司的信誉和市场的领导能力已经建立起来。此话怎讲? 简单而言就是：一个客户宁愿多等待1到2个季度，也愿意采纳一个公司的产品发布。例如，一个行业的领导者可以是这样的一种企业战略：通过定期的访问其目前客户和将来可能的客户，非常明确的让客户知道公司产品的Roadmap，比如2个季度之后产品发布的时间和承诺拥有的新特性(feature)，4个季度之后产品发布的时间和承诺拥有的新特性。。。。在拥有强大研发实力和信誉的公司背景下，一个高科技公司就不会沦落为市场的奴隶，而是通过信誉和承诺等等来实现与客户的双赢。当然具备这样实力的公司的前提是：

* 相对完整的产品线。 *高利润 *强有力的研发实力和管理，定期的，持续性的产品发布。 *信誉和承诺

华为拥有了第一点，其他3点是目前并不存在的或需要提高的。

这就是华为的研发队伍经常出于疲于奔命的根本原因：华为目前还没有能力影响市场，从而其研发周期没有能力自主。

创立于1988年，目前华为挟数万之众，在深圳(总部)，北京，上海，南京，西安，成都，武汉，欧洲，独联体，北美，埃及，巴西，南非，马来西亚，印度，香港，韩国都有其研发中心，技术服务中心或办事处。

其产品线大致分为6大集团： WCDMA – 下一代网络 – 接入网络 – 光网络 – 数据通信 – 视频通信

华为公司提供的解决方案划分为：运营商解决方案，行业解决方案和家庭与个人解决方案。

运营商解决方案，分为：无线网络，固定网络和综合解决方案。

无线网络：WCDMA, CDMA2000, GSM,移动核心网，无线网络规划，3G业务解决方案

固定网络：下一代网络(NGN)，交换网络，接入网络，光网络，数据通信，视频通信

数字电视，固网终端综合解决方案：

IPTV， IMS业务解决方案，增值业务，运营支撑。

行业解决方案：

企业业务解决方案，中小型企业视讯解决方案，高清视讯解决方案

远程教育系统，多媒体通信解决方案，数据通信教育解决方案

数据通信企业解决方案，数据通信政府解决方案，电力行业解决方案

高速公路行业解决方案，社保行业解决方案，邮政行业解决方案

铁路行业解决方案，教育行业解决方案，公安行业解决方案

华为VoIP解决方案

家庭与个人解决方案：

数字家庭，手机

通过考察华为提供的解决方案，我们可以认为：

*华为的重点是运营商解决方案。

*行业解决方案中，除了VoIP，其他的基本上是接订单，搞网络集成，收费系统等的工程项目。换句话讲，是来一家，吃一家。吃完一家，少一家。。。

在运营商解决方案中，所谓的数据通信线，其主力应该是北研所。

从上诉可见，华为的结构很大，产品线铺垫的很广，地域分布也全球化了。

笔者的问题是：华为的最重要的资产是什么？“人才，21世纪最重要的资源就是人才!”。

对于华为，其人才的智力贡献体现在那里？

笔者说：就是那些千万行摸不着，但却看得见的ASIC芯片的RTL，板子的电路图和系统的C代码! 就是这些代码实现了其各个解决方案。

华为什么都可以没有，就是不能丢失上述的代码! 没有这些代码，华为什么都不是。

这些代码不是任正非能写的，不是那些高级副总裁能写的，是那些工程师们一年一年累计出来的，用他们的青春和汗水。。。。。。

既然我们知道华为最重要的就是那些代码，那么对这些代码的管理就是华为技术管理层面的一个非常重要的部分。管理的好，其代码质量，代码重用，代码维护，代码移植，代码优化，代码集成，代码升级等等都将顺利；否则，整个华为的智力大厦的”形而下”将是非常脆弱，千疮百孔。华为的系统将举步维艰，其”形而上”的目标，比如：国际化道路，高新技术研发，公司并购与集成等都将是非常难以达到的。

那么我们来推测华为的代码管理体制。

如果我们假设华为用CVS来控制代码。

从华为的产品线分布，我们基本上可以断言，华为不可能存在一个总体华为代码属（main-line codbase）。例如，我们可以称其为：”huaweios” ，既然不存在一个统一的”huaweios”CVS 根，节点那么华为的代码控制或布局应该可能是这样的。每个产品线存在一个main-line codbase节点。各个产品线的CVS节点基本上独立的，并行运作的。其版本发布周期是与各自的项目计划单独联系在一起的。从新闻媒体上可见的消息，我们看不出各个产品线的代码是有计划的定期升级的，或是周期性的有规律升级的，而是不定期的，不规则的，强依赖于各个项目发布而升级的。从胡新宇事件的分析，我们猜测了华为在市场压力下的工程部门的项目计划和管理：

–没有R&D的自主性和规律性的中长期计划(或处于经常被打断的中长期计划中)。以此推理，我们可以得出如下结论。

为了对付市场和销售部门临时而来的要求，工程部门不得不不断在其mail-line节点上开出CVS子节点(或我们说拉出一个CVS Branch)。然后，各个子项目分别在子节点上迅速的，拼命的赶工期，check-in 代码，QA测试，然后迅速做特殊发布（Special Release）。

发布后，其工程部门的售后服务，代码维护也不得不将在各个子节点上展开。我们不妨假设数通业务的代码节点是Tree_Data. 在某个时间点t0，数通的main-line release是 Tree_Data_t0. t0=2006_0628。版本是数通OS 1.0，不失一般性。

随著时间的推移，数通的代码节点就变成了这样一个(图论的)群。

Tree_Data_t0

—————————–Tree_Data_t0_1

—————————–Tree_Data_t0_2

Tree_Data_t1 …

—————————-Tree_Data_t0_N

—————————-Tree_Data_t1_1

—————————-Tree_Data_t1_2

…

—————————–Tree_Data_t1_N

…

Tree_Data_ti

——————————Tree_Data_t(i-1)_N-1

—————————–Tree_Data_t(i-1)_N

—————————–Tree_Data_ti_1

—————————–Tree_Data_ti_2

…

—————————–Tree_Data_ti_N

…

大家知道，Tree_Data_t0_(1–N)的东西是非常有可能没有回到Tree_Data的主Release Tree_Data_t1的。换句话讲，飘在往外的子节点的新代码，更重要的是那些从现场反馈回来的bug fix是很难及时回到main-line的。

随著Tree_Data_ti的主Release的增加，飘在外面子节点的增加，整个数通Tree_Data的代码维护，升级将变成一个恶梦。

一般而言，结果是这样的：由于为了对付特殊客户/订单，大量的CVS Branch的飘在主Release之外，同时主Release又必须在Internal R&D的定义下不断发布新的Release，整个代码的Feature Merge, Bug Duplicate, Bug Sync将成为不可控制，或将需要非常巨大的代价。代码管理者，包括研发人员，有时将不知道一个Bug Fix应该往那个子节点上放。然后，只能等待客户出一件事情，解决一件。疲于奔命。整个研发队伍将不得不花费巨大人力物力在售后技术维护上。其结果体现在CVS 节点上是，在每个Tree_Data_ti_j下面还会有Tree_Data_ti_j_patchk。每个patch是为了解决某个特定用户遇到的解决方案。

最后，数通的CVS节点结构将变成：

Tree_Data_t0

—————————–Tree_Data_t0_1

———————————————————Tree_Data_t0_1_patch1

———————————————————-

———————————————————-Tree_Data_t0_1_patchM

—————————–Tree_Data_t0_2

———————————————————-Tree_Data_t0_2_patch1

———————————————————-…

———————————————————-Tree_Data_t0_2_patchM

Tree_Data_t1 …

—————————-Tree_Data_t0_N

———————————————————-Tree_Data_t0_N_patch1

———————————————————–…

———————————————————–Tree_Data_t0_N_patchM

—————————-Tree_Data_t1_1

———————————————————-Tree_Data_t1_1_patch1

———————————————————- …

———————————————————-Tree_Data_t1_1_patchM

—————————-Tree_Data_t1_2

———————————————————-Tree_Data_t1_2_patch1

———————————————————–…

———————————————————-Tree_Data_t1_2_patchM

…

—————————–Tree_Data_t1_N

———————————————————–Tree_Data_t1_N_patch1

———————————————————–…

———————————————————–Tree_Data_t1_N_patchM

…

Tree_Data_ti

——————————Tree_Data_t(i-1)_N-1

———————————————————–Tree_Data_t(i-1)_( N-1)_patch1

———————————————————–

…

———————————————————–Tree_Data_t(i-1)_( N-1)_patchM

—————————–Tree_Data_t(i-1)_N

———————————————————-Tree_Data_t(i-1)_N_patch1

———————————————————–

…

———————————————————-Tree_Data_t(i-1)_N_patchM

—————————–Tree_Data_ti_1

———————————————————-Tree_Data_ti_1_patch1

———————————————————–

…

———————————————————-Tree_Data_ti_1_patchM

—————————–Tree_Data_ti_2

———————————————————-Tree_Data_ti_2_patch1

———————————————————-…

———————————————————-Tree_Data_ti_2_patchM

…

—————————–Tree_Data_ti_N

———————————————————–Tree_Data_ti_N_patch1

————————————————————

…

———————————————————–Tree_Data_ti_N_patchM

……

上述CVS节点结构分布是非常有可能的，特别是补丁部分基本上是为了特定客户的问题。在巨大项目短周期的压力下，华为如何可能保证代码的质量的高可靠性？我们基本上可以认为，许多Tree_Data_ti_j的发布是有许多问题（bug）的。华为只能通过巨大的人力物力，通过Tree_Data_ti_j_patchk的方式来解决客户问题，来做特殊发布。

另外，由于存在不同的新性能非常有可能在不同的子节点上实现。而各个子节点又是基于不同的Tree_Data_ti。从而使得不同的新性能的整合工作非常困难。

一次大的整合就是一个巨大的内部项目(Project)。花费6个月到1年一点也不过分。而且，

还将面临巨大的从新测试的代价。

这还是在谈论一个产品先内部(Intra-Productline)的代码管理。如果谈论产品线之间(Inter-Productline)的代码共享，重用，在上述猜测结论之下，基本上是没有任何可能。

结果是，华为内部产品线R&D研发之间存在巨大的重复性工作。任何一个互相产品(ASIC，板子，代码)共用的尝试，都面临著巨大的技术困难(我们先排除技术官僚体制在这其中的争权夺利的消极影响)。

目前，我们的推测结论是：华为的代码维护是一个，从图论的观点，群状结构，而不是一个随著固定时间间隔(比如3个月，或6个月)有限深度的移动树状结构。这种技术管理导致的代码管理，使得华为的智力基础基本上会面临有一天，或已经，变得不可控制的状态。。。。”

现在，让我们忘掉华为技术管理在整个华为体系中的被动，来看看那么华为的研发结构是如何的呢？

来考察一下华为从IBM学的IPD。

一方面由于《基本法》达不到预期的效果，而华为的人员规模，销售额更加庞大，1998年，华为与IBM公司合作启动了《IT策略与规划（IT S&P）》项目，开始规划华为未来3-5年需要开展的业务变革和IT项目，其中包括IPD（Integrated Product Development，集成产品开发）、ISC（Integrated Supply Chain，集成供应链）、IT系统重整、财务四统一等8个项目，IPD和ISC是其中的重点。2003年上半年，数十位IBM专家撤离华为，业务变革项目暂告一个段落。此次业务流程变革历时5年，耗资数亿元，涉及公司价值链的各个环节，是华为有史以来影响最为广泛、深远的一次管理变革。

理论上，IPD能够在研发前期就避免以前需要投入市场后才会暴露的重大问题。以前华为的产品开发都在中研部(中央研究部)，现在改由PDT(产品开发团队)来承担。每个产品都有各自的PDT，每一个PDT团队由研发、市场、财务、采购、用户服务、

生产等各部门抽调的代表组建，像一个个创业型小企业，从研发开始，对市场、利润、产品生命周期等全程负全部责任，共同协作完成一个产品从概念、研发，到生产、上市的全过程，从而真正实现产品研发和市场的同步进行。

中研部是华为头一个面临IPD挑战的部门。以前中研部全权负责研发，市场部门负责销售，中研部做什么，市场部门就卖什么。现在，产品做成什么样完全由不得研发人员，别人都得参与，而这些人以前都是和研发根本不搭界的人。新的运作流程变为，市场代表带着产品规格、技术参数等信息到市场上搜集客户反馈，据此考虑市场空间、客户需求的排序，哪些需求会对未来产品的市场潜力和竞争力产生重大影响等等。在市场人员的强烈参与下，产品的概念得以形成。接着，财务代表根据市场代表提供的市场数据算账：需投入多少研发工程师、仪器设备成本、制造成本、物料成本、产品生命周期内销售额、利润等，一份企业业计划书产生了，用以说服IPMT(投资管理委员会，分产品线设立，共有9个)同意为该产品投资。

华为实施IPD的效果任何呢?

一位参与华为IPD变革的华为员工说：执行IPD的基层管理者还没有完全认同IPD，或者是为了维护小集体利益，造成纵横制管理带来的多头领导，产品线和资源线可能为了各自利益，对处于交汇点上的人员提出不同甚至相互矛盾的工作牵引，使得产品线人员经常感到无所适从。

5年时间过去了。华为聘请IBM的专家给自己的各个部门做管理评分（TPM），以满分5分计，华为2003年的平均分只有1.8，2004年上半年才达到2.3，而2004年的目标是2.7。按照IBM的意见，一家真正管理高效规范的跨国公司，其TPM分值应达到3.5。另外，根据IBM专家的评测，华为人均工作效率只有国际一流公司的1/2.5。华为副总徐直军对此结果并不满意。

IPD顾问说要追求效率，控制成本，但华为今年的市场投入依然是不计成本；后方的产品线改来改去，一线的办事处该怎么干还怎么干；IPD顾问说产品需要严格按照IPD模式进行规范研发，但在2001年，当某高端路由器产品出手速度落伍于竞争对手时，任正非一声令下，所有程序打乱，突击搞研发，产品得以在极短时间内铺向市场。。。。”

读者读到这里，大概能得出许多结论了。

1。知道胡是如何累死的了。

2。华为的研发(R&D)只有D没有R。基本上是被市场，销售，售后服务赶着走。

对于华为具体而言，其产品属于信息产业的通信领域。如果没有强大的研发(R&D)中的研(R)，而只有D，随着技术的发展，华为和其类似的公司的技术和产品已经或正逐步变成commodity(日用品)。Commodity是常被用来描述一个技术产品的门槛已经变得非常低的时候的术语。

当一个高科技产品已经快变成日用品的时候，靠卖这个产品的利润(margin)将变得非常小。只能靠量(volume)来获得利润。

比如，现在构建一个中低端router, switch, firewall/vpn产品，是一个非常容易的事情。

–操作系统是免费的。GPL or BSD License.

–网络处理器是便宜的。另外，华为狂用Intel的xscale core的IXP系列。

–高端CPU是可以买的。。。

–网络协议stack是免费的. GPL or BSD License.

–应用程序(BGP, OSFP,,,,Firewall, IPSEC, SSL, IDS, AV…..You name it)是免费的。GPL or BSD License.

–硬件开发版是可以outsourcing的。台湾无数小公司在做。