Hoàn thành OKR vs. thực hiện công việc

• Trong kỹ thuật, OKR (Objectives & Key Results) theo quý tạo cảm giác bị chồng lấn với kế hoạch sản phẩm
  • Thường được hiểu là có cùng ý nghĩa với việc "thực thi roadmap"
  • Nếu OKR bao gồm nội dung khác với roadmap, điều đó sẽ dẫn đến xung đột với roadmap
  • Ví dụ giả định
    • Objective: Cung cấp Frontend Observability
    • Key Result: Cung cấp mọi tính năng của giai đoạn 1
    • Key Result: Duy trì tỷ lệ lỗi dưới 3%
    • Key Result: 1.000 người dùng tương tác mỗi ngày
• Trong marketing, OKR theo quý thể hiện rõ ràng ý định của công ty và hoạt động hiệu quả
  • Đội marketing ít phàn nàn hơn về việc viết OKR
  • Ví dụ giả định
    • Objective: Kích hoạt pipeline bằng việc ra mắt Frontend Observability
    • KR: 3 cơ quan báo chí đưa tin về đợt ra mắt
    • KR: 2.000 lượt truy cập landing page
    • KR: Đạt 100 marketing qualified lead (MQL) từ các tài khoản mục tiêu
• Vì sao OKR dễ hơn trong marketing
  • Một phần là vì:
    • Marketing giống công việc theo dự án và có thể hoàn thành trong một hoặc hai quý
    • Kỹ thuật giống công việc sản phẩm liên tục, được tiến hành theo một nhịp độ cập nhật không ngừng
  • Tất nhiên marketing cũng có nhịp công việc lặp lại
    • Quảng cáo, webinar, gửi email, sự kiện, v.v.
    • OKR thể hiện rõ trong quý này sẽ tập trung vào quảng cáo, webinar, sự kiện nào
    • Điều này có thể chồng lấn với bản tóm tắt chiến dịch, nhưng tập trung vào chiến dịch mới, đối tượng mới hoặc kênh mới
    • Chỉ nói về việc chúng ta đã đầu tư bao nhiêu chi phí và thời gian trong quý này cho những việc mới mà không phải quý nào cũng làm

Nói chung, công việc đang được thực hiện đều đặn định kỳ sẽ không xuất hiện trong OKR. Đó chính là mục đích của KPI (chỉ số hiệu suất cốt lõi)

• Marketing có KPI cho công việc cốt lõi là "thu hút lead", thứ sẽ trở thành "cơ hội bán hàng", và họ tổng hợp chúng
  • Theo dõi lưu lượng web, hiệu quả quảng cáo, thứ hạng SEO, người tham dự webinar, số lượt tiếp xúc tại sự kiện
  • Các con số KPI này chỉ xuất hiện trong OKR khi muốn cải thiện chúng hoặc đạt được chúng theo cách khác, như với đối tượng mới hay thông điệp mới
  • OKR thể hiện sự chuyển hướng trọng tâm, thay đổi quy trình hoặc những cuộc trò chuyện mà chúng ta cần có
  • Ví dụ giả định
    • Objective: Mở rộng độ nhận biết về Honeycomb tại 3 quốc gia
    • Objective: Giảm chi phí trên mỗi cơ hội
      • KR: Cải thiện tỷ lệ chuyển đổi từ MQL sang SQL từ 7 lên 10%
    • Objective: Tìm ra 2 use case đáng để đầu tư
• Kỹ thuật có KPI cho công việc cốt lõi là chạy phần mềm và triển khai các bản cập nhật
  • Có thể biết công việc đang vận hành trơn tru thông qua SLOs (Service-Level Objectives), tần suất triển khai (Deployment Frequency) và các chỉ số tăng tốc tương tự
  • Việc phát hành các tính năng trong roadmap là một phần của công việc cốt lõi. Thông thường điều này không nên được đưa vào OKR
    • OKR cho biết trong quý này điều gì sẽ khác đi, chúng ta sẽ thay đổi điều gì và đang cố tìm ra điều gì
  • Ví dụ giả định
    • Objective: Ra mắt Frontend Observability một cách suôn sẻ
      • KR: Tỷ lệ lỗi dưới 3%
    • Objective: Đưa 3 thành viên mới vào vòng trực On-Call
    • Objective: Áp dụng 2 dịch vụ từ đội khác
    • Objective: Cải thiện độ phản hồi của timeline view
      • KR: Xác định mức đóng góp vào độ trễ thông qua distributed tracing
  • Trong ví dụ trên có câu "ra mắt Frontend Observability một cách suôn sẻ", nhưng chẳng phải điều này đã nằm trong "triển khai roadmap" sao?
    • Phát hành tính năng là một phần của việc ra mắt suôn sẻ, nhưng không dừng lại ở đó
    • Trong tất cả các tính năng ra mắt trong quý này, đây là tính năng quan trọng nhất với doanh nghiệp
    • Việc tính năng này có mặt trong OKR cho mọi người biết rằng chúng ta sẽ thúc đẩy thêm nhiều việc khác, phản hồi ngay lập tức với báo cáo lỗi và nhiệt tình hỗ trợ đợt phát hành này
  • Nếu OKR của đội chỉ lặp lại roadmap, điều đó có thể được hiểu là "ý định duy trì trạng thái hiện tại mà không cố cải thiện"
    • Nói cách khác, nó có thể mang nghĩa "quý này là quý giữ nguyên hiện trạng" và điều đó không tốt
