Những hiểu làm và điều cần tránh khi đặt mục tiêu OKR

I. Những lỗi thường gặp khi đặt mục tiêu OKR

Xây dựng quá nhiều OKR trong mỗi quý

Google cần nhiều OKR cho một công ty bởi vì họ đang nỗ lực xây dựng một công cụ tìm kiếm, đồng thời là một trình duyệt hỗ trợ, và cũng cố gắng để thay đổi xã hội. Hãy tưởng tượng họ sẽ ra sao nếu chỉ thiết lập một mục tiêu duy nhất “Làm thay đổi tất cả các sản phẩm của xã hội”.

Hầu hết các công ty, đặc biệt là các doanh nghiệp start-up đều không giống như Google, việc xây dựng một OKRs cho phép công ty tập trung vào một mục tiêu duy nhất và điều đó thúc đẩy những nỗ lực trực tiếp. Nếu không thể một, hãy chọn phương án tốt vừa là hai OKR, không thể gọn hơn nữa thì hãy để ba, nhưng đừng để công ti có đến 10 hay 20 OKR.

 

Xây dựng OKR cấp công ti cho một tuần 

Một doanh nghiệp start-up không nên sử dụng OKR trước khi có được sản phẩm hay thị trường phù hợp với doanh nghiệp, trừ phi mục tiêu đó là “tìm thị trường phù hợp”. Nếu doanh nghiệp của bạn không thể theo dõi tiến độ, tình trạng nhiều hơn một tuần thì điều đó có nghĩa là doanh nghiệp của bạn chưa sẵn sàng cho việc triển khai OKR.

Khi chúng ta đã định hình được sản phẩm hay thị trường phù hợp, thì hãy cam kết thực hiện mục tiêu mỗi một, hai hay ba tháng một lần. Những công việc có thể được thực hiện trong một tuần, đó là các nhiệm vụ, không phải mục tiêu của cả công ti.

 

Xây dựng Mục tiêu dựa vào số liệu

Đây là nguyên nhân gây sụp đổ hệ thống của nhiều lãnh đạo quản trị. Bạn yêu các con số, bạn yêu tiền, nhưng không phải tất cả mọi người. OKR hợp nhất các nhóm, đa ngành, và điều đó có nghĩa là bao gồm cả những nhà thiết kế với nhiều ý tưởng mơ mộng sáng tạo, các kĩ sư, và dịch vụ chăm sóc khách hàng chu đáo. Mục tiêu cần phải truyền cảm hứng, một lời kêu gọi hành động khiến mọi người nhảy ra khỏi giường và sẵn sàng cho một ngày mới, một thử thách mới.

 

Kết quả then chốt là tác vụ, không phải là kết quả

Ví dụ về Kết quả then chốt có ở khắp mọi nơi, nhưng cũng không khó để nhìn thấy các Kết quả then chốt có định dạng kiểu: “Xem xét tài liệu đào tạo từ tài nguyên huấn luyện trực tuyến” – đây là một nhiệm vụ, và khi là một nhiệm vụ thì không nên hoàn thành trong những một quý. Kết quả then chốt KHÔNG phải là việc chúng ta làm, mà là điều gì đó đã xảy ra vì những điều chúng ta làm. Hãy lưu lại các nhiệm vụ cho danh sách các việc ưu tiên trong tuần.

 

Không đặt Mức độ tự tin

Nhiều công ty mong đợi rằng chúng ta sẽ đạt được 70% Kết quả then chốt, nên họ tạo ra hai loại Kết quả then chốt, một trong số đó rất khó có thể thực hiện được. OKR khuyến khích chúng ta bắn trúng Mục tiêu để chúng ta nhận thấy những gì chúng ta thực sự có khả năng.

 

Đặt Mức độ tự tin là 5 trên 10 có nghĩa là chúng ta có 50% cơ hội đạt được mục tiêu. Điều đó kéo dãn nỗ lực của chính chúng ta.

 

Không theo dõi sự thay đổi của Mức độ tự tin

