员工呼唤“炸掉华为研发金字塔”！任正非声援！
一位曾在美国硅谷工作、和世界上最顶尖的软件工程师和计算机领域的牛人一起共事过的泥瓦客，几年的华为经历，让他发出洪荒之力，呼唤“炸掉华为研发金字塔”！
对此，任正非批示：“在技术工作的客气是毒品，直面的批评、争论才是良药”。
任正非喜欢这个‘“呼唤者”的态度。这是要挣脱多少束缚，才可以发出的呐喊呀！一个纯粹、素直、担当的人，才可以这样公开提出批评！他深爱自己的天性和华为，才可以有这样的勇敢！而围绕这种批评而升起来的争论甚至辩论，才是一个公司匠心匠魂产生的摇篮，才是华为未来领导者脱颖而出的具体形式。
有一次，任正非跟我谈起华为大学高管培训班。他说，那些敢于公开提出批评的人，是有出息的人。哪怕他们批评错误，由此而引发的辩论，也会把认识推向纵深。凡是可以在干部培训班上提出批评并引发争议的人，参加培训班都值了。他们会被记录在案。那些客客气气，不发言不引发辩论的人，就要一次次交钱参加培训班，而一次次不会有什么印记的（华为大学干训班，每次都要员工自己交学费、负担来回交通费、食宿费，还要扣除全勤奖。2014 年华为大学收入22亿元人民币）。
10年前，任正非就提出“让听到炮声的人呼唤炮火”！近两年更做出规划，要在未来15年落地这样的体制，并且做了350亿美元的预算！决心之大，溢于言表。但是庞大的华为，有大公司固有的惯性。整体协调一致性往往取代了土狼时代的尖刀突破。更离开任正非内心对现代“班长的战争”条件下“让听到炮声的人呼唤炮火”的体制设计相去甚远。眼下这位It工程师的呐喊，就是抓手！
任正非的批示，意味深远。他首肯了这篇文章的主调：符合坚持自我批判的华为文化。打破苟且偷生、可客客气气的惯性，就是摈弃毒药，而由此呐喊引发的争论，更是华为的良药。
当大部分人，还拘泥于一篇文章细节上的真实而耗费心力的时候，任正非已经看到了波澜壮阔的滔天巨浪，那是可以摧毁一切阻挡“让听到炮声的人呼唤炮火”新体制的堤坝的。
任正非说：“比世界还大的世界，就是你的心胸”！什么样的心胸比世界还大呢？
任正非是把有华为工卡的和没有华为工卡的科学家、专家、巨匠、匠人、操作工，都囊括在他的心胸里。把他们的赞扬、抱怨、批评、建议统统聚集起来为着那一针刺破天的伟业。当把全球人类、全球生命、全球资源都纳进他的心胸里去以后，这样的心胸才会成为比世界还大的世界。
千里之行始于足下。最重要的开端，就是真诚面对批评，无论这种批评是千真万确还是捕风捉影。唯有真诚，可以尽其性；唯有尽其性，才可以尽人之性；唯有尽人之性，才可以尽物之性；唯有尽物之性，才可以赞天地之化育；唯有赞天地之化育，才可以有万物一体之真善美！
仔细研读一下这篇文章，看看后面的评论，您这个当下会有不少体悟，把它们加进后面的评论里，这就是一个公司经营的无价之宝，这就是“让听到炮声的人呼唤炮火”体制的雏形。您的公司也可以像华为能量场一样，聚集无限能量，厚积薄发，一针刺破天！
提醒：把您的体悟和观感加进后面的评论里！您也在创造历史！
——王育琨记
原文：内部人建议炸掉华为研发金字塔，然后任正非给全公司发了封邮件⋯⋯
作者来源：泥瓦客＋钛小编
外人都说华为好，技术实力强大，但在华为这样的大公司作技术，也确实真不容易，公司大了，层级多了，效率低了，协作差了，那么怎么办？
钛媒体注：近日，华为内部署名“泥瓦客”的一名海龟程序员，从组织、流程、环境、工具四个方面痛斥在华为做研发的不易，并将这些问题形成了一篇文章发布在一本内部刊物上，然后这篇名为《华为该炸掉研发金字塔的时候了》的文章，又被转发到华为员工官方社区“心声社区”，激起了一场轰轰烈烈的内部讨论，更惊动了华为创始人& CEO任正非。任正非看完所有人的讨论后，签发了一封总裁办邮件，把文章和大家的讨论贴出来，告知全司，此举动背后的心思不得不说耐人寻味。
任正非签发邮件的按1写到：在技术工作的客气是毒品，直面的批评、争论才是良药。钛媒体编辑把这篇作者原文和上述任正非邮件的核心内容整理了出来，倒是一份很好的关于“研发”与技术管理的研究材料，也能更深层次帮助理解华为变大之后的内部问题。考虑到微信篇幅，钛媒体对相关素材在不影响意思的前提下，有所删减，本周周末深阅读，重磅推荐：
华为到该炸掉研发金字塔的时候了——关于我司软件研发效率和质量提升的思考
作者：泥瓦客
近年，在从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作为学习和资源分享不可分割的一部分。
留言评论选
一石激起千层浪，上述文章，直接引起了大量华为内部争论，摘录如下：
很多研发的同学都抱怨过，聪明的人都去做管理了。根源还是研发团队的作战方式。一个项目需要那么多人，必然需要有管理，就有所谓的管理者，管的人越多，管理者做技术的时间越少。要转变开发的模式，班长的战争。如果都是一个个的小团队，就不需要那么多的所谓的技术管理者了。
这些问题其实5，6年前我们内部早已经发现，如今从一个外界来的专家身上也提出了。因为以前我们的人员、组织快速膨胀，其中最难的问题：骨干员工都提拔去当官、当专家、专家不碰代码的情况确实存在。随着这两年我们的人员、组织逐渐稳定、任职上的牵引，让骨干员工深耕一线开发岗位，核心骨干负责架构代码、核心模块代码、产品的设计正在成为现实，只要坚持下去，研发扁平化组织我们也会实现。
这是由华为公司两大基因决定的！
基因一: 基于不信任的管理
假定了一个团队或者一个员工个体，没有办法自动地按要求完成任务，一定要有外力的干预和指导，才能保证航行在正确的轨道上。不信任的假定，造成了领导很焦虑，员工被干扰。
基因二：组织复杂，各自为政
华为缺少扁平化管理，层级多，通道多。这样复杂的组织机构，造成了信息沟通对齐非常困难，每个组织机构又有自己的考评，都要考虑自己的团队建设和发展，价值呈现。人都有趋利的本性，必然会希望更多坚持对自己发展和价值有利的，而放弃那种不太出彩又要大体力投入的。
其实话说回来，说难听点，这叫多头管理多通道管理，说好听一点，这不就是管理上的民主吗？这两个基因，在华为这种大公司，不太可能改变掉，局部试点是有可能的，比如搞搞精英团队，或者在某些项目上试点扁平化，都是有可能的，至于全面改变，不现实。而且真的改成那个样子，还指不定出什么更大篓子。
在公司做研发8年多了,以前也心态稳定,相信板凳要坐十年冷,以学徒的态度和品质去面对自己承担的工作任务,对业务转换和工作安排基本上没有抱怨和怀疑。可是这两三年来,我越来越不自信了。看见版本经理满口脏话地安排工作的时候,我在想研发人员的地位和自尊哪里去了?研发汪的待遇就是这样吗?如果一个研发人员连尊严和荣誉感都不能感知的话,那点钞票能代表一切吗?能够做出代表着工匠精神的产品吗?
之前我觉得公司是硬件+技术型公司的代表，是挺立于新世纪技术浪潮的旗舰，但现在我觉得公司和这个目标渐行渐远。
写的很真实到位，尤其是LM/PL不编码、SE不会编码等现象还是比较普遍的。组织分散、会议多、协调多也是顽疾。这两年研发显率提升在工程、方法上进步较多。在怎么让编码人员能够长期在编码岗位上发展，是要好好研究解决。
导致研发质量不高的原因还有一条：过量的外包开发人员，通常是一个PL带着100人的团队，95个都是外包的。完成任务和用心做事儿的差别还是很大的，PL也根本管不过来，代码质量自然不高。
技术专家在华为非常没地位，绩效/股票/分红/任职等方面都什么话语权，一直干技术会非常担心失业，因为很多领导认为，一个技术老专家干的活，找个新手让技术老专家带一段时间就可以代替老专家了，技术老专家成本高，常常会成为降成本很不错的选择，华为这种氛围，真是让想专心搞技术的兄弟心寒。
说一个几天前来我司某基地出差来的见闻：邻桌某PL在和别人espace语音，话间大意：我们组那个A童鞋，能力可以说是最强的，但他有个很严重的问题，他不会展示自己，他做的很多高质量的工作，但是无法很好的向领导展示。所以他的这个上半年绩效不能给太高。。。坐在旁边“无意”听到谈话的我一脸懵逼，内心一紧，又是个悲催的汪啊。
我就没搞明白，华为对自己的定位到底是软件公司还是硬件公司？向互联网看齐，你客户跟互联网的是一样的？你的客户能让你低成本试错吗，你的客户可以让你远程推送补丁吗，你的客户允许你的产品产品闪退吗？现实是，一个bug，华为的芯片得重新流片；一个bug，华为的基站得退服，客户得跟政府解释；互联网追求快，华为追求稳。
作为一个以产品/项目交付为主的公司，解决方案架构师的作用是什么？主要是通过架构保持整个组织对于解决方案认知的一致，这是为什么很多架构师/SE花大量时间在架构图/PPT上的原因，这也是保证整个组织、很多项目不乱的一个很重要的因素(我没有说唯一因素，没有否定coder的作用，显然再好的架构也需要coder去实现），这跟做产品运营的互联网公司，就一个版本持续不断优化，业务上线速度优先是不一样的，比如：大家都知道淘宝的架构从一开始2000美金买的简单购物网站到现在的超大规模网站，10年之间架构推倒重来了5次，包括其中请sun的Java专家重写了一遍系统，这在华为是不可想象的，在华为首先要讲清楚WHY，工程商人，投入产出先讲清楚，至少要保障逻辑上成功，这就是为什么投入大量人力在前端，也是IPD的重要作用之一。
我认为还没有挖到根上，很深的一个根因，那就是PBC牵引太强，绩效结果应用太强，绩效结果简直决定员工的一切回报！！现在PBC牵引太强了，如果能力强的员工不去搞与代码无关的事情，就会没有很好的绩效。为啥？因为现在的绩效管理是“人与PBC比”、“人与人比”。。。PBC是死的，一般员工都会看好，但人是活的，你要超过别人，你必须搞点其他与代码无关的事情，结果一搞就搞多了。研发普遍有一种认识，搞定周边部门远比搞定代码要难度大。久而久之，写代码的绩效就差了，谁还愿意写。
我司产品对需求管理较弱，都是市场人员说了算，再加上各种原因导致软件产品本身就缺少架构和设计，为了交差就用最简单粗暴的叠加方法，什么设计啊，架构啊先放一边，搞上去再说。几年下来，几波人轮流修改，代码变得庞大和冗余，很多产品都是越到后期越烂。
公司很多的软件项目给项目组留的时间非常短，经常是3到6个月就要出产品。从另一个方面讲，就是前瞻性不够。产品不需要的时候根本就不布局。等产品要的时候，跟本不给时间做探索。这样做出来的产品质量可想而知。过去成功的产品，基本上都是提前布局（悄悄的布局），等产品要的时候基本路都走通了。这个时候说三到六个月就可以从容应对了。海思现在的做法也是一个技术样片加一个产品样片，中间相差半年到一年，这就非常合理。好的软件架构是需要时间去探索和磨合，不是一上来就百分之百能做好做对。而且将来还需要不断的重构。Google的主力产品每一年到一年半就要做一次大的重构。如果不重构，工程师自己都觉得他维护的产品会落后。
问题的根源在于我们越来越厚重的管理，现在的管理要求越来越多，管理手段越来越繁琐，绩效评价、薪资调整、奖金评定、配股、任职资格、人岗匹配、团队稳定、离职跳池等，是必须有一个强有力的管理者进行团队管理，从PL开始，要想管理好团队，必须抛弃技术走向管理，导致无精力专注技术。
——————————————————
精选留言
该文章作者已设置需关注才可以留言
这篇文章可以看出出自典型的程序汪之手，一厢情愿思路眼光偏激狭隘！
6天前
任老板的意见在哪儿？ 其次，全篇是从软件开发角度写的，这东西试错容易些，而且互联网厂商真正面对的是普通人群，很少人用指标去考察互联网厂商吧！但华为靠的是硬件起家，客户是大型企业集团，稳定是第一要素，可能有那么多试错的机会么？ 好的架构师应该懂市场，运营和技术，要具备能更准确的把市场需求转化成产品规划的能力，请问笔者做得到么？
6天前
作者回复
“在技术工作的客气是毒品，直面的批评、争论才是良药。”这个就是任老板回复的邮件哦
6天前
起码看到了内部的不满足，看到了动力，不是一潭死水，证明这个企业还是不错的
6天前
一般能写这么多，这么深刻文章的都是垃圾（不是指文章，是实际研发能力）。企业是一个有机体，是一个发展到某个阶段的产物。如果重新来过一定崩塌，万劫不复。
6天前
无论国内， 国外， 不做实际工作， 还爱乱指挥的“专家”都很令人厌恶。
6天前
华为全部的管理基于两个基本点，也可以说是基因，就是基于不信任的管理和基于多给钱就能带来驱动力。
6天前
每个公司大本营的人都会看不爽市场部的，一个个以为做出了牛逼产品就行了，卖得好是应该的，不是市场营销和功劳，卖得不好就是市场部的能力不足。现在高度竞争和共享的社会，没有什么产品是真正牛逼到通杀天下的，一招鲜只能领先一朝，营销也是重头戏。苹果够牛逼了也不能阻止安卓阵营的热卖，研发很重要，也不要看不起在市场一线拼搏的弟兄的汗水
6天前
软件不等于互联网，不要给作者扣帽子，人家的原意是要做软件就向ibm，google和微软看齐，这是好用的企业级软件公司，而不是搜索引擎烂的要命的百度。山寨养成习惯了，以为软件就是把别人的拿来修改修改就要就能上马，备份改了赛门铁克，桌面改了citrix，存储封装了一下gluster，冲着人家的功能去也不想想后边的设计是为什么。上大学的时候，测试程序的每一个命名，老师都要求思索规范，这是为什么，那是因为整段代码运行下来每一个细微的字母都会影响程序的流畅性。忽视架构设计，随便扔出去一个版本，出了毛病在用户现场号称随时可以手改代码，这就是我见过的华为软件。
6天前
公司发展大了，一线基层就远离了创始人的影响力，典型的【大公司病】，好在有些创新专利 还能比普通企业集团走远一些。
6天前
根据国外研究中心呆一年的经历，支持小团队别弄那多干部。。。
6天前
任总有自己的考虑吧，那句话有深意。
6天前
外企可能好一些，其他国内企业管理者不懂技术比比皆是，很多做技术的都觉得技术没前途，也就做了管理，而逐渐脱离了技术，使管理和技术衔接不够紧密和高效，这和我们所处的环境制度企业文化都有关系。 拿我个人来讲，夜里八小时顶的上三个白班的输出，并不是自己白班效率太低，而是夜深人静的时候效率真的高。
6天前
小学就学过将心比心，可没到那境界谁又能明白任正非的心。
6天前
有人说了总是好的，不论对错，可以大家讨论讨论，实践实践，也许十年前对的东西，放到现在就是错的，也许十年前错的东西放到现在就是对的，谁说的定呢？
6天前
只有这样不停的自我反省和革新才能持续产生活力
6天前
其实研发和市场营销是2个概念，研发的组织结构和营销的组织结构也必然不同。研发应该是精英式的，营销应该是人海式的。所以效率的问题必然导致结构迭代(套用一下)，没有一成不变，只是每个企业找到属于自己的方法。华为目前应该更偏重于东方式，腾讯已经有点像硅谷了。在技术为主的企业，如何能够跟上或者领先，华为要做的还是很多。无人区，不仅仅是企业的模式、技术模式，也包括运行结构的模式。
6天前
思维差异影响并决定着中外企业管理模式的不同，但利用人性驱动达到管理的目的却是相同的。
6天前
制度：管制与开放，结果：成功的公司与伟大公司，未来怎样：应该以史为鉴
6天前
各行各业都是如此，比如医院行业，跟这个是一模一样啊
6天前
在华为做开发束手束脚,全是套路，没意思。
3天前
我记得spaceX的所有部门、任何人不分职位都全在一个大厅里工作，刻意取消了“墙”这东西， 部门间沟通 人与人之间交流很直接简便，省去了繁琐程序、文山会海，就包括马斯克他的座位也直接设在角落那。
5天前
作者显然对IPD一知半解呀，感觉华为对IPD的教育不到位。IPD是业务管理流程，不是软件开发流程。诸如敏捷开发等软件开发方法可以很好地和IPD结合起来。
5天前
————————————
———————————————