任正非5年后重新强调：华为到了炸研发金字塔的时候

任正非

日前，华为心声社区时隔5年再次转发华为创始人兼总裁任正非2016年签发的邮件《华为到该炸掉研发金字塔的时候了》。

一名华为研发员工在这篇文章中表示，华为在软件研发领域存在不少问题，这些问题导致华为的IT软件产品质量比较低下、开发效率低、产品交付周期漫长，让人痛心。

该文章的再次签发，是基于近期华为刚公布的经营业绩。

今年上半年，华为实现销售收入3204亿元人民币，净利润率为9.8％；但消费者业务受到外部影响，收入为1357亿元，同比降幅达46.95％。

今年以来，华为的手机出货量更是显著下滑。一季度，华为手机出货量跌出全球排名前五名。据市场研究机构Omdia7月底发布的报告显示，目前，华为出货仍在持续下滑。今年第二季度，华为出货980万部，同比下降了74.6%，环比下降了33.3%。

从市场格局来看，尽管华为依旧以2450万部位列第六，但今年上半年，华为已经因为外部原因与同期相比下降了三分之二，目前全球前五分别是三星、小米、苹果、OPPO、vivo，华为七年来首次跌破前五名。

这也意味着，过去，以硬件收入为主的华为，不得不增加软件方面的投入，扩大软件服务业务，从而降低对芯片的依赖。

而5年来，华为从前面临的软件研发问题，至今未能得到解决。当此之时，重提炸掉软件研发金字塔，恰逢其时。

研发问题：多头管理、晋升困难、研发环节脱离

这篇题为《华为到该炸掉研发金字塔的时候了》的作者，网名“泥瓦客”，曾在美国硅谷工作，与世界顶级软件工程师共事，也带领团队交付了许多企业级软件产品。2016年之前的几年，泥瓦客进入华为，后来于2016年写下此文，并获得了任正非认可，分享给了全体员工。

泥瓦客谈到，在华为做了几年的企业服务后，他感受到华为公司在软件产业方面，与世界领先水平差异较大；与中国领先的互联网产品相比，也存在易用性、贴近用户和产品快速迭代方面的差距。华为在软件研发领域存在的问题，导致了IT软件产品质量比较低下、开发效率低、产品交付周期漫长。

在组织架构方面，泥瓦客认为，华为主要存在的问题在以下三方面：

1、架构设计SE与开发分离：一些架构师与专家基本不懂开发，造成了设计与开发环节之间的脱节，而在硅谷公司，好的架构设计师一般随时能上手编程，且编程能力很强。

2、开发者多为低级别，比较难有技术积累：一般基层程序员在工作几年后，都会升值、加薪，成为管理者，一直做开发就会在金字塔的底层；但在硅谷，收入较高、说话有分量的是各层级中的技术佼佼者，因此技术人员不容易流失。

3、多头管理、沟通成本高：不同的经理在产品开发过程中有不同的想法和意见，可能出现多头指挥，让开发人员无所适从，沟通的成本也大。这种复杂的结构会对IT软件开发带来很大制约。

作者还表示，开发员工长期在上述流程、组织问题和客户支持的压力下加班加点，几乎没有时间“抬头看路”。技术任职上升通道不佳，论资排辈现象严重，需要完善奖励机制。

任正非回应：直面批评、争论才是良药

对于泥瓦客的观察和建议，任正非回应称：“在技术工作的客气是毒品，直面的批评、争论才是良药。”

总裁办电邮

丁耘也在编者按中提到，华为要清晰地认识到，面向ICT融合时在软件能力、效率和质量方面存在的挑战，在组织流程、作业环境等多方面存在的或多或少不适应性和问题。尽管华为在参考业界、反思自己的基础上，开展了软件能力建设并取得了部分进展，但要实现期望的目标还需要持续做出更大的努力。

针对该文，员工也发表了一些各自的观点。

有员工表示，整体观点还是同意的，部分点比如网络权限、开发流程、工具等现在很多部门已经优化了，跟互联网公司也差距不大了，不过随着公司整体对IT化的思考，应该会越来越好，部分部门有可能在2-5年内赶上业界主流互联网公司的研发效率。

