项目管理|2次心态变化和27个问题——机制落地的部分全貌与节奏控制编程语言|大数据|人工智能|j

本文介绍一项公司级机制是如何诞生以及不同时间点的一个考虑，其中有进退、有思考、有彷徨也有一些结果，不同的公司情况有所不同，此文用作参考即可，各位可多提意见。

【项目管理|2次心态变化和27个问题——机制落地的部分全貌与节奏控制】要阅读本文，建议先阅读：从顶层设计聊公司治理

第1天，CEO的困惑
公司眼看着就要突破2000人了，突然有一天，老板再也忍不了了，开始抱怨：

1）我们得为沟通付出一些成本，也得用一些工具和制度来降低这个成本；

2）哎，三体人才效率高啊，思维透明；
3）现在很多事项跟着跟着就丢了，很多不知名的项目都烂尾了竟然还不知道什么时候开始的，公司的成本就这样浪费了；
4）现在很多项目分散到了各个部门，部门管理能力参差不齐，我觉得是时候组建公司的PMO团队了；

......

规模到一定阶段的时，分散的信息变得难以处理，公司有多少项目，多少项目是总办确定的，多少是公司监控的，多少是有结果的，多少是烂尾的，这些信息一团乱麻，报上来的信息却总是好的。

公司该有多少S级项目、多少A级项目，不同项目的汇报节奏又该是什么样的？
公司项目如何跟踪、如何考核，如何复盘？

于是公司应该有一个人，一个组织来处理这个问题，那么这个人是谁呢？
那就叶小钗吧！

问题一：为什么是我？
初步接触上述信息，我的第一反应是：哦，就是要做一套项目管理的机制嘛，这个我会！保障项目结构还不简单，那么这里第一个问题来了，为什么会落我头上？
这里回想之前的经历：
1）做过大公司部门OKR负责人，并且在产研团队300人团队复制落地成功了：新晋总监生存指南三——OKR实践；
2）搭建了现有产研的项目执行流程：新晋总监生存指南四——项目执行指南；
3）是一级部门负责人，在公司影响力尚可、势能不差，不至于推动不下去；

所以这里的前提是：
1）我有相关的经历，不至于抓瞎；
2）我有对应势能，不至于没有抓手和试验田；
第3天，认知对齐
经过了一个周末，赶工出了一份项目管理的大纲，跟老板对了后，老板说要OKR，于是这里出了第二个问题......

问题二：那是什么OKR？

这里产生了第一个困惑点：老板要的OKR和我认识的OKR不是一个事！
老板口中的OKR类似于OKR，但又不遵循OKR的结构，并且有一套自己的激励体系（甚至可以独立运作的激励体系），我理解下来算是“一套类似于OKR的项目管理体系”，那么这里出现了第三个问题：要不要纠正？

问题三：要不要纠正老板？

初期尝试了几次跟老板对齐OKR的认知，但在老板完善的逻辑里面，貌似“那样理解也行”，于是就把项目管理“篡改”成了《OKR草案》，这里有个非常核心的点是：做的事情大差不差，与其不停的去说服一个打不过的对手，还不如先着手去干！
当然，这里也埋下了一个隐患，后期其他部门对这个“OKR草案”嗤之以鼻！！！甚至有部门跟老板之间发生了一轮认知冲突，最后当然是没有结果的。

在此情况下，整理出来第一套大框架，老板这边不置可否，大概意思是你先做，我观望......

文章图片

第5到10天，认知拉扯
之前，我一直认为自己是节奏大师，但逐渐节奏开始跟着老板走了......
开始我认为这次做的是项目管理，结果老板给我说要做OKR管理；

当我开始做OKR管理，老板又在引导设计一套奖金策略，我突然很懵逼，于是产生了第四个问题？
问题四：老板你到底要干撒？

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

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

部门墙形成后，每个部门只关注自己的KPI，但是公司的KPI反而得不到关注了，并且每个部门还都觉得自己没问题，这怎么破？

详情见：【周复盘】理不清的成本

老板这个问题，虽然发人深思，但却导致了第五个问题：

问题五：管我屁事？

