乔新亮的 CTO 成长复盘
乔新亮
彩食鲜副总裁兼 CTO、前苏宁科技集团副总裁、TGO 鲲鹏会荣誉导师
9321 人已学习
立即订阅
登录后,你可以任选2讲全文学习
推荐试读
换一换
01 | 职业生涯发展规划:每五年登上一个新台阶
02 | 到底该怎么理解工作与薪资的关系?
07 | 管理者最重要的三个任务(一):组织调整到位
课程目录
已完结/共 29 讲
开篇词 (1讲)
开篇词 | 削弱运气的价值
对个人认知的复盘 (6讲)
01 | 职业生涯发展规划:每五年登上一个新台阶
02 | 到底该怎么理解工作与薪资的关系?
03 | 看透本质:研发出了生产事故,到底要不要罚钱?
加餐(一)| 大学毕业,我要不要留在一线城市互联网公司?
加餐(二) | 工作遇到不懂的问题:何时可以求助,如何正确提问?
加餐(三)| 选择决定上限,努力决定下限
对管理工作的复盘 (10讲)
07 | 管理者最重要的三个任务(一):组织调整到位
08 | 管理者最重要的三个任务(二):加强组织协同效率
09 | 管理者最重要的三个任务(三):激发团队活力
10 | 管理的人性哲学:金刚之怒,菩萨慈悲
11 | 全局思维和持续完善体系的建立,让团队持续成长
12 | 管理战略上的聚焦和放弃:有舍才有得
13 | 风险管理:世界是脆弱的,持续管理风险非常重要
14 | 需求做不完,应该怎么办?(初/中级管理者篇)
15 | 需求做不完,应该怎么办?(高级管理者篇)
加餐(一) | 如何通过演讲分享,打造自己的影响力?
对专业成长的复盘 (10讲)
17 | 架构决策,是技术管理者最重要的能力
18 | 架构设计,专业分工和协作精神的体现
19 | 产品思维,契约精神是基础,洞察人性才能成就卓越
20 | 高可用设计,让产品没有后顾之忧
21 | 高性能设计,一切都围绕着契约精神
22 | 扩展性设计,看透业务的本质
23 | 考虑限制,让自己的产品不入险地
24 | 监控设计,让一切都有迹可循,尽在掌控
25 | 异常设计,让错误无处遁形
26 | 上云设计,融合云计算的未来
结束语 (1讲)
结束语 | 做时间的朋友
编辑手记 (1讲)
编辑手记 | 我被老乔洗脑了
乔新亮的 CTO 成长复盘
15
15
1.0x
00:00/00:00
登录|注册
开通超级会员可免费学习本课程,还可解锁海量内容免费学特权。

15 | 需求做不完,应该怎么办?(高级管理者篇)

你好,我是乔新亮,很高兴又和你见面了。
上节课我们聊到,面对“需求做不完,应该怎么办”这个问题,首先要认识到需求是永远做不完的,但要尽量节约各类需求对管理者精力的影响。
在此基础上,我们对管理者的工作重点进行了拆分,认为初 / 中级管理者主要解决效率问题,高级管理者主要解决价值问题,并聊了聊初 / 中级管理者提升效率的三个要素。
在这一节,我想和你重点聊聊,高级管理者如何解决价值问题,并对最近两篇内容做一个简短的总结。

需求处理量提升至 150%,仍然无法满足业务方要求

