Từ khi nhận quản lý một đội kỹ sư hồi đầu năm, đánh giá hiệu suất với tôi đã chuyển từ chuyện người khác làm với mình thành chuyện mình phải đứng ra tổ chức. Tôi viết bài này một phần để sắp xếp lại suy nghĩ của chính mình, nên bạn hãy xem đây là ghi chép của một người đang mò đường, chứ đừng coi là chân lý.

Rốt cuộc đánh giá hiệu suất để làm gì?

#

Ở cấp nào thì mục đích cũng quy về hai điều: giúp mọi người tiếp tục học hỏi, và đảm bảo những ai đang làm vượt tầm vai trò của mình thực sự được ghi nhận và đền đáp xứng đáng.

Rất nhiều công ty nhỏ nói rằng họ không có thời gian hay nguồn lực để đánh giá hiệu suất, rồi lặng lẽ lấy thâm niên làm căn cứ duy nhất để xét xem ai đã sẵn sàng lên vị trí kỹ sư cấp cao (senior). Đó là một sai lầm, và không chỉ vì thâm niên là một thước đo lười biếng. Bỏ qua đánh giá tức là bỏ luôn kênh trao đổi hai chiều giữa công ty và nhân viên, và mối quan hệ làm việc sẽ vì thế mà đi xuống.

Chuyện này đúng theo cả hai chiều. Một kỹ sư có thể đang làm việc theo cách mà họ thật lòng tin là tốt nhất cho công ty, trong khi thói quen, phương pháp hay cách giao tiếp của họ lại đang dần lệch sang hướng chẳng giúp ích gì. Không có góp ý thì chẳng ai phát hiện ra. Ngược lại, công ty nào không bao giờ lắng nghe nhân viên qua một kênh bài bản thì cứ thế vô tư không biết mọi người thực sự nghĩ gì về công ty.

Mỗi bên nên kỳ vọng gì khi bước vào

#

Về phía nhân viên, danh sách không có gì phức tạp. Họ muốn biết công việc của mình gắn với mục tiêu của đội ra sao, mình đang làm tốt ở đâu, và cần cải thiện ở đâu, nói cụ thể chứ không phải kiểu “cần giao tiếp tốt hơn”. Họ muốn đóng góp của mình được ghi nhận, muốn có một cuộc trao đổi thực chất về lộ trình sự nghiệp và đào tạo, và một quy trình công bằng dựa trên công việc chứ không phải chuyện chính trị văn phòng.

Về phía tôi, tôi mong mọi người mang tới một bản tự đánh giá, tức là góc nhìn của chính họ về những gì đã làm tốt và chưa tốt. Tôi mong họ cởi mở đón nhận góp ý, thay vì mở màn như luật sư bào chữa. Tôi mong có một cuộc thảo luận thật lòng về mục tiêu sắp tới, và những chia sẻ thẳng thắn về việc họ thấy mình hợp với đội đến đâu. Kỳ đánh giá cũng là lúc tôi tự lên kế hoạch cho mình: cơ cấu đội, những ai có thể được thăng chức, ai cần được phát triển theo hướng nào.

Không có một khuôn mẫu chung cho mọi kỹ sư

#

Một đội kỹ sư gồm những người khác nhau về văn hóa, kinh nghiệm và chuyên môn, nên không thể dùng cùng một kịch bản đánh giá cho tất cả. Đối xử như nhau và đối xử công bằng không phải là một. Cách tiếp cận phải linh hoạt theo nhu cầu, giai đoạn sự nghiệp và mức đóng góp của từng người. Tối thiểu, bạn phải đảm bảo vai trò và trách nhiệm của mỗi kỹ sư được định nghĩa rõ ràng và thực sự tương xứng với mức lương của họ.

Chỗ nhạy cảm nhất là chức danh và lương. Khi ai đó còn băn khoăn về chức danh của mình, hoặc thấy mình đã sẵn sàng lên cấp, thì những lời động viên chung chung chẳng khác gì thuốc độc. Cái có tác dụng là những thứ cụ thể: cùng thống nhất một số thử thách hoặc mục tiêu dự án cụ thể làm mốc cho cấp tiếp theo, để chuyện thăng tiến có tiêu chí khách quan chứ không dựa vào cảm tính. Lương cũng vậy. Nếu ai đó thấy mình đang bị trả thấp, hoặc muốn nhận thêm trách nhiệm, hãy đưa vào kế hoạch của họ những mục tiêu đo được, nói rõ cần đạt được gì trước kỳ đánh giá tới thì mới có cơ sở để điều chỉnh. Rồi đến kỳ đánh giá đó, cả hai bên phải giữ đúng lời.

Góp ý về những điểm cần cải thiện cũng phải cụ thể như vậy. Một khóa đào tạo, một buổi workshop hay một dự án cụ thể nhắm vào đúng một điểm yếu cụ thể thì có ích. Còn một câu “tiếp tục nâng cao kỹ năng nhé” thì không.