Không có gì đáng ngại hơn là đi vào tháng cuối cùng của quý và đột nhiên nhận ra rằng chúng ta quên mất sự chú ý dành cho OKR. Đánh dấu sự thay đổi khi chúng ta có thêm thông tin mới, nhắc nhở đồng đội và đề nghị được giúp đỡ.

Việc theo dõi sự thay đổi của Mức độ tự tin với các cấp độ Màu xanh – rất tự tin đạt được KR, màu vàng – tự tin nhưng cảm thấy có rủi ro, màu đỏ – không tự tin đạt được KR còn cho chúng ta biết rõ chỉ số sức khoẻ của OKR của cả nhóm. Chỉ số sức khoẻ này nên luôn được duy trì ở mức độ tối thiểu (0.3-0.5). Ví dụ, khi chúng ta muốn theo dõi Doanh thu, thì chúng ta phải đảm bảo các nhóm luôn “khoẻ mạnh”, bằng cách chọn một số ít các KR quan trọng, giữ cho nó luôn ở màu Xanh lá cây khi bạn triển khai OKR.

Hãy luôn để ý, màu Xanh lá cây là rất tốt, Màu vàng là cảnh báo hãy để mắt đến nó, nhưng Màu đỏ có nghĩa là một cáci gì đó quan trọng với công ty đang bị rơi tự do. Ngay lập tức, việc phải làm là ưu tiên sửa chữa hoặc tìm con đường khác để đi đến việc cải thiện kết quả OKR. 

 

Sử dụng phiên check-in để cập nhật trạng thái, không phải là cuộc trò chuyện

Thảo luận những gì cần thảo luận. Các sự ưu tiên đã dành ra trong tuần có thực sự di chuyển các Kết quả then chốt không? Lộ trình của các dự án sắp tới có yêu cầu sự phối hợp không? Sức khoẻ tinh thần của nhóm như thế nào?

 

Khó khăn vào cuối tuần

Chúng ta đã rất khó khăn với bản thân và với những người khác trong suốt một tuần. Hãy để một ly bia hay một chút snack để ghi nhận những điều chúng ta đã làm. Nếu chúng ta không đạt được tất cả các Kết quả then chốt thì hãy tự hào về những Mục tiêu lớn đã hoàn thành.

 

Biến OKR trở thành một phần của đánh giá hiệu suất làm việc

Nếu chúng ta muốn mọi người đạt được Mục tiêu cao, chúng ta không thể trừng phạt họ vì không đạt được mục tiêu cao. Thay vào đó, chúng ta có thể sử dụng việc kiểm tra trạng thái hàng tuần của OKR để tự viết đánh giá về những việc đã làm. Khi Mục tiêu là hướng đến các vì sao, chúng ta có thể chạm tới mặt trăng

 

II. Những điều cần tránh khi thiết lập OKR

Thời điểm các thành viên trong nhóm bắt đầu làm việc để đạt được OKR, sẽ xuất hiện những khó khăn trong nhóm. Sau đây là một vài tình huống bạn nên lưu ý:

Kết quả then chốt không đo được

Khi triển khai được vài tuần, nhóm bắt đầu nhận ra rằng Kết quả then chốt và cách đo thực tế không đo được. Trong nhóm bắt đầu hoang mang, không biết nguyên nhân từ đâu. Nếu Kết quả then chốt đã đảm bảo tiêu chí Kết quả then chốt tốt ở chương trước, hãy mạnh dạn đề xuất cách thức đo khác để giúp tổ chức đo được chính xác điều mong muốn. Triển khai OKR cho phép bạn điều chỉnh ở bất cứ thời điểm nào trong chu kì.

Nhưng hãy đảm bảo rằng bạn luôn có đủ thông tin để cả nhóm hiểu rằng cách đo mới sẽ chính xác hơn, không phải bạn muốn điều chỉnh để công việc dễ dàng hơn để ghi thành tích.

 

Kết quả then chốt không thay đổi

