Bảng kế hoạch nhìn rất đẹp, nhưng những người ngồi quanh bàn vẫn chưa thật sự chắc mình đang đi đâu. Ba Objective, chín Key Result, hàng loạt ô màu xanh. Chỉ có một câu đơn giản là chưa ai trả lời gọn được: nếu tất cả đều xanh, điều gì sẽ tốt hơn cho người dùng, cho doanh nghiệp hoặc cho chính hệ thống kỹ thuật?
Đó là chỗ OKR dễ trượt khỏi mục đích ban đầu. Nó có thể làm hướng đi rõ hơn, cũng có thể biến thành một danh sách việc khoác áo chiến lược. Một hệ thống Objectives and Key Results tốt nối công sức bỏ ra với kết quả muốn đạt tới. Một hệ thống yếu chỉ đổi tên các cam kết giao hàng, rồi bắt mọi người cập nhật phần trăm cho tới hết quý.
Objective nên nói được một hướng có ý nghĩa bằng lời lẽ ai cũng hiểu. Chẳng hạn: làm quy trình thanh toán đáng tin cậy hơn, giúp khách hàng mới bắt đầu nhanh hơn, giảm áp lực vận hành trong mỗi lần release, hoặc xây nền dữ liệu vững hơn cho quyết định sản phẩm. Nó cần đủ cụ thể để cả đội nhớ khi phải đánh đổi, nhưng cũng đủ rộng để thay đổi cách làm khi có thêm bằng chứng.
Key Result phải là dấu hiệu cho thấy tình hình đã cải thiện, không chỉ là việc đã hoàn tất. “Release cơ chế retry mới” là một đầu việc; “giảm 30% số lần thanh toán thất bại” mới gần với kết quả. “Viết runbook” là đầu việc; “giảm thời gian chẩn đoán sự cố trung bình từ 40 phút xuống 15 phút” là bằng chứng. Phân biệt này quan trọng vì một đội có thể đóng rất nhiều ticket mà bài toán gốc gần như không nhúc nhích.
OKR kỹ thuật cần giữ cân bằng giữa kết quả sản phẩm và sức khỏe hệ thống. Nếu mọi mục tiêu đều chạy theo tăng trưởng, reliability, maintainability và trải nghiệm của developer rất dễ bị bỏ quên cho tới ngày hệ thống phản ứng. Nếu tất cả chỉ là dọn dẹp nội bộ, đội kỹ thuật lại có thể trôi xa giá trị khách hàng. Một bộ mục tiêu vừa phải thường có một kết quả hướng ra người dùng, một kết quả về độ tin cậy hoặc chất lượng, và một năng lực nền giúp việc giao hàng sau này bớt nặng.
Phép đo không cần hoàn hảo, nhưng phải trung thực. Có metric nhiều nhiễu, baseline còn thiếu, hoặc kết quả chỉ đo được qua tín hiệu đại diện. Điều đó chấp nhận được nếu cả đội nói rõ giới hạn. Một Key Result có bằng chứng chưa đẹp nhưng ai cũng kiểm tra được vẫn tốt hơn một lời hứa mơ hồ. Mục tiêu không phải tạo ra công thức toán học thật bóng bẩy; mục tiêu là giúp cuộc trò chuyện về hiệu quả công việc bớt cảm tính.
OKR trở nên độc hại khi bị dùng làm bẫy đánh giá cá nhân. Nếu mỗi Key Result biến thành bảng điểm của một người, mọi người sẽ học cách đặt mục tiêu thấp, che đi điều chưa chắc hoặc chỉ chọn việc an toàn. Công việc kỹ thuật luôn có phụ thuộc, khám phá, sự cố và ràng buộc thay đổi. OKR nên giúp đội ngũ ưu tiên và học, không nên trừng phạt một cá nhân vì thực tế phức tạp hơn buổi lập kế hoạch.
Nhịp xem lại cũng quan trọng. Viết OKR đầu quý rồi tới cuối quý mới chấm là quá muộn. Trong quý cần có những buổi ngắn để hỏi: điều gì đã đổi, ta vừa học thêm gì, Key Result nào không còn phản ánh con đường tốt nhất, và việc nào nên dừng? Chính ở đây OKR mới có ích. Nó giữ sự tập trung, đồng thời cho phép kế hoạch thay đổi khi bằng chứng thay đổi.
Một OKR tốt còn làm cho chữ “không” có căn cứ hơn. Khi yêu cầu mới xuất hiện, cả đội có thể hỏi nó phục vụ Objective hay chỉ mang vẻ khẩn cấp. Khi đề xuất refactor, kỹ sư có thể nối nó với độ tin cậy hoặc tốc độ giao hàng thay vì bảo vệ như sở thích cá nhân. Khi lãnh đạo hỏi tiến độ, đội ngũ có thể đưa ra bằng chứng chứ không chỉ kể mình đã bận thế nào.
Tôi thấy OKR đáng dùng khi nó làm công việc dễ hiểu hơn và bớt tính trình diễn: đây là thay đổi chúng ta muốn tạo ra, đây là cách nhận biết nó đã xảy ra, đây là những đánh đổi ta chấp nhận, và đây là chỗ vẫn còn phải học. Điều đáng nhớ hiếm khi là mẫu bảng nào đẹp nhất. Nó thường là khoảnh khắc một Objective rõ ràng giúp cả đội chọn tốt hơn điều mà danh sách việc không thể trả lời.