为什么初创公司通常是充满活力的网络结构，度过初创阶段则通常会成长为官僚化的层级结构？这里简单探讨两个驱动因素，如下图中左侧悬臂（1,5）所示。
图1: 组织复杂度为何增加
第一个驱动因素是领导者对专业化效率的期望。度过初创阶段之后的一个倾向是为效率而优化，以尽可能收割其成功产品收益。提高效率的传统做法是细化分工，从创业时期的人人都是全能战士，转向"专业的人做专业的事"，如图中B1环路（2-3-4-9-2）所示：专业化效率提升压力(2)导致分工细化，分工细化使得专业化效率提升，专业化效率提升使得专业领域的产出提升，于是压力得以缓解。此动态背后的领导者心智模式是：细化分工有利于效率提升、产出增加。
然而分工细致程度同时也带来了整合成本的增加（包括分工产生的等待浪费和集成投入）。这至少部分抵消了专业区域产出导致的总产出增加。
（分工细致程度导致的专业化效率提升还受分工导致的依赖制约，为简化，图中不表达）。
第二个驱动因素是领导者对管控程度的期望。领导者的控制倾向带来增强管控程度的压力。这种压力会使分工细致程度增加，以增加角色职责清晰度，从而增强管控程度，缓解管控压力（环路6-3-7-8-6）。此动态背后的领导者心智模式是：明确的职责分工可以带来对组织和员工的有效掌控。
公司成长过程中，这两个驱动因素往往导致分工细致程度增加，然而分工细致程度的增加又带来一系列其他后果。分工细化会导致部门增加，进而导致组织层级增长，应变能力下降（3-15-16）。同时分工还会导致组织壁垒产生（3-12）。组织壁垒有促进人员增长的倾向（地盘意识以及流动性降低所致），而人员增长又容易进一步强化组织壁垒（软件开发为例，模块所有团队有使模块变复杂的倾向）。
组织壁垒的产生和应变能力的下降都导致组织更难把握市场上的机会，于是创新能力下降，这在更长的时间里导致总产出下降（13-10），组织走向下坡路。
由以上分析可知，组织复杂程度的增加有其内部原因，有些原因与领导者的心智模式相关而非价值驱动。而从精益观念来看，如果把组织的目标定位为为客户创造价值，那么组织的复杂性往往是超出必要的。所以，转型中常常有"简化组织"的呼声。
组织应变和创新能力的提升，有赖于领导者的心智模式升级。如果组织创新能力乃至总产出的下降不能触及领导者的心智模式，那么转型容易头痛医头脚痛医脚，难能成功。只有领导者理解了所面临问题的根源，才可能从管控型组织转向赋能型组织，并纠正对专业化效率的片面追求，使系统动态发生根本转变 – 如下图中上下两条红线。
图二：组织转型的心智基础
<感谢Paulino Kok老师的洞见对此文的贡献>
马林胜/20200420
僵化的详细长期计划（根据消耗的预算跟踪进度）正在敏捷组织中迅速成为对过去的褪色怀旧记忆，这由预测和非静态路线图代替。定期在这些可视化文件前聚会，您将能够学习、共享并触发重要的对话，解决依赖性并邀请服务型领导的行为。使您的OKR和预测计划共存！
在这个博客中，我想给出带有可视化示例以及伴随的重复仪式。可视化和伴随的仪式可以共享进度，并确保持续解决和减轻障碍和依赖性。它还将预测变成对话（与被视为承诺的项目计划中捕获的固定估计相反）。
参与团队回答的核心问题是：
敲黑板 - 划重点（译者注）
“您是否有信心在本季度末之前完成关键结果？”
你可能还喜欢 Google OKR小册子
如果您不熟悉OKR，目标和关键结果的概念，则可以将目标视为”让我们对这一领域/问题/需求加倍研究”，而关键结果则视为”让我们完成这一特定影响/结果/目标/交付成果”这将推动我们朝着目标迈进。” 对于每个季度，目标数量通常限制为3-5。每个目标依次具有3-5个关键结果。常见的指导原则是，平均而言，您应该以关键结果的70％成功，即以30％失败，这是正常的并且可以接受。该准则可确保我们设定大胆的目标，并避免安全起见。为什么？好吧，如果我们惩罚成功率不到100％的事情，我们最终将优化军阀制度。
OKR白板站立会议 当2017年重新引入OKR时，我曾在Spotify担任敏捷教练。我所工作的部落（认为半自治部门）不希望OKR成为PowerPoint中的静态幻灯片，而该幻灯片很快就被人们遗忘了，但是在生活我们可以随时”计划”，以找出如何互相帮助。
与其以数字演示形式总结部落的集体协作的OKR，我们将它们（OKR）写在一块大白板上，该白板在所有团队旁边的走廊上非常醒目。每两周一次，我们进行OKR白板的站立会议。希望加入的每个人都受到欢迎，但我们要求每个团队（八个团队）至少有两名代表参加。
会议的例行很简单。我们走上了白板，一次实现了一个目标。对于每个目标，我们都会大声读出关键结果的措辞。提供该关键成果的工作团队简短地分享了进展并宣布了他们的信心水平。会议持续了15至25分钟。
置信度 对于每个关键结果，相关团队都回答了以下问题：
“您是否有信心在本季度末之前完成关键结果？”
绿色自信的笑脸 –完全自信这会发生。我们可以准备市场营销活动。
橙色担忧的笑脸 –我们可能做不到，应该提醒利益相关者。
红色悲伤的笑脸 –没办法。这不会在本季度内发生。不过，我们仍在努力。
检查 –完成。已交付。做完了。
停止 –我们已停止进行此工作（…由于优先级的改变或关键结果本身已变得无关紧要）。
每个关键结果下方都有6-7个框（取决于该季度中发生了多少个两周的周期），每个OKR白板站立会议都用掉一个框。当我们进行第三次站立时，我们填写了第三个方框，依此类推。这种方法使我们对我们的信心水平有了历史的认识。
如果有几个团队提供相同的关键结果，那么他们每个人都分享他们的进度和信心水平。但是，最悲观的置信度是框中显示的置信度。
提供关键结果的团队名称以方框下方的小文字表示。
实际上，我们有第六个符号-？问号表示”我们还不知道”。有时事实证明这是现实，他们真的不知道。但是对我来说那很奇怪。如果团队不确定自己是否有决心在OKR周期内实现目标，那么如何使团队”致力于”关键结果？但是事实证明它很有用，因此我们使用了它。
关键对话触发器 但是，重要的不是信心笑脸本身的更新-重要的事件是当笑脸的颜色从上次OKR白板站立起改变了颜色。
这些变化是重要对话的关键触发因素。绿色的笑脸变成橙色或红色的笑脸时，我们暂停下来，直到我们共同弄清楚如何采取行动后才继续进行讨论。房间里谁能帮忙？会议室中的谁可以将需要帮助的团队与可以帮助的人联系起来？我们需要提醒利益相关者吗？谁提醒利益相关者？要改变置信水平吗，需要做什么？等等。
仅在决定了至少一项有力措施（有可能推动我们前进）之后，我们才进行下一个关键结果。
即使每个团队每天都尽自己最大的努力来减轻障碍和解决依赖性，但OKR白板站立会议提供了一个反复出现的机会，可以将问题升级为需要扩大支持的朋友和领导者组织。
庆祝完成 当有人宣布他们完成”关键结果”并在框中打勾时，我们显然以雷鸣般的掌声庆祝。
服务型领导的机会 最初，一名敏捷教练协助OKR白板站起来。在前几次的站会中，三个部落首领都没有找到时间来参加。但是在第四次站会，其中一个部落首领加入了。
在几分钟之内，我相信他意识到这是一次千载难逢的良机，可以阅读所有团队的脉搏，对进度进行汇总并提供有益的服务型领导行为。他可以提供建议（在被问到时），为团队面临艰难的选择时提出前进的道路，并由于他或她的广泛网络而提供帮助，将需要的团队与利益相关者和组织的其他部门联系起来。
下一次OKR白板站立会议，所有部落首领都作为观察员参加了会议，准备在被要求时提供帮助和支持。很快他们甚至轮流为仪式本身提供帮助。
OKR白板审查会议 当季度结束后，我们聚集在一起参加OKR白板审查会议。我们回顾了已完成的关键结果，并讨论了未完成的结果。我们能学到什么？在下一个OKR周期中，我们可以带些什么？我们如何改善可视化和OKR板站立状态？
完成百分比 在第二季度，我们运行OKR白板站立会议，我们添加了一个方面来尝试使进度更新更加完整。对于每个关键结果，相关团队不仅回答他们的信心如何，而且还估计到目前为止他们已经完成了多少工作。（译者注：这个百分比慎重加）
我们为什么要这样做？好吧，我们觉得我们缺少故事的一部分。我们了解到，有时即使有些团队只是猜测自己已经完成了10％的工作，他们还是感到超级自信。有时，即使90％的工作都完成了，团队也感到非常悲观。在某些情况下，这是非常有用的信息。
组织内传播 当下一个OKR周期的时候，我们进行OKR白板后续行动的方式已在内部传播。令我们感到惊喜的是，几个部落抄袭了我们的方法。
当某种东西传播并在内部进行时，这是工具/技术/方法有用且有价值的最好”证明”。
可能的变化 如果这种方法对您有所启发，但您在团队或部门中未使用OKR，则此方法有许多变体，仍将静态预测转换为持续对话，从而触发重要对话。
预测扑克计划 如果假设我们正在处理解决一系列特定问题或完成功能之前无法交付产品，那么我们可以要求团队成员逐个猜测 “多少周/每次冲刺可以完成我们需要达到X？”通过在便利贴上写下他们的猜测。
删除最悲观和最乐观的投票，并在白板上写下剩余的范围。如果估计范围不会每周减少一周，那么您就有机会讨论可能采取的措施或缓解措施。
截止日期置信度 有时我们需要应付一个固定的期限。也许我们的机会窗口有限，或者也许我们必须在特定日期之前满足法律要求（例如GDRP）。然后我们可以问团队“我们在日期Z之前完成X的信心如何？”
可以用五个手指进行投票。一根手指代表超级悲观，五根手指超级乐观。三根手指可能意味着紧张。如果信心没有每周增加一次，我们将讨论需要做的事情或摆在我们面前的选择。
版本的猜测 一些团队会持续交付，但仍需要与利益相关者和客户沟通进度和期望。他们从产品待办列表中拉取工作加入到Sprint中。
可视化预测的方法是在Backlog中添加两行（例如，使用胶带）。
每个Sprint Review团队的成员都会问自己两个问题：
“我们对在接下来的四个冲刺中交付多少产品列表条目充满信心？”
“在接下来的四个冲刺中，我们还能提供多少呢？”
绘制一条绿线以可视化我们有信心我们将完成产品列表的工作。绘制红线以可视化乐观范围。
我常说我可能发明了故事点，如果真是这样，现在我会感到很抱歉。让我们一起来探索我现在对故事点的思考。至少有一个人对我所想的很感兴趣。 – Ron Jeffries
当然，故事是极限编程的思想，不是Scrum的。不知何故，Scrum践行者接受了这个理念。尽管在Scrum官方指南中有关待办事项的内容，将待办事项作为用户故事是一种普遍的Scrum实践。
至少在某种程度上来说，他们是对的。我已经在其他地方写了关于故事的常规用法，正如它应该被写下来一样。在这里，我们将讨论的是”故事点”。
在极限编程中，故事最初是用来估算时间的：实现故事需要花费的时间。紧接着我们来谈谈”理想天数”，它是用来非正式地描述如果别人让你尽自己最大努力单独完成故事需花费的时长。我们用理想的天数乘于一个”负载因子”转换得到实际需要的时间。负载因子通常是3（3天才能完成一个理想天数的工作量）。
我们刚谈到用天数来估算，经常是把”理想”抛开。这将导致的结果是我们的老板很疑惑，怎么是要花费3天来完成本来1天就可以完成的任务，又或者说，为什么我们不能用3周来完成50”天”的工作。
我记得，我们开始称”理想天数”只是”点”。所以一个故事应该用3个点来估算，这就意味着这个故事需要花费大概9天来我完成。总之，我们确实也是只用点来决定多少工作进入一个迭代，所以如果我们说大概20个点，没人会反对。
我可能已提出改名字的建议。如果我真这样做了，现在会感到抱歉。从给我的同事西蒙的电子邮件中，有一些关于目前我对这个话题的想法，他问到：
你真的后悔发明了故事点，或者你只是简单谴责当他们做相关度量时，没有正确理解而导致滥用吗？
我答道：
我当然谴责他们滥用；
我认为使用故事点来预测”我们将什么时候完成”充其量是个无力的想法；
我觉得跟踪实际与估算的比较充其量是浪费；
我觉得比较团队的估算质量或速率是危险的。
让我们更深入一点。
实际上，一些用来做”敏捷”的方法，以更容易计划的名义，推荐给各团队规范化用户故事点。这表面上看起来非常合乎情理，却太容易掉进团队比较的陷阱，组织也是经常这样做的。
比较 首先，即使他们看起来很像，每个团队都有自己的技能和特定工作环境。所以如果他们看两个貌似一样的故事，一个团队说这是个2，另一个团队说这是个6，那就不是很有趣了，当然这样比较两个团队也不是个有效的方法。
现在我们怀着好奇心来了解这种状况，首先判断条件是否足够相似来比较，其次试问估算更高的团队，是否需要咱们能提供的帮助。这样就很好。隐式或显式地结束”更慢”团队的劣势或以某种方式搞砸——这将是非常糟糕的事，但不幸的却是很常见的。
我认为对很多管理者来说，比较两个产品团队是件极其诱人的事。在可能的情况下，抛开故事点的概念，甚至抛开评估点的概念，我认为也是足够不可抗拒的。我们回到如何用更少的估算来开展工作问题上，这里还有其他的文章也讲到这方面内容的。
跟踪 对于很多管理者，估算的存在意味着”实际”的存在，意味着你应该拿估算与实际比较，确保估算与实际相匹配。当估算与实际不匹配时，就意味着人们应该要学习如何更好的估算。
对我来说，真正的敏捷里最重要的是选择接下来要做的事，并且立即开展去做。最关键的问题是找出最有价值的事做，并且快速实施。快速开展去做，归结为去做小部分价值高的和快速迭代。如果不这样做，故事成本估算帮助不到什么。
因此，如果估算的存在让管理者把注意力从价值中移开，取而代之的是改善估算，把精力从快速交付真正有价值的东西转移。
这让我觉得估算，不管是点还是时间，都是浪费！
压力 有关估算/实际涉及的是老板们需要”更多”的自然压力。尽管很多团队已经完成了，这是不够的。更多，更多，更多。
交付有价值的东西，最好的方式不是更多、更多、更多，而是频繁的做有价值的东西。如果我们把故事分解到”足够小”替代估算故事，从而达到一直持续平稳地交付有价值的东西。
聚焦在更多的增值。让团队在越来越大的压力下做更多的需求，不可避免地会产生一个坏结果：团队试图更快速地去做，而忽略代码质量和测试。他们瞬间开始承载越来越多的缺陷，因为持续返工去修复缺陷，甚至由于代码质量迅速下滑而放慢速度。事情变得越来越糟糕，压力持续增长，这将演变成一场灾难的节奏。
由于估算至少被卷入过度压力的投入中，我宁愿避免。
我更深入点：我宁愿完全避免迭代或冲刺计划。在接下来几周，我们不会为去填补预算而工作，而会因为接下来有几项最重要的事情清单而做。
预测完成 一种常见的做法是做个基本特性列表，先想一会，然后决定定义我们产品的下一次发布。当然，接下来的问题是”这些什么时候能全部完成？”
没有人知道这个问题的答案。我们可以做很多工作来改善我们不知道的事，在某些领域和某些时候，这当中的一些事也是值得做的，譬如当一个大的合同等待投标的时候。但是当我们正忙于开发内部或外部客户的解决方案时，尽可能地频繁提供少量有价值的东西，而不是等到通常会无限期拖延的全功能一起发布。
选择临近下一次发布给客户的日期，尽可能地挑选好东西到发布中，这样更好。估算故事点或时间阻碍了交付。在我看来，如果可能的话，这最好要避免。
分解（拆分） 那么问题来了，如果你不喜欢故事估算，那你喜欢什么呢？好吧，我喜欢故事分解，它是将大的故事点分解成更小的故事点集合，每个小故事点尽可能高的价值，然而只需要很少的时间就可以完成，理想情况下，少于一天，也许只是几个小时。
现在，我不在乎与你争论分解（拆分）时是否必须进行某种估算。如果你或者你团队的估算只是在脑海里，没有告诉任何人，那么，不论是故事点或时间的估算问题，就不太可能提出来。当然，了解故事点”可能足够小”和”可能不够小”之间的差异并不等同于知道”三天”和”一天”的差别。
另外，这有个技巧。我在 Getting Small Stories 和Slicing, Estimating, Trimming有提到。我也是从Neil Killick学的：分解故事直到它只需要一个验收测试。一个好的故事点只需要很少的实践。
当然，还有关于估算主题的其他文章，点击链接会有超乎你想了解的。
预测将来 但是…难道我们不应该合理的知道一个产品发布需要多长时间和估算是否必要吗？然而也许这不是故事估算。你应该不会把你的需求归结到故事层面，若这么干，貌似是很大程度的浪费。
当然，如果你必须要这么做，那就这么做。无论我做什么或者我的关于你该做什么的理论，只是理念。最终你需要做的是在自己所处的环境下尽一切可能的成功。只是我觉得可以有些更好的东西。
第一，想想下一次发布的一个或多个重要功能。讲讲这些功能可以解决什么问题和什么样的软件可以帮助解决这些问题。谈谈可以解决一些问题的最简单功能。我们不必要解决所有的问题：通常我们提供一些解决方案足以推动事情的发展。
第二，想一个到那时你觉得可以构建出一些好的功能点的时间节点。设置最后的期限并开始着手工作。
第三，再分解重要的功能故事点并实现它。你应该能够在一天或更容易地实现。只做下一步最重要的：别试图老是先实现边边角角的功能。你应该尝试这样的思维框架”如果做了这个小东西，客户Jack就会在实际中使用它”。然后，就做这个小东西并且让客户Jack试用它。我们想尽可能快的持续传递价值。
我们想把正在做的东西的价值明显化，让产品经理或者其他老板等不及想看到产品。这样…我们就在有或没有故事估算的情况下做了正确的事。
最近怎么样？
可怕。我的团队很担心，我们感到与世隔绝，并且我很难将我们重新团结在一起。
听起来很有挑战性。
它是。真的是这样。我只是不了解我所了解的其他团队之间的合作情况如何。
嗯，团队其他成员的感觉如何？
我认为我们每个人都感到同样，沮丧和孤独。
不需要这样，让我们扭转一下……
通过经验学习Scrum的核心。
作为一名活跃的敏捷Scrum顾问和专业Scrum培训师，我一直在帮助众多敏捷团队。毫不奇怪，我所支持的所有团队都在尝试不同的方法来使远程工作正常工作！
我发现有些模式在表现非常出色的团队中很常见
1.创建一个团队WOW (Way of Working) 对于在线工作，团队”工作方式”方法一直是出色的在线Scrum团队执行的首要行动。
Team WOW是团队为自己创建的协议，概述了Covid19发生时我们作为团队将如何合作。一个优秀的团队WOW将回答以下一些问题；
我们将如何合作？ 我们会喜欢Skype、zoom等实时通讯而不是电子邮件吗？ 如果我们决定采用实时方法（好！），那么我们会鼓励打开摄像头还是关闭摄像头吗？ 我们将使用哪些工具来共享我们的工作？ 我们将使用哪些工具来可视化进度？ 我们的主要工作时间是什么？ 我们将如何互相帮助？ 我们将如何保持联系？ 随着事情的变化和我们了解更多，我们将如何更新WOW？ 2.高带宽的沟通 对于日常协作，优秀的团队更喜欢在线的实时通信，而不是电子邮件。协作良好的团队通常会优先考虑
通过视频会议和可视化的网络电话，而不是拨打电话 通过拨打电话，而不是聊天工具 通过聊天工具，而不是电子邮件 通过发送电子邮件，而不是烟雾信号 与我合作的一些团队有主要的视频会议时间，因此他们的摄像头会打开一段时间，以在一天中的一段时间内营造一种联系感。就像和您的团队一起坐了一段时间。其他人仅将视频会议用于安排的会议，这对他们来说就足够了。让您的团队来决定什么工作方式的会议（请参见上文）是有用的，并对其使用进行纪律。
3.实时协作工具 这些工具是团队在分布式时间内保持生产力的重要组成部分。缺乏透明度是我们所有人都应该担心并不断改进的问题。如果我们不知道发生了什么，我们将如何相互支持和帮助？我们如何消除阻碍保持创新和不断创造价值的障碍呢？
Trello，Microsoft Azure，Asana，Mural，Miro等协作工具为团队提供了跟踪进度，共同计划，共同回顾和不断保持我们的工作和思想对团队透明的方式，以便我们可以检查，适应克服摩擦并不断创造价值。尝试一些，采用一些。
4.迭代，使用追溯驱动的变更方法 永远不要低估团队不断学习的力量。在充满挑战的时代，我们永远无法确定会遇到什么。如果您是使用Scrum的敏捷团队，那么您已经在使用回顾来了解什么对团队有效，而哪些无效。您已经在适应新情况；您一直在评估自己的工具，并且对新的交付方式保持开放态度。回顾可以帮助我们检查对团队有用的东西，而不是无效的东西–这不仅仅是物理上的东西。良好的回顾有助于消除情绪上的摩擦，帮助我们检查团队的心理和社会健康；对于细心的团队而言，回顾可以帮助我们在出现灾难之前就对问题进行预警。回顾会通过改进问题来帮助我们变得更好。
5.安排调整后的核心工作时间 最好的团队认为，由于我们的孩子，宠物和家属现在与我们在一起，因此标准的9点到5点工作模式可能不适用。在我们的孩子休息或吃午饭，或者狗需要走路，或者年迈的父母需要检查的时候安排会议可能是不现实的。适应新常态的团队会更改其工作模式和核心工作时间，以消除日常挑战。Scrum提供了一种最小的事件模式，事实证明该事件可以在更改时起作用。最好的Scrum团队已经适应了这些事件，以应对团队特定的调度挑战。
6.测试灾难恢复 您的团队已经在使用回顾来适应吗？如果是这样，那么您可能已经在寻找保持连接的备份方式，并在发生意外情况时可视化工作。如果您的高速宽带停止工作，您的备选方案是什么？对备份技术和方法进行同步测试可帮助团队向前看，切换到备份并保持工作。最近，在进行专业Scrum Master培训时，我的互联网完蛋了。某个地方的某人认为这是切入某些电缆的绝佳时机。多么不方便。
幸运的是，我已经花了几天时间在我的移动互联网提供商之外进行培训，并且已经进行了测试备份。几分钟后，我又开始工作了，培训继续进行。您所依赖的关键技术是什么？这些技术失败的可能性有多大？您打算坚持不懈地进行哪些工作？
7.共同缓解技术摩擦 在家工作时，面对所有挑战，学习新技术似乎令人生畏。没必要。一旦您的团队选择了一些好的工具，一种快速学习它们的好方法就是安排学习课程，我们在彼此之间互相教如何在安全的支持环境中最好地使用这些工具。 当我过渡到画画时（上课不用ppt）-我有些沮丧，我只是想不出如何让壁画去表现我想要的样子。幸运的是，Ralph Joachim邀请我参加他的一项在线练习活动，我可以从他的经验以及其他15个专业Scrum培训师的经验中学到东西。拉尔夫（Ralph）创造了一个安全的空间来回答问题，无论是简单还是复杂。结果全面而快速的学习。当我的互联网失败并且我使用壁画通过移动设备进行了培训时，我没有错过任何拍子，为此我有拉尔夫表示感谢。
此外，学习的团队可以快速适应新工具，有意识地互相帮助，并使用协作安排的课程来一起实验，学习和回答问题。他们不希望它，他们计划并且有意识地互相支持。作为对此的扩展，如果您发现您的同事很挣扎，请提供支持并为他们提供支持。刻意帮助您的团队克服和掌握我们所有人面临的技术挑战，不要以为每个人都知道如何很好地使用所有工具。 8.接受学习，解决问题 动荡的时代意味着我们不会每次都正确。出现问题时，很容易对自己和同事感到沮丧。我们需要对我们的团队耐心等待。学会记住，鉴于他们的技能，能力和可用资源，每个人都在尽自己最大的努力来应对面临的挑战。
敏捷不是要怪罪责，而是要把湍流当作生活的一部分并刻意解决问题而不怪罪。
9.安排非工作事件 我认识的一个管理团队在星期四晚上向他们的团队发送信息，以进行星期五的hangout活动，您能猜到在那里工作的人的士气吗？其他团队在工作日结束时会进行30分钟的视频群聊，以讨论非工作玩笑和咯咯笑声。一些团队已经决定每周一次就足够了。尝试对您的团队有用的方法。
保持在线 请记住，Covid-19意味着我们必须在身体上相距遥远，但我们不必在社会上相距遥远。使用以上方法可以使您与团队更紧密联系，并成功克服当今的挑战。保持。连接的。
我们必须使自己摆脱海洋将永远安息的希望。我们必须学会在狂风中航行。 〜亚里斯多德-奥纳西斯
译者：乔梁 来源：《持续交付2.0》公众号
这是一本关于 OKR 迷你小册子，名为《google OKR playbook》，由 www.whatMatters.com 网站发布。 该网站由John Doerr 团队经营， 而John Doerr 正是 1999年将 OKR 引入 谷歌的那个人。
本文仅供大家学习参考，虽然文章较长，但值得一读，欢迎收藏。
文章的末尾有一些 8 道自我测试题，用来验证你的OKR是否在正确的实施。
如果你正实施OKR，可以用它们来验证一下吧～
在实现OKRs方面
没有人比谷歌更有经验
随着公司规模的扩大，它定期发布 OKR 指南和模板。以下摘录主要来自内部资源，并经谷歌许可转载。
（注：这是谷歌对 OKRs 的做法。你的方法可能不同，也应该不同。）
在谷歌，我们喜欢大张旗鼓。我们使用一个称为目标和关键结果（OKRs）的过程来帮助我们沟通、衡量和实现这些崇高的目标。
我们的行动决定了谷歌的未来。正如我们在互联网搜索、Chrome 和 Android 中多次看到的那样，一个由少量员工组成的团队，朝着一个雄心勃勃的共同目标努力，就可以在不到两年的时间里改变整个成熟的行业。
因此，作为谷歌的员工和经理，我们必须有意识地、谨慎地、明智地选择如何分配我们个人与团队成员的时间和精力。OKR 是这种谨慎选择的体现，也是我们协调个人行动，以实现伟大集体目标的手段。
我们使用 OKR 来规划要生产的产品，跟踪它们的进度与计划，并协调人与团队之间的优先级和里程碑。
我们也用 OKRs 帮助大家专注于最重要的目标，并帮助他们避免被紧急但不太重要的目标分散注意力。
OKR是有野心的，它不是逐步增量式的，我们并没有希望一次性就完成所有这些野心。（如果我们真的这样做，那么，我们就不会具有足够的进取性）。
我们用色阶来衡量我们做得有多好：
0.0 – 0.3 是红色● 0.4 – 0.6 是黄色● 0.7 – 1.0 是绿色● 正确的OKR制定方法规则 没有认真实施和管理的OKR，是一种时间上的浪费，是管理上的假大空。与之相反，如果实施得好，OKR将是一种很好的动机激励工具，它能让团队明白什么是真正重要的，哪些地方需要优化，在日常工作中应当如何去进行利弊权衡。
要写出好的OKR可不是一件容易的事，但也不是不可能。请遵循如下这些简单的OKR制定规则：
规则1：O 要回答的是 “What” 的问题，它应当： 表达清楚目的和意图；
译者：Nikijv
审校：Bob Jiang
英文原文
一个Twitter的帖子问”敏捷”是否反管理，以及”敏捷”为什么经常看起来很像反管理。简单写一下，本文中我个人的观点是敏捷软件开发如敏捷宣言所设想的那样，并不是反管理。这比反管理更激进：这是一种完全不同的管理方法。
敏捷软件开发仍然比当今的认知更激进，相当的不幸，包括大部分品牌和方法，在我这个有点老的男人对云观点大喊大叫的时候，也被大多数较小的”敏捷”供应商所采用。
敏捷软件开发正如我们所定义的那样，对于业务与开发间的日常协作较为频繁，以维持增量的可工作软件。这样团队称为自组织团队，尤其要说明的是：最好的架构、需求、设计来自这些自组织团队。
原则上很清楚，软件、架构、设计等一切工作都源自于团队，从团队中涌现。
例如，需求不来自于一些业务单元，而是通过中央委员会进行传递，然后传递到一些传统部门或项目部门直到它落在一些程序员的办公桌上。
这不是”反”管理。这根本不涉及解决类似于预算工作、人员补偿、评估性能或者其他”管理”关心的主题。
当然，敏捷软件开发提出了一个新的、不同于软件产品制作的管理。尤其通过基于工作软件的可持续生产使用的自组织、增量、速度技术，是解决软件开发应该被管理的新方式。
敏捷是反管理的么？我不这么认为，敏捷明确反泰勒式的管理，而支持推动管理。
同样，像所有好人一样，我们更乐于好的富有成效的管理，强烈反对贫瘠、无效、有害的管理。
但是我想建议这个底线是：
如果一个组织试图通过任何传统的方式控制团队的选择，该做什么以及如何做的选择来管理敏捷软件开发，这样很可能他们做错了。
如果你是敏捷的支持者，你试图与传统管理达成某种中间状态或和解，有可能你也是没有真正理解敏捷软件开发的根本意图。
一、scrum在发光
考虑到Scrum的构想，最流行的敏捷方法如果不是最有效的，那什么是？
Scrum称为自组织的团队，包括产品负责人，被授权于全部权利和责任，负责大型组织团队的投资回报率。Scrum团队中Scrum开发者的开发团队，必须包含交付产品增量的”全部必要技能”，一个被集成、测试过的、可工作软件包括团队迄今为止产生的所有价值元素。
Scrum承认Scrum团队是嵌入式的，以某种方式，在一个组织中，组织提供了资金（投资），干系人关心Scrum团队做了什么。敏捷团队通过每个冲刺向干系人展示他们已完成的工作，邀请并听取干系人的意见。Scrum团队与全权负责的产品负责人决定下一个冲刺做什么以及怎么做。
冲刺审查是Scrum团队及其嵌入组织之间的完整接口。
关于Scrum仍然有些问题没有解答，同样这些问题在上面Twitter的帖子中也涉及到了。Scrum不会告诉你如何预算，如何决定补偿，如何评估性能等等。
在Scrum课程中，人们经常询问各种管理职能。有个经典实践可以回应，课程上小组在便利贴上写下他们能想到的所有管理职能。他们可以把这些便利贴放到下面4个位置：开发团队，产品负责人，Scrum教练以及其他。
将会有两件事发生。首先，许多传统管理职能转移到一个或多个Scrum团队元素。由团队分配任务，由产品负责人决定要构建什么，由Scrum教练支撑和引导等等。有趣的一点是，总有些管理职能被贴到其他堆中。Scrum甚至不会建议如何做这些：这已经超出了Scrum的范围。
然而，很明显，Scrum打算不管这些超出范围的管理职能是什么，它们与团队的首要接口，可能只通过冲刺审查。尤其是除了产品负责人，没有人可以要求团队做任何事情，Scrum对”经理”在Scrum团队运行时可以做什么做了非常具体的限制。
二、敏捷软件开发是反管理么
敏捷软件开发需要一种新的管理方式，在团队规模上，团队内部拥有对产品的所有权利和责任，而且最主要的接口是检查实际演变的产品。
不一定是”反管理”，但一定与某些类型的管理背道而驰，尤其是源自于泰勒主义更具有侵入性的形式——福特主义，将工作视为机器，工人几乎没有权利或仲裁。尽管敏捷软件开发肯定要求从团队内部而不是外部应用这些概念，但与戴明和统计过程控制等概念的对立程度要小得多。
但我觉得主要的概念已经相当清楚：敏捷软件开发是一种完全不同的管理方法，尽可能的把权利和责任下放给团队。这种管理方法对于如何走得更远没有设置上限，但它设定了一个相当严格的下线，这个下线是嵌入在团队内部的产品做什么以及如何做。
三、这些想法的限制是什么
这很难说。我们通过敏捷团队的成长能力去决定谁在团队谁不在团队，这对薪酬和评估有很大影响。我们开始听到团队中的谁直接与客户合作，客户有时基于固定价格安排，或者更常见的基于运行速率为产品提供资金。
今天，更多的限制是被组织强加的——试图做”敏捷”，这些限制中有很多是明显错误的。有时组织没有从战略上很好地理解最好的管理是如何的。我通常认为,个人管理结构应在敏捷之前就位：不同的团队成员”属于”一个或另一个经理,而该经理则继续尝试对团队成员的行为进行控制。
坦白讲，自组织团队被授权，而这导致冲突、混乱以及很多时候应该做敏捷组织主要来源走向黑暗敏捷。这个观点是正确的。
底线，敏捷软件开发提倡不同的管理方式，很可能与一些过时的管理观念不相容，不幸的是，这些观念在今天仍然相当普遍。
反对的？不。完全不同？是的。
原文链接
知行合一的敏捷实践 内容来源：敏捷+社区线上直播003期，《知行合一的敏捷实践》分享实录 分享者：道富银行敏捷教练杨贵 关注本公众号回复“知行合一”即可获取本次分享的视频回放、下载PPT。 一、原动力-你在为谁工作
在敏捷实施过程中，有几个问题很关键，包括组织的问题、人的问题、执行力的问题。其中组织的问题不在我们个体控制范围之内，今天主要聊聊人和执行力的问题。
点击阅读原文 查看回放 总结
总结来说，知行合一的敏捷实践要求做到：
价值观的认同，团队成员要有一致的价值观。 工作过程有章可循，定义好活动规则和检查规则。 团队成员积极参与。制定各项规则的owner。 反馈闭环，以数据驱动反馈闭环。 技控，用机器和工具来解决问题。
内容来源：敏捷+社区线上直播005期，《我在哈啰的敏捷之旅》分享实录
分享者：哈啰出行陈文博
关注本公众号回复“哈啰”即可获取本次分享的视频回放、下载PPT
非常开心在空中和大家相聚，希望在接近一个小时的时间我们都能有所收获。首先感谢Bob老师和网易杭研的李岩同学，是因为他们的支持，我才能够在这里和大家分享。在开始之前，先简单自我介绍一下，我是陈文博，供职于哈啰出行PMO部门，一名成长中的敏捷教练，今天有很多敏捷社群的小伙伴来支持，谢谢大家！
【正式分享之前，先上一个彩蛋】
查看原文
言归正传，今天的分享将分为两部分：
第一部分是我在哈啰做的一些敏捷实践，包括目前我是怎么操作Scrum的，如何利用透明拉通团队共识，如何利用内驱力模型来激励团队，以及我在兼顾多个Scrum团队时如何培养内部的Scrum Master。 第二部分将给大家分享我在内部敏捷社区的一些做法，包括我是怎么发起内部敏捷社区Thor，以及社区是怎么运营的。 一、我的敏捷实践
首先给大家分享的是敏捷宣言的第一句话，”我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。” 分享这句话的原因是，我觉得敏捷实践是没有最佳实践这么一个说法，永远都是在不断地迭代，不断地找到更适合当前组织和团队上下文的一种做法，所以我在这里给大家分享的，也是基于我自己团队的上下文找到的目前最好的方法，后续还会继续迭代，以便做得更好。
查看原文获取更多材料
采访回放 - B站 | Youtube Bob：大家好，很高兴本期访谈邀请到了安晓辉。晓辉，先跟大家做个简单的自我介绍。 安晓辉：大家好，我是安晓辉，我用三个标签介绍一下自己：
第1个标签：程序员。我从2005年-2017年，做了12年软件开发，从2009年开始，也做了一些研发管理的工作。在当程序员的这段时间里，出版了两本软件开发相关的图书，《Qt Quick核心编程》和 《Qt on Android 核心编程 》。 第2个标签：职业规划师。我从2015年开始帮人做职业规划，形式包括分答、知乎、在线微咨询等。到现在为止，这种1对1的咨询进行了500多个小时，帮助过200多个人。 第3个标签，图书作者。在介绍程序员这个标签时提到了两本书，实际上我出版的不只是技术图书，还有程序员成长相关的，比如《程序员的成长课》、《大话程序员》，现在最新的一本书是讲怎么做副业，《副业赚钱之道》。 我现在是自由职业的状态，工作主要是写书、课程还有咨询。 Bob：你能给大家介绍一下写书的经验吗？ 安晓辉：大概是在2013年左右，我开始写技术博客，2013-2015年，正是移动开发非常火爆的时候，我写了几篇关于Qt在安卓上的应用的文章，在CSDN技术博客上发表。出版社找到我说要不要做一个这样的选题写一本书，因为我本身比较爱写东西，所以就答应了。
写书还是很有挑战的，特别是在时间管理上。因为当时我还在上班，纯粹是利用业务时间来写书，有时候晚上12点多调完代码再开始写，早上5点多又起来继续写，周末的时间也在写。从2013年底到2014年10月，投入了将近10个月的时间。这是我第一本书的出版经历。
虽然投入了很多时间和精力，但是写书的过程还是让我受益良多，当然这个收益不是指经济收益。技术图书的销量和你所写的技术有关，我当时写的Qt这种技术，是相对比较小众的，卖个几千册算不错了，所以经济收益这一块其实并不算大。 我所说的收益更多的是个人影响力的提升，写了两本书之后，我在Qt这个小圈子里就比较有名了，写书能提升个人影响力，能为个人品牌提供一个比较好的背书。
另外，写书能帮助个人对自有知识进行体系化、结构化的梳理和总结。写书是一个比较长期的事情，需要你有足够多的知识储备，要对所写的领域有全面、深入的理解，也会在无形中强迫你不断进行输入，再进行结构化地输出。
Bob：据悉你在知乎live上有一个很火的课程《业余时间赚钱的六个策略》，说说当时是怎么想到要在知乎live上做这样一个话题？关于在知乎上做这种直播分享，有一些什么技巧可以跟大家分享的呢？ 安晓辉：还是延续刚刚说到的，出版了两本技术图书之后，我在这个小圈子里有了一些影响力，有一个平台找到我说想做这种直播的课程，后来我们选择在知乎上做直播。
大概在2017年的元月初，做了第1次知乎live直播，主要是面向程序员，反响还挺不错的。有一天我在开发系列课程的时候想，大家可能对赚钱比较关心，要不要设计一个课程讲怎么赚钱呢？于是我就去搜各种各样的赚钱的策略，花了大半天时间把方向定下来，然后结合自己做过的事情、搜集到的各种信息把课程做出来。
这个课程得到了知乎官方的推荐，加到了信息流中，增加了曝光和传播，我讲的内容也比较有意思，课程很受欢迎，后续有很多人购买，到现在购买人数应该已经超过5万人了。
在知乎live进行直播的经验，我觉得有一点很重要，你如果要做轻量的分享或者讲座类的小课程，选题特别关键。要融入到知乎的生态里，知乎上有很多免费的回答，这些都跟付费的课程是连通的，在知乎上有关注的话，你的回答就容易被别人浏览到，可以在回答中推荐你的课程，别人看到觉得不错就会购买。
我一直在知乎上回答问题、发表文章，在回答和文章中也会去推荐我的课程，保证持续曝光，现在我的知乎号有将近11万的关注。让课程和产品被更多的人看到，转化自然也会更高。
所以，在知乎上做课程，首先要有一个好的选题；第二是宣传材料要设计得比较吸引人；第三是保持持续曝光；第四内容一定要足够干货，这样大家听完后反馈很好，也可以吸引更多的人来购买。
Bob：作为自由职业者需要具备哪些技能？ 安晓辉：我认为应该先对技能做一个分类：专业技能和通用技能。
写作是我的一个技能，通过在公众号、知乎等平台发表文章吸引关注、建立影响力。 课程设计和开发是我的第二个技能，我现在大部分收入是来自课程。 第三个是营销的技能，选择自由职业后，你一个人就成一个团队了，你的东西要让别人知道，就得懂一些营销的心理学，还要策划一些宣传文案。 第四个是演讲的技能，当你要面向企业或客户做产品或提供服务时，需要通过一些渠道来曝光自己，比如参与技术峰会的演讲、线下活动的分享等。通过你的演讲，可以让更多人知道你的状态、水平，从而吸引更多客户。 上面这些可以归于专业技能，专业技能是跟你做的事情相关的，如果你的自由职业是软件开发，那你的技能就是开发；是做课程，技能就是课程开发。
通用技能则包括：时间管理、任务管理、目标管理、沟通和谈判等。在公司时，面向内部沟通相对来说要简单一些，自由职业后直接面向客户，有时候还要去跟客户谈判，比如这个课程做成什么样、收费多少等。
Bob：这么多技能中，能给你带来直接收入的有哪些？ 安晓辉：咨询，1对1咨询，按次收费，这是最直接的。 课程开发、为企业提供内部培训，按天收费，也是直接可以带来收入的。 写作方面，出版图书、商稿（公关稿）都是有稿费的。
Bob：你下一步会做什么事情呢？ 安晓辉：实际上自由职业有一个很重要的问题：有没有一个稳定的模式？就是说你能做多久？这个产品/课程能卖多久？很多人会发现自由职业做着做着就难以继续下去。 我现在在构建我的一个产品矩阵。设计一个和《副业挣钱之道》相关的训练营，这样一来我就有书、有课、有训练营，再加上线下课、咨询，形成一个产品矩阵和循环，然后在这一块继续深耕。
安晓辉：程序员/职业规划师/图书作者
内容来源：敏捷+社区线上直播004期，《OKR与敏捷》分享实录
分享者：有赞效能改进工作者费解
关注本公众号回复”有赞”即可获取本次分享的视频回放、下载PPT
OKR是一个很热门的话题，我所在的公司（有赞）很早以前就开始实行OKR了。2014年老板去硅谷进行调研，带回来一种新的管理方式，一直执行到现在。本次分享也是我在OKR实践方面的一些经历和感受。
OKR与项目管理、敏捷，都是一种提升公司或组织效能的手段，OKR与敏捷之间也有着千丝万缕的联系，它俩是相通的，都有很多不确定性，不是你做了就一定能成功，还需要达成很多平衡。
管理是一门艺术，系统思考和组织设计，是两种底层能力，在敏捷实践过程中一定会涉及到。要组建一个敏捷团队，一定要有具体的角色，我们在组建团队的时候就开始做组织设计，在大规模敏捷框架里，组织设计也是一项非常重要的工作。
小调查
你在组织中处于什么角色？
你在组织中处于什么角色？比如项目经理、敏捷教练、ScrumMaster、技术负责人等。你在做决策时，是否客观？很多时候在小范围内做局部优化工作，没办法做到全局理性，为什么呢？我们发现，无论是什么角色，在做自己工作的过程中，视野会被工作范围所局限。
如何突破自身的角色和有限的视野，看到更大的范围和跃迁到更高的维度，就要回到系统思考的话题。
系统思考来源于系统动力学，是一门学科。其中有一个属性，系统有一种层层嵌套的现象，所看到的是一层，如果想要看到更大更高的那一层，就要跳出所在的范围，到更高维度的世界去。实践敏捷也是如此，需要系统思考和更高维度的视野。
我的敏捷世界观
见山就是山 | 见山不是山 | 见山还是山
我的敏捷世界观： 见山就是山。最开始接触敏捷的时候，从课程中学到很多关于敏捷的方法、工具等，比如：三三五五。那时认为敏捷就是这个样子的，要实施敏捷的话，以它提供的框架，按部就班地来执行就可以了。这个阶段学到的是敏捷的形，没有参透敏捷的本质。 见山不是山。后来经历了很多项目管理、组织优化、效能改进的工作，不经意间会根据需求和场景，将学到的敏捷知识和方法加以变通，灵活运用到实际的工作中。比如：基于整个组织的现状，运用同理心，感受需要被引导和改进的部分，然后慢慢结合敏捷去实践。随着时间的推移，我们在更多领域中加入了敏捷的元素，也做了一些创新。这个阶段是领会到敏捷的本质，逐渐融会贯通的过程。 见山还是山。经过反思沉淀后我们发现，敏捷给出的方法论适用于很多工作场景，能解决很多问题，是前人经过无数实践总结出的方法。我们也会慢慢去反思：为什么要做敏捷？敏捷的本质是什么？ 我认为敏捷的本质有三个：
优先级。我们的优先级是否明确。在一个团队或大的组织中，有没有做事的方法？优先级是什么？人在同一个时间段只能做一件事，先做哪件后做哪件？ 高质量的交付。我们做事的目的一定是为了交付，为了产生价值，高质量的交付是敏捷的一种结果。 灵活变化。我们的组织或团队是否能够灵活应对外界的变化。如果是就是敏捷的，也不用刻意强调三三五五，僵化的敏捷不是敏捷。 一次灵魂拷问
你存在于组织中的价值是什么？
前面问的是你在组织中的角色是什么。现在我们思考一下：你在组织中的价值是什么？是管理项目，还是作为一个敏捷教练带领敏捷团队？我们的出路在哪里？关注在哪个层面？
敏捷之上的世界
大千世界 | 道法术器 | 价值在外
根据系统思考的原则，需要看到更高的维度。因此除了敏捷之外，还要看到敏捷之上的世界，看清问题的本质。
佛曰：三千世界。世界之外还有世界。在实行敏捷的同时还应该有更高维度的思考和实践。
道法术器。道法是指我们学敏捷不应只是学习它的方法，还应该理解其本质；器是工具，工具是管理的辅助手段，在工具的制定方面，一定是工具适应组织，而不是组织来适应工具。在敏捷实行过程中，即便工具设置得再好，如果实际操作起来完全不匹配组织的现状，使用起来也会很别扭。术包括敏捷方法提供的框架和工具，比如前面提到的三三五五之类的。在这里值得注意的是：要站在道和法的层面，从更高的角度来审视，是否需要用到所有的这些工具，避免生搬硬套，使敏捷变得僵化。
价值在外。不要以为敏捷团队的敏捷就是端到端的了，在敏捷团队之上还有更高维度的团队，比如：部门、业务线、事业部、甚至公司。我们要从全局看整体的目标是什么、以及是否达成。敏捷团队产生的价值是什么，包括对公司的价值和商业价值。
“价值在外”这个词是管理大师彼得德鲁克提出的，即：我们所做的任何事情都是在组织外部，才会被评价和被认可的。我们所做的动作，是帮助公司完成敏捷转型，还是是为公司创造价值？在做组织设计时，我们也需要面向是否创造外部价值。
查看原文获取更多材料