对啊，老板这个说得挺对，但一来是管我屁事，二来这个已经超出了项目管理，乃至OKR管理的边界了吧，比如其中的“奖励方案”，貌似该HR去处理啊，我在中间处理个什么鬼，这个时候第六个问题和第七、八个问题同时出现：
问题六：这个事情做不做？
问题七：这个事情如果不做，我该怎么脱身？
问题八：如果老板不满意，该如何甩锅？
导致以上问题是因为心态发生了变化：
这件事情从熟悉变成了不熟悉，从可控变成了逐渐不可控，对于不了解事物，我们的第一反应是“害怕”，所以这里思维更多的是脱责。
但事情依旧要做，于是硬着头皮继续推进，收集到了整个公司的项目提案，并且做出了第一版的奖金方案，这个时候当然又发生了问题：
问题九：公司提案良莠不齐；
问题十：HR体系对奖金方案嗤之以鼻！
虽然不情愿，但是事情还是要继续，先是在HR那边不停的刷脸叫爸爸求人，把一些奖励数据拿到，但已经开始很吃力了。
确实有点推不动时候，卷入了HR负责人，并且卷入了一位CXO，CXO本身很专业，开始带节奏，大有拨乱反正之感，我突然有退居第二责任人，甚至第三责任人的感觉，既有大快人心，又有一点不妙的感觉......
在这个“半躺平”状态下，又碰到一个问题，我们需要对项目定级，那么标准是什么，基准线是什么啊？
问题十一：项目定级的基准线是什么？
PS：至此中间已经被骂了几次了
这里的解决方案是先把总办卷进来，跟大家一起讨论了历史已经发生的项目，为这些项目进行定级，得出了项目定级的基准线。
然后对已经收集到的提案，加上总办提出的提案，筛选出5个S级项目进行立项，于是该投入资源执行了......
第11到15天，一些杂项+躺平事件
虽然感觉自己不是第一责任人了，但很多事情依旧在推进，其中项目归属后，又产生了另一个问题，老板让我去确认每个项目的验收标准，我这里一下就又蒙了：
问题十二：项目验收标准该谁确定？

在我的认知中，验收标准不是应该负责人自己跟总办确定吧，这个与我何关，我只是一个技术负责人啊！！！

但事实上如果没有第三方机构监督的项目验收标准，会被项目负责人自己一再降低......
PS：大家注意我这里的心态变化
这个时候发生了一件关键事项，我以为的第一责任人说自己要做一个OKR大框架，我当然乐见其成，并且死而后已啊！一方面如释重负，另一方面也想学习下他怎么做的，但这里出现了其他问题：

问题十三：责任人更改的事情老板确定了吗？？？
问题十四：他的大框架是不是老板想要的东西......

大框架汇报结束后，老板还是比较满意的，觉得其中一些东西确实是他要的，于是我也长舒一口气，准备退居二线，并且在我们“小群”中发了一条信息：

我感觉老板自己跟自己和解了，似乎准备放弃“OKR”了......

然后，没几天收到了老板的私人信息：
以下是真实对话

老板：如果你不能承担公司OKR项目的推进，就明确的提出来吧，我们再安排其他人。

我：额，这块我跟XX确认下节奏，如果月底做不好，请求惩罚......

老板：所以现在到底谁在为OKR项目推进负责，推进效果向谁负责，应该听谁的？我在你这个事情上是非常困惑的。几番折腾下，原地踏步，时间已经没了。
很多情况也很诡异，我发出一个指令，你去偷偷跟不同人商量，最后给我一个结论，就是先搁置。

各个项目的验收标准也是，我说你要出一个版本，大家来讨论，然后你去找XX，人家的大框架是很优秀啊，但是你的工作就没有进展了，也不说怎么出验收标准和什么时间出验收标准。时间表也是一个样，我给你做了指导，给你做了启发，后面是要你去拆解的，结果你又引入了其他人员，甚至变成了其他同学是负责人了。
我明明是跟你沟通的，认为你是这个事的负责人，那现在你给我说这个事情的负责人到底是谁？（危险警告！！！）

老板这里的责问已经很是严厉了，我这里有些懵逼，但更多的是反思。作为一个求生欲极强的选手，面对上级不满的时候，不要去辩驳，更不要找借口，想想自己到底哪里做的不好，坦诚的说出来，寻求帮助或者获取惩罚，反而是最好的做法，千万不要抖机灵。

于是我开始回答：
1）这个事情还是以我为主；
2）这一切都是我的问题，我本来想引入更多的资源来帮助自己，但在引入资源的同时听取了太多的意见甚至反对意见，在不知不觉间被带了节奏；
3）做这件事并不是不该听取意见（相反卷入资源的动作很有必要），但被带节奏甚至见到困难就想躲的思维是根本错误，到一定阶段后根本没有简单的事情，这个是我最主要的错误；

