几年前看到这篇文章的时候对CT业务还没什么深入体会，拍案叫号。到今天再看这篇文章，其实本质上是在拿硅谷互联网为代表的开发文化跟公司现有业务流程的优劣对比。随时随地编码、设计开发不分离、技术任职的去流程化这些基本逻辑是没问题的，但是站在公司现有项目研发状态，我们问题的源头其实是业务领域专业化问题。
这里的专业化不是单纯的区分软件和硬件，就如同芯片范围内芯片与器件、接口到整机，软件也是一个非常宽泛的概念，很难说找到一个软件高手到哪个业务领域都是高手，互联网的业务线技术栈相似性比较高，但是公司的ICT业务技术栈相似性很差，比如一个互联网业务的架构首要问题是解决功能满足且后续可预见的扩展、大规模访问的可用性、用户数据（跟业务特征直接相关）的一致性，但是一个CT业务的架构首要问题是解决标准功能覆盖、各类异常通信场景可靠性、设备水平拓展能力、可测试性、安全问题，再考虑下操作系统、数据库、各类工业软件场景（比如去年热烈讨论的EDA、matlab等等）是不是又是另外一个场景。
不同的业务场景决定了不同的技术栈，不同的技术栈有各自合适的开发习惯，你让互联网类业务在项目初始阶段搞设计文档严谨评审就是开玩笑，对手已经上线获得了用户数据、进入了devop的正反馈，你让CT类业务裸奔上线发布，等来的不是客户数据是通信事故和商业赔偿，你让软件高手来搞EDA，他只能先把芯片设计场景对应到经典软件技术栈，比如我就在最开始认为整个EDA流程在设计端就像极了一个编译器，结果发现大量“pass”都关联了物理、器件模型，显然不搞懂这些东西的前因后果就敏捷不起来。
软件只是实现手段、不是解决问题的银弹，业务的专业性应该造就专业的软件工程师，而不是简单的可信工程师，各领域的专业性问题应该case by case的被各个业务部门担责、解决，这是很多“恶习”的源头。至于批评管理者和专家之间的关系，其实是一个正确的废话，因为缺乏对专业付出巨大精力的过程，自然不会有对专业的敬畏，一个再有责任心的管理者手上没有建立起对业务专业的衡量标尺，自然没办法有效建设专家队伍。
公司质量流程的出发点都是好的，甚至能感觉到都是从各种事故中吸收的教训，认真去看公司各类技术规范材料，发现深度和宽度都是相当用功的，只是“人教社”只能复杂撰写教材，各个学校各个专业自己解读、传播教材里的知识，没有人可以替代。公司是一个巨大的业务池，很难指望一纸规则厘清所有问题，各个业务团队自己当责，直面自己的专业领域，才是解决问题的有效线头之一。一句话，这本应该是一个各个局部做好，才能改善全局的故事，自上而下效率低、且实际很难毕其功于一役。主管低头看着自己的地，专家或者有志让自己团队变得更好的工程师们应该据理力争，否则批评公司再多，也改善不了。
看评论有句话还是挺有感触的：我们现在还在“工业化”时代，却妄图去引领“数字化”时代的发展。自己看看自己，其实从商业模式、研发制造到营销服，并不怎么“数智”。
文中吐槽的研发组织、流程、工具和环境等方面，其实都很明显是工业化时代的产物，对准的也是工业化时代的业务。所以根子，不在研发，在公司整体的业务设计、管理架构。
也未必就一定要照搬互联网企业的做法，什么都云化。是否敏捷、快速迭代，还是看业务本质：硬件类、核心部件，还是要稳定可靠的，好比造飞机。应用软件和云服务类、面向消费者的，需要及时快速响应，那么不单是研发，可能整个产品团队都要更加敏捷、扁平、快速决策和高效协同。
说白了，不同的业务目标和模式，决定了不同的组织形态和管理方式。
当然，尊重研发人员尤其是核心编码人员，树立工程师文化，减少管理成本，是很正确的。老板的“无生命的管理体系”也要考虑灵活性和灰度。商业的本质是创造价值，一切阻碍价值创造和传递的，终将死去。
“技术晋升通道不顺畅，能力较强的员工渐渐离开了开发岗位。”似乎这是我国软件行业普遍存在的现象，如果我司能把这问题解决好，成为国内软件行业的标杆问题不大。
1、xx对研发不满意了；
2、形式严峻，要瘦身；当年好像是瘦腰，不知道今年要瘦哪；
3、金字塔不金字塔其实不关键，多层组织架构造成管理上的浪费，么有使用先进的技术管理手段，这个是大问题；
4、撤了DU ，PDU太厚，搞了开发组，17级回归分等级等等都算是回退；不过也正常，软件还可以灰度发布，不好就回退版本呢；
5、研发队伍不好带了，加班缺乏使命感，认证考试很积极，也是指标和发文压着呢；最想学的没资源，不想学/考的浪费时间考试，反正对个人利大于弊，也算是好心办好事吧；至少提升了年轻人出去以后的竞争力；
6、任职一直是比较失败的，早就需要改革了；可惜没人听小X总的，也不敢带头瞎折腾，万一搞砸了咋办呢；任职是最应该首先数字化变革的；可惜，没人敢干，不是没人懂没思路；
7、忙的忙死，闲的内卷死，也不得内部随便流动；内源像是擦边球，搞事扭扭捏捏，特战队是领导相干，下面人反对，部门墙的根因在分配制度；
8、研发人员ABCD的考评，现在已经是弊大于利，没到考评季，所有人都痛苦的要死，背后不放枪也得回头多防着点；完全跟不上软件转型的形式要求了。当年ABCD考评制度促进了研发的活力，现在的ABCD已经阻碍了研发的活力。
嘴上说软件转型，而绩效制度不变革，那就是忽悠，扯淡。绝对考评的试点，也是扭扭捏捏，然后还要搞个排序，%；
9、炸掉研发金字塔，本来就是老板的“忽悠”，不一定明面上扁平了就更高的效率和产出；炸掉的不是金子他，炸掉的应该是利益分配制度。和GJ学习，以前追求“加满油的标杆带头冲锋效果”，现在应该讲究整体效率与公平。
10、还有一种炸法，就是多拆几个子GS。学荣耀，离婚/分家，人多了不好带，那就拆成多个各自玩。
8、在公司做研发8年多了,以前也心态稳定,相信板凳要坐十年冷,以学徒的态度和品质去面对自己承担的工作任务,对业务转换和工作安排基本上没有抱怨和怀疑.可是这两三年来,我越来越不自信了,发现工作总是那样扑天盖地,一波又一波,自己花了很多时间和心血保障了版本特性以及历史版本的验证,这在别人看来已经是理所应当,本该如此了.PL和LM们急切地需要看到亮点,看到能包装成高大上的东西.看见版本经理满口脏话地安排工作的时候,我在想研发人员的地位和自尊哪里去了?研发汪的待遇就是这样吗?如果一个研发人员连尊严和荣誉感都不能感知的话,那点钞票能代表一切吗?能够做出代表着工匠精神的产品吗?
写代码有什么前途，超过50行都写不了
这才是真知灼见，顶你
@绳命灰晃 5年前第一次看到这篇文章的时候，就和你一个观点，握个手
写的真好，学习了！
写的很好，分析得很透！
每个人都是组织的一份子，做好自己的工作，整个组织才会逐步变成自己想要的样子。
我们客户群的差异，大到已经按BG划分了，这么多代码，这么多产品，这么多场景。。。就一套流程规范。看看EBG被吐槽的N久的行业解决方案，根不就是专业化问题么？不成功，我不认为是华为人不努力了，摸鱼的还是少数，但是如果用错误的方法去奋斗，累死也未必能成。