Measure What Matters: viết KR cùng khách trước dòng code đầu tiên

Một deployment có thể chạy ổn định, đúng spec, rồi vẫn bị khách chê là thất bại. Nguyên nhân thường không nằm ở code: hai bên chưa bao giờ thống nhất thành công trông như thế nào.

Measure What Matters của John Doerr không được viết cho Forward Deployed Engineer. Portfolio Penguin giới thiệu cuốn sách là chuyện dùng OKR để đưa ra những lựa chọn khó về ưu tiên kinh doanh. Nhưng tuần đầu tiên ở khách hàng chính là lúc phải đưa ra những lựa chọn như thế.

Nếu bạn là FDE hay đang muốn chuyển sang vai trò này, cuốn sách cho bạn một kỹ năng mà nhiều kỹ sư giỏi vẫn thiếu: biến yêu cầu mơ hồ của khách thành vài con số mà cuối kỳ ai cũng chấm được.

Phương pháp này từ đâu ra?

Doerr không tự nghĩ ra OKR. Theo trang What Matters, phương pháp do Andy Grove tạo ra ở Intel, và chính Grove đã dạy lại cho Doerr. Năm 1999, Doerr mang nó tới các nhà sáng lập Google. Vì thế bản sách của Penguin Random House Canada có lời tựa của Larry Page.

Theo nhà xuất bản, Doerr đã đưa OKR vào hơn 50 công ty. Bản Anh ra ngày 26/04/2018. Nhà xuất bản cũng nhấn mạnh rằng mục tiêu phải được truyền đạt xuyên suốt tổ chức, từ nhân viên mới vào tới CEO. Với FDE, chi tiết này đáng giữ lại: OKR của một deployment phải đủ rõ để cả người dùng cuối lẫn sponsor bên khách cùng hiểu.

Ý thứ nhất: Objective chỉ là điều cần đạt

What Matters định nghĩa Objective đơn giản là điều cần đạt được, không hơn không kém. Objective không chứa con số, không chứa giải pháp. Đó là lý do nó có ích khi khách mở đầu bằng câu “chúng tôi muốn một agent”.

Thử hình dung bạn triển khai một agent xử lý hồ sơ bồi thường cho một công ty bảo hiểm. “Xây agent đọc PDF” là một giải pháp. Objective đúng nghĩa sẽ là: nhân viên bồi thường xử lý hồ sơ nhanh hơn mà không giảm độ chính xác. Viết được câu này, bạn và khách mới thật sự nói về cùng một bài toán.

Ý thứ hai: KR phải trả lời được “đạt hay chưa”

Theo What Matters, Key Result hiệu quả phải cụ thể, có thời hạn, tham vọng nhưng thực tế, và đo được để cuối kỳ biết đã đạt hay chưa. “Cải thiện trải nghiệm nhân viên” không qua được phép thử này. Đến ngày cuối pilot, không ai chứng minh được nó đúng hay sai.

Áp vào ví dụ bảo hiểm, các con số dưới đây chỉ để minh họa. KR1: trong 30 ngày pilot, agent trích xuất đúng các trường dữ liệu ở 80% hồ sơ loại A mà nhân viên không phải sửa. KR2: thời gian xử lý trung bình mỗi hồ sơ giảm từ 20 phút xuống 12 phút. KR3: 15 nhân viên dùng công cụ hằng ngày vào tuần thứ tư.

Mỗi KR buộc bạn đặt câu hỏi discovery ngay từ đầu: hiện giờ mất bao nhiêu phút, ai đo, lấy dữ liệu ở đâu. Không có baseline thì không có KR.

Hai lỗi hay gặp khi viết OKR cùng khách

Lỗi đầu tiên là nhét giải pháp vào Objective. “Triển khai agent đọc PDF trong quý này” nghe như mục tiêu, nhưng thực chất là một đầu việc: agent chạy xong mà nhân viên vẫn chậm thì Objective vẫn bị tính là hoàn thành. Khi gặp câu như vậy, hãy hỏi lại khách: làm xong việc đó thì điều gì trong công việc của họ thay đổi?

Lỗi thứ hai là viết KR không có baseline. “Giảm 40% thời gian xử lý” không chấm được nếu chưa ai biết hiện giờ mất bao lâu. Cách sửa thực tế là biến tuần đầu thành một KR riêng: đo thời gian xử lý của một mẫu hồ sơ thật, rồi mới chốt con số mục tiêu cùng khách.

Ý thứ ba: nói rõ đâu là lời hứa, đâu là tham vọng

Đây là ý mà FDE dễ bỏ qua nhất. What Matters phân biệt OKR cam kết, tức mục tiêu nhóm bắt buộc phải đạt trong chu kỳ và chỉ chấm đạt hoặc không đạt, với OKR tham vọng. Với loại tham vọng, dưới 40% bị coi là trượt, còn 40–70% là tiến bộ tốt. Điểm của OKR là trung bình điểm các KR.

Giả sử ba KR ở trên được chấm 0,9, 0,6 và 0,3. Trung bình là 0,6, nằm trong vùng tiến bộ tốt nếu đây là OKR tham vọng. Nhưng nếu khách tưởng cả ba là lời hứa, con số 0,6 sẽ thành một báo cáo thất bại.

Cách xử lý là gắn nhãn ngay từ buổi kickoff. KR1 về độ chính xác là cam kết, vì đó là điều kiện để nhân viên tin agent. KR2 và KR3 là tham vọng. Một dòng ghi chú như vậy cứu bạn khỏi cả một cuộc họp khó chịu vào cuối pilot.

Ai nên đọc, và đọc theo thứ tự nào

Cuốn sách đáng đọc nhất khi bạn bắt đầu tự chạy pilot hoặc engagement, vì lúc đó bạn có một dự án thật để áp vào. Hãy đọc phần định nghĩa và cách chấm OKR trước, rồi áp ngay vào dự án đang làm. Sau đó mới đọc phần CFR, gồm Conversations, Feedback, Recognition: theo What Matters, OKR kết hợp với CFR thành quản lý hiệu suất liên tục.

Với FDE, CFR chính là nhịp check-in hằng tuần với khách: xem KR đang ở đâu, nghe phản hồi, ghi nhận những người dùng đầu tiên chịu thử công cụ. Đọc phần này trước khi có một OKR thật trong tay thì dễ thành lý thuyết suông.

Về sự nghiệp, kỹ năng này thể hiện được ngay trong hồ sơ xin việc. Trong tin tuyển dụng, hãy để ý những cụm như “success criteria” hay “measurable outcomes”. Trong CV, thay “xây pipeline trích xuất tài liệu” bằng một dòng có Objective, con số và thời hạn. Người phỏng vấn đọc được ngay rằng bạn biết đo giá trị chứ không chỉ biết giao tính năng.

Buổi họp đầu tiên với khách vì thế không nên kết thúc bằng một danh sách tính năng. Hãy kết thúc nó bằng ba KR có ngày hết hạn và chữ ký của cả hai bên.