• OKR là "Điều gì làm quý này khác biệt?" "Có gì mới?" "Chúng ta muốn khác đi như thế nào?" "Chúng ta muốn tìm ra điều gì?"
  • Hãy để OKR nhấn mạnh trọng tâm đặc biệt. Đừng cố nhét mọi việc vào OKR

[jhj0517]

Có lẽ cần phân biệt rõ giữa những mục tiêu mà sau này có thể thể hiện kết quả bằng con số và những mục tiêu không thể làm như vậy.

[aer0700]

Khi lập kế hoạch, chắc hẳn sẽ có những dự báo về tình hình thị trường, nhưng trong những dự báo đó, bao nhiêu phần trăm là thống kê và bao nhiêu phần trăm là kỳ vọng của CEO? Đó hẳn là điều khó biểu đạt bằng con số.

[roxie]

Theo bạn, mục tiêu nào là thứ không thể thể hiện bằng con số?

[ethanhur]

OKR, tổ chức theo mục tiêu, agile đều trông khá hào nhoáng và tạo cảm giác như có thể giải quyết vấn đề của tổ chức, nhưng tôi nghĩ đây đều là những thứ không dễ để triển khai tốt trong thực tế.

Dạo gần đây tôi cũng nghĩ rằng ngay cả OKR cũng cần được cân nhắc và áp dụng thật thận trọng tùy theo năng lực của tổ chức và đặc thù kinh doanh. Có vẻ như cái giá phải trả khi nó không vận hành tốt là quá lớn.

https://x.com/sundarpichai/status/1543328071532523521

[GN⁺]

Ý kiến Hacker News

• Sau khi làm ở Facebook rồi chuyển sang làm trong một nhóm nhỏ, tôi nhận ra việc làm mà không phải lo về OKR và đánh giá hiệu suất tuyệt vời đến mức nào. Việc phải xây dựng thương hiệu và tự tiếp thị bản thân trong nội bộ nhóm thực sự rất mệt mỏi.

  • Từ góc nhìn tư duy hệ thống, tôi phản đối OKR ở mức nền tảng vì nó biến hoạt động của con người thành các con số. Điều đó khiến mọi thứ tách rời khỏi vấn đề thực tế và đi chệch hướng.
  • Tôi nhớ một giai thoại đọc được trong cuốn "The Essential Deming" của W. Edwards Deming. Để cải thiện một hệ thống kém hiệu quả trong việc vận chuyển dầu bằng sà lan, một quản lý mới đã tạo ra các chỉ số nhưng không đặt mục tiêu. Kết quả là các thuyền trưởng sà lan tự nguyện cạnh tranh để cắt giảm chi phí, và dự án trở nên có lãi rất lớn.

• Các framework đặt ưu tiên và mục tiêu của công ty như OKR giúp phát hiện sự không nhất quán trong cách các nhóm ưu tiên công việc. Tuy nhiên, các công ty thường xem đó là việc phiền phức và bỏ lỡ cơ hội học hỏi.

• Khi OKR xuất hiện, trên cương vị lãnh đạo tôi hiểu rằng cần có tính định hướng mục tiêu và khả năng chuyển hóa sang kết quả. Nhưng rất ít lãnh đạo làm tốt điều này, và nhiều người chỉ quan tâm đến việc xây dựng lãnh địa của riêng mình.

  • Với tư cách kỹ sư, luôn có những thứ cản trở OKR, vận hành và kế hoạch hàng tuần. Một PM giỏi có thể giảm bớt điều đó, nhưng đa số trường hợp thì không.

• Cũng có những người không quan tâm đến OKR. Họ làm ở công ty 2-3 năm, nhận tăng lương; năm đầu thì thong thả, năm thứ hai thì nghiêm túc, năm thứ ba thì tìm cơ hội mới.

• Trong lĩnh vực phi kỹ thuật, làm việc với khách hàng nội bộ và bị ép áp dụng OKR. Các product manager đứng giữa developer và người dùng, còn mỗi nhóm tự viết OKR của mình mà không có sự điều phối giữa các nhóm.

  • Ví dụ, một nhóm muốn dùng ít hơn 15% bê tông, còn nhóm khác lại muốn làm tòa nhà cao hơn 15%. Điều đó không phản ánh nhu cầu của khách hàng thực tế.

• Tôi thích quan sát những người muốn có kết quả nhanh đọc về Agile, OKR, KPI rồi tự đẩy mình vào thế khó. Quản lý áp đặt chúng, còn những người không có thời gian để hiểu thì lại đi triển khai.

  • Khi những người trẻ đầy tham vọng thúc đẩy việc này, cả nhóm trở nên kém hiệu quả và đội ngũ sản phẩm bắt đầu ám ảnh với OKR.

• Quản lý đặt OKR mà không có phản hồi từ nhân sự kỹ thuật, và một khi đã đặt thì không thay đổi. Điều đó phá hủy tính năng động của nhóm và khiến mọi người chơi trò tối ưu chỉ số để đạt mục tiêu. Kết quả là những nhân tài quan trọng rời công ty.

• Mỗi chỉ số được thêm vào đều mang theo một khoản thuế năng suất:

  1. Thời gian tiêu tốn để lách hoặc lợi dụng chỉ số
  2. Thời gian tiêu tốn để ghi chép và đưa chỉ số ra bề mặt