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

（原标题：华为到该炸掉研发金字塔的时候了）

近日，华为内部刊发任正非2016年签发的总裁办电子邮件《华为到该炸掉研发金字塔的时候了》。

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

紧接着，其他评论被推上了顶条。

讨论非常激烈。

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

管报、微信、心声社区网友评论摘录：

1、整体观点还是同意的，部分点比如网络权限、开发流程、工具等现在很多部门已经优化了，跟互联网公司也差距不大了，不过管理团队臃肿与问责机制的严苛，跨部门沟通成本高，安全红线与IPD流程的繁琐确实仍是相对严重的问题。不过随着公司整体对IT化的思考，应该会越来越好，部分部门有可能在2－5年内赶上业界主流互联网公司的研发效率。

2、很多研发的同学都抱怨过，聪明的人都去做管理了。根源还是研发团队的作战方式。一个项目需要那么多人，必然需要有管理，就有所谓的管理者，管的人越多，管理者做技术的时间越少。要转变开发的模式，班长的战争。如果都是一个个的小团队，就不需要那么多的所谓的技术管理者了。

3、这些问题其实5，6年前我们内部早已经发现，如今从一个外界来的专家身上也提出了。因为以前我们的人员、组织快速膨胀，其中最难的问题：骨干员工都提拔去当官、当专家、专家不碰代码的情况确实存在。随着这两年我们的人员、组织逐渐稳定、任职上的牵引，让骨干员工深耕一线开发岗位，核心骨干负责架构代码、核心模块代码、产品的设计正在成为现实，只要坚持下去，研发扁平化组织我们也会实现。

4、总体陈述较客观。不过华为毕竟是硬件公司，任总说改进也最好是小步前进。企业网项目将是后起之秀，现在比消费者项目稍微落后点，请你海归回来也是想获得些新的理念获得改进提高，但炸掉研发金字塔有些过火。

5、这是由华为公司两大基因决定的！

基因一： 基于不信任的管理

假定了一个团队或者一个员工个体，没有办法自动地按要求完成任务，一定要有外力的干预和指导，才能保证航行在正确的轨道上。不信任的假定，造成了领导很焦虑，员工被干扰。领导焦虑哪一步没看住就要出问题，所以比如各种对齐，各种进展报告，各种回溯会。然后制定各种管控流程（包括IPD），设定各种管控角色，这些东西都需要员工参与，员工就写胶片开会，为各种流程上缴交付件，向各种管控角色汇报。话分两头讲，这一点也不能说是领导完全不对，他其实触动了华为的另一个“传统”（这段可能有些人不爱听）。我们设想一下，文中提到的那个白天不出现，晚上写代码的哥们，怎么保证他是按需求和设计在编码的呢？怎么审计？怎么考核？怎么跟踪？其实答案很简单，那个哥们必定是个极客，而极客是免运维的。而我司的研发定位，绝大部分基本就是程序员而已，这能不管理吗？这就像手动挡和自动挡，既然选择了开手动，那为了适应不同速度的换挡干预就是必不可少的，否则起步后永远挂1挡就是快不了。现状嘛，我司是需要大量手动挡的开发人员，只要按部就班做好自己的事情就行，这是批量化标准化作业的要求。极客嘛，当然也是需要的，但很少，这些人单独管理就行。我觉得公司推了这么多年的所谓敏捷开发流程，其实也是要建立在精英团队基础上，几个人简单思想一碰撞，各自都能清楚的理解和心中有数，就能按时完成任务对接起来，这是很高技巧的，也不是2，3年能掌握的，如果一个团队大部分员工刚写了2年代码，工作还需要别人指导，早上像模像样的开个早会，会上各种问题从9点开到11点，这不叫早会，这叫罚站。这也不叫敏捷，这叫保姆式开发。

基因二：组织复杂，各自为政