前面我曾介绍过自己,也多次提及在苏宁的那段工作经历。
我进入苏宁的职位并不算高,最初只是一名总监。一年后就获得了晋升,Title 变成了总裁助理,同时直线管理 CTO 办公室和苏宁云研发中心,管理的团队规模急剧增加。我记得,当时直线管理了 500 多人,虚线管理有近 5000 人。后来又经历了几次升迁,到最后离开苏宁时,我的 Title 是科技集团副总裁,研发团队规模已经达到 10,000 余人。当时苏宁的技术系统也很复杂,大概存在 4000 多套系统,日高峰发布接近 4000 次。
可以想见,这样的团队规模配合这样的技术系统,需求量该有多么可怕。
所以,在最初一段时间,我的压力非常大:业务方怨言很多,主要是需求处理不及时,积压严重。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
01 | 职业生涯发展规划:每五年登上一个新台阶
02 | 到底该怎么理解工作与薪资的关系?
07 | 管理者最重要的三个任务(一):组织调整到位
08 | 管理者最重要的三个任务(二):加强组织协同效率
18 | 架构设计,专业分工和协作精神的体现
23 | 考虑限制,让自己的产品不入险地
开通超级会员免费畅看本课程
开通会员
该文章仅可免费阅读部分内容,如需阅读完整文章,请开通超级会员或单独购买本课程。
登录 后留言

