你好，我是乔新亮，很高兴又和你见面了。
上节课我们聊到，面对“需求做不完，应该怎么办”这个问题，首先要认识到需求是永远做不完的，但要尽量节约各类需求对管理者精力的影响。
在此基础上，我们对管理者的工作重点进行了拆分，认为初/中级管理者主要解决效率问题，高级管理者主要解决价值问题，并聊了聊初/中级管理者提升效率的三个要素。
在这一节，我想和你重点聊聊，高级管理者如何解决价值问题，并对最近两篇内容做一个简短的总结。
需求处理量提升至 150%，仍然无法满足业务方要求
前面我曾介绍过自己，也多次提及在苏宁的那段工作经历。
我进入苏宁的职位并不算高，最初只是一名总监。一年后就获得了晋升，Title 变成了总裁助理，同时直线管理 CTO 办公室和苏宁云研发中心，管理的团队规模急剧增加。我记得，当时直线管理了 500 多人，虚线管理有近 5000 人。后来又经历了几次升迁，到最后离开苏宁时，我的 Title 是科技集团副总裁，研发团队规模已经达到 10,000 余人。当时苏宁的技术系统也很复杂，大概存在 4000 多套系统，日高峰发布接近 4000 次。
可以想见，这样的团队规模配合这样的技术系统，需求量该有多么可怕。
所以，在最初一段时间，我的压力非常大：业务方怨言很多，主要是需求处理不及时，积压严重。
于是，我重点推行「管理数据化」，主抓技术团队的“产能问题”。其作用还是相当明显的，大概一年后，在规模不变的情况下，技术团队处理的需求量大致提升到了 150%，但业务方还是不满意。
为啥呢？因为需求是永远做不完的。
到这里，我有两条路可走：
- 继续解决效率问题，将需求的处理量提升到 200%、250%、300%……
- 像高级管理者一样，转而解决价值问题。
在上一讲，我们提到，所谓“价值问题”，就是要对需求的价值做出回答，明确这个需求在公司季度、年度目标中的地位，决定某个业务需求的优先级。
说白了，技术部门拼死拼活干了一整年，所做的需求并不都是有用的。谁来对这些需求的必要性和优先级作出回答？谁来衡量这些需求的价值有多少？
我认为只有解决了价值问题，才能在更高维度上保证公司越来越好。
同时这个选择也关乎你的个人定位。你会发现，表面上公司是在为了需求积压而焦虑，实际上是在为业务发展的困境承受煎熬和困扰。
如果你对自己的定位是个高级管理者，那就必须直面这类问题；如果定位是初/中级管理者，我们大可以好好做架构，继续跟进效率问题，保持职级不变。
你可能会说，需求处理量都提升到 150% 了，还能怎么提升效率？
去除各种花哨的外表后，答案其实很简单：压榨内部团队。在这一点上，许多管理者倒挺有一套的。只是“提升效率”要适度，否则容易造成团队的抵触和人才的大量流失。不要看到华为在加班，就学着人家一起玩“狼性文化”，你的激励体系、薪酬体系、考核体系和华为不一样。
这里我想再重复一遍，高级管理者解决价值问题，初/中级管理者解决效率问题，一切取决于个人定位。
我对自己的定位和要求是高级管理者，所以我选择了路线二，解决价值问题。
建设产品型研发组织结构，做战略上的聚焦
怎么解决价值问题呢？根据这些年的经验和思考，我认为第一步是要由“项目驱动”转向“产品驱动”。反映在体系架构上，就分别代表了“职能型研发组织”和“产品型研发组织”。这一点，我们在“管理三板斧”的部分，也曾重点介绍过。
在大部分情况里，技术部门会为了层出不穷的需求疲于奔命，但业务上的颓势没有丝毫缓解。比如一个CEO 的困惑：为什么我在技术部门身上投入这么多成本，在物流时效方面却收获不到应有的效果？
而当“产品驱动”的思想深入组织时，人人都是产品经理和业务专家，CEO 的焦虑应当是：为什么我们的物流时效产品比竞争对手差那么多？
差别在于，在“项目驱动”的模式下，可能没人对需求的价值作出负责任的回答 —— CEO 或 某事业部总经理单个人的精力不足以覆盖每一个需求；但在“产品驱动”的模式下，所有需求都应该是对产品价值的准确回答，因为这是团队共同的责任。
我认为，最终所有组织都要转变成面向产品的形态，这就是主要原因之一。
回到“需求做不完”的问题上，在对组织架构进行上述调整后，你会发现需求的数量大大减少了 —— 过去存在太多 ROI 低、优先级低的“伪需求”。从前，如果研发团队一年需要处理 100 项需求，那么如今可能只需要处理 30 项需求。整体的需求数量大大减少了，目标更聚焦、力量更集中，且与 公司季度目标严格对齐。
当然，这里有一个前提，就是团队能力尚可，技术上不存在太多挑战。作为一名高级管理者，如果麾下团队还时常面对许多技术挑战，那就说明还有太多基础工作没做好，要注意为团队先打好根基。
深度干预集团战略和激励体系
好，看到这里，你可能会想：嗯，听起来很简单，我学会了！
如果我告诉你，以上方法存在两大最致命问题，你能觉察到问题出在哪吗？现在你可以停下来用一分钟的时间细细思考一下。
可能你在心里已经有所计较，但想法还不够清晰，不妨与我接下来所说的对照参考一下。
问题一：
当团队存在“需求做不完”的困扰时，业务方往往是已经存在大量怨言的。这很正常，因为在业务方看来，当下的业务困境大半来源于技术部门的不合格支持。
作为技术部门的老大，你不但不考虑如何完成更多需求，反而准备打着“面向产品”的旗号，将 100 + 需求处理量变成 30 +，恐怕有点过分吧。况且，这里不是说由 100 项需求直接裁剪为 30 项需求，而是立足产品和公司战略，设计出全新的 30 项需求。
那么， CEO 为何要说服业务部门配合调整？谁来重新定义技术部门的 KPI 或 OKR ？谁又能罗列出这 30 项需求的具体清单？
问题二：
对于团队来说，架构调整是一回事，行为模式又是另一回事。表面上看，需求数量减少了，工作更轻松了；但实际上，人人都要设法对齐 OKR 、熟悉业务、思考产品，代码背后的工作变多了。一般团队很难在心态和行为模式上作出比较好的转型，很可能全员思维僵化，继续等待需求下发，下意识认为没有需求就等于没有工作。
你可能会想，此时团队应该换血，招聘新人加入。可少数新员工很难影响到多数老员工，一段时间后，反而会是新员工被老员工同化。
怎么样，是不是有些棘手？实际上，这两个问题，既是解决价值问题的最重要的两个步骤，也是本文话题真正的核心难点：单凭你自己，很难对价值问题作出完整解答，也很难真正解决「需求做不完」的问题。
我们先来看第一个问题，答案是：CEO 对业务和产品的认知，决定了他会不会说服业务部门；CEO 应该重新定义技术部门的 KPI 或 OKR。
所以我们常常提到的数字化转型，其实是一把手工程，一把手最重要的工作就是战略聚焦。
从概念上讲，这听起来像向上管理，但实际执行起来却不太一样。我们前面也提到过，所谓“向上管理”，是通过全局思维将认知提升到“老板层次”，然后做老板的期望管理或某一项工作任务的认知管理。
而这里却要求老板对公司的组织架构和业务驱动模式来一场大修，无疑相当困难。对于初/中级管理者来说，你甚至没有为难的必要，因为你只是个需求执行者；对于高级管理者来说，影响 CEO 一定要相当谨慎，不然很容易被理解成“为绩效不达标找借口”，壮志未酬身先死。
不得不说，此类问题也曾让我困扰。我失败过、困惑过，有时也践行不了自己的管理理念。 不过，经过这两年的实践，现实已经充分验证了这套“产品导向”架构体系的优越性。
对于第二个问题，答案是：重新规划考核体系，并将业务部门纳入考核；重新定义激励体系，从面向需求转为面向产品。
影响 CEO 只是第一步，第二步是要辐射到业务部门甚至人力资源部门，这更加困难。技术人的脾气是将数据和细节做到极致，最终一定会将流程里的所有变量纳入体系、进行考核。但问题是，技术部门凭什么考核业务部门？又凭什么影响人力资源部门？所以说数字化转型是一把手工程，不完全是 CTO 的工作。
对于任何一个产品，考核业务部门IT化水平，考核IT部门为业务部门带来的增长，就是业务IT一体化，业务就是IT，IT就是业务。
高级管理者要思考的是如何让公司越来越好。当高级管理者看到公司挣扎、彷徨的根源时，会勇于直面问题。但对很多有心人来说，这一切就只是办公室政治斗争的具现。
所以，以上两大问题，或者叫作关键步骤，都未必能在一家企业内一并解决。有时，退一步亦是海阔天空，你可以在接下来的职业生涯中，不断去探索最优解。
结语
我们前后用了两讲的时间，对“需求做不完，怎么办”这一问题做出了拆解。这里，我们再来整体梳理一下：
首先，我们要认知到，需求永远都做不完。
而在此基础上，初/中级管理者主要解决效率问题，高级管理者主要解决价值问题。
解决效率问题依赖专注做事的习惯和方法、高效的时间管理方法和「别让猴子爬上背」的管理价值观；
解决价值问题依赖产品型研发组织的构建、对 CEO 的影响力以及对业务及其他部门的影响力。
而经过这些年的历练，我认为，追求效率要适度，追求价值则要无所不用其极。
很多管理者在战略层面懒惰，逼迫下属用勤奋来解决战略问题，期望下属做得“又快又好”。试问，若我做得足够快，怎么可能做得足够好呢？基层员工在执行上的勤奋，无法弥补高层在战略上的懒惰。而对高层乃至 CEO 的认知影响，无疑是此类问题中，最困难的部分。
当然，有时解决问题的思路要更活络。在下属无法对 CEO 的决策产生影响的情况下，通过外部咨询的方式给 CEO 提供转型意见，最终也“曲线救国”，成功实现了目标。
如果你也有类似经历或经验，欢迎在评论区留言，与我互动。
到了这一讲，我们在管理层面的复盘，就基本接近尾声了。
如果你认真学习了前面的内容，你会发现：要解决一个实际的成长问题，往往会涉及多个过往不同方向的知识点，包括“管理三板斧”、全局思维、战略聚焦、管理哲学，等等。这一切都是融会贯通，互相促进的，只有这样，才能形成管理逻辑上的闭环。
在管理方面，我的讲述要结束了，但希望我们的思考不会停止。你可以随时留言，我会尽可能地回复。同样，我们专栏的最后一部分：「对专业成长的复盘」也即将到来，欢迎你继续关注。
让我们下一讲再见。
精选留言
2020-11-27 03:37:32
拥有什么样认知和性格的Leader，带出来的就是什么样认知和性格的团队。
2020-11-27 11:22:49
先谈问题，主要在人员配置能力选型上，通用的人员配置产品，研发，测试，运维，表面上看没有什么问题，但是能力选型怎么选，普遍的情况，产品不懂研发，研发不懂业务，测试和运维属于辅助，不是人员的拼凑就一定能整合成一支行之有效的战队，未必能达到1+1大于2的效果和持续提供战斗力。在之前很多大型支付公司的工作中，就遇到产品，研发，测试，运维在业务认知不在一个维度上，鸡对鸭说也很难统一，时间在内部扯皮中过渡消耗。
再谈思考，好，最简单的办法是产品主导认知，看似没错，细想想真的对么。我的认知是，初期是没有问题的，但是伴随着业务的持续稳定后，一定还是这样么，尤其到了后期在产品的平台建模上（已经从初期的抢占市场求快，逐步转化到后期求智求好的阶段，不然一味的求快，如果不能进行更好的自身平台的优化调整重构，就会像垒玻璃球一样最终发现没有办法垒了，重来成本又消耗巨大，进入两难的局面）。其实，在这个过程中研发&架构可以通过自己的技能反哺产品线的（建立在懂业务的前提上），可以让这条产品线逐步做的更智，更具备市场的竞争力，也就是由单纯的产品驱动，变成了产品&架构驱动，而这种重构需求不是单纯的产品角色能提出的，所以后期应该是一个多角色共同主导的局面出现，但是目标是一致的，逐步完成从拼凑到整合的过程（从幼生期到成熟期）。
再深度思考下，根据上述的场景很多公司可能会引入了架构师或者技术管理部门，引导团队架构驱动，做的好确实是行之有效的措施可以指导好团队。好，如果选对了架构师，技术管理部门的思想也能够很好有效的渗透到各个部门中，那是大有益处的，但是如果不能咋办。哪些情况可能导致不能，架构师已经偏于PPT而不懂实际研发工作了，很难提供有效的指导，团队也未必服气，于是就留与纸面了。技术管理部门的方案虽好，但是团队由于自身的产品周期等原因，不执行，对应的架构师也不能很深入的帮到团队，看似很美的东西其实没有发挥实际效果。
由于个人原因，带过产品，研发团队也做过架构师，所以我谈谈理想中的产品方式团队的组成要求。产品人员也要逐步对技术有点了解，最起码能够倾听技术人员的声音；技术人员要有了解业务的心，要明白技术其实是为业务服务的，明白自己所做的事情的业务定位；而架构师要求就更高了要有业务，技术深度，能明白业务&技术的痛点，能出的了方案，更重要的还要能指导研发实现，更好能自行做出一些业务组件给团队更大的便利，当然架构是一种角色（研发经理和专职架构师都可以具备的属性）；再有一个好的团队管理者把这些人能很好的包容和调用起来，那就很厉害了。对测试和运维只是了解程度，不发表想法。
哈哈，写了这么多，真的是浅见，如果有认知缺陷，还麻烦乔老师狠批。在批评中成长，可能更能记得住 :)
2020-11-27 15:20:59
2021-02-14 10:57:15
业务方提过来的需求，很多时候是伪装成需求的解决方案，如果只是头痛医头脚痛医脚的被业务方牵着鼻子走，需求就永远做不完。跳出来，站在更高的维度用更大视野，找到问题核心把问题解决掉，就好像打蛇打七寸一样。一个好的解决方案可以改变业务部门的做事方法提升他们的工作效率，很多伪需求也就自动消失了。提出这样的方案需要管理者知识框架是对的，认知维度足够高才可以，在具体执行的时候，就像老师在课里讲的"无所不用其极"。高级管理者是公司资源的看门人，要掌握好公司资源，不能随意浪费，尤其是人力资源浪费。
2020-12-28 11:15:49
实际工作中，需求是一定有优先级的，而领导关注的往往都是优先级最高的需求（或者是因为领导关注所以优先级高）。那么，在一段时间内让一个优先级最高的项目保持足够的资源，集中团队的注意力完成一件事，类似sprint。
这样产生的效果很微妙，上层领导可以看到明显的成果，下层同学也有明确的目标，团队氛围也会显得更有干劲和凝聚力。虽然总体产出可能并不会提升，但各方的满意度都提高了。
2021-05-19 16:43:36
2021-03-09 17:49:52
2021-04-19 10:24:21
2021-02-18 15:27:23
外企的IT部门基本都在服务支持业务，我在想怎样衡量我们技术部门的价值？感觉一个重要的指标是来衡量技术给业务带来多少的价值。但是具体有一些怎样来衡量这个？比如需求的数量？每个需求的价值？ 有没有一些具体的指标？还有，有没有一些方法来衡量业务部门的信息化水平。谢谢！
2020-11-29 21:21:26
上半年在一本讲销售的书中学到了 FAB 工具，对于我们思考产品价值会有些帮助：
* Feature 特征，指产品的特点和属性。
* Advantage 优势，指产品的优势如何帮助客户。
* Benefit 利益，指给客户带来的好处。
我们这些 IT 习惯讲又开发了哪些 Feature，我们要改改，要重点讲对业务方带来了哪些 Benefit，如果能更进一步说明对「客户」或「用户」带来哪些 Benefit 就更好了。
「沟通创业价值，分享带来快乐」，坚持留言的第 9 篇。
2020-11-28 23:22:48
这一句话感同身受，一直以来业务部门都是在说技术满足不了业务，主要反映在几个方面：1）技术做一个需求太慢了；2）讨论业务问题时，经常听到业务部门说“这个需求我们早就提了”；3）需求立项评估价值时，业务部门会说“这个是系统基本功能，必须要有”。请教乔老师，如何区分一个需求属于业务需求还是基础功能？如何在立项时评估需求价值？
2020-11-27 08:56:12
2021-08-20 16:04:38
2021-02-20 01:15:44
2020-12-11 15:20:09
非常赞同乔老师的观点，越到后面，技术问题一般都不是问题。重要的是全局思维，产品思维，用户思维和业务思维。这点确实是高级管理者要学的。感觉目前的认知和经验不足，还达不到高级管理者的水平，课程越往后越难了，都不敢留言了，哈哈~
2020-12-04 16:35:13
我的收获：
a.“战略上藐视敌人、战术上重视敌人”就是高层重视战略价值，基层重视执行效率
2020-12-01 05:14:20
2020-11-28 11:49:17
产品型研发组织的来源是美国研究型大学的系和实验室的关系，还有摩尔定律的问题。现在一个产品很可能1~2年就消失了，职能型组织适应不了这个变化
产品型的研发组织可能是大多数企业起步阶段后的唯一选择，没有其他好的选项支撑企业发展得更好
2020-11-27 13:14:41
2020-11-27 12:10:06