华为缺少扁平化管理，层级多，通道多。这样复杂的组织机构，造成了信息沟通对齐非常困难，每个组织机构又有自己的考评，都要考虑自己的团队建设和发展，价值呈现。人都有趋利的本性，必然会希望更多坚持对自己发展和价值有利的，而放弃那种不太出彩又要大体力投入的。但活在那里，总要有人干，很多事情都不是一两个leader能确定的，小leader也不能什么事都升级给大leader，显得自己无能。于是就讨论划域定界再讨论争议升级开会对齐拉通再讨论裁决拍板……甚至于，这种决策过程花费的人力和时间甚至超过真正做事情本身。这还是组织自上而下没太大分歧的情况。如果赶上不同通道的组织之间分歧很大，那决策和研讨时间又要再翻几倍了。我甚至见过有领导感叹自己指挥不动下面的人的情况，并不是因为指挥不动，而是多个通道的要求不同，下面不确定要怎么动。其实话说回来，说难听点，这叫多头管理多通道管理，说好听一点，这不就是管理上的民主吗？因为民主，所以才争吵啊，所以才决策慢啊，要是一个老专家或者老领导一发话，大家都照办，那是效率高，是不是又要有人抱怨专政了？

这两个基因，在华为这种大公司，不太可能改变掉，局部试点是有可能的，比如搞搞精英团队，或者在某些项目上试点扁平化，都是有可能的，至于全面改变，不现实。而且真的改成那个样子，还指不定出什么更大篓子。

6、首先肯定要直面批评。但是：1）不能用纯软件互联网公司的开发模式来套用一个有深厚硬件开发任务的公司。美国的洛克希德马丁公司也不会纯粹这样玩；2）不能用一个小作坊模式的开发团队来要求8万人研发的大公司，高通也不会容忍你半夜在家写代码白天不来； 3）美国公司的问题也挺多，容易让擅长拍马屁的印度人上位，长久下来谁优谁劣不好说。有病治病没病辞退。

7、问题是存在的，不过没有那么严重，世上没有理想的环境，各家都有各家的问题。说Java过时这种无谓的语言之争的说法格局就太小了。我在华为PaaS部，开发用Go、Python、Java各种语言，代码review是Gerrit，公司还经常会请Go、Scala的作者在公司做培训，全公司可以接入参加。华为很大，没有完美的环境，心态很重要。

8、在公司做研发8年多了，以前也心态稳定，相信板凳要坐十年冷，以学徒的态度和品质去面对自己承担的工作任务，对业务转换和工作安排基本上没有抱怨和怀疑．可是这两三年来，我越来越不自信了，发现工作总是那样扑天盖地，一波又一波，自己花了很多时间和心血保障了版本特性以及历史版本的验证，这在别人看来已经是理所应当，本该如此了．PL和LM们急切地需要看到亮点，看到能包装成高大上的东西．看见版本经理满口脏话地安排工作的时候，我在想研发人员的地位和自尊哪里去了？研发汪的待遇就是这样吗？如果一个研发人员连尊严和荣誉感都不能感知的话，那点钞票能代表一切吗？能够做出代表着工匠精神的产品吗？

9、之前我觉得公司是硬件＋技术型公司的代表，是挺立于新世纪技术浪潮的旗舰，但现在我觉得公司和这个目标渐行渐远．

10、写的很真实到位，尤其是LM／PL不编码、SE不会编码等现象还是比较普遍的。组织分散、会议多、协调多也是顽疾。这两年研发显率提升在工程、方法上进步较多。在怎么让编码人员能够长期在编码岗位上发展，是要好好研究解决。

11、虽然知道是好文，然而也知道并无卵用，公司现阶段，不管哪个层级的管理都不会重视这个问题，有的都是各种浮躁的发文研讨运动和各种浮于表面的质量检查。最无语的是发起和评价的人都是不懂具体技术细节的人。其实我说的是QA．．．

12、导致研发质量不高的原因还有一条：过量的外包开发人员，通常是一个PL带着100人的团队，95个都是外包的。完成任务和用心做事儿的差别还是很大的，PL也根本管不过来，代码质量自然不高。

13、技术专家在华为非常没地位，绩效／股票／分红／任职等方面都什么话语权，一直干技术会非常担心失业，因为很多领导认为，一个技术老专家干的活，找个新手让技术老专家带一段时间就可以代替老专家了，技术老专家成本高，常常会成为降成本很不错的选择，华为这种氛围，真是让想专心搞技术的兄弟心寒。

14、说一个几天前来我司某基地出差来的见闻：邻桌某PL在和别人espace语音，话间大意：我们组那个A童鞋，能力可以说是最强的，但他有个很严重的问题，他不会展示自己，他做的很多高质量的工作，但是无法很好的向领导展示。所以他的这个上半年绩效不能给太高。。。坐在旁边“无意”听到谈话的我一脸懵逼，内心一紧，又是个悲催的汪啊。

