月度归档： 2018 年 12 月

发布于

如何设计一个系统来实施OKR

OKR（Objectives and key results），正如德州扑克一样，规则很简单，但是做好却很难。

要引入OKR，那我们希望OKR来帮我们解决什么样的问题？

  • 保持公司战略/目标 与执行层面的一致
  • 浮现团队的主要优先工作及目标并保持专注
  • 部门间横向的一致性及协同
  • 公开提高透明度，高频度的反馈降低执行中的“意外”
  • 满足人的天性：好奇心，归属感，成就感

尝试过就知道OKR要真正落地用起来，用excel，word，wiki都很难满足OKR全生命周期的的管理及使用需求。那么如果设计一个系统来支持OKR的实施，那会是一个什么样的系统？它要支持什么样的功能？

  • 如何支持从创建，执行，评估及总结回顾的全过程
  • 如何同时支持自上而下，和自下而上的创建
  • 如何支持横向的团队协作及依赖，并将依赖显性化
  • 如何支持OKR执行中的每周状态更新及每周进度报告汇总
  • 如何及时反馈、暴露执行中的风险信息传递到相应的人并加以解决
  • 如何支持OKR在任意时刻的新建，更新，终止以反映实际运作的情况
  • 如何在系统层面达到借鉴业界最佳实践而又不过多限制
  • 如何实现OKR的可视化地图，让团队看到不同层级之间的OKR的联系
  • 如何从其他系统自动导入关键结果而不用手工输入
  • 如何将当前时间周期未完成但又有继续实施价值的OKR移入下一周期

花了不少时间整理需求，研读相关的文献书籍，很高兴看到我们的系统就要上线啦。

发布于

OKR适合敏捷开发团队么？

先说结论，适合。而且OKR是敏捷的强有力的有益补充

听朋友说他参加一个敏捷Scrum培训，培训讲师提到说敏捷团队不适合搞OKR，听着有点震惊，OKR为什么会和敏捷相矛盾，相冲突呢？

我眼里的敏捷，不在乎形式，你是Scrum，Lean，XP，Kanban还是四不像其实都不重要，只要是符合敏捷宣言和敏捷软件的12条原则的，就是一个敏捷团队。我不认为有任何矛盾之处

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，
我们更重视左项的价值。

敏捷开发中最经常遇到的问题就是优先级如何管理，团队的目标如何设立，短期目标和长期目标如何平衡，跨团队如何协作。而这正是OKR的所擅长的地方，让团队保持专注、团队的输出价值与组织目标保持对齐、有野心的目标、可量化的结果、发挥一线员工的才智及能动性、强调沟通协作与透明。这些就算是没有OKR也是一个优秀敏捷团队所必须解决的问题。

要证实其实也很简单，采用敏捷的几个标杆公司的现在都在用OKR，Google不用说了，Spotify、Google，Salesforce、Microsoft、Adobe、Twitter、Splunk、LinkedIn等等也都在OKR的阵营。