也有华为员工表示，研发团队可以考虑采用两套流程，偏硬的使用IPD，按传统的重组织架构保收入，纯软的偏互联网化的用敏捷的团队管理，避免一刀切。

还有的员工提到，要转变开发模式，就要改变作战模式，把大规模的项目模式改成一个个小团队作战，就不再需要如此多的技术管理者了，也就是扁平化管理。

华为未来重点：鸿蒙系统和车联网

华为此时再次转发5年前的文章，显然是要强调其从硬件为主的公司，想要转变为更加重视软件研发的企业。

4月中旬，华为轮值董事长徐直军在2021年华为分析师大会上表示，华为面向未来的关键战略举措之一是优化产业组合，增强产业韧性，包括三项具体措施：一是强化软件；二是开创和加大对于先进工艺依赖性相对较低的产业的投资；三是持续加大智能汽车部件产业的投资，尤其是自动驾驶软件。

分析人士普遍认为，定位为IoT操作系统的鸿蒙，将成为支撑消费者业务的重要动力。

从2019年正式发布HarmonyOS至今，华为在两年时间里加快推进HarmonyOS落地。截至2021年6月，已经有300+应用和服务、1000+硬件、50万+开发者共同参与到鸿蒙生态建设当中。

华为的鸿蒙操作系统，不仅可以解决手机操作系统问题，还是华为消费者业务“全场景智慧生活战略”的核心抓手，也可能是国产操作系统弯道超车海外传统厂商的机会。

此外，在车联网方面，据了解，华为与车企的合作方式主要有3种：定位为智能化零部件供应商，直接向车企提供智能汽车软硬件智能化产品；定位为车企平台化产品及服务提供商，向车企提供多款智能汽车软硬件产品组合；定位为智能汽车全栈式解决方案提供商，向车企提供华为Inside。

目前，华为已推出30余款智能汽车软硬件产品，覆盖激光雷达、车载芯片、鸿蒙OS车机系统、自动驾驶软件等。在中信证券看来，华为赋能的相关车企，在中国市场有望拿到20%至30%市场份额。

华为多年来一直坚持对研发领域的投入，过去3年，华为把每年近15%的收入投入到研发领域。今年，还会继续加大研发投入。

（钛媒体APP编辑陶淘综合自每日经济新闻、北京晚报、中国经济周刊）

以下为内部信全文：

总 裁 办 电 子 邮 件

电邮其他【2016】071号 签发人：任正非

转发《华为到该炸掉研发金字塔的时候了》及评论

按1：在技术工作的客气是毒品，直面的批评、争论才是良药。

丁耘按2：我们在CT领域取得的产品成功不是未来可靠的向导，我们必须要持续进步才能适应时代的客户需求、才能获得未来的发展。我们要清晰地认识到，面向ICT融合，在软件能力、效率和质量方面存在的挑战，在组织流程、作业环境等多方面存在的或多或少的不适应性和问题。尽管我们在参考业界、反思自己的基础上，开展了软件能力建设并取得了部分进展，但要实现我们期望的目标还需要持续做出更大的努力，需要生产力持续的提高，在此过程中我们各级主管和专家在思想意识和行为技能上的转变是关键。期望各级主管和专家阅读所附文章，不局限于文章中提到的问题建议，深入讨论影响软件研发效率、质量、业务发展的问题，讨论中多审视自己、少抱怨别人，天底下容易的是指责别人，难的是改变自己。组织的生命力恰恰在于自我进化能力。我们既需要坐而言，更需要起而行，从自己做起，坚持以客户为中心，通过点点滴滴、持之以恒的努力，持续有效改进，静水潜流实现ICT成功的转型。

华为到该炸掉研发金字塔的时候了

----关于我司软件研发效率与质量提升的思考

作者：泥瓦客

近年，在从CT到ICT的转型的过程中，华为公司的研发如何能解放和发展生产力，大幅提升研发效率，是我们未来能否立足于强者之林的一个关键。

笔者以前曾在美国硅谷工作，和世界上最顶尖的软件工程师和计算机领域的牛人一起共事过，也先后带领过不同的团队交付了一些业界领先的企业级软件产品。几年前进入华为，和几个做企业业务的产品线有些合作，在此过程中感到华为公司在软件产业的差距还比较大；和中国领先的互联网产品相比，在易用性、贴近用户和产品快速迭代等方面也落后不少。我们在软件研发领域的确存在不少问题，这些问题导致我们的IT软件产品质量比较低下、开发效率低、产品交付周期漫长，很是让人痛心。

