有没有负责基础平台开发的管理者？项目管理怎么做、OKR 怎么定？

果见案例库

根据「管理全景图」汇总相关模块案例。

内容来自小酒馆、小茶馆、小咖馆和小饭馆内，群友们真诚热情的讨论。

案例详情

问题

群里面有没有负责基础平台开发的管理者？一般你们项目管理怎么做。

目前我们这边事情很多不确定性：

• 就是比较多带预言性质的工作
• 或者一些工作不太好准确的评估工作量

也经常打断工作去支撑业务：

• 现在比较多的是我们的人 经常抽调到业务线
• 业务线压力一直比较大，我们的事情经常被认为不是很重要
• 上级没有那么不支持，只是业务和基础平台之间，他更倾向于业务一点（可能只是个人感觉）。

另外是最近在做平台的 OKR 还没有很好的想法，这种组的 okr 怎么定？

群友互动 1

@雪舞云飞

一个问题一个问题的聊，先说不确定性。

首先，对于基础平台团队来说，领跑的特性是天生的。因为他们没有直接面对业务线的压力。你会有现在这样的困惑，那么一定是有人对你们的产出的时间点，有了一个更靠前的预期。

基于这个预期，我们抽象的思考，能调整的，无非就是执行中的 issue 数，和预研中的 issue 数量。

总有一些「性价比」比较高的事，可以优先考虑。但是为了维持预研工作的比例，保证这个事情能够步入正轨，可以考虑从业务线抽调合适的人。

这个抽调的人，最终还是要回到业务线的。有两点好处：

• 一方面，业务线的人能够参与基础平台相关的工作，对于他的成长有帮助；
• 另一方面，基础平台是为了业务服务。这个过程中，通过协作关系的构建，也建立起了人和人之间的连接。

「我们的事情经常被认为不是很重要」这个认知，恐怕是你现在这个局的核心来源。

业务的压力是无止境的，毕竟谁都想要成长，合理的抑制，能够避免野蛮生长埋下的祸根。就好比一棵树，光长叶子是不够的，根、树干都需要配套。

那么这个事情需要跟上面沟通清楚明白，他们是你最大的支持了。如果领导层面无法认同，你需要足够的魅力，才能发挥间接领导功能，让其他业务线的领导认同你，支持你。

业务兄弟如果能意识到，配合你之后，他们将来能做更多的事，他们就不会给你阻力。但再往后走，业务部门的甲方知道他们能力提升了，仍然会尝试把资源用满。

我倾向于缩减基础部门常规编制的数量，匹夫无罪怀璧其罪。

当然，最关键的还是权。这也是我对于基础部门使命的理解。一个团队中，总要有一些人，对那些非功能性指标负责。稳定性、可扩展性、可用性。那么这些职责的负责，也需要相应的权。只有凌驾于业务部门之上，基础平台部门的工作才容易开展。这个就聊回到 OKR 的设定上了。

这样的 OKR 你们自己需要背，也需要让业务部门背一部分，这样才能从动机上，让他们不产生阻力。

如果老板强力，他自然会替你安排好这些。如果他的心力不太够用，你把成熟的方案摆在他面前，看他是否能支持你。如果这样他都不支持，有一条险路，就是从业务部门动手，本质上相当于越权发挥领导力了。

这条路走完，等于老板就给架空了，他对你可能就会心怀不满。所以一旦老板不靠谱，需要好好考虑考虑是否还在这条船上。既然这样，你可以把思路整理一下，然后跟他做一个沟通。

基础平台的工作，离不开身边人的支持，既需要上级的支持，也需要平级业务兄弟的支持。抽象的说，归根结底是资源问题。为了避免死锁，基础平台需要拥有剥夺别人资源的权利。强占无剥夺，迟早要死锁。

群友互动 2

@ChengJun

基础平台开发工作的指标设定还是要拆分。最起码把「平台开发」，「紧急项目支援」和「平台实施应用」几类任务再拆分，然后就看你具体是想解决哪个障碍了？

就我个人经验，「平台开发」你作为管理者，一定要向老板充分要权，要完全的时间自主权（靠你的产品路线图和售前支持能力）。这样你的核心研发人员有稳定性，不会做到心累。检验标准是让老板支持你，去扛住来自业务部门的压力。

然后版本规划不要大，3 个月还是 1 个月，你看情况定。积小胜为大胜，给兄弟们信心和成就感。再有就是当业务线发现了更高级别的功能需求，你也还可以及时转台。