15、一个小小PL，平时既要听资源领导，也要听业务领导的，两个老大的意见经常还不一致，一言不合就吵起来，做下属的都要累死了，实在左右为难啊。为什么在一个PDU内部还要搞矩阵管理呢，实在降低效率增加扯皮，是为了安排人员岗位吗。

16、关于先进研发工具、平台甚至开发语言，确实作为研发作战武器是至关重要的，目前公司研发能力中心、各产品线在开源应用和向外界学习的过程中，都在引入试点，希望扩大规模，公司是倡导的。我们基层干活的也需要多看看外界软件、硬件设计、开发上的一些新工具、新平台、新方法，测试，使用。

17、我就没搞明白，华为对自己的定位到底是软件公司还是硬件公司？向互联网看齐，你客户跟互联网的是一样的？你的客户能让你低成本试错吗，你的客户可以让你远程推送补丁吗，你的客户允许你的产品产品闪退吗？现实是，一个bug，华为的芯片得重新流片；一个bug，华为的基站得退服，客户得跟政府解释；互联网追求快，华为追求稳。

18、作为一个以产品／项目交付为主的公司，解决方案架构师的作用是什么？主要是通过架构保持整个组织对于解决方案认知的一致，这是为什么很多架构师／SE花大量时间在架构图／PPT上的原因，这也是保证整个组织、很多项目不乱的一个很重要的因素（我没有说唯一因素，没有否定coder的作用，显然再好的架构也需要coder去实现），这跟做产品运营的互联网公司，就一个版本持续不断优化，业务上线速度优先是不一样的，比如：大家都知道淘宝的架构从一开始2000美金买的简单购物网站到现在的超大规模网站，10年之间架构推倒重来了5次，包括其中请sun的Java专家重写了一遍系统，这在华为是不可想象的，在华为首先要讲清楚WHY，工程商人，投入产出先讲清楚，至少要保障逻辑上成功，这就是为什么投入大量人力在前端，也是IPD的重要作用之一。

19、这篇文章和其后的讨论，让我联想到一本书《失去的制造业 日本制造业的败北》，其中分析日立、NEC和三菱干不过三星的原因，和当前的市场状态蛮像的。

日本人在DRAM产品上80年代到90年代取得了巨大的成功，占据了核心供应商位置，市场占比达到80％。但在市场需求来源从高可靠性的大型机转向低成本的PC过程中，因为执着于高可靠性的制程、工艺、一致性、良品率等指标，长期按三星的两倍甚至更高的运作成本在销售DRAM，盈利微薄，最终完全退出了DRAM市场。ICT领域的商业价值在向软件、生态系统或者平台型的提供者转移过程中，如果我们也始终执着于过去在通讯领域，为高可靠性产品开发而建立的组织、文化、流程，那在新的商业地图上，我们的版图终究会缩减下来。

20、点点滴滴都说到我的心坎上了。但是，怎么改？华为文化，乃至中国文化，一放就乱，一管就死。创造性的研发工作当作低级简单老动来管理，必然抹杀创造性。好在勤能补拙，以华为企业文化“累死自己、逼死友商、成就客户”，还是一步一步地走向成功。

21、领导以为给个人就能编码，不知道编码才是所有事情的核心，所以各个产品不停的重复犯错，所以公司各级每年都要开狗屁没有用的质量大会

22、我司很多软件的idea，不是来自懂业务懂技术的大牛，而是来自领导拍脑袋；然后领导忙别的去了，具体落地业务需求有MO和SE完成。如果MO和SE就可以领导重大软件的开发，那么多公司还招聘CTO干啥？

23、对于研发工程师的定位在西方公司和中国公司之间确实有着巨大差异，本人曾经工作的美国企业和欧洲企业，美国工程师和欧洲工程师50多岁还在写代码，做测试的比比皆是，并且都在项目、组织中享有重要地位；相比较之下，国内连40多岁的程序员都很鲜见。

24、深有同感，但是楼主离开硅谷，是意味着其他公司比华为更乱吗？

