团队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完成情况。还需要一个统一的评判标准。

一个可以看到自动采集各个团队的数据情况， 并展示报表的内部系统。各个团队可以在系统看到其他团队完成情况，进行对比。

技术架构师

1. 构建了新项目的 前后端，自动化测试 框架（后端使用spring boot，前端使用React, 自动化测试使用 Selenide+TestNg），目前项目已经上线正常运行。
2. 制定了项目前后端的编程规范与开发流程.
3. 制定了团队的git工作流.
4. 对新技术进行研究并落地（PostgreSql，Cypress，React Hook）.
5. 对团队成员进行培训（git工作流培训，单元测试培训，React前端培训，自动化测试培训 等等）.
6. 指导团队进行代码架构设计，数据库设计。
7. 参与并构建了项目的Devops基础设施，如 自动化部署，自动化测试，监控报警 系统

Leader

1. 以 敏捷开发 为指导， 对项目成员进行对应的思想指导。
2. 进行 项目人员 面试，构建了一套完整的面试流程，并积极培训其他成员进行面试
3. 日常与团队成员进行沟通， review， 建立了有效的沟通反馈渠道。

2020年是硕果累累的一年， 取得了很多成绩，在新的一年需要更加努力，争取新的成就。

安全

使用双重RSA密钥验证，平台双方都有对应的密钥对， 将私钥发给对方， 发送方 对请求体按照字母顺序排序成字符串，AES进行字符串加密， 使用私钥进行签名， 接收方 使用公钥进行签名校验。 校验通过后再进行对应处理。

统一的请求，返回格式

所有的API接口都必须 返回相同的数据格式，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{

	code：``200``，` `// 非200代码 为 错误码

	data： {

			users： [],

			user: {}

		}

	msg:"" // 当非200代码时， 提示错误信息

}

幂等（可重入）

API接口相同的请求体， 不同时间请求多次， 返回的数据应该一致， 如: 入件接口，返回入件成功， 入件失败， 不会从失败变成成功。

文档

可读性， 历史可追溯， 推荐使用石墨文档markdown进行文档生成， markdown文件使用git进行版本管理。

现状

各个工作人员，固定岗位，每天都重复相同的工作（自动化测试， 开发，运维处理），员工感到前路受限， 无法接触到新的东西，环境僵持，间接导致工作效率降低。 希望能进行流动轮岗。

轮岗制度优点

提高了组织的活力，避免造成单点。

员工有接触不同工作的机会，可以学习到更多的东西，间接提高工作效率。

轮岗制度缺点

轮岗会造成一定效率的降低， 熟练工替换到非熟练工，导致工作效率降低。

轮岗人员

所有在职开发人员

轮岗时间

一年进行轮岗一次， 提前一个月对新岗位工作进行熟悉，旧岗位工作进行交接。

轮岗工作

需明确各个岗位工作内容， 方便进行转岗安排。

提前一个月，对旧岗位进行工作交接， 对接替的同事进行培训， 确保工作效率不会明显下降。

For What

通过对 每周一个技术问题 进行分享讨论的形式， 营造 分享，共同学习 的技术氛围， 提高团队凝聚力，提高团队成员的知识水平。

Whom

团队所有成员

When

每周星期四 下午四点到四点半（16：00 - 16：30 Tue）

How

主持人 按照团队成员 姓名排序轮流 进行会议主持。 下周会议主持人 要在星期五（会议后下一天）准备好下周的问题。

主题必须以问题的形式提出。尽量问实际的问题，不要太空泛。

问题范围： Java（spring，多线程，Jvm）， Linux， 数据库， Vue，React， 算法。

尽量从简单的问题开始， 大家提问题不要问需要 深入了解后才能回答 的问题。

问题范例：

1
2
3
4

Spring中事务什么情况会失效， 为什么会失效？
数据库索引什么情况会失效，为什么会失效？
Spring中为什么要有IOC，它解决了什么问题？
为什么阿里不建议使用Executors创建线程池？

为什么要以问题的形式发起sharing？

想通过发出问题 提前带动大家的思考， 因为提出是问题， 所以会自然而然去思考，“为什么的？为什么要这样的”。

如果只是陈述，”Springboot中事务的使用”， 可能就，“哦， 会讲这个。” 大家就被动的接受， 而没有进行自己的思考。

这个也是敏捷的一part，“如何让团队主动思考”。

英文自我介绍

面试者简单的自我介绍，可以根据面试者介绍再问些问题。

（Could you tell me more detail about your last job？ Do you have confidence to handle the hangwriting and listening of English？一篇全英文文档，不借助翻译 能读懂多少？ ）

技术相关

重点 springboot， 数据库相关。 尽量考察到实际要怎么做， 而不是问理论上的， 很多培训出来的， 理论背得很好

。 具体一些的实操相关的问题。

(springboot 事务如何使用。如何 写一个过滤器 统计Service层方法执行时间， springboot 如何统一返回数据格式。 springboot 如何写一个拦截器， 如何统一处理异常)

项目流程相关

git，git工作流， 项目管理软件（jira，禅道）， 敏捷开发，单元测试， 项目监控报警。

总结

所有的问题事实上背后都对应了考察的点：

英语能力，创业心， 自我学习能力， 技术(java基础，springboot框架， 数据库)，开发流程熟悉度(git工作流，项目管理软件，敏捷开发)

每一个点对应要问什么问题才能考察到，需要面试官自行总结。

面试官需要通过面试问题掌握面试者能力，不要出现面试后还在疑惑.

1

他有一些答得比较模糊， 不知道他是不是真的行!

如果觉得没办法通过这个问题掌握他的水平， 就再多问一下! 不要等到会议结束后，都无法确认候选人是否合适*