mod

极客时间专栏/黄勇的OKR实战笔记/OKR管理心经/15 | 技术团队真的是“成本中心”吗？如何改变这一现状？.md

@@ -0,0 +1,115 @@
+<audio id="audio" title="15 | 技术团队真的是“成本中心”吗？如何改变这一现状？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/26/5e/261ae57c51091e37f78e888f6a85275e.mp3"></audio>
+
+你好，我是黄勇。今天我们来聊聊如何通过 OKR 来体现技术团队价值。
+
+对于我们技术人而言，尤其是技术领导者，往往会面临这样一个问题：销售团队是公司的“利润中心”，而技术团队是公司的“成本中心”，如何才能体现技术团队的价值呢？
+
+其实，这个问题也经常会被一些非技术出身的老板或其他团队同事所质疑，此时我们往往显得有些无助。因为技术团队不像销售团队，为公司赚了多少钱，这些都很容易去量化评估和清晰呈现。
+
+然而，技术团队在不断地接需求、做项目、上系统的过程中反复循环，我们的价值似乎真的很难用一个合理的数字去度量。那么，究竟如何做才能体现出技术团队的价值呢？
+
+## 如何体现技术团队的价值？
+
+或许你也和我一样，曾经我们都思考过如何体现技术团队自身价值的问题，比如，写了多少行代码？做了多少个项目？用了多少人力成本？加了多长时间的班？可能只有“加班”这种现象能够勉强让他人觉得在技术团队上的投入是有价值的，至少会让人感受到我们“没有功劳，也有苦劳”吧。
+
+我认为，**要回答技术团队如何产生价值的问题，首先要让同事们知道工程师们每天到底在做什么。**因此，你作为技术领导者，需要向同事们介绍技术团队的内部工作流程，让对方清楚意识到技术工作其实是一个工程性要求极强的工作。
+
+此外，要想做好这份工作，不仅需要工程师们有较强的逻辑思维能力，而且团队内部还要有一系列技术规范和研发流程，对其他团队也要有相关的支持接口。
+
+你不妨在公司内部先组织一场分享，请老板和公司全员或核心部门负责人参加，最好你亲自来做这次演讲，先让大家理解技术团队的工作内容，可以说说平时遇到的困难和挑战，也可以讲讲技术团队的工程师文化，达到能让大家理解的效果即可。
+
+**除了在技术团队核心工作方面来体现价值以外，你还需要在日常的项目中体现技术团队的价值。**
+
+在项目启动之前，项目负责人一般会向团队发布一份《项目计划》，该计划包括项目过程中具体要完成的任务，以及完成每个任务的截止时间，还有所包含的人力投入情况。当项目正式启动后，项目团队需按照这份计划落地执行，直到项目正式上线。
+
+那么，请问项目上线意味着项目成功吗？显然回答是不一定的。也就是说，项目管理的价值仅在于让项目顺利上线，至于项目是否产生应有的价值，似乎就无法控制了。
+
+所以接下来，你要做得第二件事情才是“改造”项目管理，并使用 OKR 工作法来“设计”项目价值，从而进一步体现技术团队的价值。
+
+## 如何使用 OKR 体现项目价值？
+
+在项目正式启动之前，你要做的是充分理解项目的价值，请试图找出以下几个问题的答案：
+
+1.**Why：**为何我们要做这个项目，这个项目主要是为了解决什么问题？<br>
+2.**What：**对于项目所解决的问题而言，它所能产生的价值到底有多大？<br>
+3.**How：**项目上线后，是否能够有效地去验证项目的价值？如何验证？
+
+此时你可能会想：这些问题不应该是产品经理应该去考虑的吗？为何要我们技术团队来找答案呢？你能产生这样的思考，完全是正常的，但不要忘记，你要解决的问题是如何体现技术团队的价值，那么你实际上要体现的其实是：**技术团队所交付项目的价值。**
+
+为了让你更能理解我的思路，下面我就用 OKR 工作法来解决如何体现项目价值的问题。
+
+假如有一天，一位产品经理跑过来告诉你：“我在注册页面增加了一个‘图片验证码’的功能，希望技术团队能尽快上线。”临走之时他也不忘补充一句“这是老板要的功能”。
+
+当你面对产品经理这样的一句话需求，并利用老板做高压，你下一步会做些什么？或许你会考虑手头上是否有人可以安排这项工作，或者有什么现成的技术或工具可以拿来直接用。
+
+同时，你心中也会对这位产品经理的表达方式表示不满，当这样的事情屡屡发生，久而久之就会影响团队之间的相处气氛和工作协同。
+
+如果我自己遇到这样的情况，我会这样去做，供你参考。
+
+我：这个功能太酷了！我们做这个“图片验证码”功能主要是为了提升用户体验吗？
+
+产品经理：是的，市面上很多产品都有这个功能，我们也要这样去做。
+
+我：明白了，之前我看过注册数据统计，发现注册转化率只1%，可能是用户觉得我们现在提供的“数字验证码”操作起来比较繁琐，感觉这个“图片验证码”体验上线后，我们的注册转化率肯定会有所提升，你认为大约会提升多少呢？我们一起努力啊！
+
+产品经理：没错，注册页面的用户体验提升了，注册转化率肯定会有所提升，我估计能提升到 5%。
+
+我：这个数字太棒了！那我赶紧请工程师们分析一下如何实现，我们一起努力，让这个项目尽快上线，尽早产生价值。
+
+为了能与对方达成共识，并输出最终的 OKR，请注意我和产品经理的沟通方式：
+
+- 首先，我必须高度认同他的观点，而不是对他提出的需求产生质疑，因此我不断地在对他说“太棒了”和“太酷了”这些能强烈表达感情色彩的词语。
+- 其次，我在和他沟通过程中，实际上是在不断向他提出一些“引导性”的问题，我先将这个项目的价值向提升用户体验上进行引导，从而将我所知道的注册转化率过低的问题告知对方，并引起对方思考做这个项目的价值究竟在哪里。
+- 最后，我在和他的沟通中，始终强调“一起努力”，这种方式会拉近我和他之间的距离，让产品和技术快速建立信任，从而让团队之间的协同变得更加高效。
+
+在与产品经理结束对话后，我先找了一位资深的工程师，了解到实现这个功能可能需要 1 个人 1 周的时间来完成并上线，然后花了一点时间利用 OKR 工作法对此项目制定一个“**项目 OKR**”。
+
+> 
+<p>图片验证码项目 OKR	<br><br>
+O：尽快升级注册页面用户体验，从而有效提升注册转化率	<br><br>
+KR： 1）1 周内上线“图片验证码”功能 2）功能上线后，X个月内将注册转化率从 1% 提升到 5%</p>
+
+
+此时我并没有明确功能上线后的验证期有多久，因为我下一步就需要将此项目 OKR 与产品经理达成共识。
+
+于是，我拿着这份项目 OKR 去找产品经理沟通并确认，他给出的验证期是 3 个月，我觉得也比较合理。随后我将此项目 OKR 写到了项目计划中，并与项目团队和其他相关团队同事以邮件的方式进行同步。
+
+将项目 OKR 制定完毕，并将其放入项目计划中，随后将信息同步给相关人员甚至全员，这在一定程度上可以体现项目的价值，但体现价值绝不是靠一份项目计划就能完全体现出来的，我们还需要持续不断地体现项目价值，从而体现技术团队的深层价值。
+
+## 如何持续地体现技术团队价值？
+
+使用 OKR 不仅能体现项目价值，还能让项目团队对项目的目标更加聚焦。我的建议是，**不要告诉工程师们应该做些什么，更不要告诉他们应该怎么去做，而要告诉他们为什么要做**。作为技术领导者，你需要将项目的目标和价值充分体现出来，才能打造出一个真正的具备工程师文化的技术团队。
+
+经过一周的开发和测试工作，图片验证码功能成功上线，此时建议你需要写一封项目上线邮件，将项目 OKR 的完成率告知相关同事们或公司全员。
+
+> 
+<p>图片验证码项目 OKR	<br><br>
+O：尽快升级注册页面用户体验，从而有效提升注册转化率【完成率：50%】	<br><br>
+KR：<br>
+1）1 周内上线“图片验证码”功能【完成率：100%】<br>
+2）功能上线后，3 个月内将注册转化率从 1% 提升到 5%【完成率：0%】</p>
+
+
+完成率计算方式非常简单，**O 的完成率是其下每个 KR 完成率的平均值，**KR 完成了，O 就完成了。
+
+此外，为了让大家持续关注项目价值，你也可以和产品经理达成一致，以后每月都给大家同步一下该项目的 OKR 完成率。
+
+而当项目的验证期结束后，你需要组织项目组以及产品经理或需求方，使用我之前介绍的“OKR 复盘四步法”对此项目 OKR 进行复盘。在复盘会议结束后，别忘了将复盘会议结论共享给团队。
+
+我想再补充一句，**对于曾经做过的项目所产生的价值，你还需要阶段性地向你的上级领导汇报，从而建立领导和你之间的信任，这同样也能体现技术团队的价值。**
+
+## 总结
+
+今天我们一直在讨论如何体现技术团队价值，我们不仅要让同事们知道技术团队在做什么，更要让大家看到技术团队的产出及其成效。对于技术团队的产出而言，实际上就是我们不断上线的项目，而项目上线后是否有成效，需要通过科学合理的方法来验证。
+
+因此，我今天提出了“项目 OKR”的概念，在项目 OKR 中，O 指“项目上线后有何价值？”KR 指“如何验证项目的价值？”在制定和执行项目 OKR 的过程中，我们需要注意一些技巧：
+
+**1.项目 OKR 无需你一个人来制定，你需要与协作伙伴们共同来完成。**<br>
+**2.通过“引导式”提问方法，让你的伙伴们认可通过 OKR 来验证项目价值的方法。**<br>
+**3.持续体现技术团队价值，通过定期向大家同步项目 OKR 完成率，这个方法值得尝试。**
+
+## 思考时间
+
+除此以外，还有哪些可以提升技术团队价值的方法或技巧呢？期待你的留言与分享。
+
+最后，如果这篇文章让你有所收获，请把它分享给你的朋友，我们一起探讨。

极客时间专栏/黄勇的OKR实战笔记/OKR管理心经/16 | 大家都说“向上管理”很重要，你想学一些“套路”吗？.md

