Java教程

技术管理进阶——管人还是管事?

本文主要是介绍技术管理进阶——管人还是管事?,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

在之前的话题上继续衍生:技术管理进阶——利益分配机制

从管理的角度来看,人是个变量,是不可管理的,因为不可管理所以很难评估。

所以,管人不如管事,评估人不如评估事。

管人,事结束了,人会给自己找事,后面事情多了,资源耗散也多了,公司关注的事反而没结果;管事,用事把人聚集到一起,便可有效减少目标偏移。

一、熵增

团队大了后会产生很多“维护成本”,维护成本一般由几部分组成:

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

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

3)......

这里涉及到一个著名理论:

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

图片

我们常常再说一句话:

发展可以解决多数矛盾或者增长可以解决多数问题,这里的点是外力足够让系统保持有序,但发展(增长)放缓,外力不足时,内部矛盾便会变多

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

具体到我们实际工作中,一个公司存在了很多年后,一年的人力成本是10亿!而公司高层有印象的费用估计就1/10。并就这1亿的印象都很模糊,只有大框架,没有细节,输入输出也不标准,慢慢就形成了上面乱拍KPI,下面向上管理的情况。而其他9亿的花销更是摸不着门槛。

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

公司会对9亿成本花销肉痛,迫切的想要改变这一切,这是造成裁员的根本原因:

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

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

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

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

综上所述,公司会有很多冗余的人事物,但是人是有主动性的,如果公司没有分配重要的事项,他们会自发的找一些事做,而这些事对于公司来说多半是没有意义的!

公司的裁员要解决以上问题,但是这些人如何找出来,这些事如何辨别,这很难,一旦裁员错误,会引起更严重的后果。

二、利益分配机制

前文所述,老板提出了一个策略:

这里有一笔费用(资源),那么首先应该盘清楚他会被用到几个地方;如果这个资源(钱)没被用到自己想要的地方,那么就要调整他的比例;比例调整的时候要慢慢替换,用新的结构替换老的结构,太快容易拉着蛋;最终拿到最优的分配比例。

具体到实际案例:

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,这些OKR都会通过总办的Review(整改、优化)形成部门的重点项目;

这里会形成两套机制保障:公司战略输出形成的项目,一定会紧扣公司方向,不太容易出错;部门OKR经过审批后的项目会有基本的兜底保障;

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

为了激励更多人参与到项目中,可以会对每个项目进行基本定价,参与后可以拿到相关的奖励,这里会遵循一个基本逻辑:

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

除此之外,我们的工作其实可以穷举:

1)日常事项;

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

2)日常管理;

周会、日会、扯皮会....还可以细分为:

做战略、做计划->人才招聘、梯队建设->战略匹配的资源协调->做辅导->做机制匹配战略落地。

3)日常耗损;

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

比如部门级项目设计失败导致的返工都属于日常耗损。

所以,一个人的时间会被分到这些“事项”中:

1)公司级项目;

2)部门级重点项目;

3)日常运营事项;

4)日常管理;

5)日常耗损;

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

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

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

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

四、问题与展望

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

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

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

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

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

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

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

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

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

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

后续文章会提供案例佐证。

这篇关于技术管理进阶——管人还是管事?的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!