25、首先“标题”取“硅谷海归．．”有什么意义？有崇拜的因素？结果还引起一片附和。可明天一句主管赞扬的话就让你感激涕零，换了想法。谈什么思想？不过是小心思罢了。这里面有好多人回复时自以为是，但都是拿自己的工作当成全部，进而去低估别人的工作，不是想着通力合作而只想着斗争。请问：别人有没有对你的工作指手划脚？只不过是一个最初级的实用主义者的牢骚之主，谈什么格调。各级主管信心爆棚，很难听取意见

26、我认为还没有挖到根上，很深的一个根因，那就是PBC牵引太强，绩效结果应用太强，绩效结果简直决定员工的一切回报！！现在PBC牵引太强了，如果能力强的员工不去搞与代码无关的事情，就会没有很好的绩效。为啥？因为现在的绩效管理是“人与PBC比”、“人与人比”。。。PBC是死的，一般员工都会看好，但人是活的，你要超过别人，你必须搞点其他与代码无关的事情，结果一搞就搞多了。研发普遍有一种认识，搞定周边部门远比搞定代码要难度大。久而久之，写代码的绩效就差了，谁还愿意写。因此，要从根本上解决软件开发的问题，必须要解决利益分配在执行层面的问题，也就是绩效管理问题，写代码的取消相对考评、采用绝对考评！！！减少考评结果的应用，比如只关系晋升，不关系奖金！！所谓流程的问题，根本就是表面现象，虽然也需要解决，但这种解决，我认为只是持续演进和适配的问题！！！

27、深有体会，不过华为有自我进化的能力，当它发现和认识到问题的时候，就会进化。华为的进化就像中国的改革开放，不断的试探发展。

28、任何一个企业都存在自身的问题，每一个企业都有他独特的文化，华为能发展到今天说明目前的方式是适应华为的，你真正从华为工作过10年以后你再出来看看，外面的大部分企业都和华为有很大的差距。炸掉研发金字塔后又如何重建呢？

29、在工程师文化这一块，我们确实做得很不够，如果纯技术员工都觉得很痛苦，没出路，长久肯定会导致人才流失，优秀的人才吸引不来，自己的好员工都想逃离。但我觉得这个是整体导向的问题，而不光是HR思路问题，比如任职资格，本身在HR政策上就是为了牵引员工技术提升的，只是在执行上，被论资排辈和“管理者优先”的思想给害了，关键还是文章里说的，我们从上到下没有给予顶尖程序员的成长空间和足够的牵引，希望能引起公司的重视。

30、现在的HR建设思路估计会在N年后带来危机。。。希望我说的是错的

1）管理沟通为王，技术员工就是低级别／低绩效员工。一走上管理线还没做出贡献就辉煌腾达，又是升级又是加薪，以很多产品线为例，技术员工迟迟停留在14，15级，而一些和领导近，帮着领导完协调沟通开会的就能往上升级。2）形成了一层只懂沟通协调，拉通开会，不懂业务，但会写汇报材料领奖但又占据高职级的中间层。。。造成大量低效，无用的工作，因为想不清楚要干啥，所以就一拍脑袋安排任务，下面的人把事情做了，才发现方向错了。3）技术员工无出路，产品线技术储备上不去，又造成低效。4）领导想不清楚技术能力对部门的价值，因为他自己不懂。5）技术线和管理线一起考核。。让某些人既做裁判又做运动员。做技术15级就是个坎，和管理员以及沟通协调员一起考核，做技术的就只能背B背C，长此以往，消耗公司的技术储备。

31、组织的这部分描述，很认同。架构、专家等好像是为了树品牌，直接作战基层人员那种扎根持久奋战的环境不好，矩阵式管理和沟通繁琐等。另外，不仅仅是研发，公司现在几大流程为主支撑，流程中每个环节角色相对独立，但又相互关联，于是又设置了很多KCP

31、我司产品对需求管理较弱，都是市场人员说了算，再加上各种原因导致软件产品本身就缺少架构和设计，为了交差就用最简单粗暴的叠加方法，什么设计啊，架构啊先放一边，搞上去再说。几年下来，几波人轮流修改，代码变得庞大和冗余，很多产品都是越到后期越烂。

32、工业时代的管理思维和模式如IPD，在当下的数字时代肯定问题百出，不仅是研发，市场、运营也都处在类似的矛盾和冲突中，我司在追求成为社会各行各业数字化转型的使能者，但反观自身的管理运作确仍深陷工业化思维无法自拔，有时真觉得挺崩溃。

