|
|
# 15 | 需求做不完，应该怎么办？（高级管理者篇）
|
|
|
|
|
|
你好，我是乔新亮，很高兴又和你见面了。
|
|
|
|
|
|
上节课我们聊到，面对“需求做不完，应该怎么办”这个问题，首先要认识到需求是永远做不完的，但要尽量节约各类需求对管理者精力的影响。
|
|
|
|
|
|
在此基础上，我们对管理者的工作重点进行了拆分，认为初/中级管理者主要解决效率问题，高级管理者主要解决价值问题，并聊了聊初/中级管理者提升效率的三个要素。
|
|
|
|
|
|
在这一节，我想和你重点聊聊，高级管理者如何解决价值问题，并对最近两篇内容做一个简短的总结。
|
|
|
|
|
|
## 需求处理量提升至 150%，仍然无法满足业务方要求
|
|
|
|
|
|
前面我曾介绍过自己，也多次提及在苏宁的那段工作经历。
|
|
|
|
|
|
我进入苏宁的职位并不算高，最初只是一名总监。一年后就获得了晋升，Title 变成了总裁助理，同时直线管理 CTO 办公室和苏宁云研发中心，管理的团队规模急剧增加。我记得，当时直线管理了 500 多人，虚线管理有近 5000 人。后来又经历了几次升迁，到最后离开苏宁时，我的 Title 是科技集团副总裁，研发团队规模已经达到 10,000 余人。当时苏宁的技术系统也很复杂，大概存在 4000 多套系统，日高峰发布接近 4000 次。
|
|
|
|
|
|
可以想见，这样的团队规模配合这样的技术系统，需求量该有多么可怕。
|
|
|
|
|
|
所以，在最初一段时间，我的压力非常大：业务方怨言很多，主要是需求处理不及时，积压严重。
|
|
|
|
|
|
于是，我重点推行「管理数据化」，主抓技术团队的“产能问题”。其作用还是相当明显的，大概一年后，在规模不变的情况下，技术团队处理的需求量大致提升到了 150%，但业务方还是不满意。
|
|
|
|
|
|
为啥呢？因为需求是永远做不完的。
|
|
|
|
|
|
到这里，我有两条路可走：
|
|
|
|
|
|
1. 继续解决效率问题，将需求的处理量提升到 200%、250%、300%……
|
|
|
2. 像高级管理者一样，转而解决价值问题。
|
|
|
|
|
|
在上一讲，我们提到，所谓“价值问题”，就是要对需求的价值做出回答，明确这个需求在公司季度、年度目标中的地位，决定某个业务需求的优先级。
|
|
|
|
|
|
说白了，技术部门拼死拼活干了一整年，所做的需求并不都是有用的。谁来对这些需求的必要性和优先级作出回答？谁来衡量这些需求的价值有多少？
|
|
|
|
|
|
我认为只有解决了价值问题，才能在更高维度上保证公司越来越好。
|
|
|
|
|
|
同时这个选择也关乎你的个人定位。你会发现，**表面上公司是在为了需求积压而焦虑，实际上是在为业务发展的困境承受煎熬和困扰。**
|
|
|
|
|
|
如果你对自己的定位是个高级管理者，那就必须直面这类问题；如果定位是初/中级管理者，我们大可以好好做架构，继续跟进效率问题，保持职级不变。
|
|
|
|
|
|
你可能会说，需求处理量都提升到 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 提供转型意见，最终也“曲线救国”，成功实现了目标。
|
|
|
|
|
|
如果你也有类似经历或经验，欢迎在评论区留言，与我互动。
|
|
|
|
|
|
到了这一讲，我们在管理层面的复盘，就基本接近尾声了。
|
|
|
|
|
|
如果你认真学习了前面的内容，你会发现：要解决一个实际的成长问题，往往会涉及多个过往不同方向的知识点，包括“管理三板斧”、全局思维、战略聚焦、管理哲学，等等。这一切都是融会贯通，互相促进的，只有这样，才能形成管理逻辑上的闭环。
|
|
|
|
|
|
在管理方面，我的讲述要结束了，但希望我们的思考不会停止。你可以随时留言，我会尽可能地回复。同样，我们专栏的最后一部分：「对专业成长的复盘」也即将到来，欢迎你继续关注。
|
|
|
|
|
|
让我们下一讲再见。
|
|
|
|