OKRs - Phương pháp đơn giản, chẳng có gì cao siêu nhưng đã giúp Google đạt được mọi mục tiêu đặt ra
OKRs biểu hiện cho sự lựa chọn mục tiêu rất cẩn thận và là phương tiện Google sử dụng để phối hợp các hành động của cá nhân để đạt được những mục tiêu tập thể lớn lao.
Không ai có nhiều kinh nghiệm trực tiếp trong việc áp dụng OKRs hơn Google. Khi Google mở rộng quy mô, họ thường xuyên đưa ra những hướng dẫn thực hành OKRs và các bảng mẫu theo định kỳ. Những phân trích đoạn dưới đây lấy ra từ các nguồn nội bộ và được sự đồng ý của Google.
Nội dung trích cuốn sách "Làm Điều Quan Trọng", tác giả John Doerr.
Tại Google, chúng tôi thích "nghĩ lớn". Chúng tôi sử dụng một quy trình gọi là mục tiêu và các kết quả then chốt (hay gọi tắt là OKRs) để giúp chúng tôi giao tiếp, đo lường và đạt được những kết quả to lớn này.
Những hoạt động này xác định tương lai cho Google. Như chúng ta thấy đó - trong các sản phẩm như Search, Chorme, hay Android – chỉ một nhóm nhỏ chiếm vài phần trăm nguồn nhân lực của Google, hành động trong sự phối hợp chặt chẽ hướng đến một mục tiêu chung đầy tham vọng, có thể thay đổi cả ngành công nghệ, đã đủ chín muồi chỉ trong vòng chưa tới hai năm. Do đó, điều quan trọng là phải cho nhân viên và quản lý Google biết những thông tin về cách bố trí nhân lực và thời gian – cả cá nhân và những nhóm làm việc. OKRs biểu hiện cho sự lựa chọn mục tiêu rất cẩn thận và là phương tiện chúng tôi sử dụng để phối hợp các hành động của cá nhân để đạt được những mục tiêu tập thể lớn lao.
Chúng tôi dùng OKRs để hoạch định mọi người sẽ tạo ra cái gì; theo dõi tiến triển công việc của họ so với kế hoạch; và phối hợp những ưu tiên, kết quả giữa cá nhân và nhóm làm việc. OKRs cũng giúp cho mọi người tập trung vào những mục tiêu quan trọng nhất và tránh bị xao nhãng bởi những thứ khẩn cấp nhưng lại ít quan trọng.
Tại Google, chúng tôi chấm điểm theo màu để đo lường tiến trình:
0 đến 0,3 = màu đỏ
0,4 đến 0,6 = màu vàng
0,7 đến 1 = màu xanh lá
Cách viết OKRs hiệu quả
OKRs không được quản lý tốt chỉ làm mất thời gian mà thôi – giống như một động tác quản lý trống rỗng vô nghĩa. Trong khi đó, OKRs tốt là một công cụ quản lý tạo sự thúc đẩy, giúp cho nhóm thấy rõ cái gì là quan trọng, cái gì cần tối ưu hóa, cái gì cần làm để cân bằng đối với công việc hằng ngày.
Viết được một OKRs tốt không hề dễ, nhưng không phải là không thể. Chú ý những nguyên tắc đơn giản sau đây:
Mục tiêu là gì (whats), đó là:
• Trình bày mục đích và ý định.
• Khó đạt được những vấn đề thực tế.
• Phải hữu hình, khách quan và không mù mờ; nên mạch lạc cho người khác đọc hiểu cho dù có đạt được mục tiêu hay không.
• Hoàn thành thành công một mục tiêu phải đem lại giá trị cụ thể cho Google.
Kết quả then chốt là như thế nào (Hows), đó là:
• Diễn tả những hành động cụ thể có thể đo đếm được, mà nếu đạt được sẽ giúp cho mục tiêu đến gần với mức hoàn thành
• Phải diễn tả bằng kết quả, chứ không phải bằng hoạt động. Nếu kết quả then chốt bao gồm những từ như "tham khảo", "quan tâm", "giúp", "phân tích" hay "tham gia", đó là hoạt động chứ không phải kết quả. Thay vào đó, hãy mô tả những tác động đến "người sử dụng sau cùng" của những hoạt động đó.
• Phải bao gồm bằng chứng cho sự hoàn thành. Chứng cứ này phải tồn tại, đáng tin cậy và dễ dàng nhận thấy. Ví dụ, số đường dẫn đến các tài liệu, ghi chú và các báo cáo về số liệu đã có.
OKRs dành cho các nhóm làm việc chéo
Nhiều dự án quan trọng ở Google đòi hỏi sự đóng góp từ các nhóm khác nhau. OKRs lý tưởng cho sự cam kết phối hợp giữa các nhóm này. OKRs chéo phải bao gồm tất cả các nhóm tham gia vào dự án và phải thể hiện sự đóng góp của mỗi nhóm một cách rõ ràng, những cam kết này cũng thể hiện ở OKRs riêng của từng nhóm. Ví dụ, nếu ba nhóm – Ads Development, Ads SRE và Network Deployment – phải hỗ trợ một dịch vụ quảng cáo mới, sau đó cả ba nhóm nên có OKRs mô tả cam kết của họ đối với dự án.
OKRs cam kết và OKRs mở rộng
OKRs có hai loại, phân biệt được hai loại này là điều quan trọng:
OKRs cam kết là loại OKRs đồng ý sẽ hoàn thành và chúng ta sẵn sàng điều chỉnh thời gian, nguồn lực để bảo đảm hoàn thành.
• Điểm kỳ vọng cho một OKR cam kết là 1; nếu đạt dưới 1, cần phải giải thích vì sao không đạt 1 (có thể giải thích bằng cách chỉ ra những điểm sai trong lúc hoạch định hay thi hành).
Ngược lại, OKRs mở rộng mô tả chúng ra muốn thế giới trông như thế nào, ngay cả khi không có ý tưởng rõ ràng làm sao để đạt được hay chúng ta cần nguồn lực gì để thực hiện.
• Điểm dành cho OKRs mở rộng kỳ vọng đạt được trung bình là 0,7, với biến số khá lớn.
Những sai lầm và cái bẫy khi viết OKRs
Bẫy #1: Không phân biệt được OKRs cam kết và OKRs mở rộng.
• Xem một OKRs cam kết như là OKRs mở rộng sẽ tăng khả năng thất bại. Các nhóm làm việc có thể nhận OKRs một cách không nghiêm túc và không chịu thay đổi ưu tiên để tập trung vào OKRs này.
• Ngược lại, xem OKRs mở rộng là OKRs cam kết sẽ tạo nên tâm lý "phòng thủ" trong nhóm, những người không thể đóng góp được cho OKRs này; tạo ra sự đảo ngược ưu tiên, ví dụ như chuyển bớt nhân sự sang các OKRs mở rộng.
Bẫy #2: OKRs là những mục tiêu bình thường.
• OKRs được viết ra chủ yếu dựa trên những điều mà nhóm nghĩ rằng có thể đạt được mà không cần thay đổi bất cứ công việc gì họ đang làm, trái ngược với những điều mà khách hàng thật sự muốn.
Bẫy #3: OKRs mở rộng trông có vẻ rụt rè.
• OKRs mở rộng thường bắt đầu từ khi đặt ra câu hỏi khá rụt rè: "Chúng ta có thể làm gì nếu có thêm nhân viên và thêm một chút may mắn?". Một cách khác để tiếp cận tốt hơn khi đặt câu hỏi: "Thế giới/khách hàng của tôi sẽ ra sao trong nhiều năm nữa nếu chúng tôi không bị giới hạn nguồn lực?". Theo định nghĩa, chúng ta sẽ không biết làm cách nào để được trạng thái "không bị giới hạn nguồn lực" khi OKRs lần đầu tiên được thiết lập – đó cũng chính là lý do OKRs này được gọi là nguyện vọng. Nhưng nếu không hiểu và không xâu chuỗi nguồn lực đến "trạng thái đó" ngay từ bây giờ, chắc chắn chúng ta sẽ không bao giờ đạt được điều đó.
• Phép thử: Chúng ta hỏi khách hàng của mình họ thật sự muốn điều gì, mục tiêu nguyện vọng của chúng ta có đáp ứng hoặc vượt quá yêu cầu của họ hay không?
Bẫy #4: Chiến thuật "dự trữ nguồn lực".
• OKRs cam kết của một nhóm chỉ nên sử dụng hầu hết chứ không phải toàn bộ nguồn lực sẵn có. OKRs cam kết + OKRs mở rộng sẽ sử dụng hơn nhiều một chút nguồn lực sẵn có.
• Những nhóm có thể đáp ứng tất cả OKRs mà không cần sử dụng toàn bộ nguồn lực… được giả định là hoặc họ dự trữ nguồn lực riêng, hoặc là họ không thúc đẩy nhóm, hoặc cả hai. Đây là một dấu hiệu gợi ý cho quản lý cấp cao cần phải điều phối lại nhân lực và nguồn lực cho những nhóm khác sử dụng nguồn lực tốt hơn.
Bẫy #5: Những OKRs có giá trị thấp (không ai quan tâm).
Như đã nói, OKRs phải hứa hẹn giá trị kinh doanh rõ nét – nếu không thì không có lý do gì mở rộng nguồn lực để thực hiện. Những mục tiêu giá trị thấp (Low Value Objectives, còn gọi là I.Vos) là những mục tiêu có hoàn thành đến mức 1 cũng không ai quan tâm.
• Một ví dụ về LVOs (có sức cám dỗ lớn) là "tăng khả năng xử lý tác vụ của CPU lên thêm 3%. Mục tiêu này bản thân không giúp ích gì cho khách hàng hoặc Google một cách trực tiếp. Tuy nhiên, mục tiêu "giảm số lượng nhân xử lý đòi hỏi để đáp ứng thời điểm truy vấn cao nhất xuống 3% mà không cần thay đổi chất lượng/thời gian chờ… và trả số nhân xử lý trang bị dư về kho "có giá trị kinh tế rõ nét. Đây là một mục tiêu khá hơn nhiều.
• Phép thử: Liệu OKRs có thể đạt 1 điểm trong hoàn cảnh hợp lý mà không đem lại lợi ích cho người sử dụng hay lợi ích kinh tế gì hết? Nếu vậy, nên viết lại OKRs tập trung vào lợi ích hữu hình.
Bẫy #6: Thiếu kết quả then chốt (KRs) cho mục tiêu cam kết (O)
• OKRs được chia thành hai vế: kết quả mong muốn (O) và những bước đi yêu cầu (có thể đo đếm được – KRs) để đạt được O. Kết quả then chốt KRs được viết sao cho khi đạt được 1 điểm thì dẫn đến O cũng đạt 1.
• Một lỗi thường gặp khi viết KRs đó là viết điều kiện "cần" nhưng chưa "đủ" để hoàn thành mục tiêu. Lỗi này là do nhóm muốn tránh những khó khăn về nguồn lực/ưu tiên/rủi ro cần thiết để hoàn thành các kết quả then chốt khó nhằn.
• Cái bẫy này khá nguy hiểm bởi vì sẽ làm trì hoãn việc xác định nguồn lực cần thiết cho mục tiêu, kể cả khi phát hiện kịp thời thì mục tiêu đó cũng sẽ không thể hoàn thành đúng thời hạn.
• Phép thử: Có hợp lý hay không khi chấm 1 điểm cho tất cả các kết quả then chốt nhưng ý định của mục tiêu vẫn chưa đạt được?
Nếu vậy, thêm hoặc viết lại các kết quả then chốt cho đến khi nào chắc chắn các KRs đã hoàn thành, nghĩa là mục tiêu cũng hoàn thành.
Đọc, lý giải và hành động cho OKRs
Đối với OKRs cam kết
• Các nhóm được yêu cầu phải sắp xếp lại các ưu tiên của mình để bảo đảm thực hiện đúng tiến độ và 1 điểm.
• Những nhóm không thể hứa hoàn thành 1 điểm trên một OKRs cam kết phải nhanh chóng chạy đua. Đây là điểm chính: chạy đua trong trường hợp này không chỉ là gượng ép đồng ý mà đây là điều bắt buộc. Cho dù vấn đề xảy ra là do bất động về OKRs, hay bất đồng về thứ tự ưu tiên, hoặc không đủ khả năng để bố trí đủ thời gian/con người/nguồn lực, chạy đua vẫn phải tiến hành. Điều này cho phép cấp quản lý nhóm có thể đưa ra những chọn lựa và giải quyết những xung đột vừa nêu.
Kết quả tất yếu: mỗi OKRs mới có thể đòi hỏi một sự chạy đua tăng tốc ở mức độ nào đó, bởi vì OKRs đòi hỏi sự thay đổi những ưu tiên và cam kết hiện tại. Một OKRs không yêu cầu thay đổi bất kỳ hoạt động nào của nhóm chính là chiếc bẫy #2 vừa nói ở trên và những OKRs như thế không thể gọi là mới được – mặc dù chưa bao giờ được viết ra từ trước đến nay.
• Một OKRs cam kết không thể đạt 1 điểm theo đúng thời gian cần phải được "khám nghiệm tử thi" để tìm ra nguyên nhân. Đây không phải là hành động để "trừng phạt" nhóm làm việc, mà chỉ để tìm hiểu chuyện gì đã xảy ra trong quá trình lên kế hoạch hay thực hiện mục tiêu. Điều này có thể cải thiện khả năng để đạt 1 điểm một cách xác thực cho những OKRs cam kết khác.
Đối với OKRs mở rộng
• OKRs mở rộng sẽ được thiết lập vượt khả năng hiện tại của nhóm để thực hiện trong một quý đã quy định nào đó. Độ ưu tiên của OKRs mở rộng nên cập nhật những quyết định của thành viên trong nhóm về việc họ sẽ dành thời gian còn lại (ngoài những công việc hằng ngày) vào đầu sau khi nhóm đã thống nhất những cam kết. Nói chung, những OKRs càng có độ ưu tiên cao nên được hoàn thành trước những ưu tiên thấp hơn.
• OKRs mở rộng và những ưu tiên đi kèm nên được duy trì trên danh sách OKRs của nhóm cho đến khi được hoàn thành, nếu cần thiết cứ duy trì từ quỹ này sang quỹ kia. Nếu loại bỏ OKRs mở rộng ra khỏi danh sách vì không thấy tiến triển tốt là một sai lầm, bởi vì OKRs này sẽ che giấu những khó khăn cố hữu về sự ưu tiên, sự sẵn sàng của nguồn lực, hoặc sự thiếu hiểu biết về một vấn đề nào đó. Cứ để OKRs này như là cơ hội giúp khám phá ra những điểm yếu của công ty, của nhóm.
Kết quả tất yếu: chuyển một OKRs mở rộng sang cho một nhóm khác nếu nhóm này có chuyên môn và nguồn lực để hoàn thành OKRs này hiệu quả hơn.
• Các quản lý nhóm đánh giá nguồn lực cần thiết để hoàn thành OKRs mở rộng và "đòi" nguồn lực mỗi quý. Họ không thể trông mong được cung cấp đầy đủ nguồn lực yêu cầu, trừ phi OKRs mở rộng của họ là những mục tiêu có độ ưu tiên cao nhất của công ty, đứng sau OKRs cam kết.
Thêm một vài phép thử
Sau đây là một số phép thử đơn giản để xem OKRs có tốt hay không:
• Nếu viết ra trong vòng 5 phút, hầu như là OKRs không tốt.
• Nếu mục tiêu không vừa một dòng, có thể chưa đủ mạnh.
• Nếu kết quả then chốt được diễn tả bằng thuật ngữ nội bộ (chỉ họ hiểu mà thôi), ví dụ như "Ra mắt Foo 4.1", chắc chắn cũng không tốt. Cái quan trọng không phải là "ra mắt" mà chính là tác động của sự ra mắt này. Tại sao Foo 4.1 quan trọng? Cách ghi KRs tốt hơn: "Ra mắt Foo 4.1 để cải thiện việc đăng nhập của người sử dụng thêm 25%".
• Dùng ngày thật. Nếu mỗi kết quả then chốt (KR) xảy ra vào những ngày cuối cùng của quý, có thể kế hoạch thực hiện này không thật.
• Bảo đảm kết quả then chốt (KRs) phải đo đếm được, có thể gan điểm một cách kỳ quan vào cuối quý. "Cải thiện đăng nhập" không phải là một KR tốt. "Cải thiện đăng nhập thêm 25% vào ngày 1/5" trông tốt hơn rất nhiều.
• Thước đo không được mù mờ, phải nói cho rõ. Nếu ghi là "1 triệu người sử dụng", phải nói rõ con số đó là cho "toàn thời gian" hay là "trong một tuần sử dụng".
• Nếu nhóm có hoạt động nào quan trọng mà lại không nằm trong OKRs nào cả, cố gắng thêm vào OKRs.
• Đối với các nhóm làm việc lớn hơn, có thể cho OKRs phân cấp – OKRs ở mức cao cho cả nhóm lớn, OKRs chi tiết hơn cho các nhóm nhỏ. Nhưng bảo đảm OKRs "hàng ngang" phải có những kết quả then chốt (KRs) trong mỗi nhóm nhỏ.
