Trong nhiều công ty IT, OKR được áp dụng rộng rãi. Nhưng đi kèm với nó là vô số cuộc họp và hàng tuần suy nghĩ: “6 tháng tới mình phải đặt mục tiêu gì đây?” Kết quả là nhiều người trầm cảm với việc đặt mục tiêu, còn leader thì mệt mỏi để review và feedback.
Ngược lại, khi mình áp dụng SMART goal, mọi việc trở nên đơn giản hơn rất nhiều. Các mục tiêu mình viết ra thường được sếp duyệt ngay. Nếu có chỉnh sửa thì cũng chỉ là vài yêu cầu nhỏ, không đáng kể.
Vậy SMART goal là gì, và mình đã áp dụng nó như thế nào? Hãy cùng mình tìm hiểu nhé.
SMART – Bộ tiêu chí cho mọi mục tiêu
SMART chỉ là một tập hợp tiêu chí mà bất kỳ mục tiêu nào cũng cần có:
- (S)pecific – Cụ thể
- (M)easurable – Đo lường được
- (A)chievable – Có thể đạt được
- (R)elevant – Liên quan, phù hợp
- (T)ime-bound – Có thời hạn
(S)pecific – Cụ thể
Một mục tiêu phải rõ ràng thì mới đạt được. Ví dụ kinh điển: bạn gái nói “ăn gì cũng được” – và bạn rơi vào mê hồn trận: là ăn phở, ăn bún, hay thực ra cô ấy đang giận mình?
Trong công việc cũng vậy. Một developer đặt mục tiêu “tôi muốn code tốt hơn” thì quá mơ hồ. Hãy cụ thể hơn:
- “Tăng số lượng task hoàn thành trong mỗi sprint.”
- “Giảm số lượng bug tạo ra trong quá trình code.”
Hoặc với mình khi làm trong hệ thống đặt vé máy bay, thì có thể đặt các mục tiêu:
- “Giảm số bug xảy ra trong bước thanh toán xuống dưới 1%.”
- “Tăng tỷ lệ xuất vé tự động thành công từ 95% lên 98% trong 6 tháng.”
Càng cụ thể, càng dễ thực hiện.
(M)easurable – Đo lường được
Mục tiêu cần được đo lường trong suốt quá trình, không chỉ khi kết thúc.
Ví dụ: “Hoàn thành nhiều task hơn” → bạn có thể đo lường số lượng task theo từng sprint hoặc từng tháng.
Trong hệ thống đặt vé, đo lường có thể là:
- Tỷ lệ giao dịch thanh toán thành công.
- Số lượng bug xuất hiện trên production hàng tháng.
Nếu không có thước đo, bạn chỉ đang “ước” chứ không phải đặt mục tiêu.
(A)chievable – Có thể đạt được
Trong hệ thống đặt vé, bug production là chuyện khó tránh vì:
- Các hãng máy bay thay đổi giao diện liên tục dẫn tới việc làm bot để đặt vé sẽ lỗi
- Lượng người dùng tăng mạnh vào mùa cao điểm (Tết, lễ).
Vì vậy, mục tiêu phải khả thi, không “hoàn hảo ảo tưởng”:
Ví dụ mục tiêu sau sẽ là không khả thi:
- “Giảm số bug production về 0 trong 6 tháng.” (chỉ đúng nếu… không có khách hàng nào đặt vé).
Mình có thể sửa lại để thành mục tiêu khả thi:
- “Giảm số bug trên production trong quá trình đặt vé xuống còn ≤ 3 mỗi quý.”
- “Đảm bảo 95% giao dịch thanh toán thành công ngay lần đầu tiên trong vòng 6 tháng.”
Mục tiêu khả thi sẽ giúp team tin tưởng và dốc sức, thay vì nản lòng vì một “giấc mơ bất khả thi.”
(R)elevant – Liên quan, phù hợp
Mỗi mục tiêu nên gắn trực tiếp với giá trị cốt lõi của doanh nghiệp: tạo doanh thu, giảm chi phí, hoặc giữ chân khách hàng.
Ví dụ trong hệ thống đặt vé:
- Giảm bug trong bước thanh toán → tăng tỷ lệ giao dịch thành công → trực tiếp tăng doanh thu.
- Giảm bug trong bước xuất vé tự động → giảm số ticket phải xử lý thủ công → trực tiếp giảm chi phí vận hành.
- Giảm bug trong bước tìm kiếm chuyến bay → khách hàng ít rời bỏ hơn → tăng tỷ lệ chuyển đổi.
Như vậy, một mục tiêu “giảm bug” không chỉ để developer đỡ cực, mà phải trả lời được: nó giúp công ty kiếm thêm tiền, tiết kiệm chi phí, hay giữ khách hàng tốt hơn?
Ví dụ mục tiêu relevant:
- “Giảm số bug liên quan đến thanh toán còn dưới 1% để tăng tỷ lệ doanh thu thành công thêm 5% trong quý 3.”
(T)ime-bound – Có thời hạn
Trong ngành travel, yếu tố thời gian còn quan trọng hơn bình thường, vì:
- Có mùa cao điểm (Tết, lễ, hè).
- Nếu không kịp fix bug trước mùa cao điểm, rủi ro mất doanh thu lớn và khách hàng bỏ sang đối thủ.
Ví dụ một mục tiêu không time-bound:
- “Giảm bug trong hệ thống đặt vé.”
Mình có thể sửa lại thành mục tiêu có time-bound:
- “Giảm số bug trên production trong quá trình đặt vé xuống còn ≤ 3 trong vòng 3 tháng.”
Việc gắn thời hạn giúp team:
- Biết rõ mốc deadline để tập trung.
- Lên kế hoạch test regression, code review, và load test trước mùa cao điểm.
- Giảm rủi ro gián đoạn dịch vụ đúng lúc khách hàng cần nhất.
SMARTER – Nâng cấp mục tiêu
Trong một lần đào tạo nội bộ, mình còn học thêm về SMARTER goal. Hai chữ mới là:
- (E)thical – Đạo đức
- (R)ewarding – Mang lại phần thưởng
(E)thical – Đạo đức
Với hệ thống đặt vé máy bay, khách sạn, một bug production có thể cực kỳ nguy hiểm:
- Khách hàng mất tiền nhưng không có vé.
- Lịch bay/hành trình sai, ảnh hưởng trực tiếp đến chuyến đi.
- Rò rỉ thông tin cá nhân hoặc thẻ tín dụng.
Vậy nên việc giảm bug không chỉ để “đẹp số liệu”, mà còn là trách nhiệm đạo đức: bảo vệ dữ liệu, giao dịch minh bạch và trải nghiệm công bằng cho khách hàng.
Ví dụ:
- “Giảm 40% số bug nghiêm trọng trong 3 tháng tới để đảm bảo không gây thất thoát giao dịch hoặc gián đoạn hành trình của khách hàng.”
(R)ewarding – Mang lại phần thưởng
Rewarding gắn với ý nghĩa công việc và động lực cho team:
- Giảm bug → khách hàng ít phàn nàn, đánh giá tốt hơn → team tự hào.
- Công ty ghi nhận bằng bằng giải MVP.
Ví dụ:
- “Giảm số bug blocker xuống dưới 2/sprint trong 2 tháng để khách hàng có trải nghiệm đặt vé liền mạch, đồng thời team được công nhận là nhóm cải thiện chất lượng hệ thống nhanh nhất quý này.”
Kết luận
So với việc ngồi đau đầu nghĩ OKR mỗi 6 tháng, thì SMARTER goal giúp mình:
- Viết mục tiêu nhanh hơn, rõ ràng hơn.
- Ít phải tranh luận với sếp.
- Cảm thấy công việc vừa có ý nghĩa, vừa được công nhận.
👉 Bài học: SMARTER goal không chỉ giúp bạn đạt mục tiêu, mà còn giúp cả team hứng thú trên hành trình đạt được nó.