Đặt mốc ngay từ buổi gặp đầu tiên

#

Buổi đánh giá đầu tiên với một thành viên mới trong đội chủ yếu là để đặt mốc ban đầu. Hai bên cùng xem lại vai trò đó thực sự gồm những việc gì, và nó đóng góp vào mục tiêu của đội, của công ty như thế nào. Thống nhất những kết quả đo được sẽ dùng để đánh giá hiệu suất. Đặt mục tiêu cho ngắn hạn và cho xa hơn. Đây cũng là lúc thích hợp để nói về văn hóa và cách hành xử mà đội kỳ vọng, góp ý sẽ được đưa ra như thế nào và vào lúc nào, người đó có thể dựa vào những nguồn lực và sự kèm cặp nào, và lộ trình sự nghiệp từ vị trí hiện tại của họ trông ra sao. Chẳng có gì trong số này hấp dẫn cả, nhưng nhờ có buổi này mà mọi kỳ đánh giá về sau đều dễ hơn.

Chương trình tôi dùng cho các kỳ sau

#

1. Nói chuyện phiếm. Nghe thì có vẻ vặt vãnh, nhưng nó giúp không khí bớt căng, và nhờ vậy mà phần còn lại của buổi nói chuyện thành thật hơn.
2. Điểm qua chương trình buổi gặp để không ai bị bất ngờ vì một chủ đề nào đó.
3. Những tiến bộ kể từ kỳ đánh giá trước: nói rõ ra họ đã tiến bộ ở đâu, vì hiếm ai tự nhận ra sự tiến bộ của mình.
4. Hiệu suất hiện tại, bắt đầu từ điểm mạnh.
5. Những điểm cần cải thiện, mỗi điểm kèm theo một mục tiêu cụ thể và thực tế.
6. Kế hoạch sự nghiệp, và công việc hiện tại có thực sự đưa họ tới đó không.
7. Chỉ tiêu, mục tiêu và những việc cụ thể cần làm trước kỳ đánh giá tới.

KPI chỉ có tác dụng khi được may đo cho từng người

#

Với kỹ sư trong một đội sản phẩm, KPI phải phù hợp với cả mục tiêu của đội lẫn từng cá nhân. Front-end, back-end và full-stack là những vai trò khác nhau, còn kỹ sư mới vào nghề (junior) và kỹ sư cấp cao thì càng khác nhau hơn nữa. Số lượng commit có thể nói lên điều gì đó về một lập trình viên mới vào nghề, nhưng lại chẳng nói được gì về một kỹ sư cấp cao mà thành quả chính là các quyết định kiến trúc. Vì thế, KPI phải được đặt ra qua trao đổi, chứ không phải chép từ một mẫu có sẵn.

Những mảng tôi thường xem xét:

• Chất lượng mã: tỉ lệ lỗi, mức độ tuân thủ các chuẩn chung, công việc của họ có hay phải sửa lỗi lại không
• Tiến độ dự án: các mốc và hạn chót đã hoàn thành đúng hẹn
• Đổi mới và giải quyết vấn đề: những cải thiện về hiệu quả, những bài toán khó thực sự được giải quyết
• Cộng tác: rà soát mã cho đồng nghiệp, đóng góp vào mục tiêu và các cuộc thảo luận của đội
• Phát triển bản thân: các mục tiêu học tập đã đạt, chứng chỉ, công nghệ mới đã nắm được
• Tác động tới khách hàng: góp ý từ người dùng, mức độ người dùng sử dụng những tính năng mà họ đã phát hành

Về phần đo lường được, kiểm thử đơn vị (unit test) là một yếu tố mà tôi ngày càng thấy ưng. Bài viết này trên InfoQ bàn về việc đưa kiểm thử đơn vị vào đánh giá hiệu suất, cả cách làm cụ thể lẫn ảnh hưởng của nó tới văn hóa của đội, và cho rằng nên kết hợp cả thước đo định tính lẫn định lượng về độ “khỏe” của mã nguồn. Đáng đọc nếu bạn đang tìm những KPI không biến kỹ sư thành những con số đếm dòng mã.

Chọn KPI nào thì chọn, hãy cùng nhau thống nhất trong buổi đánh giá hoặc buổi 1:1, và xem lại mỗi khi vai trò, dự án hay công nghệ thay đổi. Một KPI mà không ai đồng ý thì chẳng khác gì cây roi.

Mẫu tôi dùng để ghi

#

Mỗi người tôi giữ một tài liệu riêng, và mỗi kỳ đánh giá thì thêm một mục mới vào đó, để toàn bộ lịch sử nằm ở cùng một chỗ. Đây là khung sườn:

## Đánh giá hiệu suất: [Tên], [kỳ đánh giá]

