07 管理者最重要的三个任务（一）：组织调整到位
你好，我是乔新亮。欢迎来到我们专栏的第二章：对管理工作的复盘。
在我身边，有些朋友技术很牛，别人调试了一个礼拜的 Bug，他三下五除二就搞定了；别人玩不转的高并发架构，他没用多久就设计完了。领导天天表扬，隔三差五还能给团队做个技术培训，很开心。
接着有一天，公司组织调整，程序员成为了管理者，整个人就懵了：不知道该干嘛。有的人是天天写 PPT，其实内心觉得管理是个很虚的事情；有的人坐着管理者的位置，干的却仍然是写代码的活。不懂管理，这是初级管理者的典型问题。
如果将视线拔高，你会发现，管理能力有些欠缺的技术总监、技术 VP，甚至是 CTO ，也都是存在的。我培养过许多技术总监，也经常收到猎头发来的“高薪求聘 CTO”的需求，说明当下在业内，仍然十分缺乏优秀的技术管理人才。
确实，做管理者不容易，大家都是一步步走过来的。前面我们讲了很多次关于“上台阶”的认知，每次登上一个台阶，挑战都会很大，需要时间去学习和适应，这很正常。
复盘这些年带过的精英团队、万人团队以及创业团队，我发现有一些知识，如果早一点掌握，能帮助快速搭建起关于管理的知识骨架，让你成长得更快、更系统。管理者需要做的工作很多，但如果只做三件事，会是哪三件呢？
在我看来，有三大管理任务始终最为核心，最应该在团队内率先落地，分别是：
- 组织调整到位；
- 加强协同效率；
- 激发团队活力；
你可能会想，这是不是过于简化了？要知道，做多容易，做少难，浓缩的才是精华，要学会将复杂的事情讲简单。
而且，这三大任务并不是孤立存在、毫无联系的，它们相互促进，共同实现「促进业务增长」、「建立企业竞争壁垒」等几个主要目标，同时构成了一个企业 IT 能力建设的增长飞轮。下面，我们先来拆解一下这个增长飞轮。
拆解 IT 能力建设的增长飞轮
在这张图里，飞轮有四个“叶片”，其中「端到端的产品管理」、「增强协同-项目管理」以及「绩效与激励体系」部分，其实就分别对应着管理者最重要的三个任务。在“飞轮图”左下角的「战略层面」部分，则代表着飞轮运转之后，给企业带来的业务增长。
下面我们来尝试理解一下，飞轮是如何运转的。但是你要注意，这张图的核心是飞轮本身，并不是其中某个单独的叶片。
飞轮的 1 号叶片，是绩效与激励体系。毕竟，没人会给企业免费打工，这是企业开始招聘、开始运作的起点。虽然我始终在说，对于个人不要为了薪资而工作，但对于管理者，金钱奖励仍然是最有效的激励措施之一 —— 尤其是在初中级岗位中，拥有正确认知的同学相对较少。
那么管理者要做的，就是通过团队成员的投入产出比评定绩效，通过阶梯式绩效建立有行业竞争力的激励体系。把这些做好了，在 2 号叶片 —— 项目管理部分，管理工作就有了一个好的基础。
说到项目管理，你一定比较熟悉，主要是立项、项目控制、风险管理、结项等。其中，立项非常重要，在大部分情况下，一个好的立项可以大大提高项目成功的概率。那么什么是好的立项呢？有三项工作一定要落实，分别是：
- 目标清晰：每个业务目标、产品目标、技术目标都要清晰且可量化；
- 责任到人：上述每个目标都要责任到人，不能都是项目经理扛，项目经理扛不了的；
- 承诺到位：如果需要外部组织配合，要得到外部组织的明确承诺；
如果上述任何一个条件没有落实到位，就不能立项；如果企业正处于快速迭代的阶段，可以适当放松要求，但开完项目启动会的一周内，以上三项都要落实到位，否则项目进入高风险关注列表。
在用人方面，要尽量提高人才密度。同样一份工作，宁可用两位中高级人才来完成，也不用三位初级人才来完成，主要原因是要考虑管理成本。
只会做项目还不行，我常说，做项目赢在当下，做产品赢在未来。高效地落地项目，是为了产品能更好地孵化出来。在 3 号叶片 —— 产品管理部分，重要的是建立面向产品的组织架构和机制，以产品为核心让组织运转起来。也就是说，项目管理是手段，目的是建设优秀的产品。
产品在企业内成功孵化后，最终要在市场上证明自己的价值，并为企业带来业务上的高速增长。这就来到了 4 号叶片 —— 企业战略层面。
这一部分我们主要关注业务增长，而业务增长又可以从长期、短期两个维度来理解。当下我们围绕产品做的许多工作，并不一定能帮助业务立刻跨上一个台阶，有些可能是在半年后才会深度影响业务的增长。但要记住，业务的增长一定是和产品能力的建设密切相关的。
最终，业务的增长带来企业营收和利润的增长，进而让激励体系变得更有吸引力。有关企业 IT 能力建设的增长飞轮，就正常运转起来了。
那么除了业务的增长，这个飞轮还能带给企业哪些价值呢？我认为在飞轮的运转过程中，企业的品牌是在不断被建立的。此外，随着越来越多的产品逐渐组成平台，甚至是形成对外云服务，企业积累的 IT 力量在不断增强，这也将在行业内形成真正的壁垒。
到这里，我们回过头，再看一下增长飞轮，任何一个叶片的缺失，其实都会导致飞轮停转。如果你只做绩效与激励体系，虽然短期内大家很开心，但时间一长，企业就要倒闭了，最终害了所有人；反之，如果只做项目管理和产品管理，不做激励体系，那你就成了“活雷锋”，花企业的钱为业界输送人才。
所以，我们在讲解管理者的三大任务时，是从“激励”到“增长”，按顺序介绍的。但这是一个飞轮，你可以从任何一个叶片开始看，在不同的启动点，关注点也不同。当然，图片能展示的内容有限，要让增长飞轮转得更好，我们还有很多内容需要讨论。但那都是后话，不要着急，接下来我们先来详细聊聊管理者的第一个要务：组织调整到位。
构建面向产品的组织架构
组织调整到位，在今天这个时代，就是要构建面向产品的组织架构，对应了「IT 能力建设增长飞轮」的叶片 3。
那为什么要先讲组织调整呢？因为组织架构是公司协作的基础，它决定了各团队如何思考、如何协作。如果组织架构不调整，研发团队是一条线、测试团队是一条线、产品团队是一条线，这在IT 团队里天然就形成了一定的壁垒和鸿沟，导致一些正确的战略决策落地执行慢，公司内团队协作效率差，容易扯皮。
所以在你有权限、有能力，时机恰当的情况下，我建议优先调整组织架构，从职能型研发组织结构，调整为产品型研发组织结构，也叫做“Pizza 型团队”。
比如，职能型研发组织架构的特征是：
- 每个研发中心为一个最大产品团队；
- 二级部门按岗位职能划分为多个专业职能部门，比如产品经理团队、研发团队，还有进一步把研发团队划分成开发团队、测试团队的；
- 每个人员仅归属到一个职能组织；
- 三级部门人员按编制无限扩充；
- 三级部门团队 leader 任命从岗位职能中挑选/竞聘，比如研发能力强的当研发团队 leader，测试能力强的当测试团队 leader；
产品型研发组织架构的特征是：
- 每个研发中心为一个最大产品团队；
- 二级部门按产品下分多个产品组织为三级部门，每个产品组织均形成一 个产品团队；
- 每个人员至少归属到一个产品团队，暂不限制归属产品数量；
- 每个产品团队约为 7 ~ 8 人，人数受限，最多 10 人；
- 每个产品团队产品经理、开发、测试齐备，是一个可以独立作战的小分队；
- 三级部门产品团队 Leader 可以是团队任意成员；
- 产品团队 Leader 要求（综合能力）：专业能力、领导力、汇报能力；
- 团队 Leader 任命原则为能者居之，能上能下；
你想一想，这里面最重要的变化是什么？我觉得有以下几个方面：
第一，产品经理、开发、测试，形成了一个整体，被赋予共同的文化价值观，为共同的目标去努力，战斗力变得更强了。
愿景、文化、价值观很重要。团队成员正在做的工作，是否被赋予了意义，会对工作的执行效果产生巨大的影响。比如我们彩食鲜的愿景是：希望全国人民，在生鲜食材方面能吃上可信赖的食材。当一个包含众多关键岗位的战斗小分队，都一起为这样的目标努力时，力出一孔，战斗力肯定比单打独斗强。
第二，无论是产品经理，还是开发、测试，都开始和业务部门熟悉起来，和运营同学坐在一起，为自己的产品负责。
以前，业务觉得 IT 傻，啥也不懂；IT 部门觉得业务部门是这个时代的傻瓜，啥也不会。在我的团队里，这些都不存在，所有人都要熟悉业务，不需要熟悉业务的岗位一律外包出去。连运维都要求去学习业务，只有知晓了业务的特点，才能把运维做好。业务部门和 IT 部门是兄弟，兄弟齐心，其利断金。
心在一起是团队，心不在一起就是个团伙。为什么很多公司的业务团队和 IT 团队心不在一起？其实根本原因是组织整体架构设计的有问题，局部的优化不能从根本上解决问题，需要体系化的解决方案。
彩食鲜的业务部门和 IT 部门关系非常好：互相理解、互相支持；胜则举杯相庆，败则拼死相救。我相信，这是大家都向往的团队氛围。而我思考的是，怎么去营造这种文化氛围。答案是，要从底层开始进行设计，把最基础的架构设计做好。
第三，管理者开始能通过一套统一的绩效考核体系，去考核不同岗位的团队成员。
以前我们如何考核研发人员？可能是 Bug 数量，也可能是宕机时间。其实在大部分业务驱动型公司里，考核这些指标的意义真的有那么大吗？如果业务都死掉了，系统再健壮又有什么用？如果你的产品能给公司带来一两个亿的利润，偶尔宕机一次又有什么关系？
最终一切都要变好，但在前进的过程中，如何去寻找平衡，这是管理的智慧。身为管理者，你要学会灰度管理，不断在业务发展和技术能力建设中间寻找平衡。此外，管理者要将所有人的目标调整到业务发展上，联合大家一起寻找最优解，避免各方只关注局部优势，不看全局发展。
我对 IT 团队的定位是，IT 必须成就业务。我也建议你，如果能够影响公司的 IT 策略，一定要通过利润和营收，考核 IT 产品给业务创造的价值，同时考核业务部门的IT化水平。
我曾经和亚马逊零售部门的专家沟通过，发现亚马逊很早就开始将业务部门的 IT 化水平纳入考核。在一定时期内，如果采购部门的系统自动化程度不够，采购单是无法人工下发的。
具体到方案，你可以以产品线为单元考核，参照成熟度模型，设立有挑战的绩效目标。然后用业务价值的增量部分，按百分比抽取，回馈给产品团队。
你可能会想，如何估算业务价值呢，这有点难吧？其实也不难，业务价值参照公司、部门的收入和利润进行换算；如果出现不能直接计算的情况，按人效提升、人力节省的程度进行换算。在这里，我们可以用“开源节流”这个概念来给工作更明确的分级：
帮助企业增长、扩大市场份额的工作属于开源类工作，这些事情能做就做，要优先处理。比如让企业内连接、协同效率更高，让数据共享更透明，帮助决策更高效之类的任务，基本都属于开源工作。
节流类工作的优先级次之，具体是指人效提升、人力节省等。当然，有些工作既能开源，又能节流，效果最好。
别觉得复杂，有一个基本的设计原则，可以助你理解以上内容：企业做增长，个人看成长；鼓励每个人凭借自己的成长，在团队内贡献更大的能量，赢得企业的发展，最后在越来越大的蛋糕里，共享利益。
还有很多其他的细微差别，我就不再展开谈了，留给大家在实践中体会。重要的是，这么干下来，整个 IT 部门的氛围完全变了，业务就像爸爸，贡献行业知识；IT 就像妈妈，进行科技赋能。双方共同抚养了一个既懂业务又懂技术的孩子 —— 产品。
这孩子的能力构筑在平台的能力之上，拥有过去积累的所有经验，持续学习、不断进步、越来越强。当企业坚持对 IT 长期投入时，就会形成复利效应，让这个孩子所能贡献的价值越来越大。最终受益的还是“爸爸”和“妈妈”。
如何做组织架构的选型？
当然，不是说所有公司都要立刻构建面向产品的组织架构，你也不要看完专栏，就跑去找 CEO “谈心”。
关于如何在“职能型研发组织”和“产品型研发组织”间做选型，我有三个比较关键的考量标准，供你参考：
第一，如果公司在技术方面还存在比较大的挑战，建议选择职能型研发组织。比如说，产品经理、开发、测试的能力很差，还有很多技术挑战不好解决，这时不要冒失转型。
第二，如果技术挑战所剩不多，不要犹豫，建议转为产品型研发组织结构。
第三，通过设置技术管理办公室、云部门统一建设基础平台和研发管理平台，降低对于大多数开发、测试的专业能力要求。对于 200 人以下的研发团队，设置一个技术管理组织就可以，将研发规范管理和基础平台能力建设两个功能凝聚在一起；如果团队规模超过 200 人，就要尝试分成技术管理办公室和云部门，前者负责研发管理规范，后者负责基础技术平台的研发。
你可能会说，我还没有权利做组织架构设计和调整，我能得到什么呢？在专栏的第一章，我讲过，要学习看清楚问题的本质，养成遇到问题多思考的习惯。现在，你就可以结合自己的工作，好好想一想，这套调整方案背后的本质是什么呢？
如果你是个项目经理，可以想想做过的项目，调整自己的视角，想想如何利用类似的思维模式解决项目问题；如果你是个架构师，想想这个和架构设计有什么异曲同工的地方？
无论你是产品经理、测试经理还是资深开发人员，都可以结合自己的工作，想想有什么触类旁通的问题。
虽然以上管理措施，并不是每一位管理者都有权立刻执行，但要学着先听、先了解。交流得多了，你可能会发现，其实成功的高层管理者，在管理方法上，都有许多共通之处。提前接触这些内容，有助于你拔高自身认知，更清晰地看待当下的成长路径和工作目标。
同时也不能看过了就扔一边去了。每过一段时间，就要记着来拿出来重温一下，会特别有好处！
当然，你也不用担心此后的每一讲都与中层管理者无缘，我们的内容将涉及多个层次、多个维度。
如果你已经是一名拥有决策权的高层管理者，那就太棒了，以上所讲方案均来自我在环球易购和彩食鲜的管理实践，欢迎留言与我交流技术与业务团队管理心得。
结语
到此为止，我们专栏第二章第一讲的内容，就接近尾声了，内容从认知部分跨越到管理部分，不知道你听得怎么样？
作为管理者，要学着带领出一支能征善战的队伍。这一讲，就是在讲如何搭建一支能适应“现代战争”组织形式的队伍。
接下来的两讲，我们会重点讲一讲如何加强协同效应、如何激发团队活力。这三讲，将共同构成技术团队管理的“三板斧”。
都做完了，就可以带团队去打胜仗了：每个季度定有挑战的目标，组织团队拿下这个目标。胜仗打得多了，就会养成赢的习惯，就会将“打胜仗”当作一种信仰。当这支团队再看到有挑战的任务时，就会兴奋地冲上去，然后拿下它！
希望大家都能成为各自企业内的“常胜将军”，我们下一讲再见。
- 术子米德 👍（34） 💬（4）
🤔☕️🤔☕️🤔 怎样分饼，决定了饼能做多大，看清饼的样子、看到饼增长的过程，才能更让自己知道，怎样努力、怎样有机会分到属于自己的饼。 经常看到一种现象，那就是整天忙忙碌碌的很，但是不知道这些忙碌的来龙去脉，也不知道这些忙碌会带来什么收获。 于是，就给自己一个暗示，我就是那个喜欢技术的人，我就是要把自己的技术打磨到铮亮。把自己封闭在一个技术笼子里，工作和思维都限制在这个透明笼子里，自己躲在笼子里，啃口小饼。 如老师所言，要是大家都能懂得业务，大家有一致的价值观，有相同的奋斗目标，大家都看到一起在把饼做大，而且知道以后肯定有我一份。我都不敢想下去了，真不知道，要是我在这样的团队，会激动成啥样。 但是，有个小困惑，根据老师的经验，这样的团队，相对而言是容易遇到，还是只能靠具有这样认知的技术领导打造呢？按理说这既然是个团队的好模式，为何不在技术公司里普遍存在这样的团队呢？ 如果这样的团队是良币，到底是怎样的劣币驱逐着良币呢？
2020-11-09 - 相逢是缘 👍（26） 💬（3）
目前碰到一个问题，乔老大能给点建议、指导 公司里有个比我来的早三年的同事A，A也比我多三年相关技术行业工作经验，技术能力挺强。A是别的部门的，由于各种原因现在调到我们部门，现在领导把他放到我下面，我下面也就四五个人。现在和A说话几乎不睬我，发信息一般不回。现在不知道如何处理。
2020-11-09 - 流浪地球 👍（24） 💬（4）
听了老师的这篇课程，深有感触。 所在公司刚刚结束了一轮组织架构的调整，但是从产品研发型团队向职能型团队的转变，去掉了一个个的项目部，按照产品、研发、美术来组织架构，整个过程历时1年左右，就像“消藩”一样，同时还要伴随着产品的快速迭代，实属不易。当然，如此调整也是为了解决老师文中提到的一些问题，如基础技术架构建设，人员能力提升等相关问题，职能型的团队可以让各个职能部门更加关注自己专业的部分。 调整完一段时间后，职能型团队的一些缺点也展露无疑，最明显的就是互相扯皮，产品和研发目标无法统一，互相瞧不起，都觉得对方做的不对。所以，我觉得在基础技术架构搭建完成，团队成员能力整体提升之后，还是要回归到产品型的团队，赋能给每一个产品，让大家的目标一直，激励一致，同进同退，才能最大程度激发团队的战斗力。 最后想说的是，这种团队结构的调整，最需要的还是老板层面的支持和信任，这是一个耗时费力的工作，而且过程中会遇到很多困难和质疑，如果老板对这种调整缺乏支持和信任，很容易导致调整者被离开。
2020-11-09 - 风轻扬 👍（18） 💬（2）
听到老师说。帮助彩食鲜上市之后，就会离开，踏上下一段旅程。突然想起了雷军，帮助金山上市成功，转身背包就离开创建小米。那老师这么做的原因是什么？为什么安稳之后。就要进入不安稳之中？我真的非常敬佩您这种不断进取的精神。但是，确实是非常好奇，老师为什么总把自己处于变化之中。真的没有考虑过，在一家公司站稳脚跟之后终老吗？老师的终极目标是什么？
2020-11-10 - Ryan Feng 👍（12） 💬（1）
我们是纵向职能团队，前端后端测试运维产品，然后横向用项目和产品串起来前后端测试人员，人员规划、技术提升、平台支撑、架构选型由职能团队领导负责牵头管理，各项目产品对项目产品内人员进度绩效进行考核，职能部门领导配合，实际效果是纵横两个维度来管理，不知道职能和项目产品两个维度的管理实践乔总还有什么建议
2020-11-09 - Weehua 👍（5） 💬（1）
组织架构，一定是为了完成一定的目标！职能型和产品型组织，让我理解了公司组织架构设计的目标，提高了认知！ 组织调整的另外一个目的是划清责任，让专业的人做专业的事，大家更好的协同，发挥团队价值！
2020-11-15 - Keith T.Maxwell 👍（5） 💬（1）
这课程的估值少了两个0啊，把最干的货分享出来了，乔总一定是在新的纬度有更多的成就了。
2020-11-09 - Expif 👍（4） 💬（1）
最近公司也做了架构调整，由原来的职能性团队调整成了产品型团队，这样对于业务来说有了专门的研发团队，但是目前业务跟技术虽然只是在一个公司但是两个不同的部门，按照业务单元的形式划分后，实际实施下来就变成了甲方跟乙方的关系，业务很强势，处处造成技术很被动，这个关系一时半会还扭转不过来。这样对科技团队来说该如何进行调整呢。
2021-02-24 - 一切皆底层 👍（3） 💬（5）
乔老师 ，你好非常感谢！辛苦了，我描述一下我们公司组织架构： 1、目前是面向产品的纵向小分队（测试，研发，运营、产品经理等）组成的，分成8个产品线。 2、产品经理是小分队的Leader，小分队成员绩效考核由产品经理决定。 3、我属于技术管理部4人，（做IT管理，运维开发、中间件研发）帮助业务提高效率，上级领导是创始人的其中一位。 问题：每个产品线人员能力参差不齐，导致新版本发布有很多bug，严重一点的业务线接口相互调用出现问题（导致线上故障），技术管理部做了很多技术相关的培训，效果不好，产品线参与度也不高，大家经常说业务研发工作太多，没时间参加。 感觉纵向做了组织架构调整，横向缺少了什么。（公司没有cto） 希望乔老师能帮忙分析一下，非常感谢。
2020-11-09 - yxw 👍（2） 💬（2）
感谢乔老师的精彩分享，有两个问题想要请教一下： 背景：我们公司的组织架构属于矩阵型，有5条业务产品线，4条创新业务，处于业务摸索阶段，且相对独立，产品技术和业务组成5个虚拟团队，技术中心30多人，包含了前端、后端、大数据、测试，运维岗位，没有二级部门；技术团队规模不大，运维和大数据为公共支撑小组，当前组织架构以业务为导向，快速响应业务需求，因为各个业务相对独立，业务需求变化快，技术之间的交集很少，目前主要沉淀了自动化运维平台、基本的技术架构规范和基础组件，没有专人维护 问题1：技术沉淀少，团队技术氛围一般，现阶段想做好这两件事，是成立基础技术组专门负责还是由各个业务技术团队各自负责好？ 问题2：当前的组织架构下的技术leader对项目交付为主，各团队内后端、前端、测试、大数据等专业提升是否需要专业线leader来负责？感觉考核和汇报关系有点复杂了 以上，希望乔老师可以指点迷津
2020-12-06 - Geek_dmr6un 👍（2） 💬（2）
[在我的团队里，这些都不存在，所有人都要熟悉业务，不需要熟悉业务的岗位一律外包出去。连运维都要求去学习业务，只有知晓了业务的特点，才能把运维做好] 乔大好，个人非常认同您的这个观点。 遇到的问题是比如运维同学会讲，了解业务了还不是做发布，监控这些工作，了解业务干嘛呢？请教乔大这种情况怎么破？ 所有人都要熟悉业务，要熟悉到什么程度呢？如何量化呢？
2020-11-18 - 柯基道格 👍（2） 💬（2）
乔大大，你好 我们公司的组织架构是最近才调整的职能型研发组织，我不喜欢现在公司的这种模式。 我们公司特征，比乔大大的职能组织的例子还要更职能，也没有研发中心概念，如果算研发中心也就整个公司就是一个研发中心吧。 1、一级部是按岗位职能划分，如产品需求组团，开发团队，测试团队，运营团队等，但没有任何横向串联团队，如产品经理团队和项目经理团队来串各部门协作。需求实现是使用瀑布模式从需求-研发-测试-运营开展，负责人由几个职能团队中出一个人来负责。如果是内部优化，则开发做负责人，如果是新业务，由产品做负责人，如果是性能优化，则测试做负责人，如果是市场客户反馈需求，则是运营做负责人。每次负责人因为来自不同部门，多少会在整体驱动过程中偏向于自己部门，从而使得部门间协作有时不太协调。 2、二级部是是岗位再细分，如需求，业务条线细分，研发，语言和开发架构细分，测试，业务条线细分，外加工具研发，运营，运维和市场来分。 3、再之下是小组，还是岗位细分，需求的某些业务分配到人，开发的某个开发架构下某个项目分配到人，等，到小组这层，基本变成一个人在一个很细分的领域下要管好几个项目上的这一很小部分的细分领域。对于这个人来说对项目整体的视野范围非常之小。 这样模式下，目前遇到的问题 1、如果发生产事件，那就需求，研发，测试，运营，每人都要挨打，但实际已经足够小心也难免会发生。然后到了年终评选部门时，与项目不搭界的部门，如机房硬件运维部，人事培训部，就会经常获得好评。虽然不是说他们不重要，但是做项目错了，全部项目相关的全否，也是很打击士气。领导说这是为了让大家所有人都要时时刻刻警惕生产事件，一刻都不能放松。 2、人的能力下降，全栈能力下降。需求只会写文档，写完文档他们就认为是他们工作结束了，开发只会某个领域下的开发，且不做单元测试，因为来不及写，测试手工为主，自动化没空转，运营手工操作，自动化涉及开发，开发部的忙着实现各种需求，不接这种事，测试团队的工具组也不接，运维开发只给运维的钱，既会运维又会开发看不上这点钱。 3、逆淘汰问题，人员的越来越专，不知应该说是好，还是不好，但知道的是，有些既能做开发，又能做测试的人走了。因为把他算成测试了，钱比开发少。然后，不会测试的开发变成主流。会反而成为异类。 4、人员这碗水流动不起来，招人要求很高，我们不是互联网大厂，只是有国企背景的子公司，那吸引力是什么呢，国企背景下在落户上，在分配租房上，在早中饭三餐上都是有吸引力的，所以投得人真还挺多的，因此要求上来说不是985/211的硕士级别大领导都看不上。虽然说，有可以突破学历这条，但是极为苛刻，而且有工作经验的普本，在技术等级上要比985的硕士要低一档。现在符合条件都是应届生，应届生特点就是进人慢（11月发OFFER，但对方说明年6月毕业才能来，要3个月到6个月才能上手业务，等于进一个人要等一年），而社招条线已停，原因为人士部门要兼顾校招和社招忙不过来，再加上面的逆淘汰问题，还有镀金镀完，国企的福利得到后，就会另飞等等。想想就可怕，虽然我这个级别，也没有要求我去想这些。 5、技术序列和管理序列的问题，技术序列是隐性的。而管理序列是显性的，给所有人造成印象是管理序列才是领导，不走管理就不是领导，只有被安排干活。管理序列的提拔有着浓厚的国企风格，即领导秘书很容易变成领导，因为秘书天天和领导说话，而没有接触领导的技术负责人，很难升。这样结果就是 管理者，可以不会产品，不会开发，不会测试，不会运营，但他曾经是秘书，则他就可以做任务部门的负责人了。因此领导分付他的事，他肯定听，肯定去推。具体推不推得动，反正挂着大老板的名头，其它人也不得不听罢了。 个人现在就身处于国企技术部门转换技术公司的漩涡之中，身为二级部下的小组长，有理念冲突的地方，有想法但没地方提。因此这个改法是大领导说要这样改的，你反对他，这不就是在打他脸吗？
2020-11-16 - 里仁 👍（2） 💬（2）
乔老师好，对于支持型的后台系统产品，比如供应链系统、客服系统，怎么跟业务指标挂钩呢？
2020-11-13 - hzg 👍（2） 💬（1）
乔总，谢谢您的分享。本人在一家传统制造行业工作（销售规模千亿、多品类+多区域），IT支持公司的研发、制造、供应链、销售、服务等，近几年业务一直没有原有水平徘徊。现在很很困惑两个问题：1.IT的成效与评价是否要和业务的KPI绑在一起？ 对于业务没有处于飞轮转动情况下，激励体系怎么设计？绑在一起，如果业务不增长，IT激励也会成空，压力很大。不挂勾的话，内部做一些IT项目评比，择优激励。从自身角度也肯定希望业务增长。 2. 对于制造型企业的数字化转型体系，是否适合采用产品型组织？看相近行业标杆（华为），选择的职能型IT组织（包括流程变革、流程、架构、需求、应用开发等），核心强调的是流程导向，与战略衔接，与业务对齐。 对于不全是互联网领域的业务形态，是否适合产品型组织？ 期待后面精彩的分享。
2020-11-09 - :) 👍（2） 💬（1）
IT能力建设增长飞轮：1.绩效 2.项目 3.产品 4.业务 感觉这就如同一辆前行的车： 业务：前行的终极目标和方向，一切行为的最终指向和评判标准 绩效：车的燃料，驱动着车的前进。 项目和产品：前行路上的一个个里程碑。如何向着终极业务目标前进，把握着前行的节奏，在短期与长期，技术与业务间达到一个平衡。
2020-11-09