Tôi thấy rất nhiều OKR (Mục tiêu và Kết quả chính) không tốt. Thông thường, chúng chỉ là KPI (Các chỉ số hiệu suất chính) được đặt tên OKR. Bạn biết những điều này bởi vì chúng có xu hướng giống như

Mục tiêu: cung cấp sản phẩm x

Kết quả chính: sản phẩm x đang được sản xuất

Mục tiêu: thúc đẩy việc sử dụng sản phẩm y

Kết quả then chốt: 5 nhóm tham gia vào sản phẩm y

Trong bài đăng này, tôi quyết định viết ra định nghĩa của mình về thế nào là một OKR tốt. Suy nghĩ của tôi đã phát triển từ những gì tôi học được lần đầu tiên cách đây rất lâu trong các bài nói chuyện, bài đăng trên blog và sách, và bây giờ dựa trên kinh nghiệm của tôi khi sử dụng chúng để đặt mục tiêu cho nhóm trong hơn mười năm qua.

mục tiêu

Mục tiêu có bản chất tường thuật và thể hiện trọng tâm chiến lược cũng như quan điểm về việc đạt được kết quả đó, chứ không chỉ là kết quả chung mà bạn đang tìm kiếm.

Ví dụ: tôi thường đảm nhận vai trò điều hành các nhóm là một phần của nỗ lực di chuyển đám mây công cộng. Đối với một công ty thuộc mọi quy mô/độ phức tạp, việc di chuyển lên đám mây công cộng là một sáng kiến ​​kéo dài nhiều năm. Vì vậy, mặc dù tôi có thể có một mục tiêu lâu dài: “di chuyển công ty lên đám mây” hoặc “tăng tốc áp dụng đám mây” hoặc những gì bạn có, nhưng tôi thường không đặt mục tiêu rộng như vậy.

Thay vào đó, tôi xem xét những công việc tiềm năng mà chúng tôi nghĩ rằng chúng tôi cần thực hiện, những vấn đề mà chúng tôi đang gặp phải khi truy cập vào đám mây và tôi cố gắng xác định phần quan trọng tiếp theo của chiến lược mà chúng tôi cần tập trung vào. Ví dụ, một năm mục tiêu là một cái gì đó như:

Make (tên công ty) Cloud Ready

Mục tiêu này rất rộng và bao gồm công việc liên quan trực tiếp đến việc kích hoạt và sử dụng đám mây công cộng, nhưng nó cũng bao gồm công việc thúc đẩy các ứng dụng của chúng tôi trở nên giống với đám mây hơn thông qua quá trình container hóa và các cải tiến cơ bản khác, cho dù chúng có đang di chuyển sang đám mây vào thời điểm đó hay không. hay không. Mục tiêu này thể hiện quan điểm rằng, cho dù chúng tôi có chuyển mọi thứ sang đám mây công cộng hay không, thì các phương pháp cơ bản cần thiết nếu bạn muốn có kiến ​​trúc và hoạt động “gốc đám mây” là rất quan trọng để thúc đẩy.

Tôi có một ngoại lệ đối với việc viết các mục tiêu thể hiện quan điểm và đó là khi tôi có một mục tiêu thể hiện giá trị thường xanh và lĩnh vực trọng tâm. Đối với tôi, đó luôn là “hoạt động xuất sắc.” Hàng năm, tôi thiết lập OKR xuất sắc trong hoạt động để đánh dấu các dự án quan trọng cần giải quyết các vấn đề như di chuyển Python 3, giảm bớt công việc nặng nhọc trong các hệ thống quan trọng hoặc các lĩnh vực tập trung vào độ tin cậy và khả năng hoạt động chính khác. Tôi làm điều này vì tôi muốn nhấn mạnh rằng công việc này đối với tôi cũng quan trọng như những sáng kiến ​​quan trọng khác, và hơn nữa, tôi mong rằng tất cả các nhóm của tôi đều tập trung vào công việc này bất kể họ đang làm gì khác.

Kết quả chính

Các mục tiêu thể hiện một chiến lược cấp cao với một số loại quan điểm hoặc tuyên bố về giá trị. Các kết quả chính cung cấp các tín hiệu và thước đo tổng hợp về cách bạn mong đợi để thấy tác động hoặc tiến trình hướng tới việc đạt được mục tiêu đó.

Sự cám dỗ với các kết quả then chốt là làm cho chúng chú trọng vào công việc được thực hiện hơn là tác động. Nếu kết quả chính của bạn là tất cả về hệ thống vận chuyển, hoàn thành dự án hoặc đạt được các mốc giao hàng, thì bạn thực sự chỉ đang đo lường xem mình có hoàn thành những gì bạn ước tính có thể hoàn thành hay không. Và điều đó không tệ, chính xác, nhưng nó có hai nhược điểm.

Nhược điểm đầu tiên là nó không cho phép bạn linh hoạt trong cách bạn đạt được mục tiêu của mình và điều này khá hạn chế! Một trong những điều khiến các kỹ sư thất vọng với việc lập kế hoạch là nó có thể rất cứng nhắc. Khi bạn đang nói về quy trình tạo OKR tổng thể hàng năm, bạn đang cố gắng không chỉ dự đoán những gì bạn sẽ hoàn thành trong năm mà còn dự án nào là dự án quan trọng cần hoàn thành. Nếu hoàn cảnh thay đổi và hóa ra là bạn không cần chuyển tất cả mọi người sang EKS mà thay vào đó, bạn cần chuyển một nhóm người sang ECS ​​chẳng hạn, thì KR của bạn về “chuyển 100 ứng dụng sang EKS” sẽ ngay lập tức chuyển sang màu đỏ và bạn phải viết lại nó theo hướng cứng nhắc không kém “di chuyển 50 ứng dụng sang EKS và 50 ứng dụng sang ECS”. Nếu có thể, tôi tin rằng tốt hơn hết là viết các KR cho phép linh hoạt trong cáchchúng đạt được trong suốt cả năm.

