15 | 需求做不完，应该怎么办？（高级管理者篇）

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

哈哈，乔老师的第十五讲真香，现在看这个课程有点追剧的感觉，也提升了我的很多认知。下面谈谈一点在我视角上的思考。首先我不是高级管理者，所以针对这个方面的认知，我感觉乔老师讲的很有道理，个人不反对加班（996也OK，只要有实际意义），但是如果久久没有粮草的苦战，只有意识也吃不消哇。在围绕产品方式组件团队，也会有些内部的问题和思考，下面谈谈浅见。 ​ 先谈问题，主要在人员配置能力选型上，通用的人员配置产品，研发，测试，运维，表面上看没有什么问题，但是能力选型怎么选，普遍的情况，产品不懂研发，研发不懂业务，测试和运维属于辅助，不是人员的拼凑就一定能整合成一支行之有效的战队，未必能达到1+1大于2的效果和持续提供战斗力。在之前很多大型支付公司的工作中，就遇到产品，研发，测试，运维在业务认知不在一个维度上，鸡对鸭说也很难统一，时间在内部扯皮中过渡消耗。 ​ 再谈思考，好，最简单的办法是产品主导认知，看似没错，细想想真的对么。我的认知是，初期是没有问题的，但是伴随着业务的持续稳定后，一定还是这样么，尤其到了后期在产品的平台建模上（已经从初期的抢占市场求快，逐步转化到后期求智求好的阶段，不然一味的求快，如果不能进行更好的自身平台的优化调整重构，就会像垒玻璃球一样最终发现没有办法垒了，重来成本又消耗巨大，进入两难的局面）。其实，在这个过程中研发&架构可以通过自己的技能反哺产品线的（建立在懂业务的前提上），可以让这条产品线逐步做的更智，更具备市场的竞争力，也就是由单纯的产品驱动，变成了产品&架构驱动，而这种重构需求不是单纯的产品角色能提出的，所以后期应该是一个多角色共同主导的局面出现，但是目标是一致的，逐步完成从拼凑到整合的过程（从幼生期到成熟期）。 再深度思考下，根据上述的场景很多公司可能会引入了架构师或者技术管理部门，引导团队架构驱动，做的好确实是行之有效的措施可以指导好团队。好，如果选对了架构师，技术管理部门的思想也能够很好有效的渗透到各个部门中，那是大有益处的，但是如果不能咋办。哪些情况可能导致不能，架构师已经偏于PPT而不懂实际研发工作了，很难提供有效的指导，团队也未必服气，于是就留与纸面了。技术管理部门的方案虽好，但是团队由于自身的产品周期等原因，不执行，对应的架构师也不能很深入的帮到团队，看似很美的东西其实没有发挥实际效果。 ​ 由于个人原因，带过产品，研发团队也做过架构师，所以我谈谈理想中的产品方式团队的组成要求。产品人员也要逐步对技术有点了解，最起码能够倾听技术人员的声音；技术人员要有了解业务的心，要明白技术其实是为业务服务的，明白自己所做的事情的业务定位；而架构师要求就更高了要有业务，技术深度，能明白业务&技术的痛点，能出的了方案，更重要的还要能指导研发实现，更好能自行做出一些业务组件给团队更大的便利，当然架构是一种角色（研发经理和专职架构师都可以具备的属性）；再有一个好的团队管理者把这些人能很好的包容和调用起来，那就很厉害了。对测试和运维只是了解程度，不发表想法。 ​ 哈哈，写了这么多，真的是浅见，如果有认知缺陷，还麻烦乔老师狠批。在批评中成长，可能更能记得住 :)

这一讲的维度太高了，暂时只能先知道【有这么回事】，后续可能有机会实施吧。哈哈，给自己加油。

现在公司真实发生的事，技术主管在加入公司前，研发加班加点的干活满足运营部门的要求，可需求仍然无穷无尽。技术主管加入后，重新规划把运营部门需要的统计功能做了很好完善和优化，为运营部门老大做决策提供了更好的依据，这项工作做好后，运营部门的一些需求就自动不需要了。 业务方提过来的需求，很多时候是伪装成需求的解决方案，如果只是头痛医头脚痛医脚的被业务方牵着鼻子走，需求就永远做不完。跳出来，站在更高的维度用更大视野，找到问题核心把问题解决掉，就好像打蛇打七寸一样。一个好的解决方案可以改变业务部门的做事方法提升他们的工作效率，很多伪需求也就自动消失了。提出这样的方案需要管理者知识框架是对的，认知维度足够高才可以，在具体执行的时候，就像老师在课里讲的"无所不用其极"。高级管理者是公司资源的看门人，要掌握好公司资源，不能随意浪费，尤其是人力资源浪费。

针对需求做不完的问题，我们在管理工作中有个不同角度的处理。 实际工作中，需求是一定有优先级的，而领导关注的往往都是优先级最高的需求（或者是因为领导关注所以优先级高）。那么，在一段时间内让一个优先级最高的项目保持足够的资源，集中团队的注意力完成一件事，类似sprint。 这样产生的效果很微妙，上层领导可以看到明显的成果，下层同学也有明确的目标，团队氛围也会显得更有干劲和凝聚力。虽然总体产出可能并不会提升，但各方的满意度都提高了。

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

请问对于技术团队的产能，数据化是怎么做的呢

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

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

高层是 Doing the right things，中层是 Doing things right ，一两个人甚至一两个团队可以靠自觉，要让整个组织都实现「业务 IT 一体化」要靠体系。也许，除了「业务」和「财务」还要学学 HR，需要一本写给技术管理者的 HR 书 :) 上半年在一本讲销售的书中学到了 FAB 工具，对于我们思考产品价值会有些帮助： * Feature 特征，指产品的特点和属性。 * Advantage 优势，指产品的优势如何帮助客户。 * Benefit 利益，指给客户带来的好处。 我们这些 IT 习惯讲又开发了哪些 Feature，我们要改改，要重点讲对业务方带来了哪些 Benefit，如果能更进一步说明对「客户」或「用户」带来哪些 Benefit 就更好了。 「沟通创业价值，分享带来快乐」，坚持留言的第 9 篇。