「完全实施应用型」的最好解决，因为是需求稳定。最麻烦的是「紧急项目支持」，一般老板是各打 50 板子，又想冲业务，又理解你们现有功能暂时不足。这种情况下你也很难脱掉责任。

那就象 CR 一样，尽量只做优先级高的，实在不行，就和业务部门按资源收费。都是免费支持的话，你的任务越来越多，销售都是可劲向前冲的。等把费用扯清楚了，你也有缓冲余地了。

一个长线，一个短线，只是怎么平衡的分寸问题。而且这个平衡是动态的。说实话，一家公司发展的好不好，就看这个分寸把握的怎样了，而且特别考验老板，以及平台负责人（划重点）的心胸，都要有战略视野才行。

产品研发不是无源之水，可以要求业务部门定期（比如按Q）为产品路线图做出贡献。而且因为很多项目都是有一段动作周期的，那这样就变成你和业务部门不会互相推诿。而是一起共同商量下一个Q，要把哪个几DEMO 原型，要把哪几个功能支持放在核心版本里了，目标统一了。就是多想一些类似这样的机制。

群友互动 3

@巧亮ᶻ

既然是平台支撑，还是需要有明确理由告诉老板，支撑的重要性，支撑出问题引起业务风险的严重性。基础平台就像地基，地基不牢，楼再高也有倒的一天。

基础平台为业务服务的时候，是不是能把繁杂的业务抽象出更具体的基础。这样业务方如果慢慢压力小了，基础平台也就能更好发展了。

全景图分析

诊断

此案例中管理者基于「基础平台」的特殊性，面临以下两个问题：

• 如何制定团队 OKR，做好团队规划
• 如何做好任务管理，实现制定好的 OKR

应对思路

管理规划

基础平台即然也是一个团队，那么制定规划还是离不开「职能」、「目标」、「团队」、「路径」。

• 职能：回答团队是干什么的。
• 目标：回答团队要产出什么。
• 团队：回答团队是什么状态及未来会是什么状态。
• 路径：回答所需要投入的资源及理由。

职能：

团队职能有两个层次，即基本的职责和升华的使命。

相关问题：

• 公司为什么要设置这个团队，对这个团队的期待是什么?
• 这个团队如果要持续存在下去，其独特价值是什么?
• 你用什么维度来衡量团队价值的高低?

目标：

团队要取得什么成果来体现其价值。常用的句式是：

未来的一段时间里，三个月、六个月或一年，你希望带着团队达成一个什么样的目的呢?

团队规划：

团队规划的三个视角：

• 从团建目标的设定来看。
• 从资源角度来看团队构成。
• 从人才发展角度来规划梯队。

路径：

明确了目标，盘点了团队，接下来要筹划的事情就是：带着团队前往目标有哪些可选的路径。

相关问题：

• 有哪几条路可走，即通过哪几项重要的工作来实现目标。
• 各需要做什么准备，即这几项工作各需要投入多少资源。

更多详细信息可参考：管理规划手册。

任务管理

「如何做好任务管理，实现制定好的 OKR」，一是要处理好任务的轻重缓急，二是要做到有效执行。

轻重缓急：

可以尝试问自己下面这两个问题。

1. 如果做，收益是否很大?收益越大，这个事情就越重要。
2. 如果不做，损失是否很大?损失越大，这个事情就越紧急。

我们把日常的工作分为两种情况：

• 一种是计划内的，按照我们的规划进行的；
• 另一种是计划外的，即突发的情况和任务。

因此，我们维护工作清单和优先级的问题，就变成了如何应对「计划内」的工作，以及如何应对「计划外」的工作。对工作任务的安排和决策，主要是两步。

1. 对于计划外工作，看损失是否足够大，损失越大越紧急。
1. 损失够大就按照紧急任务安排，以「止损」为核心目的。
2. 如果损失可控就放入计划内工作列表，以「收益」为衡量标准。
2. 对于计划内工作，看收益是否足够大，收益越大越重要。
1. 收益越大，就越需要给予相匹配的优先级、资源和关注度。
2. 收益相对较小，就放入「to do list」，作为待办任务处理。

有效执行：

目标清晰、责任明确、机制健全、沟通到位是有效执行的四要素。

为了提升可操作性，我们把这四个要素扩展为 12 个问题。

如果你对某个项目的执行不够满意，又想了解到底是哪里出了问题，就可以参照这个「问题清单」检查一下，相信很快就可以找到问题出在哪里，从而对症下药。

更多内容可查阅图书《知行：技术人的管理之路》。

期待你的案例分享！