Điều này đưa chúng ta đến nhược điểm thứ hai của KR đầu ra công việc: chúng không tính đến tác động. Đây là một điểm mù đặc biệt của các nhóm kỹ thuật loại nền tảng, họ tập trung vào việc xây dựng và cung cấp thứ mà họ nghĩ rằng họ nên xây dựng và cung cấp mà không dừng lại để hỏi xem liệu đó có phải là điều hữu ích nhất để giúp người dùng đạt được mục tiêu của họ hay không. Khi bạn viết các KR liên quan đến tác động (giảm thời gian triển khai ứng dụng đám mây mới từ 2 tuần xuống 2 ngày (hoặc, 50%, hoặc…)), bạn buộc mọi người phải đối mặt với câu hỏi: công việc của tôi sẽ được thực hiện như thế nào va chạm?

Trên thực tế, có nhược điểm thứ ba đối với KR đầu ra công việc, một nhược điểm xuất hiện nhiều hơn khi bạn điều hành các tổ chức lớn hơn. Quy tắc OKR của cá nhân tôi là: không quá 5 mục tiêu, mỗi mục tiêu không quá 4–5 KR. Đối với bất kỳ đơn vị giám sát nhất quán nào mà bạn có, hãy cố gắng tuân theo điều này, cho dù nhóm của bạn là 50 hay 500. Khi bạn đang cố gắng thể hiện một danh mục công việc lớn giữa nhiều nhóm khác nhau, bạn không có chỗ để lãng phí một KR cho bất cứ thứ gì không phải là một sáng kiến ​​lớn và KR đầu ra của công việc có thể là một sự lãng phí của một vị trí KR có giá trị.

Bạn sắp có một số KR đầu ra cho công việc, đó là điều không thể tránh khỏi. Có những việc cần phải hoàn thành, và công việc thực hiện chúng khó đến mức bạn muốn đánh giá đó là tiến độ để báo cáo. Nhưng đừng lười biếng! Xem xét kỹ lưỡng từng KR đầu ra công việc và thực sự tự hỏi bản thân xem liệu có cách nào tốt hơn để đo lường điều này dựa trên tác động hơn là phân phối thuần túy hay không.

Tất cả điều này là khó khăn

Điều này quay trở lại quan điểm ban đầu của tôi: OKR rất khó. Bạn phải có quan điểm chiến lược để viết ra các mục tiêu tốt và bạn phải có một số ý tưởng hay về những gì khách hàng của bạn muốn, nhóm của bạn có thể cung cấp những gì và những gì bạn có thể đo lường để tạo ra KR tốt. Bạn phải hiểu khả năng có một tập hợp rất lớn các nhóm và dự án để tạo ra OKR vừa truyền cảm hứng vừa tích cực nhưng không phải là không thể.

Và sau đó, tất nhiên, có tất cả các trường hợp ngoại lệ cám dỗ bạn. Tôi có một mục tiêu cho sự xuất sắc trong hoạt động và một khi bạn bắt đầu ở đó, bạn sẽ muốn thêm ngày càng nhiều mục tiêu khác. Chúng ta phải luôn có OKR cho văn hóa nhóm/tuyển dụng/phát triển nhân tài. Chúng tôi không thể bỏ qua chức năng nhận dạng X, vì vậy chúng tôi cần tạo một cái gì đó đặc biệt cho nhóm đó. Tôi không thể nói rằng mô hình 4–5 Os của tôi, mỗi chiếc có 4–5 KR thực sự, thực sự có quy mô vượt quá vài trăm hoặc với mọi loại hình kinh doanh. Và có lẽ có những nhóm thực sự không cần OKRs, do tính chất công việc của họ, quyền kiểm soát cách đo lường, quy mô của họ, hoặc bất cứ điều gì.

Đây là sự sụp đổ của OKRs. Chúng khó, nhưng được bán như một thứ mà mọi người nên làm, vì vậy mọi người đều làm chúng kém và kết quả là hầu hết mọi người không thấy bất kỳ giá trị nào. Bạn không cần phải thực hiện OKRs (trừ khi bạn làm việc cho tôi, trong trường hợp đó, bạn có thể làm). Nếu ít nhất bạn không định cố gắng viết những bài hay, thì bạn không nên làm chúng! Nhưng nếu bạn thực hiện công việc, họ sẽ buộc bạn phải suy nghĩ một cách chiến lược hơn về các mục tiêu của mình và đặt ra những câu hỏi khó về tác động mà bạn hy vọng đạt được với họ và cách bạn đo lường điều đó. OKRs tốt kể một câu chuyện về điều gì là quan trọng, chúng giúp bạn truyền cảm hứng cho mọi người nghĩ về lý do tại sao họ đang làm việc với những gì họ đang làm và tôi nghĩ rằng họ mang theo một chút năng lượng đến từ việc nhìn thấy mọi thứ phù hợp với nhau như thế nào trong một hình thức ngắn gọn.