Đợt vừa rồi tôi có gửi mail tặng free bộ tài liệu 3P (MTCV, KPI, Khung năng lực, Lương 3P) phòng HCNS thì nhận được mail phản hồi của một anh chị có nội dung như sau:
"Chào anh Cường,
Cảm ơn anh và team đã chia sẻ thông tin về hệ thống QTNS core theo lương 3P. Hiện em thấy tài liệu này khá hữu ích, đặc biệt là trong việc xây dựng khung hệ thống cho các phòng ban, trong đó có cả HR.
Hiện tại bên em đang quan tâm đến việc xây dựng các KPIs để đánh giá hiệu suất cho nhóm Developer và đang phát triển một số tiêu chí để đánh giá performance của Developer, không biết team anh Cường có template hoặc quy trình tham khảo cụ thể nào cho lĩnh vực này không ạ?
Mong nhận được phản hồi từ anh về việc tư vấn quy trình cũng như tài liệu tham khảo thêm nếu có. Em xin chân thành cảm ơn.
Trân trọng!"
Bản thân tôi cũng đã va chạm, làm KPI với kha khá những vị trí khó định lượng như thế này. Ngoài Developer, chúng ta có thể liệt kê ra như các vị trí: Kiến trúc sư, kỹ thuật... Khó có thể là với ai đó. Nhưng với tôi thì không. Xin chia sẻ kinh nghiệm với anh chị và các bạn.
1. Hãy coi các vị trí khó như anh thợ "đụng"
Kinh nghiệm của tôi là... hãy tưởng tượng những người làm những công việc đó như anh thợ đụng. Công việc của anh là đụng cái gì làm cái đó. Nào là trát vữa, quét sơn... Giờ phải trả công cho anh như thế nào? Trả theo công nhật hay khoán? Mà trả kiểu gì cũng phải khoán. Nhưng việc của anh đâu phải lúc nào cũng chỉ 1 mà lúc có việc này anh đụng nó, hết việc anh đụng sang cái khác. Cho nên có một cách khoán là quy đổi công việc ra 1 giá trị nào đó rồi giao chỉ tiêu.
Ví dụ:
- Sơn nhà có giá là 200k/ 1 m2
- Xây tường có giá là 400k/ 1 m2
- Trộn vữa có giá là 100k/ 1 bao xi măng (theo công thức 2 vữa 1 xi).
Suy ra chúng ta có chỉ tiêu: Tổng giá trị công việc mà thợ cần "đụng": 1000k/ ngày.
2. Các bước làm KPI cho các vị trí khó định lượng như Developer, kiến trúc sư, kỹ thuật cơ điện
Không biết bạn đã tìm ra được hướng để xây KPI cho Developer, kiến trúc sư, kỹ thuật chưa? Tôi tin là rồi. Bản chất các công việc này là đi xử lý các "khối công việc". Đối với Developer, họ sẽ cần phải làm ra các tính năng hoặc xử lý các vấn đề lập trình. Kiến trúc sư thì thiết kế các cấu phần của ngôi nhà. Kỹ thuật sửa chữa các thiết bị. Mục tiêu cuối cùng là những người làm ở các vị trí này cần hoàn thành các "khối công việc" được quy đổi thành 1 giá trị nào đó đồng nhất.
Đây chính là KPI: Tổng giá trị "khối công việc" cần phải hoàn thành.
Cụ thể các bước như sau:
2.1. Đầu tiên, chúng ta sẽ xác đinh, đặt tên các khối công việc. Chúng ta đặt tên kiểu gì cũng được miễn sao cho phù hợp với chuyên môn.
Ví dụ:
- Developer: Các khối công việc cần code là lập trình tính năng hoặc lập trình sửa các vấn đề. Chúng ta đặt tên các tính năng hoặc vấn đề là: Issue (hoặc block).
- Kiến trúc sư: Các khối công việc cần thiết kế là thiết kế các cấu phần ngôi nhà hoặc thiết kế ngôi nhà. Ta đặt tên cấu phần ngôi nhà hoặc cả ngôi nhà là: Dự án.
- Kỹ thuật cơ điện: Các khối công việc cần sửa là sửa các thiết bị hoặc sửa các máy móc. Đặt tên các thiết bị hoặc máy móc cần sửa là: Máy
2.2. Có quy ước tên rồi thì chúng ta ra tên thước đo KPI (về mặt số lượng):
- KPI Developer:
+ Tổng số issue deve cần hoàn thành
+ Tổng số block deve cần hoàn thành
- KPI Kiến trúc sư:
+ Tổng số lượng cấu phần kiến trúc sư cần thiết kế
+ Tổng giá trị dự án thiết kế mà kiến trúc sư cần thiết kế xong
- Kỹ thuật cơ điện:
+ Tổng số lượng điểm kỹ thuật mà kỹ thuật cơ điện cần tích lũy
+ Tổng giá trị sửa chữa kỹ thuật cần kiếm được
2.3. Bước tiếp theo, ta tiến hành xác định hoặc quy đổi khối công việc ra giá trị. Việc quy đổi này cần tính trên một người Y có năng lực trung bình khi xử lý xong khối công việc. Tùy từng tổ chức sẽ quy ước giá trị là gì cho phù hợp với đặc điểm bộ phận và công việc.
Ví dụ:
- Developer: 1 Issue (hoặc block) = 30 phút code.
- Kiến trúc sư: 1 Dự án = 20 triệu.
- Kỹ thuật cơ điện: 1 Máy = 5 điểm kỹ thuật = 2h sửa chữa.
2.4. Khi có được giá trị khối công việc, ta sẽ xác định chỉ tiêu cần hoàn thành dựa trên so sánh năng lực của nhân viên với người nhân viên trung bình Y.
Ví dụ:
- Developer:
+ Bậc thợ (Level) 1: Tổng số issue deve cần hoàn thành: 16 issue/ ngày.
+ Bậc thợ (Level) 2: Tổng số issue deve cần hoàn thành: 25 issue/ ngày.
- Kiến trúc sư:
+ Bậc thợ (Level) 1: Tổng giá trị dự án thiết kế mà kiến trúc sư cần thiết kế xong: 2 dự án (hoặc 40 triệu).
+ Bậc thợ (Level) 2: Tổng giá trị dự án thiết kế mà kiến trúc sư cần thiết kế xong: 3 dự án (hoặc 60 triệu)
- Kỹ thuật cơ điện:
+ Bậc thợ (Level) 1: Tổng số lượng điểm kỹ thuật mà kỹ thuật cơ điện cần tích lũy: 20 điểm
+ Bậc thợ (Level) 2: Tổng số lượng điểm kỹ thuật mà kỹ thuật cơ điện cần tích lũy: 40 điểm
Đến đây, hẳn bạn sẽ thấy hóa ra các vị trí đều có đầu ra nào đó được định lượng và hoàn toàn có thể đo được bằng một thước đo số lượng.
2.5. Trong trường hợp nếu gặp phải việc xác định "khối công việc" khó khăn thì chúng ta có thể quy định hoặc ra tiêu chuẩn rồi nhóm chúng thành các nhóm khác nhau như A, B, C hoặc Quan trọng, bình thường, ít quan trọng. Sau đó quy đổi các nhóm đó ra giá trị công việc.
Ví dụ:
- Developer:
+ Những vấn đề như sửa chính tả, sửa lỗi tiếng việt hoặc tính năng nhỏ kiểu thêm nút hoặc menu... thì cho vào nhóm A gọi tên là Issue A.
+ Những vấn đề như sửa lỗi đứng hình hoặc tính năng trung bình như thêm tính năng đếm thời gian... thì cho vào nhóm B gọi tên là Issue B.
+ Những vấn đề khó khác theo đánh giá của trưởng bộ phận thì cho vào nhóm C gọi tên là Issu C.
- Kiến trúc sư:
+ Những yêu cầu thiết kế có số tiền < 10 triệu thì cho vào nhóm A gọi là Dự án loại A.
+ Những yêu cầu thiết kế có số tiền từ 10 - 20 triệu thì cho vào nhóm C gọi là Dự án loại B.
+ Những yêu cầu thiết kế có số tiền > 20 triệu thì cho vào nhóm C gọi là Dự án loại C.
- Kỹ thuật cơ điện:
+ Những máy mà có lỗi cơ bản, chỉ cần điều chỉnh, không cần thay thiết bị gọi là Máy A.
+ Những máy có lỗi chỉ cần sửa thiết bị gọi là Máy B.
+ Những máy có lỗi mà phải sửa và thay thiết bị gọi là Máy C.
Vậy là tôi đã chia sẻ điểm trọng yếu "ăn tiền" khi làm KPI rồi. Về cách làm thước đo KPI ngoài những thước đo trên thì vẫn giống như các vị trí khác.
3. Cách làm KPI tắt
Bạn hãy vui lòng vào xem bài: Xây dựng KPI tắt như thế nào cho nhanh? để biết cách làm KPI tắt. Cách làm tắt này có một cái tên gọi khác là phương pháp JD - KPI. Các bước như sau:
Bước 1: Mở mô tả công việc ra. Nếu chưa có MTCV thì làm mô tả công việc.
Bước 2: Nhìn vào từng đầu công việc rồi lẩm bẩm khẩu quyết:
Bc2.1. Làm thế nào để đo được hiệu suất - tức:
- Khối lượng
- Chất lượng
- Tốc độ hoàn thành
- Chi phí
của người thực hiện công việc đó? Hay trả lời câu hỏi khẩu quyết: Công việc như thế nào là đạt về số lượng, chất lượng, thời gian, chi phí?
Bc2.2. Có được câu trả lời rồi thì chuyển đổi câu trả lời về mẫu KPI:
Số + ...
Tỷ lệ + ..
Thời gian ...
Bước 3: Sau khi ra được chỉ số rồi thì tiến tới lựa chọn KPI bằng cách lầm bẩm tiếp câu: Chỉ số này có Smart - tức:
- Cân
- Đo
- Đong
- Đếm
được hay không?
Bước 4: Có các thước đo, tiếp sau là tính trọng số cho các thước đo (kpi). Trọng số còn đc gọi là tỷ trọng.
Vậy là chúng ta ra thẻ KPI cho vị trí.
Ví dụ đơn giản: Chúng ta có CÔNG VIỆC: ĂN CƠM
Công việc "Ăn cơm" như thế nào là đạt về:
- Số lượng: Ăn hết 1 tô cơm
- Chất lượng: Ăn vui vẻ (Dạ ko bị la “ ăn đi con” hoặc ba mẹ khen)
- Thời gian: Ăn trong thời gian quy định (15 phút)
- Chi phí:
Chuyển đổi câu trả lời về mẫu KPI:
* Đạt về số lượng: Ăn hết 1 tô cơm
>> KPI:
- Số tô cơm con cần ăn hết: 1 tổ
- Tỷ lệ số tô cơm con ăn được/ tổng số tô cơm con cần ăn: 100%
* Đạt về chất lượng: Ăn vui vẻ (Dạ ko bị la “ ăn đi con” hoặc ba mẹ khen)
>> KPI:
Không bị la:
+ Số lần ba mẹ la con khi ăn: 0
+ Tỷ lệ số bữa ăn ba mẹ la con khi ăn/ tổng số bữa ăn: 100%
Ba mẹ khen:
+ Số lời khen của ba me cho con
+ Tỷ lệ số bữa bố mẹ hài lòng về con/ tổng số bữa ăn
* Đạt về thời gian: Ăn trong thời gian quy định (15 phút)
>> KPI:
- Số lần ăn muộn hơn so với quy định: 0
- Thời gian trung bình con ăn cơm/ 1 bữa: 15 phút
- Tỷ lệ tổng thời gian con ăn cơm/ tổng thời gian cho phép: 100%
Chúc bạn thành công!
Tái bút 14/11/24: Hôm nay tôi nhận được 1 trao đổi thế này: "Thầy cho em hỏi thêm là công ty em làm về công nghệ thông tin, có vị trí developer, công việc của họ là viết tính năng, sửa bug chẳng hạn, tuy nhiên việc định lượng được thời gian chung khá là khó vì sẽ có task dễ task khó, thì cái này sẽ chia theo cả độ khó của task ạ.
Ngoài ra em có đọc 1 bài trên blog của thầy về cách viết KPI của 1 số vị trí khó định lượng, em có đưa cho sếp em tham khảo thử nhưng anh ấy cũng bảo là nếu lấy việc số lượng bug sửa được để làm thước đo thì cũng ko được chính xác để đánh giá công việc (ý là nếu giải quyết được nhiều bug tức là phần mềm đang xảy ra nhiều lỗi -> việc code có vấn đề, còn nếu giải quyết ít thì lại có khả năng nhân viên làm chưa hết công suất)".
Đây là tin nhắn của chị học viên sau khi học buổi hoàn thiện KPI trong lớp Hệ thống QTNS core lương 3P. Trong buổi học tôi có hướng dẫn việc lên chỉ tiêu KPI bằng định mức lao động (theo chi phí và thời gian). Chi tiết như trong bài: "Định mức lao động và 4 cách xác định các chỉ tiêu KPI".
Câu hỏi có 2 ý:
- "Việc định lượng được thời gian chung khá là khó vì sẽ có task dễ task khó, thì cái này sẽ chia theo cả độ khó của task ạ?" (1)
- "ý là nếu giải quyết được nhiều bug tức là phần mềm đang xảy ra nhiều lỗi -> việc code có vấn đề, còn nếu giải quyết ít thì lại có khả năng nhân viên làm chưa hết công suất" (2)
Câu hỏi (1), gắn với phần: "2.3. Bước tiếp theo, ta tiến hành xác định hoặc quy đổi khối công việc ra giá trị. Việc quy đổi này cần tính trên một người Y có năng lực trung bình khi xử lý xong khối công việc. Tùy từng tổ chức sẽ quy ước giá trị là gì cho phù hợp với đặc điểm bộ phận và công việc.
Ví dụ:
- Developer: 1 Issue (hoặc block) = 30 phút code.
- Kiến trúc sư: 1 Dự án = 20 triệu.
- Kỹ thuật cơ điện: 1 Máy = 5 điểm kỹ thuật = 2h sửa chữa."
Thực ra, câu hỏi này đã được tôi trả lời trong phần: "2.5. Trong trường hợp nếu gặp phải việc xác định "khối công việc" khó khăn thì chúng ta có thể quy định hoặc ra tiêu chuẩn rồi nhóm chúng thành các nhóm khác nhau như A, B, C hoặc Quan trọng, bình thường, ít quan trọng. Sau đó quy đổi các nhóm đó ra giá trị công việc.
Ví dụ:
- Developer:
+ Những vấn đề như sửa chính tả, sửa lỗi tiếng việt hoặc tính năng nhỏ kiểu thêm nút hoặc menu... thì cho vào nhóm A gọi tên là Issue A.
+ Những vấn đề như sửa lỗi đứng hình hoặc tính năng trung bình như thêm tính năng đếm thời gian... thì cho vào nhóm B gọi tên là Issue B.
+ Những vấn đề khó khác theo đánh giá của trưởng bộ phận thì cho vào nhóm C gọi tên là Issu C."
Kết luận:
- Task dễ, task khó giống như Issue A, Issue B.
- Một người có năng lực trung bình sẽ xử lý 1 Issue (hoặc block) A = 30 phút code. Issue B = 1,5 lần Issue A = 1,5 * 30 = 45 phút.
- KPI có thể là:
+ Số Issue A (hoặc task dễ) cần xử lý.
+ Số Issue B (hoặc task khó) cần xử lý.
Thực ra trong câu hỏi (1) này có ý phụ nữa là làm sao biết được 1 Issue (hoặc block) A = 30 phút code. Cái này do trưởng phòng Deve quy định dựa trên quan sát của ban thân về tốc độ code của anh em trong phòng.
Câu hỏi (2), tôi đánh giá sếp của chị học viên đang không muốn nghe nên không đọc kỹ và nghe lọt thông tin. Với kinh nghiệm của tôi, có nói nữa cũng không giải quyết được vấn đề gì. Là tôi thì tôi sẽ không nói thêm, cứ để đó. Chứ tôi đi tư vấn chưa có ai nói thế. Đối tác của họ sẽ tự biết cách kiểm soát chất lượng code. Còn không, họ sẽ hỏi theo kiểu thiện chí là: "Có cách nào để đánh giá chất lượng code không?"
Nếu đúng là câu hỏi tìm thêm KPi về chất lượng code thì tôi đã trả lời ở phần "3. Cách làm KPI tắt
...
Bước 2: Nhìn vào từng đầu công việc rồi lẩm bẩm khẩu quyết:
Bc2.1. Làm thế nào để đo được hiệu suất - tức:
- Khối lượng
- Chất lượng
- Tốc độ hoàn thành
- Chi phí
của người thực hiện công việc đó? Hay trả lời câu hỏi khẩu quyết: Công việc như thế nào là đạt về số lượng, chất lượng, thời gian, chi phí?"
Tức là khi làm KPI thì không chỉ đơn giản chỉ có 1 thước đo như ở trên (ví dụ:Số Issue A (hoặc task dễ) cần xử lý) mà sẽ còn thêm những thước đo khác đi kèm nữa như:
- Số lỗi code bị tester phát hiện
- Tỷ lệ Issue được xử lý/ tổng số Issue được phân công.
Nguyễn Hùng Cường (kinhcan24)
Tư vấn xây dựng hệ thống QTNS bài bản
