注：所有评论全部是个人观点，仅供读者参考与探索！
管报、微信、心声社区网友评论摘录：
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开始，要想管理好团队，必须抛弃技术走向管理，导致无精力专注技术。管理是需要灰度的，但是我们现在的管理（特别是绩效、薪资、奖金、配股、任职、人岗等），更多的是对复杂多变规则的理解和执行，导致管理成本进一步上升。
---- 技术成本也是很高的，呵呵，不做过多评论。