33、电信级的安全、稳定要求与消费级的快速迭代和快速适应调整天然就存在矛盾，如果用电信的思维去管理必然导致以上问题，但我们的基因就是电信级的严谨；要想在消费领域有效突破唯有破釜沉舟大胆启用外部新人，同时挑选一些内部仍有变革思想和欲望的员工组建新团队，以新带旧实现转型；突破既有的电信级研发管理框架启用新流程，人与流程适配才能有所作为！

34、软件开发模式不是一种就可以包打天下，因此还需要针对不同的软件开发进行适当的定制化和调整，包括组织、流程、环境和工具：如文中所提的互联网应用软件，其体量、周期短，因此势必要调整为快速迭代的敏捷开发模式。如果是开发体量大、周期长的通信底层软件，可以应用稍厚重的软件开发流程。还有一个观点不太认同，“IPD流程不太适合需要快速迭代的软件”，这里不应该是IPD流程，而是在IPD流程体系下的软件开发模型，对软件开发怎么走起到决定性的还是下面的软件开发流程（CMM or 敏捷等子流程）。事实上IPD流程框架只解决如何将产品开发作为投资来管理。

35、看看华为项目中PMO的多寡，就知道 效率高低。项目管理还有个专门的职业通道呢，数数就知道了。互联网公司哪些什么PMO，QA也是测试人员，和我们的QA也完全不一样。

36、公司很多的软件项目给项目组留的时间非常短，经常是3到6个月就要出产品。从另一个方面讲，就是前瞻性不够。产品不需要的时候根本就不布局。等产品要的时候，跟本不给时间做探索。这样做出来的产品质量可想而知。过去成功的产品，基本上都是提前布局（悄悄的布局），等产品要的时候基本路都走通了。这个时候说三到六个月就可以从容应对了。海思现在的做法也是一个技术样片加一个产品样片，中间相差半年到一年，这就非常合理。好的软件架构是需要时间去探索和磨合，不是一上来就百分之百能做好做对。而且将来还需要不断的重构。Google的主力产品每一年到一年半就要做一次大的重构。如果不重构，工程师自己都觉得他维护的产品会落后。当然我司的产品也在做持续改进，但意思好像不完全一样。我们更多的关心的是竞争力，人家关心的是架构可持续发展。

37、程序猿、攻城狮文化的建设首先需要在晋升通道要畅通，让更多的人留在专业岗位上，才能真正的出现沉淀、传承和创新。如果每个人都想着往管理岗走，意味着一圈又一圈的轮回，竞争力就更无从谈起。

38、楼主用硅谷的互联网软件开发模式，跟华为的ICT行业嵌入式软件开发模式来比较，是不是有些南辕北辙了呢？互联网软件是全球集中控制（如Google），系统发现bug后，能够在线低成本实时更新版本，你甚至都没有感觉，人家就悄悄的整完了，因此敢玩敏捷试错，可以每周甚至每天更新版本。由此也就产生了与之对应的新的开发模式。CT嵌入式软件，发布之后是随硬件发货遍布到全球各地，发现bug就要到现场批量召回／替换／整改，你得跟客户道N次谦，做好N个应急切换方案，才敢去干，成本非常高昂。我司主力产品每年都是上百万级别的，“敏捷试错”一下试试，每个错的代价最低都是千万美刀起步吧？你敢玩儿吗？你的客户让你这么玩吗？ IPD流程根本就不是为了敏捷试错，而是为了高可靠性而打造的。拿互联网的开发模式跟嵌入式ICT软件的IPD开发模式，来比较，有些牛头 VS 马嘴了吧？当然，改善下程序猿们的工作环境，工作氛围，让大家身心健康的工作，我还是举双手支持的，但一上来就要比照互联网软件的开发模式来整组织、动流程，咱是不是先悠着点儿呢？

39、问题的根源在于我们越来越厚重的管理，现在的管理要求越来越多，管理手段越来越繁琐，绩效评价、薪资调整、奖金评定、配股、任职资格、人岗匹配、团队稳定、离职跳池等，是必须有一个强有力的管理者进行团队管理，从PL开始，要想管理好团队，必须抛弃技术走向管理，导致无精力专注技术。管理是需要灰度的，但是我们现在的管理（特别是绩效、薪资、奖金、配股、任职、人岗等），更多的是对复杂多变规则的理解和执行，导致管理成本进一步上升。