4）迷信权威，碰见比自己的专业的，自愿做二号位，自愿做别人抓手，但我才是需要培养的对象啊，分不清主次，搞不清形势；

5）没有为一件事撞得鼻青脸肿的觉悟，明哲保身思维太重；
6）最终明确，我是负责人，我为此事负责，做不好我背锅，降职降薪随便你惩罚；

至此，心态发生了第二次关键变化：

很多时候我们去做一件很难的事，就会想有没有什么取巧的办法可以绕过去，剑走偏锋嘛。
但很难的事，多数时候是绕不过去的，是需要硬刚的，是需要碰得头破血流的，什么明哲保身、什么以退为进，在这些事情上是行不通的。今天能退，总有不能退的时候，那么何时来面对这一切呢？
过程中会有很多“意见”和建议，不要不听但也不要全听，有你的节奏有你的主线，持续做，不过是解决问题罢了！

于在执行到15天的时候，才真实确定了我要为此负责，我与此事不死不休的心态......
第16-20天，对齐认知，从项目管理到公司治理
最开始，以为老板要项目管理，然后发现老板要OKR管理，最终，我发现老板要的是公司治理！
我那个去，我是被卷入了什么事件！

不同的是，这次没有退缩，只有一往无前......虽然是一往无前，但问题是How To！
问题十五：如何设计公司治理框架
我们的治理框架是不是真的治理框架，会不会被质疑的问题，但这一切已经不重要了，回到问题本身，我们到底要解决什么问题：

问题十六：到底问题是什么？
答案：全局成本问题，燃烧的费用。
近期产研一直在做成本优化，数据团队给我的报表是产研一年用了1亿多，看到数据的时候我自己都吃了一惊，对于我们这种体量的团队，不可谓不高啊！
说起来令人心疼，今年产研的产出真心不高，以【维护类工作为主】，之前老板问我维护类工作是不是要花这么多钱？我回答不出来，但我也觉得当时的产研确实是有问题的，而这里核心问题就出现了：
公司有很多项目，在一定时期完成后做出了贡献，后面项目结束了，而相关的人事物都留下来了。但是后续因为组织结构变化，或新官上任后的梯队重组，那批人事物不再发挥关键作用，也没人想主动优化。于是冗余慢慢出来了，一年、两年、五年、七年，产研的冗余已经做了治理，那么其他团队的情况，乃至公司的情况势必不容乐观，我觉得这是想用项目管理的一个出发点，用项目把重要的人事物圈起来。否则得罪人的事，没人愿意主动优化的。
OKR只是一个工具，项目管理只是一个说法。

我的感受，公司事实上未必想要OKR，OKR与否并不重要，如果有方案B能解决问题，成本更低、稳定性更高，也没什么不可以。
公司一年的人力成本是10亿的话！而公司那边有印象的费用估计就1/10，并且就这1亿的印象都很模糊，只有大框架，没有细节，输入输不标准，更可怕的是项目没有很好的复盘，所以也没人追究，慢慢就形成了上面乱拍KPI，下面向上管理的情况，其他9亿的花销更是摸不着门槛。
基于上述原因，公司会有很多冗余的人事物，但是人是有主动性的，如果公司没有分配重要的事项，他们会自发的找一些事做，而这些事对于公司来说多半是没有意义的，这些人如何找出来，这些事如何辨别，作为这些人事物的容器保护扇的部门墙，部门黑盒问题，如何解决，这个是真正的难点所在，于是新的问题又产生了：

问题十七：冗余识别如何做？
问题十八：部门墙如何打破？
至此，与老板直接才真正的对齐了认知......

第21-30天，自发思考，顶层设计
回到问题十五，如何设计公司治理框架，这里的思路是（技术管理进阶——利益分配机制）：
1）识别冗余；
2）格局梳理，识别利益分配者；
3）利益比例调整，结构替代法；
4）找到资源分配出去的方法，即如何将资源给到你想给的人事物；
5）确定稳态比例，并开始再迭代；

文章图片

底层逻辑确定后，新问题产生：

问题十九：如何收集数据，毕竟这是度量效能！
针对，效能度量获取和数据准确性问题这里开发了一套系统：

文章图片

文章图片