因此笔者写下了这篇文章，希望能抛砖引玉，供大家思考。

一、组织

1、架构设计SE与开发分离，一些架构师与专家基本不懂开发

一般各个产品线都会设有架构设计部，主要成员也会以各个层次的SE为主。这些SE也都曾是程序员，但通常因为长期脱离开发部门，主要精力都放在会议、胶片和文档的编写上，以致编程的能力基本丢失，新技术学习的机会也有限。例如一个移动开发的SE，自己对怎么在Android、iOS上进行开发一点儿都不清楚。在这样的基础上，做好真正的架构简直是空谈。在硅谷成功的公司里，好的架构设计师一般是融入在产品团队中的，随时都能上手编程，而且编程能力非常强。

2、开发者多为低级别，比较难有技术积累

一般基层程序员在工作几年后，有能力的都被提升到PL、PM、SE等职位，员工也都想着被提拔，渐渐成为管理者。大家觉得，光做开发没有职业前途，永远都是在金字塔的底层。而在硅谷的公司，说话比较有分量、收入相对较高的有很多是在各层级中的技术佼佼者，他们备受尊重，干得也开心，不少人根本不愿意转做管理者。

编程其实是一门艺术，热爱和用心是非常重要的，也相应的容易出成绩。这就是为什么在计算机领域，如果做到顶尖程序员，一个人顶一百个很正常。如果程序员觉得没有前途，不思进取，而资质较好的很快又被提拔为管理者，那我们的软件开发将很难有技术和人才的积累。

3、多头管理

我司负责产品开发的部门有PDT、PDU等，相应的拥有PDT经理、PDU经理、架设部经理和SE、Project Manager、PO经理、RDPDT经理、Line Manager、Project Leader等多个角色。这种组织结构清晰地定义了每个Leader的角色，确保一个大的产品开发周期和质量有保证，同时保证开发的人力得到最合理的应用。

但它带来的问题也显而易见，就是各个角色在产品开发过程中有不同的想法和意见，可能出现多头指挥，让开发人员无所适从，沟通的成本也非常大。同时，这种复杂的管理结构对需要快速迭代的IT软件开发也会带来很大制约。大家看看微信的起家史，应该能感觉到，对于一些相对独立的、需要快速迭代的IT软件产品，往往在一个比较强的（产品）经理带领下的一个扁平化的团队效率会高很多。

4、沟通成本高

由于组织复杂，中间层较多，各种各样的任务从上面下来，落实的方法就是各种各样的会议，所以现在很多研发员工的不少时间都被各种各样的规划、研讨、问题回溯、客户支持等会议占用。员工笑称：白天是用来开会的，晚上加班才有时间编程序。针对于不同的组织和项目，能尽快找出相应的沟通节点并能有效地减少这些沟通节点，是一个项目和部门领导需要经常思考的问题。

二、流程

1、IPD流程不太适合需要快速迭代的软件

公司引入的IPD产品开发交付流程给公司带来了巨大的收益。但时代在发展，技术在演进，IPD流程更适合偏硬件的产品开发，为了保障产品质量，开发交付的周期较为漫长。从基层员工的角度，IPD流程节点的很多环节，如为完成CLINT减少Warning的数字、DTS值减少等僵化的指标，实际上反而可能会加大产品的风险，降低产品质量。

2、安全红线耗费资源巨大

安全红线的目的是防止产品出现安全漏洞，初衷是好的，但执行起来相对比较僵化，效率也低。试想一个互联网产品为了过安全红线一个版本等一两个月，根本无法生存。

建议参照一些先进公司的方法，把安全意识教育和SDLC（安全开发生命周期）融入到员工日常开发习惯中，在开发的同时进行测试和督促整改，对于一些红线达标比较好的部门，可以适当放松以加快交付，检查出问题，相应的问责机制要严格。把安全意识充分融入到开发者的血液中，让安全红线检查“形同虚设”。

三、环境

1、没有时间抬头看路

