原创不易，求分享、求一键三连

当业务复杂到一定阶段的时候，效率问题会首当其冲，基本解法是化整为零、分赛道，对应的产物可以是子公司、事业部、业务单元、项目组。

好处是目标聚焦、问题也会聚焦；工作内容闭环，团队人数可控，协作、试错成本都会很低；但是不可避免的会有很多问题：

1）重合区域

2）三不管区域

初期重合、三不管区域占比小于2%，团队总有愿意「吃亏」的同学，倒也不成问题。

随着团队规模扩大，业务复杂度加剧，重合、三不管区域占比大于一定数值，比如10%的时候，加之专业领域冲突，文化冲突，阵营冲突，这种区域所造成的效率影响可能是「成倍增长的」

DDD可以解决科学分组的问题，中台要扮演「垃圾桶」协调解决重合与三不管问题，但是「漏网之屎」必不可少。

管理者嘛，无非一天「拉偏架」协调大家解决这些问题，再决策由谁「吃亏」（权责利模型）去解决。

这里就出了「第一个问题」，谁去吃亏？

谁背这个锅？

公司大了后，无效资源消耗增多已经很让人头疼了，但是真实情况这里还会多出很多「维护成本」

这种维护成本一般由几部分组成：

1）之前十分重要的业务，迭代减缓，但依旧有很重的地位，需要持续维护；

2）之前不愠不火的业务，直接停止迭代，其中参与人员无事可做，却又因为一些因素（如架构调整、leader离职）没有得到妥善安排；

3）之前死掉的业务......

类似于这种业务以及之前的部分参与者，都会变成所谓的「维护成本」，这包括一些之前的「有功之臣」，处理起来比较麻烦了。

这种比例一大整体成本马上就变高了，接下来就会定期出现成本优化，HC冻结事项。

成本优化是很多公司一直在做的事情，甚至这些公司并不缺钱！。

这里的重要标志就是「限制HC」、限制成本，对于不缺钱的公司似乎很奇怪。

这是因为公司大盘有一笔账，他识别到整体的业务资源投入是完全够的，比如各团队多给10%资源用以解决冲突问题，但实际情况却是各个团队依旧在闹缺人缺资源，那么公司就会认为我们所付出的「维护成本」与「解决冲突成本」过高，公司会认为当下自身「结构出了问题」。

而事实上多余的人事物所造成的资源浪费和「效率降低」甚至最终引起「死海效应」是公司绝对不能接受的，所以成本优化会是一个永久的话题，这里优化的不是成本，而是「缓解系统性问题」的一种手段。

话虽然好听，那么冗余成本「如何识别」呢？

团队一旦大了，如何判断哪个团队该投入多少人，各个团队leader是否会因为「本位主义」而有「善意谎言」，于是这个时候就会出现所谓的「公司级效率团队」。

但真要细究，这里有几个问题：

1）这种识别冗余团队的「效率团队」本身就是冗余；

2）效率团队多数情况只能算老板的传声筒，未必能深入业务、深入团队，所以多数时候能做的有限；

3）效率团队是建立在良好数据收集的前提下的，如果各个业务方初期项目数据收集工作都没做，也没办法统计；

所以，公司级的成本优化、效率提升，需要良好的顶层设计，否则成本识别可能成为一笔死账，效率团队在左右横跳中陷入消亡。

如何解决这种效率问题，是我们今天要探讨的...

熵增

1998年9月20日， IBM顾问向任正非阐述了对华为管理问题的十大诊断：

一、缺乏准确、前瞻的客户需求关注，反复做无用功，浪费资源，造成高成本；

二、没有跨部门的结构化流程，各部门都有自己的流程，但部门流程之间是靠人工衔接，运作过程被割裂；

三、组织上存在本位主义，部门墙高耸，各自为政，造成内耗；

四、专业技能不足，作业不规范；

五、依赖个人英雄，而且这些英雄难以复制；

六、项目计划无效且实施混乱，无变更控制，版本泛滥

……

其实华为的问题总结下来就两个事：

1）规模扩张引起的管理掌控力下降、「跨部门协作」难度指数级上升；

2）专业瓶颈导致的难度；

两个因素制约了团队创新。

一些解法

问题是什么？

大概在两年多以前，B站的leader在设计团队招聘的时候，会宏观强调职能比例，比如前后终端有一定比例要求，否则容易出现某个端成为瓶颈的现象：

我们遵照这个比例去做事，也确实没有出现过某个端出现瓶颈的问题，除非突然某个端大批量离职。

这里的点是将资源，分给了不同的职能线，偶尔也会微调不同职能线资源占比，只要不出问题，那么就会形成一个区间，比如：

我们发现前后端的比例在3:7和5:5之间都不会出现什么问题，那么在某个特别需要后端建设的时候，便会尽量压缩到3:7。

