Performance review

Đánh giá kết quả của 1 nhân viên kinh doanh tương đối dễ dàng, do kết quả hầu hết đều ở dạng số, target (mục tiêu) của bạn là bao nhiêu và actual (phần thực đạt) của bạn là bao nhiêu đều rõ ràng. Đối với nhân viên mảng công nghệ thì không như vậy và bài viết này nhằm chia sẻ vài góc nhìn của mình về vấn đề này.

1. Software engineer

Đối với software engineer, target chính sẽ là hoàn thành ticket/tính năng được giao và chất lượng của ticket/tính năng này.

Tuy nhiên, trong 1 tính năng lớn sẽ có rất nhiều ticket nhỏ, nếu đánh giá từng ticket nhỏ sẽ rất chi li và mất thời gian, do đó bạn cần "tóm tắt và tổng quát hóa" nó, diễn giải công việc mình làm sao cho

• súc tích (bản đánh giá không thành tài liệu 69 trang)
• rõ ràng, dễ hiểu (với người ngoài)
• thuyết phục (nếu có số liệu dẫn chứng thì càng tốt) và hấp dẫn

Team lead/Product lead sẽ là người thích hợp để hỗ trợ/tư vấn các engineer vấn đề này, vì nhiều bạn engineer có thể chuyên môn tốt nhưng chưa quen với việc "diễn tả công việc mình làm sao cho hấp dẫn". Việc này cũng nên được thực hiện thường xuyên trong suốt quá trình làm việc chứ không đợi tới lúc performance review mới nhớ lại trong suốt mấy tháng qua mình đã làm gì, như vậy sẽ rất khó chính xác.

1 cách tiếp cận đơn giản khác là bảo họ hình dung mình đang đi interview, vậy mình nên tả công việc đã làm thế nào để hấp dẫn nhà tuyển dụng, đó là cách nên dùng để ghi performance review.

Đối với chất lượng hoàn thành ticket, tính năng, được hiểu là

• ít bug
• dễ hiểu
• dễ mở rộng
• có performance tốt.

Đây cũng là những yếu tố không dễ để lượng hóa, team lead có thể nhờ các bạn technical lead đánh giá cùng về vấn đề này. Lưu ý, trọng số của việc "hoàn thành" và "chất lượng hoàn thành" có thể sẽ thay đổi theo từng tính năng, dự án. Những dự án có deadline ngắn, ảnh hưởng cao thì có thể chấp nhận việc người engineer làm "tắt" 1 số bước, và ngược lại có những dự án (hoặc thời điểm) mà yêu cầu chất lượng code cần được đề cao và không thỏa hiệp với những cách làm "tắt". Cân bằng những tiêu chí này là dựa vào thảo luận, thống nhất giữa Product lead và Tech lead.

2. Product/Project

Đối với Product, target chính bao gồm các phần sau

• các metric chịu trách nhiệm

• chất lượng triển khai các dự án/tính năng chịu trách nhiệm

• xây dựng team

Việc đánh giá chất lượng hoàn thành metric cũng không hẳn là straight-forward, vì sẽ có metric bạn Product chi phối hoàn toàn, nhưng sẽ có metric mà nó thay đổi thế nào ngoài chuyện Product tốt hay không còn phụ thuộc khá nhiều về phía qui trình user sử dụng và các yếu tố khác.

Tuy nhiên, điều nên làm là cứ suy nghĩ liệt kê ra các metric này và ghi nhận lại kết quả đạt được, lí do vì sao nó tăng hoặc giảm. Dần dần mình sẽ có góc nhìn rõ ràng hơn và thấy là metric nào hợp lí, metric nào "không liên quan" có thể bỏ ra

Đối với các bạn Product mà sản phẩm phục vụ internal công ty, thì có 1 phần lớn kết quả công việc sẽ phụ thuộc vào việc triển khai những tính năng/dự án mới

• có đúng thời gian cam kết hay không
• đạt chất lượng hay không
• việc hỗ trợ "bảo hành" sau đó như thế nào

Như vậy họ sẽ được đánh giá dưới góc nhìn của 1 người Project manager hoặc Service manager, còn việc user sử dụng tính năng này và tạo ra giá trị như trong kế hoạch ban đầu hay không thì sẽ được đánh giá riêng.

Cuối cùng, 1 yếu tố quan trọng và cũng cần thiết khi đánh giá những bạn Product có lead team là họ có xây dựng được 1 team mạnh hay không. Team mạnh định nghĩa là có máu lửa, dám thử dám làm, các thành viên cởi mở chia sẻ feedback của mình và cảm thấy được tạo điều kiện làm việc tốt. (1 câu hỏi khác liên quan vấn đề trên, là có nên tách việc quản lí con người ra khỏi vai trò của Product hay không ?)

-- to be updated --