1）每天上午系统会推送一条信息给每个员工，让他们预估今天的工作投入，这个过程1分钟就能结束，最多不超过5分钟；
2）当天晚上下班后会给每个员工再推送一条信息，让他们去确认今天的工作内容；

所以，问题二十：员工使用成本高，问题迎刃而解，问题二十一：如何保证数据准确性，的策略是三层兜底方案：
1) 部门leader会校准下面员工的工作占比；

2）项目负责人会校准自己项目人员的工作占比；

考虑部门leader利己性，所以项目负责人对项目参与人员的校准权限会很高，一旦被项目负责人校准，相关同学今天的工作量会很多是工作冗余，这样部门数据就会很难看。

而一旦产研同学今天的工作确实是完成其他部门的项目，那么该同学的人力成本会由这个部门承担，出于对自己部门成本的保护，项目负责人势必会保障没有“额外”的项目闲人摸鱼。

这两层策略下来会解决绝部分数据准确问题，而后每个项目的人力投入会作为项目考核时ROI重要因子，出于想要取得更好的成绩，项目负责人会在这里更为严格，从而产出的数据可信度会很高。

由此，我们可以拿到整个公司的资源投入数据，并且其数据准确性会有基本保障，拿到数据后就会知道当前团队大概哪里出了问题，这里以研发为例：

文章图片

文章图片

整个，研发团队竟然有大量的时间在做技术重构，这真是不可思议的事情！！！这也产生了一个问题：
问题二十一：如何引导比例改变

这里的答案涉及到了一个非常困难的问题，我的项目执行不下去怎么办？

问题二十二：为什么我的项目执行不下去

这里核心是两个问题：

1）部门墙是公司战略落地的最大阻碍；
2）部门墙会形成冗余，冗余会导致抱团，抱团会扼杀创新；
而这一切的根源，与我们人力的考核机制有很大的关联：

文章图片

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

文章图片

这里对公司关注项目的投入会加大各部门的投入，但并不会消灭部门墙，所以打破部门墙的激励策略依旧需要存在，那么新的问题又来了：
问题二十三：项目考核策略如何设计才能打破部门墙

其实很多公司人力考核策略，都有对跨部门协作的考核，但粒度很粗，往往就是合作共赢属性，单独打个分即可，没有任何依据可言，我们这里设计的策略至少要解决两个问题：

1）有所依据，并且大家认可这个可以作为跨部门考核的依据；
2）项目负责人可以对其他部门成员有一定控制力；
其实说白了就是，项目负责人把一部分考核的权限从部门负责人手里拿过来，并且这个考核结果是有理有据的，这里的策略是：

文章图片

文章图片

1）对每个职位进行积分KPI定义，并且这个定义有程序员的算法兜底，他们至少找不出问题......
2）每个职位想要获取积分就必须参与项目，项目负责人具有对参与人员打分的权限；
3）年底积分超过职位要求的人，会有一大波奖金安排；
4）年底没达到积分要求的人，会有点惨......
5）部门负责人同时需要完成部门KPI，否则有卸任风险；

在奖惩的加持下，问题二十一：如何引导比例改变和问题二十三：项目考核策略如何设计才能打破部门墙，便可得到有效解决。
第31-45天，系统实现，节奏控制，案例打造
在思路确定后，并且再三与老板确定“这到底是不是你要的”后，便开始加班加点进行系统实现，那么要实现哪些呢，要不要做一整套项目管理工具出来呢？
问题二十四：系统实现的尺度

做探索性实现的同学一定要注意尽量少，尽量核心，不要求大求全；
其次是UI一定要好看，不要出bug，这个时候老板依旧会催促你：

问题二十五：面对老板催促怎么办？

老板都是PUA高手，他会不停的以他的方式来push你加速，这个时候一定要掌握好节奏，不要忍不住装逼，襁褓中婴儿需要猥琐发育，按住性子，不要频繁汇报，沉下心来做实现，不停打磨体验，但这并不是叫你一个月不做汇报，这里要注意节奏把控。
系统实现后该怎么办会成为另一个问题：
问题二十六：系统实现后要不要全公司推？

首先这个机制本来就是一个创作，并没有证对或者证伪，所以千万要在自己最可控范围内做验证，拿到尽量多的数据，打造一个小的成功的案例，把相关推广的说明书，培训材料，培训人员都整理好，然后拿着你成功的案例再去跟老板聊，再去说后续，不可避免，这里会有最后一个问题：
问题二十七：证明机制不行怎么办？

这个其实很简单....