@@ -0,0 +1,120 @@
+<audio id="audio" title="16 | 大家都说“向上管理”很重要，你想学一些“套路”吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3d/e1/3dac8bbc478987188ebdee90355e9be1.mp3"></audio>
+
+你好，我是黄勇。在进入今天的正题之前，我想先和你探讨一下关于管理的三个方向，即向下管理、向上管理、横向管理。简单来说，向下管理指的是管理自己的团队等；向上管理指的是与自己的领导有效沟通；横向管理指的是与自己的跨部门同事进行工作协同。
+
+其实，我们通常谈论的管理多数情况还是倾向于向下管理，其管理难度系数最低，毕竟你是团队的领导，团队向你汇报工作，你对团队有管理权力，所以管理起来也相对容易一些。
+
+但是，向上管理和横向管理却有着“先天性”难度，因为你所要管理的对象并不需要向你汇报工作，而当你要和他们进行工作协同时，就一定会产生很多阻碍因素，让你无法按照自己的想法顺利推动工作进度。
+
+今天，我们就来聊聊“向上管理”的话题，我将结合 OKR 来分享一些心得和体会，也许能让你更好地“管理”自己的领导，与他进行有效沟通。
+
+## 向上管理，到底管理的是什么？
+
+目前看，市面上有很多关于“向上管理”方面的书，我想几乎没有人会将这类书放到自己的办公桌上，其实这些书也许更适合放在你的床头。在你每天晚上睡觉之前学习，就书中所讲到的一些方法，学个一招半式，并应用在你实际工作上，可能也会产生相当不错的效果。
+
+### 问题
+
+不过，看了向上管理的书就真的有效果吗？事实却是这样的：一旦你和领导之间发生不愉快，最后离开的人往往是你自己。曾经有一项调查显示，75% 的员工离职原因都是和自己的领导无法相处。任何员工离职对于企业来说都是一种损失，毕竟公司培养一名员工需要付出的不仅仅是薪资成本，还有时间成本，然而时间成本是无法赚回来的。
+
+那么，我们为何与自己的领导一言不合，就会选择离职呢？其根本原因还是在于自己和领导之间的沟通出现了问题。
+
+### 实质
+
+因此，与其说是向上管理，不如说是向上沟通。既然是沟通，那么一定是你和领导之间为了某个目的而去谈话，而这个目的其实就是领导对你的期望。所以，**向上管理，管理的其实是领导对你的期望。**
+
+试问你自己，在跟领导的沟通过程中，是否真的明白了领导对你的期望？其实，很多下属都没有真正搞清楚这一点，就像很多产品经理没弄明白用户对产品的需求一样。所以，向上管理就需要你多跟上级沟通和确认，尤其是在一些重要工作的沟通和决策上，当双方理解完全一致后，再去落地执行。
+
+### 难点
+
+我觉得这样的沟通方式非常好，可以很大程度上解决沟通中的分歧，让彼此之间对沟通内容的理解更加一致，但无形之中也产生了沟通成本大的问题。
+
+因此，员工想要的是更深层次理解领导的想法和要求，领导想要的是让员工能尽可能地按照自己的想法和要求去执行，而关于如何能够使双方的沟通变得更有效，这成为了我们每个人都更加关心的问题。
+
+## 如何让双方的沟通变得更加有效？
+
+接下来要讲的这一案例内容，来源于上海一家互联网创业公司，案例的主角是一位 CTO，案例中将展示他与老板之间的向上管理方法和技巧。为了更好地还原当时的场景，我将以第一人称来讲述。
+
+### 案例展示
+
+有一天，老板从阿里巴巴公司参观回来后，叫我去他的办公室，说有要事跟我商量。
+
+当我来到他办公室后，他语重心长地对我说：“这次我参观阿里，感受很深啊，阿里为什么可以成为互联网大佬呢，我想你去看看他们晚上 11 点时，办公室里灯火通明，就知道原因了。”
+
+以我多年的职场经验，瞬间就明白了老板说这话的意图，但我此时没再接任何话。
+
+老板看我没表态，他就接着对我说：“你再看我们公司的同事们，每天 7 点就下班了，我们怎么能拼得过那些同行的竞争对手呢？”
+
+看来老板的意思已经非常明确了，此时我必须发言，否则老板会认为我作为 CTO 都没能站在公司的立场上考虑问题。
+
+我坚定地回答老板：“是的，我们必须努力拼一下。”
+
+老板看我的态度比较诚恳，就直接向我提了要求：“感谢你的支持和理解，那么我们从明天开始，每天早上 9 点上班，晚上 9 点下班，周六再来一天，周日可以好好在家休息，你看这样行不行？”
+
+如果此时你是那位 CTO，你会如何回答老板提出的这个问题呢？关于老板提出的“996”，你会答应强制加班吗？
+
+### 案例分析
+
+我想你的回答可能多数会是这几种：
+
+1.没问题，我们坚决执行公司的安排。<br>
+2.这样不太好吧，长期加班，恐怕会导致团队工作效率低下。<br>
+3.我没意见，您看看其他部门负责人意见吧。
+
+就以上三种回答，我们来分情况解析老板可能会产生的几种反应：
+
+1.如果你立刻答应老板的要求，那么很有可能就会导致工作效率低下，不仅是效率低下，伴随的还有士气低下；<br>
+2.如果你直接反驳老板的观点，他可能会对你说一句严厉的话：“如何提高团队效率，那是你的问题，这是我请你来的目的。”而这样的对话，将严重影响老板对你的信任；<br>
+3.如果你表达自己没意见，那么老板很有可能就会先让你在技术团队内尝试“996”。
+
+不过，似乎真的很难回答老板的问题，难道就没有其他更好的办法了吗？
+
+如果你现在已经掌握了 OKR 使用方法，那么就能将其上升到“OKR 思维”层面了，建立与领导之间的有效沟通，从而实现向上管理。
+
+## 如何使用“OKR 思维”进行向上管理？
+
+当领导提出让你不太认可的要求时，你此时要做的是快速获取领导所期望的目标，也需要思考两个问题：他到底想让你去做什么，以及他期望你能达到怎样的效果。
+
+承接上文，我接着讲述上面这个案例：
+
+面对老板提出的“996”强制加班要求，其实我内心里是不认可的，我希望带领的是一支能“打仗”的队伍，该拼的时候一定要能拼，而不是为了加班而去加班，做样子给别人看，而且我认为阿里的成功，那绝不是单纯靠长期加班而取得的。
+
+我对老板说：“我明白您的意思，那么您期望达到的目标是什么？”
+
+老板回答说：“我们是一家创业公司，我希望通过加班能提高我们的工作效率，让我们有更多的产出。”
+
+看来老板所要求的“996”实际上是为了提高工作效率，当理解到这个目标后，我接着对老板说：“是的，我们的工作效率确实应该提高一些，我突然有个想法，还请您能给我一些建议。”随后，我在白板上写下了老板希望达成的目标：
+
+> 
+目标：成为一家追求工作效率的公司
+
+
+当写下这个目标后，我接着说：“如果我们希望看到大家在工作效率有所提升，那么就应该关注大家的‘人效’，也就是说，在不增加人员的的情况下，努力提高每个人的工作产出。”
+
+当我说到这里时，观察到老板在向我点头示意，说明他认可我所提到的“人效”的概念，于是我接着说：“我建议可以这样做，每个部门根据自己的人员情况，对‘人效’做出一个科学合理的计算方法，我们先看看当前的人效水平如何，在未来一个季度后，我们希望人效应该提升到多少，逐步给每个部门提出更高的要求。”
+
+老板听完我的建议后，瞬间就理解了，他高兴地回答说：“我非常同意你想法，我们是一家互联网科技公司，大家也会非常认可这样的‘数据驱动’方式，这个目标应该写在我们今年的‘公司 OKR’中。”
+
+和老板交流结束后，我和技术团队一起制定了一套“人效”的计算方法，通过曾经我们交付的项目情况中所涉及到的时间和人力成本进行计算，得到了目前技术团队的“研发人效”是 2.19，我希望一个季度后，这个数字将提升到 3。于是，我在下季度的团队目标中加上了一个新的 OKR：
+
+> 
+<p>O：成为一支追求工作效率的技术团队<br>
+KR：研发人效从 2.19 提升到 3</p>
+
+
+OKR 就是这样神奇，如果你只是将其用成了工具，那么它的价值也就大打折扣了。我认为，**OKR 应该是一种思维，当你需要进行向上管理时，OKR 是你和领导的“共同语言”。**
+
+## 总结
+
+使用 OKR 后，不仅看到团队中每个人都在不断成长，也看到整个团队在不断提升进步，还能管理领导对你的预期，沟通成本明显减少，向上管理变得不再困难。不过，在向上管理过程中，你需要注意以下三点：
+
+**1.做一名“被领导者”，需要发挥自己的智慧，充分挖掘出领导对你的期望。**<br>
+**2.产品经理管理的是用户对产品的期望，你需要管理的是领导对你的期望。**<br>
+**3.OKR 是一种管理思维，只要双方认可 OKR 的价值，就能快速达成共识。**
+
+因此，当你掌握了 OKR 使用方法，其实也就掌握了一种思维方式，利用这种思维方式，将有助于你和领导之间有效沟通，从而为你实现向上管理。
+
+## 思考时间
+
+作为各层级的“下属”，你平时还会使用哪些向上管理的方法和技巧呢？期待你在留言处与大家一同分享。
+
+最后，如果这篇文章让你有所收获，请把它分享给你的朋友，我们一起探讨。

极客时间专栏/黄勇的OKR实战笔记/OKR管理心经/17 | 跨部门协同费劲，沟通效率低，如何粉碎“部门墙”？.md