需要知道底线在哪里，可操作空间在哪里，确定这个比例后，便形成了宏观的「机制兜底」，也是「最外层」的兜底。

然后才是具体到前端团队的招聘中高级:中级:初级的比例问题，这个会形成「第二层兜底」，有了这几层兜底，便不容易出现端口上的瓶颈。

这里需要注意的一个点是，比例一定要不断微调验证，一旦发现团队因比例减少出现问题的时候，就要开始回调。

Case 2，家庭收入配比

上述Case中只是调整了一些数字，问题却消失了！

问题为什么消失，有没有「更宏观」的视角？

再次回到裁员的话题，单单一个裁员就会有几个视角：

1）一线员工：公司是不是没钱了；

2）leader视野：又瞎搞，我的XX重构做不了了；

3）大leader视野：团队可能确实已经产生冗余了，要进行成本优化，接下来需要聚焦，但是那些由于人力短缺做不了的项目怎么办呢？

4）老板视野：同样一笔钱，是要用于维护老旧业务还是要用于创新，这是一个问题，但相关的投入比例必须开始调整；

所以这里最宏观的视角是：

这里有一笔费用（资源），那么首先应该盘清楚他会被用到几个地方；

如果这个资源（钱）没被用到自己想要的地方，那么就要调整他的比例；

比例调整的时候要慢慢替换，用新的结构替换老的结构，太快容易拉着蛋；

最终拿到最优的分配比例。

具体到实际案例：

1）老板开始识别冗余，发现产研线一个月ROI较低；

2）老板约谈产、研负责人，要求做成本优化以及结构调整；

3）产研leader私下商量，少裁点，毕竟那么多老旧业务要维护；

4）老板不买单，要求首先将总成本减少某个比例，其次将现有资源投入做重新布局；

这里举个例子，之前是有70%的人在维持老旧业务，30%用于新业务探索，老板认为老旧业务投入太大没有未来，于是希望把比例先调成5:5，然后在新体系开辟后逐渐改成4:6乃至3:7。

这里产研leader的问题是会被历史包袱束缚，并且这种历史包袱反而是其「安身立命的根本」，是之前各种考核指标重点考核项，是KPI量化的体现。

所以单靠产研leader自己努力，很难跳出框架处理这个问题，老板的策略也很简单，直接调整投入比例，帮产研leader卸下了包袱。

这个案例再细化，老旧业务维护资源40%中，到底有哪些业务，这些业务依旧有一个比例，要再细分；

创新事项、新体系建立事项也是可以穷举的，那么这60%的资源又该如何投入？

以这种利益分配思维思考下去后，会引发以下结果：

1）一些老旧业务不得不放弃；

2）创新会更有重点，不会想要大而全；

3）在不停的调整比例过程中会达成一个动态平衡，确实有一些老旧业务无论如何都必须存在，那么这个就会变成基建或者公共项；

4）在系统稳定后开始第二轮迭代；

规整一下思路：

1）识别冗余；

2）格局梳理，识别利益分配者；

3）利益比例调整，结构替代法；

4）找到资源分配出去的方法，即如何将资源给到你想给的人事物；

5）确定稳态比例，并开始再迭代；

如此一来，我们便有了解决冗余问题的大思路了，也就是我们所谓「顶层设计」

接下来便是机制落地的问题了。

落地思路

首先，总办做至上而下的战略宣导，提出自己的OKR，甚至做命题作文形成公司的重点项目；

其次，各部门会形成自己的OKR，这些OKR都会通过总办的Review（整改、优化）形成部门的重点项目；

使用OKR是因为每个项目都会有明确的验收标准与时间，这会让很多事项变得「相对可控」

这里会形成两套机制保障：

• 公司战略输出形成的项目，一定会紧扣公司方向，不太容易出错；

• 部门OKR经过审批后的项目会有基本的兜底保障；

公司、部门级重点项目各自卷入一批人，能解一部分资源的「有效性」

为了激励更多人参与到项目中，会有配套的奖惩措施。这里会遵循一个基本逻辑：

事前预支，事中监控，事后评估，事成结算。

最后，我们开始盘点事项：

每个人会把自己的时间片分到不同的事项中，而汇总起来就形成了部门的资源投入汇总，这个时候再引入前面的利益分配机制：

如果日常类事项占比过高，肯定是有问题的，这里不同部门如行政、财务会更偏向于日常运营事项的比例会有所不同的。

比例的改变，应该由「机制引导」，比如我们就想在公司级项目多投入，便会将考核与公司级项目做挂钩，公司级项目就那么多，各个部门会争相参与，从而缓解部门墙带来的问题。

注意，没有奖惩挂钩的机制，就是无根之水

这里有一点要注意，这里的事项分类，是面向公司的大类，拉近到具体的部门，比如研发部门，由于他们的特殊诉求，需要把一些成本归集到业务部门，会进一步细分，但大类就以上四类，如果有超出的，就要迭代基本机制。

