团队OKR
Object：目标
Key Result： 关键结果
OKR的目标是引导，驱动团队成员主动的去思考， 主动的想怎样能达到对应的目标（Object）。 OKR需要团队成员参与制定，并了解每一项内容（Key Result）。
每个团队都有自身的特点， okr需要根据不同的团队，不同特点进行设定。
Object 目标，定性，定义事件的性质，不要定义数量，抽象化：如“赚到1亿”， 而是使用 “公司盈利，上市”。
Key Result 关键结果，定量，定义需要达到多少，如“赚一个亿”
ORK 必须是公开透明的，由上到下， 公司的OKR，团队的OKR， 个人的OKR
可以参考的制定规则
普遍的OKR示例
提高发布频率
每周发布一次
所有的发布都应该分割成较小的部分， 能够进行zero down time的部署， 不影响到生产环境使用（数据库修改除外）
参与发布的人数达到全员
团队所有成员都熟悉整个发布流程与工具，没有知识断层
提交代码到版本管理服务的人数达到全员
所有开发人员都必须提交能够使用代码版本管理服务，提交代码到版本管理服务
15分钟完成所有发布工作
完善发布工具， 减少发布时间，单个服务发布时间不能多于15分钟
其他能提高发布效率的举措
减少生产问题
减少生产问题数量 由10减少到5
生产环境的问题应当逐渐减少， 直至没有
生产问题影响
生产问题的影响，应该能够衡量， 并且影响逐步减小
生产问题处理人员数量 由1加到4
生产问题人员处理数量应当在合适的数量， 逐渐减少，建立良好的问题处理模型
减少 新的功能导致的生产问题，由10减少到5
新的功能导致的生产问题应当逐渐减少，如： 完善对应的测试， 自动化测试， 减少问题出现。
其他能够避免生产问题发生的举措
团队建设
团队成员每月学习目标
团队分享每周有一次
证书数量每人获取到一张新证书
提高工作效能
每月举行一次团队反馈会议
团队进行会议，评估自身团队： 好的，能够提升的，保持的，需要改变的。 稳定会议数量， 固定每月进行会议。
每次一篇团队知识文章
团队发布知识文章， 分享自己的知识给社区， 逐步提高数量
减少安全问题
代码扫描工具
所有的服务都必须使用代码扫描工具（sonar， checkmark）
减少 代码扫描问题，重大问题数量为0
扫描不能出现 紧急 的问题， 逐步减少代码扫描工具扫出来的问题
上市
总流水达到5000w
用户规模达到1000w
用户日活达到100w
OKR 统一评判标准
可以看到上面的Oeject 目标都是定性的，KeyResult 关键结果都是定量的。为了更好的对比各个团队的OKR完成情况。还需要一个统一的评判标准。
一个可以看到自动采集各个团队的数据情况， 并展示报表的内部系统。各个团队可以在系统看到其他团队完成情况，进行对比。