精选留言(29)

  • E
    通俗点说就是,Leader是团队的天花板,放大点说,总监是部门的天花板,CEO是公司的天花板。
    拥有什么样认知和性格的Leader,带出来的就是什么样认知和性格的团队。

    作者回复: 你好,E
    确实是, 找到一个好的leader,是非常重要的,也是很幸运的事,任何时候都是如此

    2020-11-27
    4
    18
  • Tony.xu
    哈哈,乔老师的第十五讲真香,现在看这个课程有点追剧的感觉,也提升了我的很多认知。下面谈谈一点在我视角上的思考。首先我不是高级管理者,所以针对这个方面的认知,我感觉乔老师讲的很有道理,个人不反对加班(996也OK,只要有实际意义),但是如果久久没有粮草的苦战,只有意识也吃不消哇。在围绕产品方式组件团队,也会有些内部的问题和思考,下面谈谈浅见。

    ​ 先谈问题,主要在人员配置能力选型上,通用的人员配置产品,研发,测试,运维,表面上看没有什么问题,但是能力选型怎么选,普遍的情况,产品不懂研发,研发不懂业务,测试和运维属于辅助,不是人员的拼凑就一定能整合成一支行之有效的战队,未必能达到1+1大于2的效果和持续提供战斗力。在之前很多大型支付公司的工作中,就遇到产品,研发,测试,运维在业务认知不在一个维度上,鸡对鸭说也很难统一,时间在内部扯皮中过渡消耗。

    ​ 再谈思考,好,最简单的办法是产品主导认知,看似没错,细想想真的对么。我的认知是,初期是没有问题的,但是伴随着业务的持续稳定后,一定还是这样么,尤其到了后期在产品的平台建模上(已经从初期的抢占市场求快,逐步转化到后期求智求好的阶段,不然一味的求快,如果不能进行更好的自身平台的优化调整重构,就会像垒玻璃球一样最终发现没有办法垒了,重来成本又消耗巨大,进入两难的局面)。其实,在这个过程中研发&架构可以通过自己的技能反哺产品线的(建立在懂业务的前提上),可以让这条产品线逐步做的更智,更具备市场的竞争力,也就是由单纯的产品驱动,变成了产品&架构驱动,而这种重构需求不是单纯的产品角色能提出的,所以后期应该是一个多角色共同主导的局面出现,但是目标是一致的,逐步完成从拼凑到整合的过程(从幼生期到成熟期)。

       再深度思考下,根据上述的场景很多公司可能会引入了架构师或者技术管理部门,引导团队架构驱动,做的好确实是行之有效的措施可以指导好团队。好,如果选对了架构师,技术管理部门的思想也能够很好有效的渗透到各个部门中,那是大有益处的,但是如果不能咋办。哪些情况可能导致不能,架构师已经偏于PPT而不懂实际研发工作了,很难提供有效的指导,团队也未必服气,于是就留与纸面了。技术管理部门的方案虽好,但是团队由于自身的产品周期等原因,不执行,对应的架构师也不能很深入的帮到团队,看似很美的东西其实没有发挥实际效果。

    ​ 由于个人原因,带过产品,研发团队也做过架构师,所以我谈谈理想中的产品方式团队的组成要求。产品人员也要逐步对技术有点了解,最起码能够倾听技术人员的声音;技术人员要有了解业务的心,要明白技术其实是为业务服务的,明白自己所做的事情的业务定位;而架构师要求就更高了要有业务,技术深度,能明白业务&技术的痛点,能出的了方案,更重要的还要能指导研发实现,更好能自行做出一些业务组件给团队更大的便利,当然架构是一种角色(研发经理和专职架构师都可以具备的属性);再有一个好的团队管理者把这些人能很好的包容和调用起来,那就很厉害了。对测试和运维只是了解程度,不发表想法。

    ​ 哈哈,写了这么多,真的是浅见,如果有认知缺陷,还麻烦乔老师狠批。在批评中成长,可能更能记得住 :)

    作者回复: 你好,Tony.xu
    谢谢你写这么多,真的都是特别好的思考。
    产品思维一定一直都很重要,产品思维其实不是一定是小分队由产品经理负责,其实更应该的是综合能力强的,但首要的是帮助业务成功的能力。
    所以,小分队的leader可以是任何背景出生的,不同出生的同学会有不同的优势,但技术会越来越不是问题,业务思维,产品思维,全局思维就会变得越来越重要。
    架构师很重要,公司的核心能力,稳定的是否能够抽象出来,适应业务的变化,会非常重要,帮助企业能够在更长的时间内跑的更快,让业务更成功。其实一个好的产品经理将来也是一个好的应用架构师。

    2020-11-27
    2
    10
  • Sam_Deep_Thinking
    这一讲的维度太高了,暂时只能先知道【有这么回事】,后续可能有机会实施吧。哈哈,给自己加油。

    作者回复: 你好,幻想
    加油,你可以的,看到你很多认真的思考和留言

    2020-11-27
    2
    5
  • 毕成功 Antony
    针对需求做不完的问题,我们在管理工作中有个不同角度的处理。

    实际工作中,需求是一定有优先级的,而领导关注的往往都是优先级最高的需求(或者是因为领导关注所以优先级高)。那么,在一段时间内让一个优先级最高的项目保持足够的资源,集中团队的注意力完成一件事,类似sprint。

    这样产生的效果很微妙,上层领导可以看到明显的成果,下层同学也有明确的目标,团队氛围也会显得更有干劲和凝聚力。虽然总体产出可能并不会提升,但各方的满意度都提高了。

    作者回复: 你好,毕成功 Antony
    这也是一种聚焦方法,特别好

    2020-12-28
    3
  • 能静居士
    乔老师,假如招聘到了一个下属是部门的负责人,总监。专业能力不错,管理能力也挺有一套,业绩也不错,但是这个人非常强势,有把部门内部原来的人都逐步替换成自己招聘的人或者自己的旧部的趋势。此时作为CTO,是否要去干涉?或者因为他业绩还可以,并且趋势也还可以,就再观察下?

    作者回复: 你好,能静居士
    要了解,沟通,是不是原来的确实不行,而不是山头意识,这个非常重要。
    能带来价值,并且不断提高人才密度,这是好事。另外要让原来的人找到自己合适的位置,这个也很重要。
    关键一点,出业绩,带领团队成功。

    2021-05-19
    2
  • 谷常生
    高层是 Doing the right things,中层是 Doing things right ,一两个人甚至一两个团队可以靠自觉,要让整个组织都实现「业务 IT 一体化」要靠体系。也许,除了「业务」和「财务」还要学学 HR,需要一本写给技术管理者的 HR 书 :)

    上半年在一本讲销售的书中学到了 FAB 工具,对于我们思考产品价值会有些帮助:
    * Feature 特征,指产品的特点和属性。
    * Advantage 优势,指产品的优势如何帮助客户。
    * Benefit 利益,指给客户带来的好处。

    我们这些 IT 习惯讲又开发了哪些 Feature,我们要改改,要重点讲对业务方带来了哪些 Benefit,如果能更进一步说明对「客户」或「用户」带来哪些 Benefit 就更好了。


    「沟通创业价值,分享带来快乐」,坚持留言的第 9 篇。

    作者回复: 你好,gucs
    总结的真好

    2020-11-29
    2
  • 极客一神
    乔老师,你每一篇专栏都值得我去思考,在工作中出现过很多你分析到的问题和困境

    作者回复: 你好,jkYishon
    共勉, 一起努力

    2020-11-27
    2
  • cool~doudou💯
    让我散装的意识终于有体系化了,今年Q1我花了绝大多数精力用在说服ceo,去掉伪需求,虽然结果是好的,但这个过程简直太艰难了,期间我无数次的怀疑自己是不是方向错了, 期间和业务部门产生了非常多的误会和矛盾, 个人感受最大的难点在于:一个技术人员,非得在业务插一脚,“指导”业务部门做业务, 还得证明自己是对的, 简直就是一个人要挑战整个公司, 我真是小心翼翼,每跟老板聊天我都得事先准备好脑图、资料、数据,来证明自己是对的。

    作者回复: 你好, cool~doudou💯
    你太棒了,坚持做正确且难得事情,坚持长期主义,一定可以上一个台阶

    2021-04-19
    1
  • 流沙
    请问对于技术团队的产能,数据化是怎么做的呢

    作者回复: 你好,流沙
    要把过程数据、结果数据都要收集起来,这是第一点,要有数据,对于开发人员、测试人员都有很多数据要看,我的专栏里面也提到了。
    第二, 要去分析数据,分析数据的时候要整体来看,不要直接用数据做绩效,非常不好,分析数据还是管理者自己来做
    第三,复盘,数据分析看的是数据,关注的是人,人的效能怎么提升是关键点。要激励人,而不是把团队成员放在管理的对立面。

    2021-03-09
    2
  • 旺旺(Jason)
    你好,乔老师。听了你的课,特别受用。谢谢你的分享。
    外企的IT部门基本都在服务支持业务,我在想怎样衡量我们技术部门的价值?感觉一个重要的指标是来衡量技术给业务带来多少的价值。但是具体有一些怎样来衡量这个?比如需求的数量?每个需求的价值? 有没有一些具体的指标?还有,有没有一些方法来衡量业务部门的信息化水平。谢谢!

    作者回复: 你好,Jason
    你说的特别对,最后都是要给业务带来的价值。
    第一,明确自己的产品
    第二,明确自己负责产品的用户
    第三,明确给用户带来的价值
    关于第三点,尝试用购买产品的角度思考,你提供的产品你的用户愿意花多少钱购买。
    价值可以是营收的增加,利润的增加,人员的节省,人员工作时间的节省,效率的提升,最后都算成钱会比较好。需求的数量,需求的价值都是过程性的指标,这些指标要继续往前推导,推到到钱是最好的。

    2021-02-18
    1
  • adang
    现在公司真实发生的事,技术主管在加入公司前,研发加班加点的干活满足运营部门的要求,可需求仍然无穷无尽。技术主管加入后,重新规划把运营部门需要的统计功能做了很好完善和优化,为运营部门老大做决策提供了更好的依据,这项工作做好后,运营部门的一些需求就自动不需要了。

    业务方提过来的需求,很多时候是伪装成需求的解决方案,如果只是头痛医头脚痛医脚的被业务方牵着鼻子走,需求就永远做不完。跳出来,站在更高的维度用更大视野,找到问题核心把问题解决掉,就好像打蛇打七寸一样。一个好的解决方案可以改变业务部门的做事方法提升他们的工作效率,很多伪需求也就自动消失了。提出这样的方案需要管理者知识框架是对的,认知维度足够高才可以,在具体执行的时候,就像老师在课里讲的"无所不用其极"。高级管理者是公司资源的看门人,要掌握好公司资源,不能随意浪费,尤其是人力资源浪费。

    作者回复: 你好,adang
    写的真好,真棒,理解非常到位,加油

    2021-02-14
    2
    2
  • Weehua
    想判断需求的价值和优先级,必须懂业务,否则很难说服业务。如果技术管理者熟悉业务,可以给业务很多建议,遇到不合理的需求问几个问题,估计业务就不会乱提需求了。这也就是高级管理者都需要懂业务的原因吧。作为初中级管理者的我们,大部分情况下对业务的理解程度是不够,把主要精力放在了人员管理和技术架构方面了,不懂业务,肯定就没有办法判断需求价值和优先级了。

    非常赞同乔老师的观点,越到后面,技术问题一般都不是问题。重要的是全局思维,产品思维,用户思维和业务思维。这点确实是高级管理者要学的。感觉目前的认知和经验不足,还达不到高级管理者的水平,课程越往后越难了,都不敢留言了,哈哈~

    作者回复: 你好,Weehua
    你的思考都特别好啊,加油

    2020-12-11
    1
  • dbtiger
    乔老师您好!
    我的收获:
    a.“战略上藐视敌人、战术上重视敌人”就是高层重视战略价值,基层重视执行效率

    作者回复: 你好,dbtiger
    谢谢分享

    2020-12-04
    1
  • 我能走多远
    这章节可能超出了我的认知范围,一直是底层开发者,目前感觉自己需要一个台阶上。拔高自己的认知。不知道自己适不适合做技术管理。今天和CTO提离职了。这里一直是啃老本没有提升自己的能力。也努力去找到自己上台阶的可能,但是太难了。所以决定离职。原因如下:个人负责业务基础平台的搭建,目前已经稳定运行,但是没有市场考验无法评估平台需要支撑数据(cto也没有这方面要求)。这个平台只用来作为公司核心平台的补充(核心平台cto维护,没有权限涉及)。2:技术方向可能要更换,但是评估那个方向就业面更窄,并且是其他厂家已经有比较完善的产品(我司基于客户需求要支持)。但是cto没有精力管理,而且偏离cto的想法。做的产品稳定很差,目前全部重新设计(个人认为完全是管理问题)。3:对我自己提升空间太小。基于目前困境决定换工作。

    作者回复: 你好,我能走多远
    认真思考,对自己负责,从长远看,做时间的朋友,只要不断提升自己的能力,长期一定有回报

    2020-12-01
    1
  • Ken
    表面上公司是在为了需求积压而焦虑,实际上是在为业务发展的困境承受煎熬和困扰。

    这一句话感同身受,一直以来业务部门都是在说技术满足不了业务,主要反映在几个方面:1)技术做一个需求太慢了;2)讨论业务问题时,经常听到业务部门说“这个需求我们早就提了”;3)需求立项评估价值时,业务部门会说“这个是系统基本功能,必须要有”。请教乔老师,如何区分一个需求属于业务需求还是基础功能?如何在立项时评估需求价值?

    作者回复: 你好,Ken
    其实站在长期的角度看,每个合理的需求都是产品的能力,但问题是当下是否有更有价值的功能要满足。
    聚焦不仅要看全局,更要看当下最重要的,最有价值的需求是什么。对于企业营收增加、利润增加、人效提升,资源节省的都是很重要的方面。

    2020-11-28
    2
    1
  • spark
    非凡的管理需要非凡的认知和分解,乔老师我有一个问题,“架构是侧重解决效率问题的?我以前认为是解决价值创新问题的”
    产品型研发组织的来源是美国研究型大学的系和实验室的关系,还有摩尔定律的问题。现在一个产品很可能1~2年就消失了,职能型组织适应不了这个变化
    产品型的研发组织可能是大多数企业起步阶段后的唯一选择,没有其他好的选项支撑企业发展得更好

    作者回复: 你好,spark
    架构是侧重解决效率问题的?
    架构是去发现一个研究对象中最核心的、稳定的部分。架构的组成部分是元素和元素间的关系。
    而本文中提到的效率和价值是针对不同级别管理者提出的思考维度,和架构的关系并不大。

    2020-11-28
    3
    1
  • worfzyq
    第二个问题打个问号,假如一线员工人人都去思考产品,这个在产品上升期没啥问题,但在产品过度期甚至产品爬坡期这两个阶段很容易出现员工过度考虑roi,执行没有动力。请问这个问题是怎么考虑的呢?

    作者回复: 你好,worfzyq
    一个企业要做的产品很多,按照产品型组织进行调整后,每个组织一般来说会负责很多产品。产品很难做到都很完善,如果都很完善,企业的产品很强了,那么公司的业务发展的也很好了,我看到的很多情况,很少的企业进入到这个时期。
    至于员工是否过度考虑ROI,如果员工真的都这样考虑,那太棒了,做选择题就好了,大多数情况是很多员工根本就没有财务思维,连个财务账都不会算。

    2020-11-27
    1
  • 黄立
    这更改的是组织协作的方式,在苏宁这么大的企业中,非常好奇是如何做到的

    作者回复: 你好,黄立
    对于大企业做这种调整,其实都涉及很大的变革,涉及很多方面。
    我在环球易购,在彩食鲜都做了这样的调整,效果非常好;有的时候,要知道有些事在有些时候不可为,接受它。

    2020-11-27
    2
    1
  • 鱼苗
    聚焦,很重要啊,新leader很容易眉毛胡子一把抓,忙了半天,产出还不理想,于是焦虑

    作者回复: 你好,鱼苗
    以终为始,每个考核周期,想清楚要达到的目标,然后为之努力。

    2020-11-27
    1
  • 麦田的守望者
    乔老师,您好。听到这一节有点直击内心的感觉。请容我先啰嗦下我们遇到的问题,我们公司有独立的技术部、产品部、业务部、销售部等等,我是技术部负责人,起初需求的优先级还是产品部门为主、业务部门补充的形式,渐渐的产品部失去CEO的信任,成了CEO抓产品,从产品的大方案到优先级乃至各种细节都亲自审核,提出的需求也渐渐随意了,产品部门自嘲自己是会画原型的工具人。几年下来,产品形态朝各种维度不断扩展,逻辑超级复杂。但是销售重心却仍然在最早的几个核心模块,花大量成本扩展新模块却鲜有过问。这样给我们技术部门造成困扰,维护难度和成本急剧增加,新需求响应速度逐渐下降,新员工上手越来越慢,销售部门得不到应有的支持也颇有怨言。CEO却对技术部门的产出和效率提出质疑,不停的指示大家要多加班,考核也是倾向于完成工作量的多少。所以,我的工作重心放到了,怎样提升团队工作效率和产出,技术架构升级、敏捷开发、KPI、OKR、团队人员调整都尝试过,很明显像您上面说的,效果不理想。所以这几年一直苦于“需求做不完”,忙来忙去不止我个人,从下面的项目经理到组员普遍成就感极低,大家的一副躺平的态度,公司让干嘛就干嘛吧,反正我们都是执行部门,不对决策负责。沟通过多次,碍于CEO的强势和固执,却反而质疑我们这些中层不了解市场,不理解公司的大方向,战略高度不够。面对这样的领导,该怎样向其传导用价值导向来评价工作,而不是陶醉于团队紧张加班的满足感中?

    作者回复: 你好,麦田的守望者
    一将无能,累死三军。
    这点首先我说很难得,坦诚得沟通一次,甚至是一起去喝一次酒,深入的尝试谈一次,这个主要看你的向上管理能力,但更大的取决于你的领导。
    只能不断尝试沟通,希望领导理解,为什么说数字化转型是一把手工程,就是这个意思。

    2021-08-20
收起评论
29
返回
顶部