**Vai trò và cấp bậc:** [chức danh, và cấp bậc đó nghĩa là gì trong đội này]
**Mục tiêu từ kỳ trước:** [chép lại từ mục của kỳ trước]

### Tự đánh giá (kỹ sư điền trước buổi gặp)
- Những gì đã làm tốt, kèm một hai ví dụ
- Những gì chưa tốt, và lần sau sẽ làm khác đi thế nào
- Một năm nữa muốn được làm gì

### Tiến độ với các mục tiêu của kỳ trước
- [Mục tiêu]: đạt / đạt một phần / chưa đạt, kèm bằng chứng

### Điểm mạnh (kèm ví dụ cụ thể)
- [Đã làm gì, khi nào, và điều đó thay đổi được gì]

### Điểm cần cải thiện (mỗi điểm kèm một mục tiêu)
- [Hành vi hoặc kỹ năng] → [thế nào thì được coi là "tốt hơn"] trước [ngày]

### Lộ trình sự nghiệp và cấp bậc
- Đang ở đâu so với cấp tiếp theo, và còn thiếu gì

### Mục tiêu đến kỳ đánh giá sau
1. [Mục tiêu đo được]
2. [Mục tiêu đo được]

### Những việc đã thống nhất
- [Ai] sẽ [làm gì] trước [khi nào]

Bản tự đánh giá phải được gửi tới trước buổi gặp một hai ngày, không bao giờ để đến lúc ngồi họp mới làm. Đọc trước bản này khiến cuộc nói chuyện khác hẳn: cứ hai lần thì có một lần chính kỹ sư đã tự nêu ra đúng điều tôi định nói, và hai bên có thể dành cả buổi để bàn xem nên làm gì với nó.

Câu hỏi cho phần tự đánh giá

#

Đây là những câu hỏi gợi ý mà tôi gửi trước cho mọi người. Tôi cố tình để chúng ở dạng câu hỏi mở, để câu trả lời cho tôi biết người đó nhìn nhận công việc của chính mình ra sao, chứ không chỉ liệt kê họ đã làm những gì:

• Kể từ kỳ đánh giá trước, bạn tự hào nhất về điều gì, và vì sao lại là điều đó?
• Bạn đã bị vướng ở đâu, và điều gì có thể giúp bạn gỡ được sớm hơn?
• Có góp ý nào từ đồng đội hay người rà soát mã cho bạn mà bạn vẫn còn nhớ mãi?
• Trong các mục tiêu của kỳ trước, bạn nghĩ mình đã đạt những mục tiêu nào, và muốn bỏ hay thay đổi mục tiêu nào?
• Tiếp theo bạn muốn học gì, và công việc hiện tại có cho bạn cơ hội học điều đó không?
• Với vai trò là quản lý của bạn, tôi nên làm gì khác đi?

Câu cuối cùng là câu khiến người ta im lặng ngượng ngùng lâu nhất, nhưng cũng mang lại những câu trả lời có ích nhất.

Góp ý cụ thể nghe như thế nào

#

Phần lớn những góp ý tồi trong buổi đánh giá không tệ vì gay gắt, mà vì mơ hồ. Dưới đây là sự khác biệt, kèm những ví dụ theo kiểu mà tôi cố gắng viết:

Mỗi góp ý cụ thể đều nêu ra một sự việc, nói rõ sự việc đó đã dẫn tới điều gì, và chỉ ra một việc người đó có thể làm tiếp theo. Viết như vậy tốn thời gian hơn, và đó chính là lý do tôi tự bắt mình ghi lại ví dụ dần dần trong suốt cả quý, thay vì đến tối hôm trước buổi đánh giá mới cố nhớ lại.

Viết ra giấy

#

Sau buổi gặp, hãy viết một bản tóm tắt: những điểm chính đã bàn, các vấn đề được nêu ra, những việc cần làm, và những mục tiêu mà cả hai đã thống nhất. Nghe thì có vẻ quan liêu, nhưng chính bản ghi này giúp tránh được màn “ơ, đâu có thống nhất như vậy” sáu tháng sau. Vấn đề nào đã ghi lại thì sẽ được theo dõi thay vì bốc hơi, danh sách việc cần làm trở thành phần mở đầu cho chương trình kỳ đánh giá sau, và người ta cũng nghiêm túc với mục tiêu hơn khi nó đã nằm trên giấy.

Toàn bộ hệ thống thật ra chỉ có vậy: kỳ vọng rõ ràng ngay từ ngày đầu, KPI may đo cho từng người, mọi thứ đều được ghi lại, và theo sát tới cùng từng việc cần làm. Một buổi đánh giá mà không phải là cuộc trao đổi hai chiều với kết quả đo được thì chỉ là làm cho có, và kỹ sư thì ngửi thấy mùi “làm cho có” ngay từ lúc nhận lời mời họp.