Việc đánh giá các Dev rất quan trọng với những ai muốn tham gia làm phát triển phần mềm. Nhiều Dev rất quan tâm đến thăng tiến hoặc ít nhất là tăng lương. Vì vậy, các Manager cần có những quyết định về chế độ đãi ngộ và tăng lương.

 

Hợp lý nhất là các Dev nên được thưởng dựa trên tổng giá trị mà họ làm được cho một doanh nghiệp. Khá đơn giản: bạn càng tạo lợi nhuận cho công ty nhiều hơn, công ty sẽ trả cho bạn nhiều tiền hơn.

Thực tế, phức tạp ở chỗ bản chất của phát triển phần mềm lại không dễ tính được giá trị mà Dev có thể mang lại. Nếu bạn có sản phẩm với hàng trăm tính năng và kiếm được 10 triệu $ một năm, làm sao bạn biết mỗi tính năng kiếm được bao nhiêu tiền? Giả sử bạn có thể làm được điều đó thì khả năng nhiều Dev sẽ làm được tính năng này. Vậy làm sao để bạn tính được hiệu quả của mỗi tính năng?

Hoàn toàn không có câu trả lời nào cho câu hỏi đó. Chỉ là hơi xa thực tế khi cố gắng thực hiện các phép tính này. Phần còn lại thuộc về những phán đoán chủ quan của Manager mà thôi.

Phương pháp này vẫn tiềm ẩn các tiêu chuẩn mơ hồ đối với Dev. Họ có thể không hiểu rõ suy nghĩ của người quản lý. Hiện nay có một xu hướng là tập trung vào học cách quảng bá bản thân tới Manager thay vì tập trung vào việc cố trở thành một Dev tốt hơn.

Một giải pháp thích hợp cho vấn đề này là các chỉ số định lượng. Nếu chúng ta không tính được chính xác các giá trị mà một Dev có thể mang lại cho công ty, chúng ta có thể tìm thấy một giải pháp thay thế để đo lường dễ dàng hơn, ví như là một chỉ số hay những giá trị?

Cách đơn giản nhất ở đay là đếm số dòng mã một Dev viết ra. Cách này hoàn toàn đơn giản với những người không chuyên, thậm chí lần đầu đều có thể làm được. Các Dev viết mã ... vậy thì, nhiều code thì có năng suất hơn không?
Vấn đề ở đây là code "xịn" chính là dòng code ngắn. Một ví dụ rất đơn giản: Giả sử bạn muốn đăng 100 sản phẩm trên website của mình. Bạn có thể làm như sau:

displayProduct(1)

displayProduct(2)

displayProduct(3)

….97 lines later…

displayProduct(100)

100 Sản phẩm, 100 dòng code!

Không có Dev nào làm như vậy.

Thay vào đó họ sẽ viết 2 dòng mã:

 

for productNumber = 1, productNumber <= 100, productNumber++:

   displayProduct(productNumber)

 

Nếu bạn trả tiền dựa trên số dòng code, bạn có thể sẽ phải thưởng cho các Dev làm việc không hiệu quả.

Tương tự như viết tiểu luận, tiểu thuyết, viết blog, vv, bạn có đánh giá một nhà văn viết hay chỉ vì số lượng chữ không? Chắc chắn không. Cần một lượng từ tối thiểu cho những từ khóa chính, nhưng sẽ không có gì hay ho khi một nhà văn cố gắng chèn thêm những câu vô bổ. Tôi biết vì tôi đã từng đọc những bài tiểu luận dài 3 trang nhưng rốt cuộc nội dung rất nghèo nàn.

Vì vậy, số dòng mã không quan trọng, quan trọng là chỉ số định lượng để đánh giá các Dev.

Vài lập luận cho rằng việc tạo nhiều nhánh code đang là ưu điểm của một Dev tốt. Tuy nhiên, tôi từng làm việc với một Dev tạo ra nhánh code để giấu đi khả năng làm việc không hiệu quả.

Một số khác lại cho rằng bạn có thể đo số lượng code commit mà Dev làm. Nhưng điều đó chỉ khiến Dev cố gắng có nhiều commit mà có rất ít code hoặc không có gì bên trong. Hoặc một Dev có thể mạo hiểm bằng cách undo và redo vài thay đổi nhỏ rồi nộp lại tổng lượng commit.

Có lẽ lượng bugfix là câu trả lời? Dù sao thì bug trong phần mềm khá phức tạp. Bằng cách buộc tăng lương và chế độ đãi ngộ cho việc fix bug, bạn khích lệ các Dev để khắc phục các vấn đề trước mắt trong khi lờ đi nguyên nhân bên trong. Giống như dùng băng keo để dán vào chân bị gãy. Trường hợp xấu nhất, bạn có thể sẽ thưởng cho những Dev không chủ động fix bug.

Vấn đề thực sự trong số liệu định lượng là người ta thay đổi đãi ngộ đối với Dev. Trong khi mục tiêu là tạo ra giá trị kinh doanh, nhưng có thể khó thấy họ đang tạo ra giá trị lao động. Sẽ dễ hơn nhiều nếu chỉ tối ưu hóa các số liệu định lượng bất kể chúng có hiệu quả hay không. Một ước muốn khá xa vời.

Tuy nhiên vẫn tồn tại câu hỏi đầy thách thức: làm sao biết một Dev đang làm việc hiệu quả?

Theo tôi, những biện pháp tốt nhất cõ thể trả lời những câu hỏi sau:


Họ là thành viên tốt trong nhóm?
Họ có thể giải quyết vấn đề?
Họ có khả năng viết mã tốt?
Họ mong muốn tìm tòi học hỏi?
Bạn có thể tin tưởng họ?


Còn nhiều lắm, nhưng vấn đề là tiêu chuẩn cho một Dev tốt là chất lượng công việc. Điều này đòi hỏi các Manager cần tương tác thường xuyên hơn với Dev để hiểu họ. Manager phải tạo ra văn hóa thưởng phạt để các Dev biết rằng sẽ được thưởng vì làm việc hiệu quả, chứ không phải chỉ là làm đúng việc.
Các biện pháp định lượng đều được đánh giá cao vì dễ thực hiện. Nhưng không có việc quản lý nào dễ dàng. Nếu mà dễ thì ai cũng làm được mất.

 
Source: Beekums

Related