KR should be specific and measurable, and follow the SMART principle.
KR should describe the result rather than the task (process)
Let's take a look at the OKR case of the test center: (from Tita OKR Training Camp)
O: Improve the detection level and better ensure the product quality.
KR 1: organize testing training once a week;
KR2: The average test case coverage of the team reaches 95%;
KR3: There are less than 3 bugs in the product due to the omission of the test;
KR4: Urge developers to solve bugs every day;
Case study:
KR 1: It is a specific job to organize the training of testing once a week, and the number of times is the measure, but will the training definitely improve the ability? There are certain risks involved. Through training, it is the result of improving the ability of all employees. This is a process, not a result, and it is invalid.
KR2: The average test case coverage of the team is over 95%, which is a concrete and measurable work. The wider the coverage, the smaller the error probability, so this is an effective key result.
KR3: There are less than three bugs caused by missing tests, which are concrete and measurable, making the product quality more stable, which is an effective key result.
KR4: Daily supervision is a concrete and measurable work, but it is not the final result. After supervision, developers can adjust iterations in time, which is the final result, so this is a process, not a result.
So the optimized OKR is:
O: Improve the detection level and better ensure the product quality.
KR 1: There are at least four P5 employees in the team;
KR2: The average test case coverage of the team reaches 95%;
KR3: There are less than 3 bugs in the product due to the omission of the test;
KR4: The efficiency of bug solving is improved 1 times.