一些问题

一到怎么做，轮到谁都不好使了...

在网上找了很多资料，类似这类问题实操类的文章偏少，或者根本找不到，所以第一个问题是怎么做！

从知行合一的角度我们肯定要处理到底，于是这边设计了一个系统《CEO驾驶舱》去解决这些问题，也拿到了初步结果，这里顺便「把一些代码放给大家」算了：

关注公众号（叶小钗）：

关注公众号后回复：一分钟日报，获取源码。

演示地址：https://yexiaochai.github.io/60s_report/

回到上述问题，这里要解决的是：

1）现在的资源用到了什么地方？

2）我所关注的事项用了多少资源，是否足够？

问题很清晰，我需要知道每个人都做了什么，而这个知道每个人都做了什么本身就是一个很难的事情！！！

怎么知道每个人做了什么？

这里的方案很简单，人作为最小单元模型，让每个人「写日报即可」。但这里马上会遇到第二个问题：

写你妹的日报！

写日报是反人性的，如果花费每个人的成本过高，这个事情会被各大leader联合抵制，还没开始就得结束，所以这个日报必须要被限制到1分钟以内，最好是30S，于是形成了《一分钟日报》的设计思路：

这里先是对我们的工作内容做了穷举，其次让大家做选择题，最终实现的效果是做选择题，大家可以自己体验：

https://yexiaochai.github.io/60s_report

这里基本功能设计完了，马上就迎来了第三个问题，基本功能开发完了如何推呢？

如何实施？

有了小案例后就不要闭门造车了，该去找「投资人」了。

于是直接拿着当前案例去找CEO，也从他那里拿到了正反馈，CEO：这个东西真是个天才设计！！！这是继续做下去的基础。

接下来也不必着急全公司推，先看看情况，并且继续打磨产品，毕竟从开发到上线到试用到CEO汇报一共才3周呢！

现在要做的是控制节奏，鼓励项目组同学加班加点完成新模块开发，并且不断的优化体验，想下周要拿什么东西给CEO以便获取更多的支持。

而好的东西是能说话的，过程中CEO已经把这个工具介绍给了其他部门：小钗那边有个管理的好东西，你们都应该去了解下。

于是控制权已经不完全在你手里了，要注意节奏，「控制节奏」这里要做的是去除阻碍，千万不要在「大面积推广过程中被劝退」，所以这里的问题是：

如何去除阻碍？

很遗憾，一分钟日报仅仅是CEO驾驶舱的1/4，他只是开始！CEO驾驶舱的设计是：

《CEO驾驶舱》是一套效能解决方案，是公司数字化转型、精细化运营的开始。

他对公司的帮助是：有一个工具能提供「依据」以「验证」哪个地方「效能有问题」，并且提供一定「手段」去「降低」这些「损耗」产生的概率。

他的四个版本是：

「1.0 一分钟日报」

将公司资源用到什么地方能看清楚，并且有一些宏观调控的能力；

「2.0 项目工作台」

主要目的是将所有项目收归起来，每个项目不能随意立项，可以保证资源不被浪费；每个项目必须有验收标准（甚至多个验收标准），这样会在一定阶段防止烂尾（毕竟，有追责成本）；

「3.0 打破部门墙」

以项目虚拟货币而成的“市场经济”，以“宏观经济”加“市场经济”促进跨部门协作（虚拟货币+奖惩引导）；

「4.0 数据有意义」

人才天梯榜、部门天梯榜，项目ROI以及业务ROI测算模型与展示（精算+风控）；

一些效果比较敏感，随便截点图：

那么，系统开发结束就完了吗？

这才是一个开始呢......

系统与机制

有同学私下问了一些问题，也在此更新：

数据真实性

日报没看出对一线经理的管理造成了怎样的影响，没有说一线经理怎么调整员工投入产出

第二部分是涉及了的，但是我这里没写那部分，也就是CEO驾驶舱的第二部分。我们会把所有重点事项项目化，项目化后必须有考核和验收，后续会根据考核结果给予奖励也会有信用积分的增减

一年大概有一大笔的项目「奖金池」做宏观调控。

考核的错误引导

月度的项目怎么保证符合预期，比如是否因为月报好做汇报够三个项目，存在大拆小、快拆慢的情况

这里所谓的月度项目不是每个月就必须结项一个项目，而是公司想要看到每个部门在「持续」的做一件事情或者投入一件事情，「不要太唯上」；

项目长的会持续2年，但我们希望至少一个季度会有一个节点考核，以防止「沉没成本」的产生。

工程团队的问题

工程团队会不会成为众矢之的

大概率会吧...

好了，今天的分享就到这，希望对各位有用。「原创不易，多多分享」

出处：https://www.cnblogs.com/yexiaochai/p/15889806.html