时隔5年，任正非再一次要炸掉华为研发金字塔（附全文）

程序员求职简历，项目经验怎么写？免费修改简历、提供模板并内部推荐

最近华为内部员工社区平台“心声社区”时隔5年又转发了一遍2016年的文章《华为到了该炸掉研发金字塔的时候了》及评论，在互联网引发热议。

这篇文章并不是任正非写的，而是一个署名为“泥瓦客”的程序员写的，泥瓦客从组织、流程、环境、工具等四方面谈到了华为研发系统的问题，阐述了自己对华为软件研发效率与质量提升的思考。

任正非签发时说：在技术工作的客气是毒品，直面的批评、争论才是良药。表明了任正非也认可文章中提到的研发系统上问题，并下决心推动组织变革，直面批评去解决问题。

华为重新转发这篇文章的2天前，8月6日，刚刚发布上半年经营业绩。上半年，华为实现销售收入3204亿元人民币，净利润率为9.8%。但消费者业务受到明显影响，今年上半年，华为消费者业务收入为1357亿元，同比下降46.95%。

而时隔5年，华为官方再次转发文章及任正非的评论，可能是华为又遇到了新的课题与挑战，或者发现革命尚未成功，5年前的问题如今很多依旧存在。具体情况如何，作为外人就不得而知。

不过作为程序员，我看到这篇文章真的感慨良多。这篇文章说的很多都并不是华为特有的现象，而是整个互联网圈的通用问题。

比如：架构师和技术专家整天开会，脱离编码一线，完全不懂开发；有能力的优秀的程序员都转管理了，真正编码的都是低级别程序员，很难有技术积累；白天开会，晚上写代码，没有时间抬头看路。

真的很多观点都说到程序员的心坎上了，我自己是反复读了好几遍。我觉得作为程序员或者互联网工作人员，认真读一读这篇文章肯定会有所收获。如果是互联网行业的管理人员，那更应好好读一下这篇文章，想想自己的团队是否存在同样的问题，如何把这些问题解决掉。

所以，我把全文给大家整理了一下，我个人觉得好的观点和内容，已经给大家加粗了。

全文如下：

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

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

作者：泥瓦客

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

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

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

01

组织

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、沟通成本高

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

02

流程

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

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

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

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

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

03

环境

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 岁左右已经有了非常高的技术职级和地位。

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

04

工具

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 作为学习和资源分享不可分割的一部分。

推荐阅读：

程序员的“三十而已”

《无bug经》，转发无bug！

---

你好，我是云峰小罗，毕业于国防科大，已在腾讯和百度搬砖10年，是35项互联网技术相关专利的发明人，是一个信奉终身成长的职场人。

小罗也是一个不错的段子手哦，会朋友圈经常发一下有趣事情或者小罗对这个世界的看法，欢迎加我微信围观朋友圈、一起交流、或者找我内推。

微信已将好友数放开到1万了，小伙伴们又可以加我微信了，先到先得！2021，抱团取暖，一起牛逼。