查看原文
其他

从底层逻辑聊日报设计与公司治理

叶小钗 叶小钗 2022-10-27

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

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

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

1)重合区域

2)三不管区域

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

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

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

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

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

谁背这个锅?

某天,测试环境有个BUG,前端可以写代码解决,于是后端认为是前端的问题;后端也可以写代码解决,于是前端认为是后端的问题,这是一个有趣的「评价模型」

谁能解决或者说谁最终的解决了这个问题,谁就变成了这个锅的拥有者

两个同学一步不让,10分钟代码的事,扯了一个小时,甚至后端同学已经把前端的代码写出来,贴在了群里,让前端同学发上去即可,可谓侮辱性极强。

前端同学气不过就是不上传代码,让后端同学自己去上传,于是10分钟的事情两个人拉扯了一天...

一些同学可能会认为他们「小肚鸡肠」,于是马上升级场景!

线上有一「严重事故」,A团队的同学能解决,B团队的同学也能解决,但是现在「触发点」在A团队,线上页面「影响面」却在B团队。

于是10分钟的事情,两个团队6个人扯了半天,都怕这次事故算到自己头上...

在这个时候你会不会「小肚鸡肠」呢?

这种事没有绝对对错,也没有道理可讲的,往往都是看谁「拳头硬」(势能高、影响力足),如果你看到有个「傻子」在那里大放厥词,可能有三个原因:

1)他在维护自己「较真」的人设,顺便增加点自己的团队「活跃度」属性;

2)他在以讲道理的方式「叫冤」,就算输了也要找补下,因为以后的这类「脏活」是不是都要自己接?

3)这是个「真傻子」......

屁股决定脑袋,对站在某个立场的leader或者同学来说,当然是正确的。但是站在全局来说又很有问题,因为「10分钟的事情变成了一天」啊!

这还只是技术团队层面的事情,扩大到产研团队、事业部之间,这类分而治之所导致的效率问题,「不可谓不大」

以上问题已经很令人头疼了,但你以为就结束了吗?

维护成本

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

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

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

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

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

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

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

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

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

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

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

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

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

但真要细究,这里有几个问题:

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

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

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

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

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

熵增

上述的问题到底是什么呢?一个物理热词能可解释——「熵增」

熵增:在一个孤立系统里,如果没有外力做功,其总混乱度(即熵)会不断增大

管理的动作就是为了对抗熵增。

我认为管理是激发团队小伙伴执行力的行为,借鉴更专业的描述:

如果你想创造一个能够维持一定秩序、不会分解的系统,那么这个系统必然是一个开放系统,就需要为他注入能力,并让其在系统中流动以维持这种秩序。

管理动作就是为团队注入能量,能量停止系统就会开始退化,这种持续为组织注入能量的行为、有效的熵减动作,正是领导力的核心。

有两个核心点可以防止熵增:

1)不断的能量输入;

之前工作中常常听到一句话「流量红利时代已经结束」,后续的存量流量争夺可能会有很多公司被埋葬!

这句话背后表达的是在流量自然增长的时代,很多很普通的产品也能有不错的增速,而当增量变得困难的时候,内部问题便会暴露,逐渐走向衰亡。

增长可以解决很多问题,创新是最好的增长手段,但未必会引起熵减,甚至会加速熵增!

2)开放系统,熵减;

大侠武功再高,也要放下包袱,背上背着共患难的媳妇,怀里抱着红颜知己,面对真正的强敌时,也不免进退失据。

对于公司来说,腐败的员工、落后的制度是必须清理的。

这里再举个例子,古代打仗如果没有纪律和机制保障,队长死了有人兜底,兜底的死了还有人兜底,直到兜底到最后一人,很容易出现逃兵。

具体到我们实际工作中,一个公司存在了很多年后,一年的人力成本是10亿。

而公司高层有印象的费用估计就1/10。

并就这1亿的印象都很模糊,只有大框架,没有细节,输入输出也不标准,慢慢就形成了上面乱拍KPI,下面向上管理的情况。

公司管理复杂度提高,边际效益递减,无效的人事物增加,组织臃肿......

嗯?之前的华为貌似就遇到了这个问题

二十年前的华为

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

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

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

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

四、专业技能不足,作业不规范;

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

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

……

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

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

2)专业瓶颈导致的难度;

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

一些解法

金山的解法是先做朋友、再做事业,只有关系很好的朋友,和关系一般的朋友;

阿里的解法是大中台、小前台;

华为的解法就牛逼了:

一套完善的项目管理办法、绩效管理机制,事无巨细全部定义......

这套东西怕要值不少钱,对于小一点的公司可能不太适用,那么中小型公司应该怎么办呢?

利益分配机制

问题是什么?

再次回到最初,问题到底是什么?

Case 1,职能线比例

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

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

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

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

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

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

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

Case 2,家庭收入配比

在某一段时间里,我的家庭关系处理的很糟糕,现在回想起来,除了最初主动作死之外,最大的矛盾点来自于跟老婆结婚后,由二人世界变成了两个家庭,而在家庭利益分配这个事情上总是达不成一致。

女人总是帮娘家的嘛,男人虽说会更顾全大局一点,但对自己原生的家庭依旧会有所偏移,于是就容易出现各为各家,鸡飞蛋打的结果。

后来生了个娃,大家更多的把精力投入到了自己的小家庭,一些矛盾也就自然而然化解了...

这里的点是什么呢?

有一笔资源,是花在我家,还是我老婆家,整个应该有一个比例,举个例子:

男方父母:女方父母:小家庭 = 2:3:5,大家都不开心;

于是调整为3:3:4,双方父母倒是开心,但是我们夫妻不大开心;

最后生一个娃后比例变成了1:1:8,于是我们自己的家庭和谐了;

双方父母却有所怨言,当变成1.5:1.5:7的时候,似乎进入了一个稳态。

有了这个模型后,我们再观察下当前教育行业的改革,国家医疗的投入,教育的投入,似乎慢慢能看懂一些东西了...

底层逻辑

上述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)确定稳态比例,并开始再迭代;

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

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

落地思路

这里实行「利益分配机制」的策略是将公司所有事务分为五类:

  • 公司级项目
  • 部门级项目
  • 日常运营事项(包括日常管理)
  • 损耗

日常事项

比如公司级项目立项前的讨论成本;

比如日常管理必须的周会、日会、扯皮会;

比如项目的日常运营事项,或者线上事故处理,或者项目某个节点准备,或者奖励配置上传,或者竞品调研;

可以看见,大框架由管人、管部门,演变成由项目管人,是个很大的跨度。

在理论落地过程中确实也遭遇了很多问题:

1)缺少理论基础,毕竟是没有验证过的猜想;

2)上有政策,下有对策,实际执行缓慢;

3)很多事情没有评价标准,冗余难以识别;

4)......

没经过实践的理论连方法论都算不上!

如果机制本身没太大问题执行不下去往往是环境有问题,怎么快速「统一认知」,很关键!

而OKR是一个很好的工具,从本质来说,OKR与否不关键,「资源可控」,目标实现才是重点,只不过OKR正好契合。

实操过程

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

其次,各部门会形成自己的OKR,这些OKR都会通过总办的Review(整改、优化)形成部门的重点项目;

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

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

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

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

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

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

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

最后,我们开始盘点事项:

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

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

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

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

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

一些问题

这套机制问题很多,需要持续迭代:

1)这套机制想要量化每个人的投入,并且规则复杂,初期会为每个部门带来了大量工作量,推行不易;

2)人天生是不想被测量的,加之指标引导性可能导致大量「失真数据」,这样拿到的数据「颗粒度会很粗」

3)项目具有很强的周期性问题,这也给测算带来了很大的困难;

4)并不是参与了项目就是有效的输出,比如我在项目中摸鱼,项目负责人对我十分不满,项目负责人的评价会很重要,但这同时又加大了项目负责人的「管理成本」,可谓「双刃剑」

综上,这里的问题总结下来就是,拿到的数据会「不准确」并且「推行难度不小」,但就算粗粒度的数据也「并非一无是处」,比如:

1)我可以知道一个项目的投入是什么,对应人力甚至可以换算成钱;

2)我可以知道一个人一个周期内的投入是什么;

3)我可以知道一个部门的资源成本是什么;

到一定阶段,我可以知公司级项目用了公司多少资源,部门级用了多少,莫名其妙的事情用了多少,我在调整的时候可以有所依旧了......

所以问题又来了,怎么做,你TM告诉我怎么做?

一分钟日报

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

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

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

关注公众号(叶小钗):

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

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

回到上述问题,这里要解决的是:

1)现在的资源用到了什么地方?

2)我所关注的事项用了多少资源,是否足够?

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

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

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

写你妹的日报!

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

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

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

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

如何实施?

各位如果以后要推广一个系统或者落地一个机制,一定要先做一个事:

打造案例!在你最有话语权的地方打造成功案例。

我在产研话语权很大,系统完成第二天就直接在产研团队使用,要求所有人必须填,由此在线打磨体验,边修BUG边优化体验,并且拿到了第一波数据,于是可以处理第四个问题了:

如何进一步推广?

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

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

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

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

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

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

如何去除阻碍?

1)马上筹备培训材料;

2)马上筹备宣传图册以及宣传海报,比如:

3)来个更有冲击力的大屏,直接在公司播放!

于是,这个至下而上的产物演进为至上而下,拿到了红头文件:

后面就是顺理成章的事情,只需要不停的优化运营......那么到此就结束了吗?

CEO驾驶舱的四个版本

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

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

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

他的四个版本是:

「1.0 一分钟日报」

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

「2.0 项目工作台」

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

「3.0 打破部门墙」

以项目虚拟货币而成的“市场经济”,以“宏观经济”加“市场经济”促进跨部门协作(虚拟货币+奖惩引导);

「4.0 数据有意义」

人才天梯榜、部门天梯榜,项目ROI以及业务ROI测算模型与展示(精算+风控);

一些效果比较敏感,随便截点图:

那么,系统开发结束就完了吗?

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

系统与机制

在某种程度上说,有机制就可以了,机制可以保证很多问题得到根本解决,这里想要表达的点是:

所有的数字化转型都需要匹配的机制与流程辅助,甚至系统只是机制的辅助!

但系统可以加速这一切的发生,也可以加固体系的稳定性,是不可或缺的重要组成部分。

所以,系统完成后,还需要产出:

1)冗余预警策略以预警哪里出现了冗余;

2)项目月会策略以滚动跟踪项目形成闭环;

除此之外的宣传案例、奖惩策略、汇报模板、会议设置等等全部必须匹配!!!

每一个模块的推行,都需要重复一分钟日报的所有行为,甚至更难,其中一个环节出问题甚至会导致所有前期努力白费......

这里以项目月度报告举例,他可能是这样的:

机制要求:每个月月底,各部门需要写一份项目月报;

月报内容:上报本部门最重要的三个项目(或者三件事),并且简单描述项目(事件)进展;

项目结项:如果部门本月有结项的项目,会安排汇报并做评级,而后记录在案,随后也会有专门的项目结项表彰大会予以激励;

对于部门而言,以上并不重要,重要的是给到模板(请不要让我动脑,多数人都不喜欢思考),他可以是这样的:

然后在不断的责骂中「日报写了现在又来月报?」,最终会得到推行......

我想说,这一切很难,因为人都是有防御机制的,部门的防御机制更强。

管理的动作稍有放松,管理的意志稍加薄弱,这些防御机制就会反扑。

他们甚至会不停的试探你的底线,你只要在其中一个小策略松口,就有可能千里之体溃于蚁穴。

这种事情做得好收益很大,做的不好就会变成公司的噪音!里面的拉扯很值得玩味......

总之,这一路走的很不容易...

结语

有同学私下问了一些问题,也在此更新:

数据真实性

个人填写的日报怎么保证或者确定是真实的呢,毕竟没人会写我今天摸鱼50%?

会有4层兜底校准策略:

1 leader每周或者每天会校准每个人,leader不爽谁就可以校准谁,这个是个管理工具;

2 项目负责人会校准参与我项目的人;

3 项目是要计算ROI的,参与人越多ROI越多;

4 总办会问责ROI极低的项目或者事项;

经理如何用

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

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

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

考核的错误引导

考核这些东西,很容易出现「考核什么,就得到什么」的结果,解决日报、月报准确性,怎么保证资源分配,尤其是月报,对于没有资源的团队经理造成伤害比较大,会裁撤团队还是怎么办?

现在公司「主要的矛盾」是冗余过大,具体点说公司战略执行不下去,所以更想要达到聚焦的作用,所以也是引导往项目上走。

具体的做法是公司会给几个公司级重点项目,做上层“发改委”经济调控,也鼓励每个部门自己提报项目做市场经;

关于每个部门的资源或者事项的投入会有一个额度,比如研发还是需要做工程类建设,但是这个比例只能在10%以下,不同的团队会有带宽,我们希望的是大家抢占带宽,并且给到结果。

对于拿不到资源的团队我们会认为他就是冗余,除非他证明自己有用。

跨周期项目怎么办

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

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

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

工程团队的问题

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

大概率会吧...

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

想要更多交流可以加群:

也可以加入知识星球免费提问:


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存