一位硅谷海归在新生社区发表《华为是时候炸掉研发金字塔了》，引发华为内部关注和反思。 任正非亲自添加了注释，并以电子邮件文件的形式发送给全体员工学习。 虽然这件事已经发生四年了，但仍然存在很多问题。
任正非注：在技术工作中，礼貌是一剂药，而直接的批评和争议是最好的药。
丁云注：我们的产品在CT领域的成功并不是未来的可靠指南。 我们必须不断进取，以适应时代客户的需求，实现未来的发展。 我们必须清醒地认识到，面对ICT融合，存在软件能力、效率和质量方面的挑战，也存在组织流程、运营环境等方面或多或少的不兼容和问题。 虽然我们在参考行业、反思自己的基础上，进行了软件能力建设，取得了一些进展，但要达到我们预期的目标，我们还需要继续付出更大的努力，继续提高生产力。 在这个过程中，我们各级管理人员和专家的思想和行为能力的转变是关键。
希望各级主管和专家阅读所附文章，不仅仅是文章中提到的问题和建议，还要深入讨论影响软件开发效率、质量和业务发展的问题。 在讨论的过程中，我们应该多审视自己，少抱怨别人。 这在世界上会很容易。 责备别人是很困难的，但改变自己却很难。 组织的生命力恰恰在于其自我进化的能力。 我们不仅需要坐下来谈论，更需要站起来采取行动。 我们需要从自身做起，坚持以客户为中心，通过一点一滴、持之以恒的努力，不断做出有效的改进，实现ICT转型的成功。
华为是时候炸掉研发金字塔了
——关于提高我国软件研发效率和质量的思考
石匠
近年来，在从CT向ICT转型的过程中，华为研发如何解放和发展生产力，大幅提升研发效率，是未来能否跻身强者世界的关键。
作者此前曾在美国硅谷工作，与计算机领域的世界顶尖软件工程师和大师一起工作。 我还带领不同的团队交付了一些业界领先的企业级软件产品。 我几年前加入华为，与企业业务的多个产品线有过合作。 在这个过程中，我感觉华为在软件行业还有很大的差距； 与中国领先的互联网产品相比，在易用性、贴近用户、产品快速迭代等方面也存在差距。 我们在软件研发领域确实存在很多问题。 这些问题导致我们的IT软件产品质量比较低，开发效率低，产品交付周期长，令人非常苦恼。
因此，笔者写下这篇文章，希望能为大家的思考提供一些启发。
1. 组织机构
1.架构设计SE与开发分离。 有些架构师、专家基本上不懂开发。
一般每个产品线都会有一个架构设计部门，主要成员都是各级SE。 这些SE都是程序员，但通常因为长期离开开发部门，主要精力放在开会、拍电影、写文档上，这样他们的编程技能就基本丧失了，学习新技术的机会也少了。也有限。 例如，开发移动设备的SE不知道如何在iOS上进行开发。 在此基础上构建一个真正的架构简直就是说说而已。 在硅谷成功的公司中，优秀的架构师通常会融入到产品团队中，随时可以开始编程，并且拥有非常强的编程能力。
2. 大部分开发人员水平较低，技能积累困难。
一般来说，有能力的程序员在基层工作几年后，就会晋升到PL、PM、SE等职位。 员工也希望得到晋升，逐渐成为管理者。 大家都觉得只做发展是没有职业前途的，永远处于金字塔的最底层。 在硅谷的公司里，说话比较有分量、收入相对较高的人很多都是各级技术带头人。 他们受到高度尊重，工作愉快。 很多人根本不愿意成为管理者。
编程实际上是一门艺术。 热爱和奉献很重要，也很容易取得成果。 这就是为什么在计算机领域，如果你是顶尖的程序员，一人胜过百，也是很正常的事情。 如果程序员觉得没有前途，不愿意上进，而资历较好的又迅速晋升为经理，那么我们的软件开发就很难积累技术和人才。
3、多头管理
我们公司负责产品开发的部门有PDT、PDU等，对应有PDT经理、PDU经理、安装部经理、SE、PO经理、RPDDT经理、Line等多个角色。这个组织架构明确界定了每个角色，保证产品开发周期大和质量保证，同时保证开发人力得到最合理的利用。
但它带来的问题也很明显，那就是产品开发过程中每个角色都有不同的想法和意见，而且可能存在多个方向，让开发人员无所适从，沟通的成本也很高。很高。 同时，这种复杂的管理架构也会给需要快速迭代的IT软件开发带来很大的制约。 如果你看看微信的历史，你应该能感觉到，对于一些相对独立、需要快速迭代的IT软件产品来说，一个相对强势的（产品）经理带领的扁平化团队会高效很多。
4、沟通成本高
由于组织复杂，中间层多，各种任务自上而下，实施方式就是各种会议。 因此，现在很多研发员工大量的时间都被各种计划、讨论、问题评审、客户支持等会议所占据。 员工开玩笑说：白天开会用它，晚上加班才有时间编程。 对于不同的组织和项目，能够尽快找到相应的沟通节点，并有效减少这些沟通节点，是项目和部门领导需要经常思考的问题。
2. 流程
1、IPD流程不适合需要快速迭代的软件。
公司推出的IPD产品开发和交付流程给公司带来了巨大的效益。 然而，时代在发展，技术在进步。 IPD流程更适合面向硬件的产品开发。 为了保证产品质量，开发和交付周期相对较长。 从基层员工的角度来看，IPD流程节点中的很多环节，比如完成CLINT的数量减少、DTS值的减少等硬性指标，实际上可能会增加产品风险，降低产品质量。
2、安全红线消耗巨大资源
安全红线的目的是防止产品出现安全漏洞。 初衷是好的，但执行起来比较僵化，效率低下。 试想一下，如果一个互联网产品要等一两个月才有一个版本过了安全红线，那它根本就活不下去了。
建议参考一些先进企业的方法，将安全意识教育和SDLC（安全开发生命周期）融入员工日常开发习惯，边开发边测试、督促整改，对一些红线较好的部门适当放宽标准。 为了加快交付速度和发现问题，相应的问责机制必须严格。 将安全意识充分融入开发者的血液中，让安全红线检查“形同虚设”。
3、环境
1. 没有时间抬头看路
开发员工长期顶着上述流程、组织问题和客户支持的压力加班加点。 他们几乎没有时间“抬头看路”。 他们只使用一些较旧的技术，不太可能站在巨人的肩膀上前进。 走了很多弯路，消耗了更多的资源。
互联网时代，MOOC提供了大量实时、实用、高级的在线课程（有免费的也有付费的），比如Udemy、edX、相应的等等，你想学的课程几乎都有。
当今的计算机技术日新月异，新的思想、方法、工具等层出不穷。 例如，Java语言在2000年左右出现在企业软件领域，几乎成为许多平台和服务器端软件的必备。 然而，随着大规模分布式架构的出现、云计算的兴起，其缺点，如内存管理/GC不可控、多线程或异步IO控制效率低、过度依赖更重载的OOP等问题，如果使用不当很容易造成灾难性的问题。 在内部，他们逐渐将一些后端软件迁移到他们发明的更先进的Go语言环境中。 两年前，我们开始使用比 Go 更先进的 Rust 语言，无缝迁移了 90% 以上的云存储平台。 我想问一下，我们公司有多少人使用过甚至听说过这些语言？ 我们的研发人员如果不不断进步，怎么能跟上时代的步伐呢？ 怎样才能开发出优质的产品呢？
2、技术资质不实效，传授指导困难。
理论上，技术资格是用来为技术人员提供晋升渠道的。 但在实际应用中，虽然有特殊的晋升机制，但排名一般是按资历进行的，评委大多是具有较高技术资历但对现有技术了解不多的管理人员。
同时，从申请、技能鉴定考试到答辩片、答辩的过程消耗了员工大量的时间和精力。 硅谷的公司在这方面普遍比较灵活。 技术渠道由360及与其工作密切相关的主管直接考核、申请和奖励。 有些员工在28-33岁左右就已经具有很高的技术职级和地位。
由于技术晋升之路并不顺利，更有能力的员工逐渐离开开发岗位，更多的时间沉浸在文档、电影、会议中。 几年后，新加入的年轻员工将再次经历同样的循环。 能否彻底打通技术升值通道，鼓励能者引进新人，完善奖励机制，在及时激励和长期激励上下功夫，让研发人员看到技术发展的空间，肯写代码，留住人才。
4. 工具
1、研发办公环境
在硅谷的先进软件公司，Pro/Air是标准配置，方便携带，随时随地编程。 很多软件和移动端的开发和调试都可以在家里、公司、食堂随时进行，包括编程、编译、提交； 数据库、各种工具等都可以在本地OSX/Linux环境中运行。 如果有需要，您可以随时通过命令行连接到公司内部服务器，传输和测试文件和代码。
我在硅谷工作的时候，认识了一位美国年轻人。 他基本上都是深夜在家写代码。 白天他几乎见不到任何人，但他的效率和质量却很高。 我们大部分研发人员都被限制在公司内部拥挤嘈杂的敏捷岛上，利用桌面云进行低效开发。
2. 代码库管理和bug工具
基于Web/Git的相应工具差距非常大。 通过源程序的审批和审批机制，可以快速传递能力，实现相互学习，提高代码质量。 同时，在任何时间点，任何高级工程师或领导都可以使用这些工具了解员工在代码中的真实贡献和价值，查看进度和版本分支，轻松掌握进度和质量。 根据作者的经验，这是转移技能的最佳工具之一。 往往一个有能力的人，可以很快带动一群年轻人的能力。
我们公司一般采用内部开发的DTS bug工具，比较死板，一般无法与上面提到的最新的Git源程序管理工具、工具、自动化、Build、敏捷管理工具无缝对接。
3、知识资源的获取
由于公司内网Proxy权限问题以及大家英语水平的限制，大部分员工还是习惯使用百度来搜索程序、库、方法和问题。 但由于共享性差，技术水平与美国差距较大，所以在百度上能找到的好资源非常有限，而且质量较差。 美国软件开发人员已将 、 、 和 等工具视为学习和资源共享不可或缺的一部分。
