mức năng lượng rất có thể sẽ giảm. Vì vậy, khi phác thảo kết quả then chốt,
chúng tôi khuyên bạn nên mở rộng các giới hạn để thách thức đội nhóm suy
nghĩ khác đi, như Niket Desai đã chia sẻ trong phần trước. Tuy nhiên, sự
cảnh báo rõ ràng (một trong những mục tiêu chúng tôi đã đạt được trong
phân đoạn về khả năng đạt được mục tiêu) là việc đảm bảo kết quả cuối
cùng có thể đạt được. Một cách để đi trên đoạn dây xiếc này là thông qua
việc chấm điểm hiệu quả các kết quả then chốt, một chủ đề chúng ta sẽ
khám phá sau trong chương này.
Cụ thể
Làm rõ các điều khoản và khái niệm, đảm bảo sự hiểu biết được chia sẻ là
những điều rất quan trọng khi viết kết quả then chốt nếu bạn hy vọng thúc
đẩy giao tiếp giữa các đội nhóm và tránh sự mơ hồ không cần thiết cũng
như gây tổn hại. Dưới đây là một ví dụ về những gì có thể xảy ra khi bạn
không xác định chính xác ý muốn của mình bằng những từ bao gồm kết quả
then chốt. Như một phần của OKRs, CEO của một công ty đã nhấn mạnh
vào kết quả then chốt về “100% đối tượng người dùng (use cases) có sẵn
trên nền tảng mới”. CNTT, nhóm chịu trách nhiệm đưa các đối tượng người
dùng lên nền tảng mới, đã không biết CEO có ý gì về “
đối tượng người
dùng”, vì vậy họ đưa ra những gì có thể, dựa trên sự hiểu biết hạn chế về
yêu cầu của anh ta. Vào cuối quý, CEO hỏi: “Chúng ta đã có gì rồi?”,
CNTT đã trả lời: “Rất tuyệt! Chúng ta có tất cả các đối tượng người dùng
trên đó.” Chắc chắn, những gì họ đăng không liên quan gì đến điều CEO đề
cập khi ông nói về các đối tượng người dùng. Sự lãng phí thời gian, công
sức và rất có thể là cả nỗ lực triển khai OKRs có thể dễ dàng được tránh
khỏi bằng một số cuộc đối thoại đơn giản ngay khi bắt đầu quá trình soạn
thảo.
Sở hữu
Trong ví dụ trước, chúng ta đã thấy những vấn đề có thể xảy ra khi một kết
quả then chốt được tạo ra bởi ý chí của giám đốc điều hành, mà không phải
