|
|
# 07 | 管理者最重要的三个任务（一）：组织调整到位
|
|
|
|
|
|
你好，我是乔新亮。欢迎来到我们专栏的第二章：**对管理工作的复盘**。
|
|
|
|
|
|
在我身边，有些朋友技术很牛，别人调试了一个礼拜的 Bug，他三下五除二就搞定了；别人玩不转的高并发架构，他没用多久就设计完了。领导天天表扬，隔三差五还能给团队做个技术培训，很开心。
|
|
|
|
|
|
接着有一天，公司组织调整，程序员成为了管理者，整个人就懵了：不知道该干嘛。有的人是天天写 PPT，其实内心觉得管理是个很虚的事情；有的人坐着管理者的位置，干的却仍然是写代码的活。不懂管理，这是初级管理者的典型问题。
|
|
|
|
|
|
如果将视线拔高，你会发现，管理能力有些欠缺的技术总监、技术 VP，甚至是 CTO ，也都是存在的。我培养过许多技术总监，也经常收到猎头发来的“高薪求聘 CTO”的需求，说明当下在业内，仍然十分缺乏优秀的技术管理人才。
|
|
|
|
|
|
确实，做管理者不容易，大家都是一步步走过来的。前面我们讲了很多次关于“上台阶”的认知，每次登上一个台阶，挑战都会很大，需要时间去学习和适应，这很正常。
|
|
|
|
|
|
复盘这些年带过的精英团队、万人团队以及创业团队，我发现有一些知识，如果早一点掌握，能帮助快速搭建起关于管理的知识骨架，让你成长得更快、更系统。管理者需要做的工作很多，但如果只做三件事，会是哪三件呢？
|
|
|
|
|
|
在我看来，有三大管理任务始终最为核心，最应该在团队内率先落地，分别是：
|
|
|
|
|
|
1. 组织调整到位；
|
|
|
2. 加强协同效率；
|
|
|
3. 激发团队活力；
|
|
|
|
|
|
你可能会想，这是不是过于简化了？要知道，做多容易，做少难，浓缩的才是精华，要学会将复杂的事情讲简单。
|
|
|
|
|
|
而且，这三大任务并不是孤立存在、毫无联系的，它们相互促进，共同实现「促进业务增长」、「建立企业竞争壁垒」等几个主要目标，同时构成了一个企业 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 人，就要尝试分成技术管理办公室和云部门，前者负责研发管理规范，后者负责基础技术平台的研发。
|
|
|
|
|
|
你可能会说，我还没有权利做组织架构设计和调整，我能得到什么呢？在专栏的第一章，我讲过，要学习看清楚问题的本质，养成遇到问题多思考的习惯。现在，你就可以结合自己的工作，好好想一想，这套调整方案背后的本质是什么呢？
|
|
|
|
|
|
如果你是个项目经理，可以想想做过的项目，调整自己的视角，想想如何利用类似的思维模式解决项目问题；如果你是个架构师，想想这个和架构设计有什么异曲同工的地方？
|
|
|
|
|
|
无论你是产品经理、测试经理还是资深开发人员，都可以结合自己的工作，想想有什么触类旁通的问题。
|
|
|
|
|
|
虽然以上管理措施，并不是每一位管理者都有权立刻执行，但要学着先听、先了解。交流得多了，你可能会发现，其实成功的高层管理者，在管理方法上，都有许多共通之处。提前接触这些内容，有助于你拔高自身认知，更清晰地看待当下的成长路径和工作目标。
|
|
|
|
|
|
同时也不能看过了就扔一边去了。每过一段时间，就要记着来拿出来重温一下，会特别有好处！
|
|
|
|
|
|
当然，你也不用担心此后的每一讲都与中层管理者无缘，我们的内容将涉及多个层次、多个维度。
|
|
|
|
|
|
如果你已经是一名拥有决策权的高层管理者，那就太棒了，以上所讲方案均来自我在环球易购和彩食鲜的管理实践，欢迎留言与我交流技术与业务团队管理心得。
|
|
|
|
|
|
## 结语
|
|
|
|
|
|
到此为止，我们专栏第二章第一讲的内容，就接近尾声了，内容从认知部分跨越到管理部分，不知道你听得怎么样？
|
|
|
|
|
|
作为管理者，要学着带领出一支能征善战的队伍。这一讲，就是在讲如何搭建一支能适应“现代战争”组织形式的队伍。
|
|
|
|
|
|
接下来的两讲，我们会重点讲一讲如何加强协同效应、如何激发团队活力。这三讲，将共同构成技术团队管理的“三板斧”。
|
|
|
|
|
|
都做完了，就可以带团队去打胜仗了：每个季度定有挑战的目标，组织团队拿下这个目标。胜仗打得多了，就会养成赢的习惯，就会将“打胜仗”当作一种信仰。当这支团队再看到有挑战的任务时，就会兴奋地冲上去，然后拿下它！
|
|
|
|
|
|
希望大家都能成为各自企业内的“常胜将军”，我们下一讲再见。
|
|
|
|