Một số nhóm sẽ bắt đầu luống cuống vì 3,4 tuần liên tiếp mà Kết quả then chốt không thay đổi. Với nhiều nỗ lực làm việc mà Kết quả then chốt lại không “nhảy số”. Nếu gặp tình huống này, việc cần làm là hãy bình tĩnh. Bạn có thể cần kiểm tra lại một số thông tin: Cách tiếp cận đối với KR có đang gặp vấn đề ở đâu không? Có cách tiếp cận nào khác đối với KR không? Hãy trao đổi với OKR Master, hay những thành viên khác trong nhóm mà bạn nghĩ có thể giúp bạn. Vấn đề này sẽ sớm được cải thiện sau vài quý.

 

OKR thay đổi mà tổ chức không tăng trưởng gấp đôi

OKR không phải công cụ toàn năng giải quyết tất cả các vấn đề bạn gặp phải trong tổ chức. OKR không thay thế được cho lãnh đạo kiệt xuất, văn hoá doanh nghiệp, hay những ý tưởng kinh doanh táo bạo, đánh giá sắc bén. Nhưng khi bạn đã có tất cả những điều trên, OKR sẽ chắp cánh cho tổ chức của bạn. Tất cả các Kết quả then chốt hoàn thành, tức là Mục tiêu của bạn đã đạt được. Nếu không đạt, tức là OKR ban đầu của bạn quá tệ. 

Google áp dụng OKR như thế nào, tôi cũng áp dụng OKR như thế ấy!

Mỗi mô hình tổ chức khác nhau, khi áp dụng OKR sẽ có những cách thức khác nhau. Không có một quy trình, các bước tiếp cận chung cho tất cả các tổ chức. Với các start-up nhỏ, OKR giúp cho công việc đi đúng hướng, giúp họ vượt qua thời gian khó khăn thật nhanh. Với các công ti đã có văn hoá, phòng ban chức năng, OKR giúp họ có được ngôn ngữ chung, phá bỏ các quan hệ nhóm lợi ích để mở rộng hơn. Hãy bỏ thời gian nghiên cứu mô hình kinh doanh của bạn thật kĩ trước khi chọn một quy trình áp dụng OKR. Bạn có thể tham khảo các công ti khác, nhưng hãy thận trọng.

 

OKR là 100% minh bạch!

Áp dụng OKR sẽ lộ ra những điểm yếu trong việc quản trị doanh nghiệp, ví dụ như làm việc nhóm, năng suất làm việc. Nếu bạn có một cá nhân thường xuyên có những ý tưởng đột phá hữu ích nhưng không năng suất như những người khác, có thể người đó sẽ không muốn bị những thành viên năng suất khác đánh giá, so sánh. Trong trường hợp ấy, có thể bạn sẽ cần chọn báo cáo, trao đổi qua văn bản, hoặc ngồi riêng lẻ thay vì ngồi cùng nhau. Lúc này, lãnh đạo sẽ mất nhiều thời gian hơn để trao đổi với từng cá nhân. 

Có thể, bạn chưa biết, Google xây dựng khung năng lực cho nhân viên trước khi áp dụng OKR. Đây chính là bước chuẩn bị cơ bắp cho các thành viên. Sau đó, Larry – một trong hai nhà sáng lập Google dành 2 ngày mỗi quý trong suốt hai năm đầu để kiểm tra, trao đổi riêng về OKR của từng kĩ sư phần mềm và tự tìm ra các mối liên kết giữa các bộ phận để phản hồi cho họ. Báo cáo bằng văn bản cũng không phải lúc nào cũng tệ.

Jonathan Rosenberg đã từng yêu cầu bộ phận phát triển sản phẩm của Google phải gửi ít nhất 20 báo cáo một tuần. Nhóm do đó cũng tự chủ hơn, giám sát từ trên xuống cũng ít hơn.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Website này sử dụng Akismet để hạn chế spam. Tìm hiểu bình luận của bạn được duyệt như thế nào.