开发员工长期在上述流程、组织问题和客户支持的压力下加班加点，几乎没有时间“抬头看路”，只会用一些比较老旧的技术，也不太会站在巨人的肩膀上前进，走了不少弯路，消耗了更多的资源。

互联网时代，MOOC提供了大量实时、实用、先进的网上课程（包括免费的和收费的），如Coursera、Udemy、Pluralsight、Stanford Online、edX、YouTube相应的Channel等，想要学的课程几乎什么都有。

现在的计算机技术日新月异，新的思想、方法、工具等层出不穷，例如Java语言是2000年左右在企业软件领域崛起的，几乎成为很多平台、服务端软件的必选，但随着大规模分布式架构、云计算的兴起，它的短板，如内存管理/GC不可控性、多线程或是异步对IO的控制效率，过度依赖较为重载的OOP等问题，如果使用不当很容易造成灾难性问题。Google内部渐渐把它们有些后台软件都迁移到了他们自己发明的更为先进的Go语言环境下。Dropbox更是两年前开始使用了比Go还先进的Rust语言，无缝迁移了90%以上的云存储平台。试问，我司有几个人用过甚至是听说过这些语言？我们的研发员工如果不去不断地提升，怎么可能赶上时代的步伐？怎么能开发出质量好的产品？

2、技术任职资格效果不佳，传帮带困难

理论上，技术任职资格是用来给搞技术的人提供晋升通道的。但实际应用上，虽然有破格提拔机制，总体上还是按资排辈，评委也大多是由有较高级别技术任职资格，但对现在技术并不太了解的管理者担当。

同时，任职从申请、技能鉴定考试到做答辩胶片、答辩，消耗了员工不少时间和精力。硅谷的公司一般在这方面比较灵活，技术通道由360 Review和与其工作密切相关的主管直接评价、申请和授予，有些员工在28-33岁左右已经有了非常高的技术职级和地位。

因为技术晋升通道不顺畅，能力较强的员工渐渐离开了开发岗位，较多时间沉浸在文档、胶片和会议中，新来的年轻员工过几年又在走同一个循环。是否可以彻底打通技术升值通道，鼓励有能力的人带新人，同时完善奖励机制，在及时激励和长期激励上下功夫，让研发人员看到技术发展空间，乐于编码，留住人才。

四、工具

1、研发办公环境

在硅谷先进的软件公司里，MacBook Pro/Air是标准配置，方便携带，随时随地编程。很多软件及移动开发调试都在家里、公司、食堂随时可以进行，包括编程、编译、Review和提交；数据库、各种Library、工具和Docker等都可以在本地的OSX/Linux环境下运行。需要的话，也随时可以跟公司内部服务器通过命令行互联，进行文件、代码的传输和测试。

笔者在硅谷工作时认识一个美国小伙子，他基本都是深夜在家里写代码，白天几乎看不到人，但效率和质量都很高。而我们的大部分研发人员，都被局限在公司内部拥挤嘈杂的敏捷岛，用着桌面云进行着低效开发。

2、代码库管理、Review、Checkin和Bug Tracking工具

基于Web/Git的Review和Checkin的相应工具差距非常大。通过源程序的Review审批和Checkin的机制，可以很快传递能力和互相学习，提升代码质量。同时，在任何一个时间点，任何一个高级工程师或是领导都可以通过这些工具来了解员工真正在代码上的贡献和价值，审查进度和版本分支，进度和质量也好把握。以笔者的经验，这是最好的传递技能的工具之一，往往有一个能人，很快就能把一批年轻人的能力带起来。

我司一般用的是内部开发的DTS bug tracking的工具，比较死板，总体和上述提到的最新的Git源程序管理工具、Review工具、自动化和Nightly Build、敏捷管理工具无法无缝地连接在一起。

3、知识资源的获取

由于公司内网Proxy权限问题和受限于大家英语水平的原因，大部分员工还是习惯于使用百度进行程序、库、方法和问题的搜索。但由于共享性差，同时技术水平与美国相差比较大，所有能在百度上找到的好的资源非常有限，质量也较差。美国软件开发人员已经把诸如StackOverflow、GitHub和Google作为学习和资源分享不可分割的一部分。

更多精彩内容，关注钛媒体微信号（ID：taimeiti），或者下载钛媒体App