@@ -0,0 +1,109 @@
+<audio id="audio" title="17 | 跨部门协同费劲，沟通效率低，如何粉碎“部门墙”？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7e/6b/7ed5d7c6b51757e8fcfd662d6188916b.mp3"></audio>
+
+你好，我是黄勇。不知道你是否也有过这样的困惑：为何公司发展起来了，规模越来越大，可是跨部门协同却越来越难呢？
+
+我认为，**企业内部之间存在一堵无形的“墙”，它阻碍着跨部门协同，阻碍着各部门之间信息传递和工作交流，我们称这堵墙为“部门墙”，正是由于“部门墙”的产生，才导致公司缺乏执行效率，战略无法迅速落地。**
+
+现在大家更多地只是把自己所负责的工作做好，跟自己关系或利益不大的事情尽可能不去接触。同事之间不再有频繁互动，更多的是“各自为政”，工作上不出问题就好。
+
+试问在这样的工作环境中，我们还能踏踏实实地做点自己认为有意义的事情吗？或许你觉得有意义的事情，但别人却不见得认为它也有意义。
+
+或许，刚开始你还满腔热血地去推动一些事情，却发现对方表面上认同，但实际工作上却根本不配合你，而你和他们只是平行关系，又没有直接的管理权限，进而引出了下面要讨论的问题：如何让跨部门业务协同效率更高呢？
+
+今天我就针对跨部门协同问题，谈谈自己的一些实操经验和个人观点。在整个过程中，OKR 工具和思维帮助我解决了许多麻烦事儿，希望通过本文能让你对 OKR 有更深的认识。我们不妨先穿越“部门墙”，再进入 OKR 的世界。
+
+## 为何公司变大了，部门墙也变厚了？
+
+所谓“隔行如隔山”，在公司里隔着一个部门，就隔着一面“墙”。也许是“术业有专攻”的原因吧，公司为了让各部门多聚焦在自己的工作领域，所以各部门也开始陆续出现各种专家。
+
+比如，对于一家互联网公司而言，技术部门有技术专家，产品部门有产品专家，运营部门有运营专家，市场、销售、财务、人力等部门也有各自的专家。
+
+<img src="https://static001.geekbang.org/resource/image/dd/14/dd40ba29267a890f1cc562917a0e8914.png" alt="">
+
+专家多，好不好？当然很好，专家可以解决公司在成长之路上遇到的各类问题，进而加快公司的成长速度。从这方面来看，各部门确实发挥了自己独特的价值。
+
+此外，每个部门都有各自的领导者，同时这些领导者在各自的领域中也都是一把好手，他们的领导力也非常强。不过，这些部门负责人彼此之间是平行的，他们的工作要统一向老板汇报。
+
+不过，由于很少有老板是“万金油”类型的，能够把每个部门的业务都搞得明明白白，所以老板更多地只是看结果，至于过程好不好，就让各部门领导者自己去负责吧，这也是他们的工作职责，于是 KPI 就成了老板来衡量各部门领导者工作产出质与量的核心武器。
+
+正是由于这些部门负责人彼此之间没有上下级之分，各自又有自己的专业性门槛，因此迟早都会产生“部门墙”现象。但是，随着公司规模的扩大，每个部门的规模也在扩大，为了让逐渐变大的部门有着高效的执行力，部门负责人会将自己更多的精力放在内部流程和效率上。
+
+因此，**部门墙使部门协同会变得越来越弱，导致出现“各人自扫门前雪，休管他人瓦上霜”的“本位主义”现象。**随着公司人员规模逐渐壮大，业务体系变得越来越复杂，部门墙也会变得越来越厚。
+
+既然部门墙现象会带来如此严重的后果，那么应该如何才能打破部门墙呢？绝大多数公司希望能通过“业务单元”来打破部门墙，可效果究竟如何呢？
+
+## 使用业务单元能打破部门墙吗？
+
+简单来说，业务单元实际上就是一个独立的跨部门协同团队，在互联网公司中较为常见。
+
+举个例子，假如公司有三款产品，曾经需要多个部门来通力配合才能高效协同工作，公司为了最大化提高员工的工作效率，希望大家的工作目标能更加聚焦，所以针对这三款产品组建了对应的三个业务单元，简称三条业务线。同时，在每个业务单元中都有一位负责人，他来协同内部各团队之间的工作，并向公司老板或高管汇报。
+
+<img src="https://static001.geekbang.org/resource/image/08/ef/085e8ecea8982fd1b746dac9f10825ef.png" alt="">
+
+这样的组织架构看似已经将曾经的横向部门拆分为多个纵向团队，部门墙就此被打破。实际上，却容易引发新的问题，虽然部门墙已被打破，但是“单元墙”却被建立起来了。
+
+难道不应该化部门墙为“单元墙”吗？我们对组织架构目标进行调整，难道不是为了让团队更加专注于此吗？没错。
+
+从让工作变得更加聚焦、更加高效的角度来看，业务单元协同工作的产出确实能够达到这一效果，但这些相同职能的伙伴们之间的交流却开始匮乏了，从而影响了他们在专业技能提升方面的成长，长期下去会让大家感觉没有归属感。
+
+因此，**从绩效考核角度来看，业务单元的形成起到了明显的作用，但从成长角度来看，似乎它并没有起到任何作用，它将破坏人才的成长环境。**
+
+我曾经就经历过这样的组织架构重组，对此深有感触。
+
+当时我们公司内部拆分了两个业务单元，一个业务单元目标聚焦在 B 端产品上，另一个业务单元目标聚焦在 C 端产品上。这样的组织架构刚开始还非常受欢迎，只是时间久了，这两个业务单元的交流也越来越少了。
+
+与此同时，这两个业务单元还在不断地招聘新员工，团队规模越来越大，导致研发人效降低。
+
+当我有一天去更加深入、细致地了解这两个团队的内部工作流程和规范时，发现两者其实是有所差异的，当时我还没太在乎这些，心想只要大家能聚焦目标做事就好，能提高效率就行，没想到后续更严重的问题就来了。
+
+由于我们在 B 端业务上发展得不太理想，公司的资源投入更多情况下倾向于C 端，导致 B 端业务单元的同事们产生严重不满，当时就有人抱怨道：“我们 B 端的活儿没少干，倒是年终奖为什么拿得比 C 端少那么多？一年到头，工资还不给加。”
+
+按照我们当初设置这两个业务单元的目的来看，一是希望大家更加聚焦工作目标，二是希望凭大家可以业绩说话，谁做得越好，谁拿到的年终奖就越多，高薪只会给绩效高的员工。不过，当时我们只是从金钱这个方面来激励团队成员，却忽略了他们的成长。
+
+可见，一旦业务单元被建立起来，我们更多地是追求绩效，希望能通过金钱来激励团队。当员工的绩效考核数据显示优秀的情况下，感觉一切都没问题，如果绩效数据做得不好，对公司中的一些人才却是一种伤害。
+
+回过头来想想，人才是极力需要并渴求在各个阶段中成长的。**其实关注成长就是一种激励，而且比金钱激励效果更好，被激励的时间也更加长久。**
+
+不过，既然问题已经出现了，那么应该如何来解决呢？下面我想分享一下，我曾经在团队中使用 OKR 解决过这一问题，希望能对你有所启发。
+
+## 如何使用 OKR 彻底粉碎部门墙？
+
+当时我的做法是，保留纵向业务单元的结构，并在横向层面设立了不同的职能团队。可以看到，**纵向业务单元和横向职能团队构成了一个矩阵式结构，**两者实际上对应的是同一批员工，虽然他们是同时处在两种不同的团队中，但有着不同的目标和职责。
+
+此外，**在汇报方向上，并不存在双向汇报问题的情况，所有的员工只需向业务单元负责人汇报即可。**
+
+<img src="https://static001.geekbang.org/resource/image/ca/83/ca89dcfffcd03e71e1e49183ac455883.png" alt="">
+
+**业务单元是一个实际组织，它存在的价值在于消除跨部门之间的协同，让大家的目标更加聚焦，一切围绕追求绩效而做出努力。**由于业务单元日常做的工作都在项目中，因此可用 OKR 来制定并执行项目目标，同时还能体现技术团队价值，这方面在本专题[第 15 讲](https://time.geekbang.org/column/article/112110)中有讲到。
+
+此外，建议公司高管要多去挖掘领导力较强的员工，让他们成为业务单元负责人，并激励他们为公司的业绩做出杰出贡献。
+
+**职能团队是一个虚拟组织，它存在的价值在于加强业务单元间的联系，让团队伙伴们感觉到更有归属感，职能团队负责人将主要精力投入到提升人才技能的培养上。**与其说是职能团队负责人，不如说是职能团队的“教练”，他使用 OKR 工作法来帮助团队伙伴们制定个人目标，扮演职能团队的“OKR 教练”。
+
+我建议，公司高管要学会去培养这样的教练型职能团队管理者，让他们为公司培养更多的优秀人才。
+
+从实操过程上讲，团队伙伴们每天都在业务单元中工作，但每周都会参与自己所在职能团队的活动。
+
+比如，面试新员工，讨论流程和规范，参与技能培训等，每个季度会进行一次 OKR 评估和制定，每年会进行一次内部职级晋升的申请和评级。我们的原则是，奖金和业务单元的绩效挂钩，但薪资和职能团队的职级挂钩。
+
+在整个过程中，**OKR 不仅帮助了业务单元，让大家围绕项目目标进行聚焦，OKR 也帮助了职能团队，让大家围绕个人目标进行突破。**就像这样，以垂直业务单元为主，同时以横向职能团队为辅，在纵向和横向两个垂直方向上彻底地打破了部门墙，建立了一个更加健康的跨部门协同组织架构，以支撑公司未来更大规模的人员扩张。
+
+## 总结
+
+今天我重点围绕“部门墙”做了讲述，从它的由来开始探讨，讲到了业务单元虽然能在一定程度上打破部门墙，但同时也会带来一些“副作用”，阻碍团队相互交流与快速成长。
+
+为了解决这一问题，我分享了自己以前在实操中所经历过的一些场景，尤其是有效使用 OKR，并彻底打破部门墙的具体实战方法。
+
+你会发现，公司越大，部门墙越厚，我们不仅需要通过垂直的“业务单元”来打破部门墙，还要搭建横向的“职能团队”去辅助业务单元，让业务单元跑得更快、更稳、更健康。我将今天的内容总结为三句话：
+
+**1.各部门关注点和利益点不同，自然会形成“部门墙”，可使用 OKR 将其打破。**<br>
+**2.当公司进入快速成长期，需尽早组建横向职能团队，并为其培养“教练型”管理者。**<br>
+**3.将横向职能团队和纵向业务单元进行“虚实”结合，在团队成长和项目管理上实施 OKR。**
+
+只有你对 OKR 深入理解了，才能更有效地使用 OKR 工具和思维，彻底打破“部门墙”。
+
+## 思考时间
+
+你所在公司是否也存在“部门墙”呢？它对大家工作协同产生了哪些阻碍？你们又是如何将其打破的呢？期待你的留言。
+
+最后，如果这篇文章让你有所收获，请把它分享给你的朋友，我们一起探讨。

极客时间专栏/黄勇的OKR实战笔记/OKR管理心经/18 | 企业“腰部力量”不够，如何提升中层领导力？.md

@@ -0,0 +1,108 @@
+<audio id="audio" title="18 | 企业“腰部力量”不够，如何提升中层领导力？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1f/95/1f3a96cacbf7d2f197578b426e3e3795.mp3"></audio>
+
+你好，我是黄勇。今天我想和你聊聊中层管理者的领导力问题。
+
+我认为，**企业的发展方向取决于创始人，但企业的经营节奏却取决于管理者。**尤其对于中层管理者而言，上有高层领导，下有基层团队。更加形象地来说，高层领导是企业的“头部”，基层团队是企业的“腿部”，那么中层管理者就是企业的“腰部”。
+
+从上面的讲述内容中，可想而知，一家企业如果“腰”不好的话，“头”和“腿”再好，那也“站不了”，就更别说“跑得快”了。然而，当下许多企业都存在“腰部力量薄弱”的现象，或简称为“腰虚”。因此，**必须提升中层领导力，才能让企业不再腰虚。**
+
+今天我想为你分享的是，如何借助 OKR 去提升中层领导力，让企业从此告别腰虚。首先，我们一起来聊聊企业腰虚的几种具体表现形式，看看你所在的企业是否存在这样的现象呢？
+
+## 你们公司“腰虚”吗？
+
+不瞒你说，这些年我确实接触过许多“腰虚”的公司，所以最近几年也非常关心如何治疗“腰部疾病”的问题，自己时常也会和身边朋友们深入交流公司为何“跑不快”的原因。
+
+我们讨论下来，企业腰虚主要导致以下几种不良症状：
+
+- **团队执行力不强。**高层说中层缺乏能力，中层说基层能力不够，对下级总是不认可。
+- **高层对基层交付结果不满。**高层认为是中层没传达好，中层说是基层没执行好。
+- **基层出现无法解决的问题。**久而久之，就会逐级上升，直到高层介入，高层会认为中层能力不行。
+- **中层之间关系不和谐。**经常互怼，甚至相互伤害，所带领的团队也出现“抱团”现象。
+- **中层抗压力不够或内心不够强大。**经常给基层制造负面情绪，导致团队吐槽不断。
+
+当然，以上只是我身边比较常见的情况，可能你也遭遇过更“奇葩”的经历，面临过更有“挑战”的状况。不论情况有多么严重，大家都更愿意将这类情况归因于管理出了问题，更直白地说，一定是中层管理者身上出了问题。
+
+为什么不觉得是高层领导或基层员工自身有问题呢？高层和基层都认为是中层不行，是“腰”不行吗？
+
+## 为何总说中层管理者不行？
+
+接下来，我将主要从中层管理者的处境、成长、职场等方面，来讲述中层管理者所面临的问题与压力，分析其现象背后的原因，旨在帮助你清楚了解当前或未来所面临的挑战，“知己”后而“知彼”，才是管理的破局之道。
+
+### 处境艰难
+
+可能做过中层管理者的人都有过这样的感受：中层难做，上有“老”，下有“小”，领导需要伺候好，员工照顾不能少。工作一旦出了问题，不管是不是自己的原因，最终结果一定是自己去“背锅”，稍有不慎，基层还会认为我们在“甩锅”，甚至归因于我们人品不行，无法服众，难以担当管理者大任。
+
+### 成长受限
+
+另一方面，从中层管理者自身成长角度来看，其实多数是从基层逐步成长起来的，当然也拥有更多的提升空间。我们渴望成长，期盼领导能多教教我们，却事与愿违，我们所承担的压力已超出自己的想象。
+
+### 职场高危
+
+此外，从职业稳定性来看，中层管理者是最危险的岗位。一旦经济形势不好，公司要做出裁员，可能首先被拆掉的就是这些中层管理者。
+
+然而，公司会让基层直接向高层汇报，还美其名曰这是为了让团队更加“扁平化”，提升沟通效率。自己出去找工作，却发现市场竞争压力依旧很大，每次换工作又担心自己再次掉入火坑。
+
+可见，中层管理者不好当啊，好不容易从基层走向中层，终于有机会做领导了，没想到自己反而会面临更大的挑战。如果想要从中层走向高层，更是一件不容易的事儿，可能真的做到了高层，却又发现“高处不胜寒”，回过头来想想自己曾经做基层的时候，其实还是蛮幸福的。
+
+那么，如果你也是一位中层管理者，或者不久后也打算担当这一职位，当这些挑战摆在你眼前时，你会怎样应对呢？
+
+作为一位从基层到中层，再走到高层的“过来人”，我认为这些问题多数都可归因于缺乏中层领导力。
+
+实质上，**领导力是你自己所拥有的一种能力，一部分是先天带来的，另一部分是后天锻炼形成的，**但绝不是其他人可以赋予给你的，更不要期望看了几本领导力的书，或者听了某些专家的演讲，抑或读了我写的这篇文章，你就能具备领导力了。
+
+**作为一名中层管理者，想要提升自己的中层领导力，不仅需要从自身努力出发，还要借助科学合理的方法论。**接下来，我将借助一个场景来展示，分享自己的个人观点，也请你思考一下：使用 OKR 究竟能否提升中层领导力？希望我的观点能对你有所启发。
+
+## 如何使用 OKR 提升中层领导力？
+
+比如，当高层认为团队执行力不强的时候，你作为中层管理者，此时不妨虚心地向领导请教：“请问您所期望执行力强的团队是怎样的？”当领导说出对团队执行力的期望，其实也是领导对你的期望，也就是接下来你要努力的方向，而此时 OKR 的 目标（O）也就诞生了。
+
+假如领导说：“我希望，关于我们决定要做的事情，产品研发团队可以快速去执行，并交付给我们希望看到的成果。”在与领导交谈时，你需要针对领导的口述，快速将其归纳为能用一句话概述的目标：
+
+> 
+O：快速实现业务需求，并确保交付质量
+
+
+此时，你需要跟领导明确这个目标制定得是否合理，是否满足领导的期望。总之，当你和领导交流完毕后，你们双方应该对这个目标达成一致。
+
+从目标中可见，领导希望看到的执行力，其实包含两个层面，一是效率，二是质量。也就是说，要达成以上目标，你需要从效率和质量两方面进行考虑，并将其放入目标的衡量标准中，这样 OKR 的 关键结果（KR）也就出现了。
+
+随后，针对以上所展示的O 进行讨论，你可以和团队一起制定以下三条 KR，例如：
+
+> 
+<p>KR1：当业务部门提交需求后，需在 1 天内给出评估和反馈<br><br>
+KR2：被确认的需求，将在 3 天内进入功能研发阶段<br><br>
+KR3：当功能正式上线后，不会产生 P0 和 P1 级别的 Bug</p>
+
+
+可见，以上 KR 的前两条是对效率的衡量标准，第三条是对质量的衡量标准，如果这三条 KR 都能做到，那么 O 就实现了。
+
+此时，你需要再次跟领导确认以上 KR 是否能有效地支撑你们双方都认可的 O，这一步操作，至关重要。可能你会认为领导根本不关心这些细节，但我仍然建议你向领导及时汇报，汇报形式比内容更重要，这也是你与领导建立信任的一个必要过程，也是发挥你中层领导力的最佳时机。
+
+我认为，制定 OKR 其实不难，难的是如何发挥你的中层领导力，让基层和高层都能认可你所制定的 OKR。不过，“对下”和“对上”要采取不同的沟通技巧。
+
+- **对下，需要让你的团队理解高层的期望。**千万不要去跟团队讲这是领导的要求，而要设身处地站在提升团队价值的角度去讲。比如，你可以说业务部门堆积的需求迟迟得不到处理，这些事实会降低其他部门对我们的评价，认为我们不够高效。
+- **对上，需要让你的领导知道团队的现状。**比如，现在业务部门提了需求，一般要 3 天才能评估和反馈，希望通过流程的改进，让响应时间尽可能压缩到 1 天。你要注意和领导谈话时的技巧，要让他了解现状和目标，让他感受到你在为提升执行力而努力。
+
+作为中层管理者，你不仅要准确理解领导的意图和期望，还要将其转化为可执行的策略，并得到团队的认可和支持。所以，你需要无处不在地施展你的领导力。
+
+其实，**OKR 就是这样的工具，它能帮助你将领导的意图和期望转化为目标，随后你需要发挥你的领导力，让团队真心认可这个目标，并且和你的团队一起制定衡量这个目标的关键结果**。OKR 就像一根纽带，它通过建立统一的目标，将高层、中层和基层牢牢地系在一起。
+
+## 总结
+
+作为中层管理者，你不应该感到沮丧，反而你应该感到无比兴奋，因为在这个岗位上，你将学到比其他人更多的经验，尤其对你而言最重要的领导力。如果每一位中层管理者都能有这样的意识，将产生更强的正能量，而带团队就需要对团队各成员不断地进行正向引导。
+
+另外，有压力也是好事，挑战就是机会，当你遇到压力或挑战时，不妨思考一下，是否有更好的方法来解决这个问题。OKR 就是这样的好方法，只要你正确使用它，就能快速了解到大家心中不同的诉求，达成共识，产生共赢。
+
+今天我所讲到的内容，可简要概括为以下三个核心观点：
+
+1. **中层管理者是企业的“腰部力量”，腰不好，诸多问题都会出现。**
+1. **提升中层领导力，是解决企业“腰虚”的有效方法。**
+1. **OKR 不仅能管理工作目标，还能将领导的期望和团队的成长连接在一起。**
+
+最后我想说的是：**如果将 OKR 放在那里，它只是一种目标管理工具；如果将 OKR 和你的领导力相结合，它必将威力无穷。**
+
+## 思考时间
+
+你怎样看待“领导力”与“执行力”，你认为谁更重要？期待你的留言。
+
+最后，如果这篇文章让你有所收获，请把它分享给你的朋友，我们一起探讨。

极客时间专栏/黄勇的OKR实战笔记/OKR管理心经/19 | 敏捷与OKR都是为了“拥抱变化”，两者如何无缝整合？.md

@@ -0,0 +1,134 @@
+<audio id="audio" title="19 | 敏捷与OKR都是为了“拥抱变化”，两者如何无缝整合？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d8/92/d81b02e804829d0f63ef28772e691f92.mp3"></audio>
+
+你好，我是黄勇。记得在十多年前，我第一次了解到了“敏捷”的概念，当初我只是把敏捷理解为高效，不过后来才发现，**敏捷不只是高效，更多的是适应外界环境的不断变化，并做出灵活调整，**这就是我们常说的“拥抱变化”了。
+
+今天，我想和你从“拥抱变化”开始聊起，看看传统敏捷方法所遇到的一些现实问题，以及如何将敏捷与 OKR 相结合，进而发挥出更大的效用。
+
+## 为何敏捷可以拥抱变化？
+
+在此之前，我先来给你讲讲什么是“敏捷”。其实，敏捷概念提出之初，人们就一直在关注并探讨敏捷的落地问题，首先是《敏捷宣言》的诞生，它正式宣传了“四大价值”这些软件开发方法：
+
+<img src="https://static001.geekbang.org/resource/image/67/26/67048cd0d9bb6a9f4a657fd93e640826.png" alt="">
+
+### 什么是敏捷？
+
+由上述讲述内容可知，敏捷强调个体之间的互动，要求能够发布可以工作的成果，提倡跟客户建立合作共赢，也推崇拥抱变化的思维。
+
+在十多年前来看，敏捷确实是一套先进的方法论，虽然在传统软件开发领域，其实大家更在意的是流程、工具、文档、合同、计划这类不变的东西，但是人们所处的外界环境在不断变化，面对的业务也在不断变化，人们常说“唯一不变的就是变化”。逐渐地，人们开始接受敏捷，并认同它所主导的核心价值。
+
+另外，在敏捷宣言提出后，业界也出现了一些偏实践的敏捷方法，例如：XP 极限编程、Scrum 敏捷方法、看板等。而这些敏捷方法中包括了很多有价值的工具，比如，每日站会、结对编程、代码评审、持续集成、测试驱动、计划扑克等。
+
+### Scrum 敏捷方法
+
+尤其是 Scrum 敏捷方法，还提出了团队的角色分工和协同流程。
+
+比如，由 Product Owner（产品负责人）负责维护 Product Backlog（需求池），由 Scurm Master（项目负责人）召开 Sprint Plan Meeting（计划会议）和 Daily Scrum Meeting（站立会议），最后全员一起参与 Sprint Retrospective Meeting（回顾会议）。
+
+<img src="https://static001.geekbang.org/resource/image/0a/d1/0ae6fe4700fbba86a57d9aaeba6898d1.png" alt="">
+
+实质上，Scrum 敏捷方法的核心思想，就是将不断变化的业务需求放入 Product Backlog， Product Owner 从 Product Backlog 中取出优先级较高的需求并将其放入 Sprint 迭代中，随后定期发布一次迭代，每次发布都需向客户交付可以工作的软件。
+
+此外，Scrum 的会议也在此过程中扮演了重要的角色，不仅跟踪了进度，也能起到计划和复盘的作用。
+
+可见，每次 Sprint 的迭代都是一个固定的阶段，该阶段包括了一些具体的任务，我们通过完成这些任务去实现阶段性的目标。这样一来，基于“任务驱动”的方式看似敏捷，而在实际应用过程中，往往又会遇到一些现实问题。
+
+## 传统敏捷方法有何问题？
+
+以我们团队为例，曾经使用 Scrum 敏捷方法进行软件开发，不过经历了几次迭代后，我却发现似乎团队伙伴们更关注每次迭代中的任务本身和实现细节，而且技术团队就像一台机器，在周期性地运转，并不断地对外交付客户所需要的成果 —— 代码。
+
+### 发现问题
+
+**技术团队疲于奔命，不过一旦发现自己交付的成果无法体现自身价值时，整个技术团队的士气都会受一定影响。**
+
+比如，技术团队完成了 2 周的迭代，上线了一个新功能，但发现上线后 2 个月内都很少看到用户在使用功能，更别说积累大量数据了。
+
+此时，技术团队就会认为产品团队当初接受了业务团队当初提出的“伪需求”，让技术团队花大量精力去做了一件没有意义的事情，长此以往，技术、产品、业务三个团队之间就容易产生一些分歧甚至争吵。我觉得这样的事情不应该频繁发生，而是应该依靠一种机制来解决。
+
+### 分析问题
+
+既然问题已经出现，那么就不妨仔细分析一下 Scrum 敏捷方法的价值。其实，Scrum 敏捷方法划分出许多 Sprint 迭代，这样操作的价值主要体现在以下几个方面：
+
+1. 让 Sprint 迭代周期更短，更能适应外部环境带来的变化或影响，实现“小步快跑”的节奏。
+1. 让 Sprint 迭代变得更有规律性，从而提升团队协同工作效率。
+1. 让每一次的Sprint 迭代的目标变得更加聚焦。
+
+那么，迭代周期到底需要多短？如何让每次迭代都更有规律、更加聚焦呢？
+
+### 解决问题
+
+不难发现，当我们学习了 OKR 之后，很容易就会发现，OKR 和敏捷所提倡的方法类似。同样地，实施 OKR 也是要**固定周期、小步快跑、一步一个脚印的**。通过团队使用 OKR，可帮助伙伴们围绕团队目标不断努力，做出贡献，让团队精力更加聚焦。
+
+可见，OKR 和敏捷之间存在了大量的相似性，是否能在敏捷中使用 OKR，从而让敏捷迭代的目标更加聚焦，让团队更有激情地去实现所迭代的目标呢？于是，我自行设计了一套**基于 OKR 的敏捷方法，**下面我将详细介绍它的用法。
+
+## 如何在敏捷中使用 OKR？
+
+敏捷过程中的许多环节都涉及到开一些重要会议，比如，项目启动时有计划会议，项目执行过程中每天都有站立会议，项目结束后还有回顾会议。此外，敏捷也需要团队内部高度协同。可见，OKR 执行过程中也是类似。
+
+### 开季度会
+
+在每个季度开始之前，技术、产品、业务三个团队的负责人会在一起开一次重要的会议，在会上主要讨论的是：本季度业务遇到的用户痛点有哪些；业务上优先级最高的需求是什么；要想解决这些需求，能对公司年度 OKR 的哪些方面有所支持或贡献。
+
+接下来，产品和技术团队也会聊聊自己部门季度 OKR 是什么，以及与公司年度 OKR 对齐的逻辑是什么。
+
+最后，大家将在会上决定本季度即将发布几次迭代，以及每次迭代的目标是什么。
+
+其中，会议组织者往往是产品负责人，他将引导大家一起制定出每次迭代的 OKR，以及迭代 OKR 中包含哪些 O，以及能支撑 O 的 KR 是什么。
+
+### 经验输出
+
+我的经验是，**一般设置 2 周 1 次迭代，为了目标更加聚焦，每次迭代 OKR 仅包含 1 个 O。**也就是说，每个季度差不多有 6 次迭代，总共将实现 6 个目标。
+
+比如，Sprint1 的目标是提高用户注册率；Sprint2 的目标是提高付费转化率；Sprint3 的目标则是改善程序性能问题；而Sprint4 的目标是解决数据安全问题；Sprint5 的目标是为了解决高并发问题；Sprint6 的目标是为了解决系统稳定性问题。
+
+下面是 Sprint1 迭代的 OKR：
+
+> 
+<p>Sprint1 OKR<br><br>
+O：提高用户注册率<br><br>
+KR：<br>
+1）每日网站平均 UV 为 10000 次<br>
+2）每周吸引新用户注册 1000 人<br>
+3）将用户注册率从 0.1% 提升到 1%</p>
+
+
+在设置迭代所对应的目标时，我们会根据公司年度 OKR 和部门季度 OKR 进行考虑，最终给出一份技术、产品、业务三个团队都认可的迭代 OKR。
+
+### 深度协同
+
+**在每次迭代中，技术团队都要深刻理解产品团队给出的需求文档，并在此基础上拆分为多个任务。**
+
+比如，Sprint1 是为了提高用户注册率，我们将重点放在提高潜在用户数和吸引用户注册这两件事情上，而对于提高潜在用户数而言，我们将会在多种不同的渠道上进行引流，包括在网站上改善用户注册入口的用户体验，以及做一些营销工具等小型应用程序。
+
+### 高度融合
+
+此外，项目负责人会将迭代中的任务与迭代 OKR 中的 KR 进行关联，比如，改善用户注册入口的用户体验将对 Sprint1 OKR 的 KR2 有推动作用。
+
+这也就是说，项目成员在完成自己所负责的任务时，就知道自己的工作对本次迭代有何贡献。通过完成任务来驱动 KR 进度更新，从而促进 O 的完成，这种感受会有效加强项目团队的参与感和成就感，进而产生激励效果。
+
+当迭代发布后，我们将基于此 Sprint1 OKR 对 Sprint1 的目标做出评估，技术、产品、业务三个团队的负责人将在一起复盘本次迭代的过程和结果，最终会看到我们投入了多少成本，又将成本投入到了哪些地方，以及所对应的价值产出。
+
+可见，OKR 与敏捷具有高度融合性，OKR 让敏捷变得更加敏捷。
+
+## 总结
+
+敏捷虽好，但它更加聚焦于软件开发本身，能帮助技术团队加快开发节奏，以小步快跑的方式去拥抱业务的变化。但是，敏捷毕竟也不是完美的，除了技术团队，其他人不会关心我们用了什么开发方法，而更关心的则是用户需求和自身诉求能否得到满足。
+
+此外，当需求池积累得越来越多时，技术团队将坠入“生产代码”的陷阱中，我们生产的是代码，而不是价值。如何让我们生产的代码变得有价值呢？必须确保我们做的事情是在建立共识情况下进行的。
+
+因此，我们需要在敏捷过程中学会管理迭代的目标，使用 OKR 工作法将有效解决这个问题，不仅让技术、产品、业务等团队的目标更加聚焦，还能让技术团队所交付的成果，更容易验证出它的价值。
+
+从我的实践经验来讲，**OKR 可与敏捷过程无缝整合，敏捷关注迭代，迭代关注任务，任务由人去执行，人更关心产出，产出可推进 KR 的完成，KR 可推进 O 的完成，O 完成了对人产生激励效果**。
+
+今天的核心内容可归纳为以下三点：
+
+1. **任何看似完美的方法，实质上都有自身缺陷，关键在于灵活应用，敏捷和 OKR 都不例外。**
+1. **只有结合问题思考解决方案，并努力创新实践，才有可能从根源上解决问题。**
+1. **敏捷一般应用于软件开发领域，而 OKR 可应用于任何领域，两者结合，值得尝试。**
+
+祝愿你也能敏捷与 OKR 结合之路上产生更多的收获，沉淀出更多有价值的实践经验。
+
+## 思考时间
+
+你在敏捷开发过程中还遇到过哪些问题？借助 OKR 思维，你会怎样解决这些问题？期待你的留言。
+
+最后，如果这篇文章让你有所收获，请把它分享给你的朋友，我们一起探讨。

极客时间专栏/黄勇的OKR实战笔记/OKR管理心经/20 | OKR大咖说：OKR还有哪些应用场景？.md

@@ -0,0 +1,161 @@
+<audio id="audio" title="20 | OKR大咖说：OKR还有哪些应用场景？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/18/7a/1818f0fb7fd5d5643958409c0aecb77a.mp3"></audio>
+
+> 
+<p>From 黄勇：<br><br>
+每家公司都有一套自己的管理和协作方式，每位领导者都有一套自己的实施心经。为了让你能够更加全面地了解目前国内外互联网公司（包括创业公司）的实施流程和落地标准等内容，更多元化地了解各位大咖对 OKR 的想法，我和极客时间团队一起为你策划了“OKR 大咖说”栏目。在这个栏目中，我会邀请不同公司的大咖来从不同的角度为你分享他们的实施心经。<br><br>
+今天邀请到的姚琼老师，是美国人力资源协会OKR认证讲师，她曾担任微软培训经理以及原爱立信人力资源总监，一直致力于人力资源绩效管理的创新研究与实践，是国内最早倡导企业引进与运用OKR的讲师，另外，著有《世界500强绩效管理，你学得会》《OKR敏捷绩效管理，你学得会》和《OKR使用手册》。</p>
+
+
+你好，我是姚琼。近几年，我在全国各地帮助许多企业辅导实施OKR，非常充实，也非常有成就感，因为我看到了OKR带给企业、企业管理层，以及企业员工的变化。我看到了很多企业引入OKR，以此帮助企业或团队来推动战略落地、优化绩效管理，这是OKR常见的应用场景，我想你可能也很熟悉了。
+
+然而，我也发现OKR还有一些其它的应用场景，目前看国内的一些图书和文章里少有提及，在此我将结合我的实践经验与心得来分享给你，希望能给你提供不同的视角，让你能够将OKR结合组织自身的痛点实现“本地化”，实现具有自身组织特色的OKR。
+
+不过在正式讲解之前呢，我想先来给你讲一讲大家在用OKR时可能会面临的一些困惑，只有清楚了这些，我想你才能更深层次理解OKR的实质和精髓。
+
+## 如何解除你关于OKR的困惑？
+
+OKR，是最近风靡全球的管理热词。2019 年年初，百度宣布全员推行OKR，又将OKR推向一个新的高度。但是当你搜索OKR的时候，你会从网络上或者朋友圈中，看到两种截然对立的观点：一种，放弃KPI，转投OKR；另外一种，OKR在中国99.9%的公司根本行不通。
+
+那么，OKR究竟有没有用？能不能用？
+
+我认为，先不要纠结它好与不好，你首先要回到思考问题的本源上。你希望解决什么问题？哪类问题是时常让你感到困惑，却又力不从心的？OKR能不能帮助你解决这个问题？我想，只有你搞清楚了这些，才能知道如何在实践OKR中将其“本地化”，只有专注组织的期望与最终目的，才能避免陷入一些“坑”。
+
+比如，我们在帮助一些组织实践OKR的过程中发现，一些组织期望通过OKR来优化绩效管理，将OKR分数用于绩效考核，那么OKR当然会“像KPI”，员工当然也不会提出具有挑战性的目标。这个时候，你要埋怨OKR不好，那究竟是谁的问题呢？
+
+## 应用场景，决定你OKR的落地方案
+
+基于姚琼工作室这几年对于OKR的研究与咨询辅导实践，我发现一件事，**OKR的运用，除了推动战略落地、优化绩效管理，还有其它几个场景：管理变革项目、激发组织创新、强化组织文化、提升管理水平。**
+
+接下来，我们将从组织痛点、OKR价值、案例与应用时的注意事项这四个方面来逐一阐述，为你思考和导入OKR提供一些参考。
+
+### 场景1：管理变革项目
+
+先来说说我对“变革”一词的理解。其实不难发现，变革是当前组织的常态，不过变革往往就意味着会面临变化：各层级对变革目标的认识，会随着变革推进而进一步明晰；变革的具体路径，也会随着推进而动态调整。
+
+可见，我们很难通过KPI的方式去管理变革，因为KPI更多情况下是依赖于固定的动作去指向一个已知的结果，但变革往往是不可预知的。
+
+相反，OKR就很适合变革项目。首先，OKR是一种沟通工具，通过明确目的、目标、策略、结果来描述变革，这种清晰的结构能使沟通保持在同一个频道。不至于我们在沟通时，有人谈的是目的，有人谈的是方向，还有人谈的是策略，导致沟通不同步，进而使得各自理解有差异，最终导致工作效率低下，工作进度缓慢等。
+
+其次，OKR同时要求不断迭代，每阶段都会通过复盘的形式来迭代制定下一周期的OKR。同时，在实施的过程中，我们也对应着目标O来调整KR，动态地适应变革的要求。
+
+接下来，我将通过一个变革项目的OKR应用示例，来说说OKR是如何管理变革项目的。
+
+2018年12月，国内某著名集团公司面对层出不穷的对手和快速变化的市场，开始进行新一轮组织变革。其中，家电企业变革项目OKR将承担从产品主导、销售主导转向用户运营的战略变革重任。
+
+实质上，变革对任何组织而言，都是一个巨大的挑战。通过赋能培训后，家电企业变革项目OKR的每个变革项目组，都组织项目组成员进行了多次头脑风暴，制定了年度OKR。
+
+此后，我们工作室帮助组织公司总裁及其它高管召开OKR共识会，对项目年度OKR和个人OKR进行确认。在共识会中，我们还是发现大家对变革的方向、目的的理解存在不一致的地方。
+
+例如：电商变革，变革目的不是单纯地提升电商占比或者电商占比达到什么程度，而是“首选本公司品牌”。同时，高管们也提出了要有经营逻辑，而不仅仅是一项项的任务，毕竟OKR不是项目管理。
+
+通过共识会，让上下层级的人对变革目标达成一致，形成了共识。在这种应用中，**关键在于几点：**
+
+- 项目OKR与项目计划是不同的。OKR侧重于明确项目的方向和期望达成的结果，它如同项目的指南针，用来保证方向一致。用OKR来管理项目，项目计划则是从KR来推导出来的，并且在执行的过程中，进行不断调整，以推进KR达成。这与我们过去常用的项目管理是不同的，它不是以“计划任务准时完成”为目标，而是以“OKR能否达成”为目标。
+- 项目成员，应该是能对OKR做出直接贡献的人员。我们要打破“层级”和“部门”观念。项目成员彼此之间，要“补位”，共同努力去达成项目目标。另外，项目成员之间没有上下级关系，项目leader更多的是负责提供资源与支持，以确保方向一致；项目成员之间，相互奉献，是横向的协作，而非纵向的“负责”。
+- 要加强项目目标共识，不断强化对变革项目的目标的理解，检查OKR是否能达到项目目的，保持方向正确。
+
+作为OKR的教练，我们参加了多场OKR共识会，都会多次提出这份灵魂问题：**你为什么要制定这个O？这些KR是否能证明O的价值实现？**
+
+### 场景2：激发组织创新
+
+激活组织活力，是当前组织管理中比较热门的话题。除了大家纷纷学习华为，崇尚任正非提出的“熵增”管理思想外，还在于大家所关注的企业所面临的一些困境：当前的商业环境，增长乏力，竞争加剧。组织要想继续维持增长，除了降低成本、提高效率外，还必须加大组织创新，寻找新的业务增长点，或者通过创新找出新的差异点，从而在市场上获胜。
+
+**对于组织内部而言，如何去解决“惰性”，加大创新？如何保持员工像新入职时那样的激情？如何让组织保持像创业时期那样的活力？**我认为这些是作为管理者要一直思考的问题，而我不得不说，OKR恰恰是一个很好的抓手。
+
+接下来，我就以谷歌公司举例来说，因为OKR恰恰推动它实现了指数级增长，当然这也正是很多企业希望使用OKR来推动自身，实现突破与更大增长的原因所在。那么，**谷歌是如何使用OKR来鼓励组织创新的呢？**
+
+第一，员工的目标，是通过自上而下和自下而上两种方式来制定的。一般为一半对一半，也就是几个目标O来自于上级的要求，几个目标O是员工自身提出的。这种机制的设置，可以保证有不同新想法的涌现。比如，谷歌Gmail产品的出现，就来自于一线员工的想法。
+
+第二，员工的目标，要求雄心勃勃，要有野心。在谷歌，一般OKR平均得分在0.6～0.7范围内，就会被认为完成得很好。如果得到1，可能就需要反思是否目标设定得太低。只有具备挑战性的目标，才会激发员工不断挑战，激发创新的做法和策略。
+
+第三，OKR不直接与考核挂钩。创新，尤其是突破性的创新，往往蕴含着失败。在谷歌，即使你的OKR没有达成，公司也并不会扣你的奖金。
+
+在我们帮助实施OKR的一些集团公司中，变革项目的OKR，都是通过与项目成员的多次、反复沟通形成的，不是自上而下推进的。另外，我们为了引导员工敢于挑战，在项目实施中引入了信心指数（confident index），同时明确表示不希望KR的完成是100%有把握的，而应该将把握度控制在50%～70%这一范围内。
+
+虽然在刚开始的时候，大家对目标及数据还战战兢兢，但一周期复盘后，高管更关注未来的推进，并未因大家未达成目标而做出“惩罚”举措，这让大家“松了口气”。在复盘中，员工表示实施OKR后，心态上也发生了变化，不再甘于平庸，更有自驱力了。我想，这也正是管理者们想要看到的。
+
+在这种应用中，关键要注意以下几点：
+
+- 每次设定OKR时，都要求员工必须自己提一个改善、创新的OKR。
+- 要检查OKR的信心指数，引导员工不要设定有100%可能性完成的OKR，只有挑战才能激发创新。
+- 不能将OKR分数与考核进行关联，因为如果直接挂钩，会导致大家不敢提出具有挑战性的目标。
+
+作为OKR的教练，我们会提出这几个问题：**这是你过去没有做的事吗？这个KR完成的把握有多大？这个KR完成的难度在哪里？**
+
+通过提问，我们来判断面前的OKR是否具有挑战性，是否能够促进和激发组织创新！
+
+### 场景3：强化组织文化
+
+所有的人，都认为企业文化非常重要。但究竟什么是企业文化呢？你所在组织的文化是什么呢？不过你可能会发现，好像谁都无法准确地说清楚。关键还在于如何将企业文化落地，我们不难发现，大多数做法是多搞活动、多搞宣传。热热闹闹过后，即使要求所有人都必须记住价值观，但这真的就表示落地了吗？
+
+就OKR可以强化组织文化这一观点，在约翰·杜尔的[《这就是OKR》](http://item.jd.com/12462499.html)这本书中有两个案例：
+
+- Coursera这家公司，将OKR方法与组织的价值观和使命联系在了一起，且公司的核心价值观之一就是：“学生永远是第一位的。”而团队在设定OKR的时候，要检查O（方向）和KR（策略）是否符合公司这一理念。
+- 另一家公司是Lumeris，它们尝试实施了3个季度的OKR，但发现效果并不是那么好，并没有与实际工作关联起来。这其实是我们大多数人在尝试OKR时经常会碰到的问题。在重新“复活OKR”的过程中，人力资源通过引导让高管投入到OKR管理的过程中，员工感受到了老板的关注，并开始真正重视OKR，让员工担负起真正的“责任感”，强化“责任承担”的价值观。
+
+在变革项目的OKR设定中，集团高管一直强调“用户运营，让用户满意”，用这条经营理念来检验和校准OKR。回顾场景1中电商变革的例子，其中O不是“提升电商占比”，而应该是“首选本公司品牌”，因为“提升电商占比”这是销售导向，而“首选本公司品牌”则是用户运营导向。用户运营得好，用户满意，电商占比自然得到提高。
+
+其中，家电企业变革项目OKR总裁在总结会上说道：“OKR可以帮助我们形成最愉悦的工作氛围，保证目标一致，不计较数据，不讨价还价；看准一个目标，心无旁骛地去战斗，共同努力。此外，在用OKR这件事上，我觉得很重要的点在于，一来OKR可以让‘长期思维’落地，以免‘记住KPI，却忘记了长期目标’。二来OKR能帮助并让大家想明白长期目标这件事儿，并能够围绕长期目标去建设组织能力，实现长期主义思维在组织的落地。”
+
+那么，如何使用OKR强化组织文化呢？我们要注重以下几个方面：
+
+- 为什么要设定这个目标？目的是什么？目的应用于公司的使命、愿景和经营理念，要保持一致。
+- 你的OKR管理规则是如何设计的？要强化责任，不一定是通过奖罚，也可通过严谨深入的复盘回顾来落地。要强化创新理念，而你对那些产生价值但不一定有成果的OKR，要有所包容。
+
+作为OKR的教练，要观察组织高层的经营思路与生意逻辑，这其实就是企业文化中最重要的“经营理念”。OKR教练在检查OKR的时候，要强化这种经营理念，保持从上到下的目标和行动上的一致性。
+
+### 场景4：提升管理水平
+
+管理能力和领导能力的提升，是人才发展的重中之重。但是如何提升？仅靠培训，有的时候大家会觉得培训很难转化。如何将所学应用到实际管理工作去呢？OKR可能是一个很好的切入点。
+
+我认为，在设定OKR的时候，要不断地提示自己：什么是最优先的？管理者在一个阶段要面临和处理的事务有很多，要在“一百件事中找出优先级最高的几件事”，这就需要管理者在工作中不断思考工作的价值，抓重点。
+
+那么，什么是关键的？我认为，为了完成一个目标，其实有很多制约性因素，而这就要求管理者在规划目标完成策略的时候，要有一个整体概念和清晰的经营逻辑，同时需要不断思索究竟哪些才是完成目标的关键要素，排除完成目标的非关键因素等。最终，通过目标的设定，不断提升管理者的概念思维能力和计划水平。
+
+另外，在OKR管理过程中要充分沟通。沟通是管理者发挥领导力的关键工具，它涉及：
+
+- 如何与员工达成OKR共识？
+- 如何在OKR实施过程中获取认可和有效反馈？
+- 如何对员工进行教练式辅导？
+- 如何在复盘中提升员工能力？
+- ……
+
+可见，OKR管理过程是提供了一系列场景的，能够让我们将学习到的管理方法和领导力艺术在场景中得以尝试、练习，进而获得相关层面的提升。
+
+在集团变革项目实施过程中，项目组为了加快变革的步伐，以两个月为一个周期来迭代OKR。而且，项目组不只共创了双月OKR，而且将项目OKR分解至各个项目成员：
+
+- 项目经理与成员沟通确认，再在过程中予以辅导。
+- HR与运营部门将OKR推进作为一个重要的项目进行管理。
+
+他们与我们工作室认真进行了探讨，形成了项目OKR具体指引，包括共享方式、OKR更新方式、周会机制等，指引各项目组推进OKR落地。
+
+另外，项目组采用周会的形式进行OKR跟踪，通过腾讯文档、公司云盘等方式来实现OKR周更新和信息共享。HR与运营部门为每个项目组安排一个专职HR人员担当OKR观察员，确保项目组及时按要求进行周跟踪。
+
+首次周会，我们通过远程参与，观察周会执行的流程与关键要点，确保有效和高效。在周会召开前，我们重新提示了周会该如何召开，因为OKR周会与过往的工作例会有很大的不同，它聚焦于未来；召开完毕后，我们进行了针对性辅导，提示了可以增加的元素和注意的要点；所有小组首次周会结束后，创新项目OKR观察员与我们又进行了探讨，形成了周会指引，规范了OKR周会执行。
+
+实质上，周会是一种高效的沟通形式，如不涉及专项问题讨论，一般情况下在45分钟左右。后期在复盘整个OKR落地时，大家的反馈还不错，认为周会是一种很好的机制，不仅可以及时纠偏、及时发现机会点。项目成员认为应该继续坚持周会机制。
+
+在本次OKR落地过程中，由于该集团家电企业变革项目OKR管理层级及项目组成员严格执行OKR过程管理，因此迅速提升了管理层的领导力。
+
+在这种应用中，我们要注重以下几个方面：
+
+- 要通过OKR来强化什么？比如强化业务规划能力，强化过程管理能力，强化反馈能力，强化管理者教练能力等。另外，我建议你可以在一个阶段专注一个点，就如OKR方法一样，聚焦和专注能带来突破。
+- 组织内部要针对性对管理人员进行赋能，比如提供指引文件（如何开会、如何填写报告等）、赋能培训（比如行动教练、问题分析与解决等）。
+
+OKR教练要做的，就是有针对性的根据组织管理痛点，有阶段性的专注某一方面，提供场景化和可操作性的方案，赋能管理者。
+
+## 总结
+
+本文总结了国内企业使用OKR的一些其它场景，当然有的组织会想要“一箭多雕”，但需要注意的是，你最希望通过实施OKR来解决什么？使用的场景，决定了我们OKR实施“本地化”的策划。
+
+我们正在帮助越来越多的中国企业落地实施OKR, 也的的确确看到了惊喜和成果。一起加入我们吧，让OKR助力中国企业转型变革，突破创新！
+
+## 思考时间
+
+讲完以上内容，我想请你来思考几个问题：
+
+1.当前组织中，管理的痛点有哪些？<br>
+2.这些痛点中，可以用OKR方法来解决吗？<br>
+3.如果你使用OKR，最希望达到什么期望？
+
+我的分享就到这里，如果今天的内容让你有所收获，或有新的启发，欢迎你在留言区留言，与我分享你的故事，也欢迎你把它分享给你的朋友，一起沟通探讨。

极客时间专栏/黄勇的OKR实战笔记/OKR管理心经/21 | 热点问题答疑（三）：如何计算研发团队人效？.md

@@ -0,0 +1,168 @@
+<audio id="audio" title="21 | 热点问题答疑（三）：如何计算研发团队人效？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9d/4c/9d8f821d143135bc84be21baafaf544c.mp3"></audio>
+
+你好，我是黄勇。相信你学完了“OKR 管理心经”，一定对 OKR 有了全新的认识，**OKR 不只是一款目标管理工具，也是一种目标管理思维，**它也就是我经常提到的“OKR 思维”。
+
+当你学会了这种思维，我想，这一定会对你的管理能力带来显著地提升。为了能帮助你更加深入理解“OKR 思维”，今天我挑出了几个比较有代表性的问题，接下来与你进一步探讨。
+
+我们先从任务（Task）和关键结果（KR）的区别开始聊起，因为学会了 OKR 思维，你将更好地将 OKR 运用到日常的项目管理工作中去。
+
+## Task 与 KR 到底有何区别？
+
+在执行 OKR 过程中，我们容易将 Task 与 KR 发生混淆，从而不理解它们之间的本质区别，有位读者就产生了一些困惑：
+
+> 
+<p>读者「David Mao」表示：<br><br>
+这篇文章中的例子我有点困惑，老师讲目标与任务要分开，不能把任务当目标，可举的例子看起来就是任务。<br><br>
+来源：《15 | 技术团队真的是“成本中心”吗？如何改变这一现状？》</p>
+
+
+我认为，**在 OKR 的世界中，Task 是微观的，而 KR却是宏观的。**要想分辨 Task 还是 KR，可以遵循这一基本原则：**当你打算去做一件事情时，如果完成这件事情非常容易，比如说难度小或者耗时少，或者做完这件事情后，对 O 没有明显推动作用，那么它就是 Task，否则就是 KR。**
+
+根据以上判断依据，对于[《15 | 技术团队真的是“成本中心”吗？如何改变这一现状？》](https://time.geekbang.org/column/article/112110)文中所提到的 OKR 示例，我们重新来理解 Task 与 KR 的区别。
+
+> 
+<p>图片验证码项目 OKR<br><br>
+O：尽快升级注册页面用户体验，从而有效提升注册转化率<br><br>
+KR：<br>
+1）1 周内上线“图片验证码”功能<br>
+2）功能上线后，3 个月内将注册转化率从 1% 提升到 5%</p>
+
+
+以上 O 制定得非常清晰，就是要“升级注册页面的用户体验”，目的是为了“有效提升注册转化率”，因此，我们的 KR 就需要基于这个 O 进行展开，KR 必须对 O 产生强有力的支撑作用才行。所以接下来，关于这些 KR，我们逐个继续分析。
+
+> 
+KR1：1 周内上线“图片验证码”功能
+
+
+完成这件事情非常容易吗？难度小？耗时少？就“图片验证码”这项功能而言，如果自行开发的话，由于细节较多，开发起来还是有些难度的，同时开发周期也比较长；如果找开源工具来做，也需要做一定程度的加工和优化，难度虽难不大，但开发周期也不短；如果购买商业产品，几乎没有太大的开发难度，但内部需要走采购流程，也要几天时间。
+
+看来不管哪种方式，耗时都较长。所以，可以判断出这件事不是 Task，而是 KR。
+
+> 
+KR2：功能上线后，3 个月内将注册转化率从 1% 提升到 5%
+
+
+是否增加了图片验证码，就一定对注册转化率有增长？对于这个问题，就需要通过一段时间来观察，我们不妨称这段时间为“观察期”。
+
+不过，我们需要对此观察期设置一个可衡量的指标，该示例中是“注册转化率”，此外还需要对该指标设置一个增长预期，比如从 1% 到 5%。可见，花 3 个月时间来观察，耗时就不短，而且注册转化率增长 5 倍，倒也不少。看来完成这件事，耗时比较长。所以，可以判断出这件事不是 Task，而是 KR。
+
+**当我们制定出 KR 后，接下来就需要分别对这些 KR 制定更细粒度的 Task。**如果我们选择通过购买商业产品来实现图片验证码功能，那么就可将以上 KR1 分解为如下 Task：
+
+> 
+<p>KR1：1 周内上线“图片验证码”功能<br><br>
+Task：<br>
+1）研究 3 家“图片验证码”供应商产品<br>
+2）整理 1 份产品对比文档，并决定最终选型<br>
+3）向公司提交产品采购申请<br>
+4）付费购买“图片验证码”产品<br>
+5）接入“图片验证码”产品，并确保其可用性</p>
+
+
+同理，针对 KR2，你也可以尝试分解一下它所包括的 Task，可在留言处告诉我你是如何细致分解的。
+
+关于 KR 与 Task 的区别，以及如何使用它们的方法，我先讲到这里，若有不理解之处，欢迎在留言处继续探讨。
+
+当我们将 KR 分别出可执行的 Task 后，接下来的问题就在于如何提升团队执行 Task 的效率，也就是“人效”了。那么，对于研发团队而言，我们应该如何计算这个“人效”呢？
+
+## 如何计算研发团队“人效”？
+
+尤其对于研发团队而言，关于“人效”的问题确实比较难于衡量，在[《16 | 大家都说“向上管理”很重要，你想学一些“套路”吗？》](https://time.geekbang.org/column/article/112373)篇中，就有多位读者提出过类似的问题：
+
+> 
+<p>读者「天涯海峰」提问：<br><br>
+老师，能透露一下那位 CTO 是怎么计算人效的吗？我们一天早 9 晚 7，工作时间为 9 小时。记录 2 个月每天的用时情况，包括加班，以半小时为维度，每天工作占总时间 32%，按照统计工作接近 8 小时，但效率肯定不是。</p>
+
+
+> 
+<p>读者「阿神」提问：<br><br>
+这个案例的人效怎么算？会不会上有政策，下有对策，为了纠正对策，可能又引入一些影响人效的流程。</p>
+
+
+> 
+<p>读者「黑暗天使」提问：<br><br>
+对于团队来说，还是需要塑造向上管理的团队文化，作为技术出身的人，本身沟通技能就偏弱，培养这种文化，将有助于帮助团队进行好的沟通管理。老师，我也想问下，根据项目的情况，计算人力与时间成本，这个具体的计算方式如何衡量的？</p>
+
+
+那么，结合以上几位读者的提问，人效到底应该如何计算呢？我仅针对研发团队而言，给出一种计算人效的实操方法，以供大家参考。
+
+第一步：**针对所有的研发岗位，制定出对应的岗位级别与人力系数。**
+
+<img src="https://static001.geekbang.org/resource/image/9e/71/9ebeeb21c6556d19dfd098d02c584a71.png" alt="">
+
+对于所有的研发岗位，我们可将研发人员分为专业岗（P）和管理岗（M），并选择团队中人数最多的岗位作为基准，设置该岗位的人力系数为 1，表示最普通的人力资源，其他岗位可依此做出合理设置。此外，对于不参与具体执行的岗位，无需设置人力系数。
+
+第二步：**针对项目的难度级别，分别对应其设置难度系数。**
+
+<img src="https://static001.geekbang.org/resource/image/ab/e7/abfd9960abba4ddf3fdddfc26726ade7.png" alt="">
+
+可以先对最容易做到的项目设置难度系数，其他项目以此做出合理设置。
+
+第三步：**根据实际投入情况，计算研发团队人效。**
+
+<img src="https://static001.geekbang.org/resource/image/9f/db/9f637f3477a95d34e6ea05bad136aedb.png" alt="">
+
+其实，我们可按照季度为周期来计算平均人效，以上图片中所展示的内容，就是我们曾经在 2018 年第四季度的人效情况。
+
+我认为，可在 Excel 或 Numbers 电子表格制作一个便于自动计算的工具，并将这份文档共享给团队每一位成员。我们只需填写项目名称、难度系数、项目启动、项目上线、非工作日、人力投入（P1、P2、P3……），表格将会自动计算出人力成本、时间成本、人效。
+
+其中有几处涉及到以下几个计算公式，需要加以说明：
+
+> 
+时间成本 ＝ 项目上线 － 项目启动 － 非工作日
+
+
+时间成本是指项目从启动到上线的天数，不过需要除去非工作日，包括法定节假日。
+
+> 
+人力成本 ＝ ∑ (人数 × 人力系数)
+
+
+人力成本是指项目投入的人数与对应岗位级别的人力系数的乘积并求和。
+
+> 
+人效 ＝ 难度系数 ÷ (人力成本 × 时间成本)
+
+
+人效是项目的难度系数除上人力成本与时间成本的乘积。
+
+可见，要想提升人效，在难度系数不变的情况下，需要降低人力成本的投入，或者降低时间成本的消耗。
+
+因为完成项目的难度是客观存在的，我们唯有提升团队能力，才能有效降低人力成本和时间成本，这样才能从根本上提升人效。那么，如何从从根本上提升团队能力呢？
+
+## 如何从根本上提升团队能力？
+
+关于如何提升团队能力的问题，我身边的同行们也经常在探讨，有些人认为提升团队能力需要招聘更优秀的人才，还有些人认为需要对下属提出更高的要求，但我认为这些都不能从根本上解决这个问题。借助[《17 | 跨部门协同费劲，沟通效率低，如何粉碎“部门墙”？》](https://time.geekbang.org/column/article/113441)中这位读者的提问，我想谈谈自己对此问题的看法。
+
+> 
+<p>读者「w*waiting」提问：<br><br>
+不假象情况，从我（项目部负责人）个人角度出发，项目部内产品-研发-测试-交付；每个项目实施前，确认好最后目标，交付客户满意的成果，这个流程基本没有问题。从横向看的话，个人成长，大家自主性较差，不太好界定（求指导怎么培养）。<br><br>
+来源：《17 | 跨部门协同费劲，沟通效率低，如何粉碎“部门墙”？》</p>
+
+
+我认为，要想粉碎“部门墙”，提升团队能力，**需要建立纵向的“项目团队”，同时还需要构建横向的“职能团队”，并且要以项目团队为主，以职能团队为辅，才能彻底粉碎“部门墙”。**其中，横向职能团队的主要职责是帮助团队成员提高专业能力，需要一位在专业技能上非常卓越，也愿意培养团队的领导者来带领职能团队。
+
+但是，对于自主性较差或自驱力不强的人，如何帮助他们得到成长呢？这里我给出几条建议，大家可有参考性地选择。
+
+第一招：**竖立内部典范。**在团队内部找出有代表性的案例，通过典型的事来激励对应的人，并在团队内部加以宣传，重点强调个人能力的提升，以及对团队做出的贡献。
+
+第二招：**借助外部危机。**通过职场现状，从个人职业发展角度来给内驱力不强的人施加危机感，不努力的人，将无法得到更好的机会，随着年龄的增长，就业压力和失业风险也将越来越大。
+
+第三招：**讲自己的故事。**通过自己的个人成长，以及自己对职业的态度，分享自己的经验和方法，帮助团队成员认清自身情况，找到适合自己的成长路径。
+
+管理就是这样，要学会借助一些方法来提升团队能力，而不是使用自己的职权去要求下属完成任务。所以，管理的目标是让团队高效，而不是让团队在高压下工作。
+
+## 总结
+
+在《孙子兵法》中讲到过“不战而屈人之兵，善之善者也”，孙子认为战争的最高境界是“不战”，不是“百战百胜”，而是“不战而胜”。我认为，**管理的最高境界就是“不管”，不管胜过管。**尤其对于内驱力不强的人，千万不要去“管”他，不要通过管理的手段让他去“变”，而是让他自动地学会去“变”，这才是我认为的“管理心经”，归纳起来就三句话：
+
+1. **管理不是艺术，也不是科学，而是人性，我们要让管理适合人性。**
+1. **管理就是让团队成员认同目标，并帮助大家合力去完成目标。**
+1. **不要去管那些难于管理的人，要去管那些值得管理的人。**
+
+想象一下，把自己当作一名园丁，一手提着洒水壶，一手提着肥料桶。偶尔，你需要除草，但是大多数时候，只要浇水和施肥，细心呵护。随后，你就能看到满园花开了。
+
+## 思考时间
+
+在你与上级领导、同级部门、下级同事合作过程中，经常会遇到哪些棘手的问题？欢迎留言告诉我。
+
+最后，如果这篇文章让你有所收获，请把它分享给你的朋友，我们一起探讨。