总 裁 办 电 子 邮 件
电邮其他【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作为学习和资源分享不可分割的一部分。
管报、微信、心声社区网友评论摘录：
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开始，要想管理好团队，必须抛弃技术走向管理，导致无精力专注技术。管理是需要灰度的，但是我们现在的管理（特别是绩效、薪资、奖金、配股、任职、人岗等），更多的是对复杂多变规则的理解和执行，导致管理成本进一步上升。
报送：董事会成员、监事会成员
主送：全体员工，全公开
二○一六年八月五日
在华为也做了多年DE的岗位,感觉文中对华为技术岗的分析还是比较中肯的,虽然不乏对SE/DE角色的质疑. 我觉得SE/DE 这个岗位是必须的, 只是工作中心有待商榷. 至于纯粹的开发岗位, 我相信大家的感觉是一致的,没有前途,不受尊重. 从我自身讲,我就想踏踏实实做一个DE , 有些兄弟就是喜欢做技术, 为什么公司不能营造氛围, 让我们踏踏实实开开心心做下去呢. 管理理念, 影响很大, 如果他真的很懂, 指点一下,我想大家都会虚心接受, 即使他比我年轻; 但是如果他不怎么懂 ,指手画脚,盛气凌人, 做技术的兄弟怎么能安心做下去呢.
开发者多为低级别，比较难有技术积累
一般基层程序员在工作几年后，有能力的都被提升到PL、PM、SE等职位，员工也都想着被提拔，渐渐成为管理者。大家觉得，光做开发没有职业前途，永远都是在金字塔的底层。而在硅谷的公司，说话比较有分量、收入相对较高的有很多是在各层级中的技术佼佼者，他们备受尊重，干得也开心，不少人根本不愿意转做管理者。
编程其实是一门艺术，热爱和用心是非常重要的，也相应的容易出成绩。这就是为什么在计算机领域，如果做到顶尖程序员，一个人顶一百个很正常。如果程序员觉得没有前途，不思进取，而资质较好的很快又被提拔为管理者，那我们的软件开发将很难有技术和人才的积累。
不仅仅是懂技术，还要懂客户。不知道客户要啥就上马，结果是做出一坨翔，还有一堆人必须说这坨翔很好很香。
"口才好的应该去市场，不要耽误产品" 领导应该赶紧放我走呀 不要耽误产品了
@跟帖产品线主管 这种思路我觉得是不对的，只有懂技术的基础上，才能更懂客户。如果不懂技术，不可能真正懂客户需求。基础是技术，没有技术谈客户简直是扯淡。
这一点无比同意。领导们干吗不去评管理级别非要和技术人员去抢技术任职资格。真正PK技术，很多领导连15级都PK不过但是能升到19、20级（更高级别咱没机会接触）。
理解需求，理解客户难道不属于技术本身吗？这也是当前公司程序员需要自身提高的，本来就属于一类东西，执行起来却分开了...
本来软件在一线就有定制团队和SA组织，结果一线不少人只负责跟客户沟通和呼唤其他的人来支持他输出方案和架构。结果导致一件事安排了两倍的人来负责，等到售前沟通完方案，还要转到另外一个部门呼唤一个售后的炮火，呼唤不到还要用研发的炮火，难道这是0成本地么？这三倍的资源消耗掉了，研发已经没有人看着实现了，开发又跟客户要的不一致，于是问题就来了。一线也很痛苦，两手一摊，我啥也不会啊，只能呼唤炮火，甚至连迫击炮的射程都不知道，连坐标都常常不准，机关又没有资源全部响应，只好开很多会呼唤炮火和控制呼唤炮火。然后机关又不能一个炮火都不打出去，就消耗研发资源，然后研发的产品搞不好，资料也弄不好，遇到新的需求没有成熟的方案，又要安排很多人并行做很多不同的方案来支撑不同需求，每个方案都质量一般又没有文档，一线就更不会了。于是呼唤炮火的雪球就越滚越大。
所以问题的核心不是哪个角色不负责，而是整个工作地阵型都是乱的。最后所有岗位都在抱怨，所有岗位都觉得自己比窦娥还冤。然后不管是市场一线，还是服务一线或者是研发一线，发现似乎能够解决方案的只有架构师，SE，就呼唤神一样的架构师。这就是我们的问题轨迹。
一线呼唤炮火，我们给与炮火支持的时候要问清楚坐标，要看效果，如果给了炮火，一顿狂轰滥炸，万一炸的不是敌人怎么办，我们自己也是有责任的，不能要啥就给啥，也是要抬头走路的。
注：所有评论全部是个人观点，仅供读者参考与探索！
管报、微信、心声社区网友评论摘录：
1、整体观点还是同意的，部分点比如网络权限、开发流程、工具等现在很多部门已经优化了，跟互联网公司也差距不大了，不过管理团队臃肿与问责机制的严苛，跨部门沟通成本高，安全红线与IPD流程的繁琐确实仍是相对严重的问题。不过随着公司整体对IT化的思考，应该会越来越好，部分部门有可能在2-5年内赶上业界主流互联网公司的研发效率。
---- 抽象的内容，不做评论
2、很多研发的同学都抱怨过，聪明的人都去做管理了。根源还是研发团队的作战方式。一个项目需要那么多人，必然需要有管理，就有所谓的管理者，管的人越多，管理者做技术的时间越少。要转变开发的模式，班长的战争。如果都是一个个的小团队，就不需要那么多的所谓的技术管理者了。
---- 我认为是适者生存。就让那些自以为聪明的人去做管理，真心热爱技术的人，不会去关注别人怎么走路。如果有想法的话，无非是自己想做管理而没做成！
3、这些问题其实5，6年前我们内部早已经发现，如今从一个外界来的专家身上也提出了。因为以前我们的人员、组织快速膨胀，其中最难的问题：骨干员工都提拔去当官、当专家、专家不碰代码的情况确实存在。随着这两年我们的人员、组织逐渐稳定、任职上的牵引，让骨干员工深耕一线开发岗位，核心骨干负责架构代码、核心模块代码、产品的设计正在成为现实，只要坚持下去，研发扁平化组织我们也会实现。
---- 确实，公司管理者不太善于倾听自己内部的声音，外部过来的专家说一句顶内部100句。没办法，只希望多招一些内部专家来慢慢改变。
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们急切地需要看到亮点,看到能包装成高大上的东西.看见版本经理满口脏话地安排工作的时候,我在想研发人员的地位和自尊哪里去了?研发汪的待遇就是这样吗?如果一个研发人员连尊严和荣誉感都不能感知的话,那点钞票能代表一切吗?能够做出代表着工匠精神的产品吗?
---- 个人也谈谈感受，首先尊严是自己争取的，不是别人给的！别人的脏话只能说明这个没素质，你去跟一个没素质的人计较，那你去吧！我也遇到过类似的情况，不过还好，部门上层主管马上意识到问题，调整了版本经理的工作。如果上层主管没有意识到问题，导致整个团队都出现消极状态，主管是有不可推卸的责任。那么你可能会觉得，我就这么倒霉，遇到这样的版本经理（PL）！怎么说呢，关键还是在自己，没有人一辈子顺风顺水，反之一样。自己的心态很重要！另外，如果专心做研发N年，还觉得自己提升不够，真心不能报怨别人，想想自己的原因！
9、之前我觉得公司是硬件+技术型公司的代表,是挺立于新世纪技术浪潮的旗舰,但现在我觉得公司和这个目标渐行渐远.
---- 相反，我觉得越来越近。越是问题暴露的时候，越是说明在前进！
10、写的很真实到位，尤其是LM/PL不编码、SE不会编码等现象还是比较普遍的。组织分散、会议多、协调多也是顽疾。这两年研发显率提升在工程、方法上进步较多。在怎么让编码人员能够长期在编码岗位上发展，是要好好研究解决。
---- 怎么说呢，不编码就是十恶不赦的坏事吗？为什么这么多人对PL，LM，SE不编码就这么大意见！？那些搞维护的，每到好代码评审时，也是一行代码拿不出来！而一些优秀的SE还能获得好代码奖项。还是一句话：因人而宜！我还是前面的观点，写代码就专心写你的代码，为什么总是计较别人不写代码呢？你要不想写，你就去做你想做的事，公司不会阻止你！你想写，在哪里都可以，当上了总统一样可以写！
11、虽然知道是好文，然而也知道并无卵用，公司现阶段，不管哪个层级的管理都不会重视这个问题，有的都是各种浮躁的发文研讨运动和各种浮于表面的质量检查。最无语的是发起和评价的人都是不懂具体技术细节的人。其实我说的是QA...
---- 呵呵，这个有点针对性了，QA也有无奈的地方，理解就行了。同理，专心做自己的事，别人走别人的路去吧！说不定那一天你也做QA了，呵呵，祝福你！
12、导致研发质量不高的原因还有一条：过量的外包开发人员，通常是一个PL带着100人的团队，95个都是外包的。完成任务和用心做事儿的差别还是很大的，PL也根本管不过来，代码质量自然不高。
---- 我有一次在外面遇到一个外包的，是给华为做事的，但他不知道我是华为的，只知道我是做技术的，我们聊的很开心，人家也是很有追求的，不但在华为做事很认真，还在外面报学习班，想有朝一日能加入华为。我司的员工代码就一定写得好吗！？还是看人，外包把握好人的质量，问题不会太大，人家其实很努力的。我们团队有一个外包快8年老员工，大家对他非常的信任与认可！
13、技术专家在华为非常没地，绩效/股票/分红/任职等方面都什么话语权，一直干技术会非常担心失业，因为很多领导认为，一个技术老专家干的活，找个新手让技术老专家带一段时间就可以代替老专家了，技术老专家成本高，常常会成为降成本很不错的选择，华为这种氛围，真是让想专心搞技术的兄弟心寒。
---- 不赞成！如果一个技术专家很容易被新员工取代，只说明一个问题；你是伪专家（前部门主管时常警示我们的一句话）！
14、说一个几天前来我司某基地出差来的见闻：邻桌某PL在和别人espace语音，话间大意：我们组那个A童鞋，能力可以说是最强的，但他有个很严重的问题，他不会展示自己，他做的很多高质量的工作，但是无法很好的向领导展示。所以他的这个上半年绩效不能给太高。。。坐在旁边“无意”听到谈话的我一脸懵逼，内心一紧，又是个悲催的汪啊。
---- 这个，不合适！不过我的观点是：不管非技术的事！另外，我在公司9年了，结合自己的考评来看，公司还是相对公平的！但：没有一辈子顺风顺水的事！
15、一个小小PL，平时既要听资源领导，也要听业务领导的，两个老大的意见经常还不一致，一言不合就吵起来，做下属的都要累死了，实在左右为难啊。为什么在一个PDU内部还要搞矩阵管理呢，实在降低效率增加扯皮，是为了安排人员岗位吗。
---- 世界本身就是多样化的！一言堂就好吗？PL要有自己的观点，自己可以决策做什么不做什么，要有做为！
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是死的，一般员工都会看好，但人是活的，你要超过别人，你必须搞点其他与代码无关的事情，结果一搞就搞多了。研发普遍有一种认识，搞定周边部门远比搞定代码要难度大。久而久之，写代码的绩效就差了，谁还愿意写。因此，要从根本上解决软件开发的问题，必须要解决利益分配在执行层面的问题，也就是绩效管理问题，写代码的取消相对考评、采用绝对考评！！！减少考评结果的应用，比如只关系晋升，不关系奖金！！所谓流程的问题，根本就是表面现象，虽然也需要解决，但这种解决，我认为只是持续演进和适配的问题！！！
---- 我个不人赞成绝对考评！现在外面市场上看看，所有服务态度好的地方，你都可以明显的感觉到都是有XXX在牵引的！这是人的本性，无法认清这一点，就无法做管理！至于编码的相对于绝对，我只能说相信组织，好代码评审，代码网上表现，代码维护成本等，还是有一定反馈的。只是不像其它的那么及时。搞技术的，要耐得住寂寞。【个人观点】
27、深有体会，不过华为有自我进化的能力，当它发现和认识到问题的时候，就会进化。华为的进化就像中国的改革开放，不断的试探发展。
---- 赞成！
28、任何一个企业都存在自身的问题，每一个企业都有他独特的文化，华为能发展到今天说明目前的方式是适应华为的，你真正从华为工作过10年以后你再出来看看，外面的大部分企业都和华为有很大的差距。炸掉研发金字塔后又如何重建呢？
---- 赞成！
29、在工程师文化这一块，我们确实做得很不够，如果纯技术员工都觉得很痛苦，没出路，长久肯定会导致人才流失，优秀的人才吸引不来，自己的好员工都想逃离。但我觉得这个是整体导向的问题，而不光是HR思路问题，比如任职资格，本身在HR政策上就是为了牵引员工技术提升的，只是在执行上，被论资排辈和“管理者优先”的思想给害了，关键还是文章里说的，我们从上到下没有给予顶尖程序员的成长空间和足够的牵引，希望能引起公司的重视。
---- 怎么说呢，专家的发展空间还是有的。很大程度上不是看个人！在公司待了9年，很多同事离职了，有转岗了，有情绪低落想走的，也有7-8年了直是基层编码的（也很开心）。整体来说，公司的任职，任岗还算是相对公平的。“论资排辈”和“管理者优先”我也遇到过，也只是相对一点点，而且每年不一样，根据实际情况会有变化。只要大方向是没问题的，一两年的小问题不会影响你一辈子！你要为这一点小事影响你一辈子，那你自己去影响吧，没人可以帮你！
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流程框架只解决如何将产品开发作为投资来管理。
---- 比较赞成软件开发模式不是一种可以包打天下的观点。怎么说呢，CMM也好，敏捷也好，都只是为了满足最终目的的工具和手段。如果把一些问题归结到工具和方法上，可能只是因为使用的工具和方法不正确。
35、看看华为项目中PMO的多寡，就知道 效率高低。项目管理还有个专门的职业通道呢，数数就知道了。互联网公司哪些什么PMO，QA也是测试人员，和我们的QA也完全不一样。
---- 呵呵，很多中小公司很希望有华为的QA去过帮助他们的！用好QA以及各种角色的人，真正要人的时候没有了，你会后悔的！
36、公司很多的软件项目给项目组留的时间非常短，经常是3到6个月就要出产品。从另一个方面讲，就是前瞻性不够。产品不需要的时候根本就不布局。等产品要的时候，跟本不给时间做探索。这样做出来的产品质量可想而知。过去成功的产品，基本上都是提前布局（悄悄的布局），等产品要的时候基本路都走通了。这个时候说三到六个月就可以从容应对了。海思现在的做法也是一个技术样片加一个产品样片，中间相差半年到一年，这就非常合理。好的软件架构是需要时间去探索和磨合，不是一上来就百分之百能做好做对。而且将来还需要不断的重构。Google的主力产品每一年到一年半就要做一次大的重构。如果不重构，工程师自己都觉得他维护的产品会落后。当然我司的产品也在做持续改进，但意思好像不完全一样。我们更多的关心的是竞争力，人家关心的是架构可持续发展。
---- 看什么产品吧。有的做了提前布局，有的没有做，说明是有取舍的，也说明老大们是有做事的，呵呵。。。。
37、程序猿、攻城狮文化的建设首先需要在晋升通道要畅通，让更多的人留在专业岗位上，才能真正的出现沉淀、传承和创新。如果每个人都想着往管理岗走，意味着一圈又一圈的轮回，竞争力就更无从谈起。
---- 程序猿、攻城狮文化是要建设的，但我不认为只是在晋升通道上。过宽松的通道反而不好（对一些新招的人员，特殊起薪高出普通员工很多的现象不太认可）。
38、楼主用硅谷的互联网软件开发模式，跟华为的ICT行业嵌入式软件开发模式来比较，是不是有些南北辙了呢？互联网软件是全球集中控制（如Google），系统发现bug后，能够在线低成本实时更新版本，你甚至都没有感觉，人家就悄悄的整完了，因此敢玩敏捷试错，可以每周甚至每天更新版本。由此也就产生了与之对应的新的开发模式。CT嵌入式软件，发布之后是随硬件发货遍布到全球各地，发现bug就要到现场批量召回/替换/整改，你得跟客户道N次谦，做好N个应急切换方案，才敢去干，成本非常高昂。我司主力产品每年都是上百万级别的，“敏捷试错”一下试试，每个错的代价最低都是千万美刀起步吧？你敢玩儿吗？你的客户让你这么玩吗？IPD流程根本就不是为了敏捷试错，而是为了高可靠性而打造的。拿互联网的开发模式跟嵌入式ICT软件的IPD开发模式，来比较，有些牛头 VS 马嘴了吧？当然，改善下程序猿们的工作环境，工作氛围，让大家身心健康的工作，我还是举双手支持的，但一上来就要比照互联网软件的开发模式来整组织、动流程，咱是不是先悠着点儿呢？
---- 严重赞成！很多问题还是因产品而宜。
39、问题的根源在于我们越来越厚重的管理，现在的管理要求越来越多，管理手段越来越繁琐，绩效评价、薪资调整、奖金评定、配股、任职资格、人岗匹配、团队稳定、离职跳池等，是必须有一个强有力的管理者进行团队管理，从PL开始，要想管理好团队，必须抛弃技术走向管理，导致无精力专注技术。管理是需要灰度的，但是我们现在的管理（特别是绩效、薪资、奖金、配股、任职、人岗等），更多的是对复杂多变规则的理解和执行，导致管理成本进一步上升。
---- 技术成本也是很高的，呵呵，不做过多评论。
何以见得？
卧槽，你说的这是真的吗？新员工表示很震精。
我说的透露出来的意思，就是我个人的感觉，当然不是官方行文。这种感觉来自两个方面，第一是心声上之前大裁员，很多年龄较大的员工给干掉；其次是前一段看到任总有一个讲话“第一，服务专家要有广博的知识，越老越好。不要总是像研发一样强调年轻化、接受新事物。为什么？这跟摸脉一样，老专家懂得旧网络。旧网络不一定要淘汰，新网络和旧网络同时运行，故障不一定都在新网络上，有可能是旧网络带来的。没有老中医摸摸脉，新医生就得在CT上找半天。”，这里提到“不要总是像研发一样强调年轻化”，说明高层在人力策略上，对研发有一条，就是强调年轻化。http://xinsheng.huawei.com/cn/index.php?app=forum&mod=Detail&act=index&id=2977601第一段，可以自己看。再说一遍，这些都是个人感觉，不是公司正式发文，所以，想在我厂写代码写很多年还是算了。成长为高级专家，年龄大点存活的概率要大些。不过别说高级专家，我厂很部分15，大多数16级的都不写代码了吧。@工程师@橙木木
@大梅沙 8年前左右，真说过，老员工编码是浪费，发文了，当时我很震惊，后来又删除了……
好
跟互联网企业比，都加班，不过华为心累。不光你要做事情，核心你要花很大的精力去让领导知道这个事情是你干的。所以一堆人要半夜发邮件，要申报议题去给领导讲，要不然都白做了。出了问题，影响考评，责任谁都不愿意承担。理想的模式本来，本来是大家都从自己的环节找问题，看是否自己的改进可以避免问题的发生。所以周边部门都要求把问题转化为需求提。团队合作氛围差，总是说这个问题担心别人捅，那个问题要捅给别人。
“金字塔”不是一无是处，“互联网”也不是无懈可击，“金字塔”阵地阵型战和和敏捷的“自由蜂窝”阵型相结合就好，还是要把握好灰度。一管就死，一放就乱，怎么把握好管和放，这个需要“度”的智慧，喊口号的人和心里明白的人一大把，真正的拿捏好的高人无几