zoukankan      html  css  js  c++  java
  • 从顶层设计聊公司治理

    PS:文中更多的是个人认知,有错误请批评

    之前零零散散聊了很多类似的话题:

    【周复盘】理不清的成本

    技术管理进阶——利益分配机制

    【周复盘】探讨一下项目分级

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

    但不成体系,这次我们将整个线索串起来,这里有个公众号如果可以求关注!

    PS:嘴贱跟一个同事赌钱年底没2000粉输一万......

    熵增&必然结果

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

    管理的动作就是为了对抗熵增。我认为管理是激发团队小伙伴执行力的行为,借鉴更专业的描述:如果你想创造一个能够维持一定秩序、不会分解的系统,那么这个系统必然是一个开放系统,就需要为他注入能力,并让其在系统中流动以维持这种秩序。

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

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

    1)不断的能量输入;

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

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

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

    2)开放系统,熵减;

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

    对于公司来说,腐败的员工、落后的制度是必须清理的,国服打野在高端局也带不动四个青铜。

    熵增案例·二十年前的华为

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

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

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

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

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

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

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

    ……

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

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

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

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

     跨部门难的原因

    1)认知不一;

    我们假设,人们成长轨迹一定是从下到上的,极少有人出身就在终点,毕竟真实世界很少有龙傲天。在这个假设下,有一个人问请我图书馆在什么方向:

    ① 市区认知的人会说,东北边有一个南边有一个

    ② 县区知的人会说,书店在北边,市区的人在说谎

    ② 而省区认知的人会说,东边也有一个书店哟,于是市区认知的人会很不以为然

    认知是向下兼容,认知更高的人知道下面的人在想什么,而认知低的人未必知道上面的人在说什么

    所以说,我们在传递一个信息时候一定要做到【同频对话】,尽量拉齐认知,否则极容易成为鸡同鸭讲,这个情况最常见于产品、运营、研发、GM各说各话。

    2)沟通困难;

    信息会由于很多因素被“修剪”,大家在沟通前要尽可能的对齐认知,做到尽可能的【同屏对话】,这样会减少很多无畏的分歧,字节其中一个文化是多同步context,少同步信息,其意也在于此:

    多提供context,减少control,决策指令不是单纯的上传下达,而是让同事之间通过提供上下文,通过内部信息透明来解决问题、做出决策、提高效率。

    熵增表现

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

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

    1)重合区域

    2)三不管区域

    3)单元组黑盒问题

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

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

    管理者嘛,无非一天拉偏架协调大家这个问题(重合、三不管)怎么解决,再决策由谁“吃亏”(权责利模型)去解决,一旦规模变大就要出事!

    其次是业务单元内部,维护成本会逐渐增高:

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

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

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

    类似于这种业务以及之前的部分参与者,都会变成所谓的“维护成本”,这包括一些之前的“有功之臣”,处理起来比较麻烦了,这种比例一大整体成本马上就变高了,接下来就会定期出现成本优化,HC冻结事项。

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

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

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

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

    其他公司解法

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

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

    华为的解法就牛逼了:

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

    公司聚焦&顶层设计

    现在将镜头拉近到自己公司有哪些问题呢:

    这里核心是两个问题:

    1)部门墙是公司战略落地的最大阻碍;

    2)部门墙会形成冗余,冗余会导致抱团,抱团会扼杀创新;

    传统的考核机制,重点是职位对应的胜任力,部门对应的KPI,很容易导致“自扫门前雪”的结果。这里解题思路也很简单:

    具体下来有几个底层逻辑。

    底层逻辑·利益分配机制

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

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

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

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

    男方父母:女方父母:父亲小家庭 = 2:3:5,大家都不开心,于是调整为3:3:4,双方父母倒是开心,但是我们夫妻不大开心,最后生一个娃后比例变成了1:1:8,于是我们自己的家庭和谐了,双方父母却有所怨言,当变成1.5:1.5:7的时候,似乎进入了一个稳态。

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

    底层逻辑·Leader的五件事

    底层逻辑·20倍增速

    这个模型刚好和今天看到的一个短文一致:

    以上是我们的基本解题思路,有了思路便需要落地验证,而落地验证是另一个非常痛苦的事情!!!

    统一语言&中层疏导

    机制的落地,一定要打通关节,公司的管理层需要统一语言

    很多时候一些高管互相角力,是因为认知不一,甚至对什么是OKR、什么是项目,定义都不一致,这会导致一些好的东西都不能落下去,所以管理层统一语言是机制成功的第一步,这里作为技术出身的我直接给出了算法,首先是:

    跨部门考核依据·部门考核绑定项目

    这里给一个demo:

    接下来是部门资源投入调控机制:

    资源宏观调控机制·效能度量

    公司日历·统一节奏

    至此,公司将采用两条线考核,一条是HR为主的胜任力考核模型;一条是以项目为主的项目考核模型,所以项目跟踪会变得很重要,我们可以设计一个公司级项目日历,让大家共同维护:

    1)将所有项目注册上去;

    2)将每个项目的时间节奏维护上去;

    3)拥有丰富的筛选功能;

    公司日历,会逐渐让大家的步调与公司保持一致。

    秀操作&微观实操

    ​底层逻辑确定后,公司的基本结构也就确定了,结构影响行为,结构导致趋势,而后具体到认知对齐、机制推导,可以使用的手段比较单一,大逻辑上来说就两个:

    1)设定公司的基本运转逻辑;

    这里首先是由利益分配机制诊断公司问题,并做第一步宏观调控;而后使用Leader的五件事,划定我们对应的招式;最后使用增加实验组,金钱换时间逻辑,加速公司战略落地,也加速整个公司的资源重塑。

    2)选择最优策略,对齐管理层认知;

    这里能做的也很有限,机制对应的方案,说白了就是两点:将项目考核与部门考核绑定将部门优化与工作资源投入挂钩

    剩下来的工作就是,找到一条自洽的逻辑,说服自己,说服其他高管,然后开始推行,所以:

    底层逻辑,往往很清晰、很简单,可以做的事情极少,甚至不需要宣导;

    底层逻辑演化出来的机制也不会太复杂,也就多了几个流程、几章表格,唯一不同的是多了一些解释、多了一些培训,却可能导致一些“分歧”;

    具体机制的落地就很难“约束”了,正如八仙过海各显神通,成仙是动作的底层逻辑,过海是底层逻辑对应的实现路径(机制),具体到怎么过海,那就关我屁事了。

    综上,机制落地会变成最秀操作的行为,里面会有很多骚操作,前文所述的OKR、项目制是机制,对应项目制里面的:

    1)日报如何写;

    2)风险如何处理;

    3)事故处理办法;

    ......

    等等都是微观实操,这些只有案例学习,不太具有模仿或者复制的必要,下面举几个实操的例子:

    风险要不要处理

    项目日报怎么写

    保障怎么做

    结语

    希望此文对大家有用,结尾还是来一张图吧......

    微信交流一下
    成都天府软件园招聘技术专家
  • 相关阅读:
    整理了一份React-Native学习指南
    新建项目
    spring security 匿名登录
    spring security remember me实现自动登录
    spring security为不同用户显示各自的登录成功页面
    spring security 管理会话 多个用户不可以使用同一个账号登录系统
    spring security 图解过滤器的使用
    spring security 判断用户是否登录 只要登录就可以访问资源
    spring security动态管理资源结合自定义登录页面
    spring security自定义拒绝访问页面
  • 原文地址:https://www.cnblogs.com/yexiaochai/p/15477117.html
Copyright © 2011-2022 走看看