- Những sai lầm thường gặp khi đo lường năng suất của lập trình viên
- Vấn đề khi đo lường đầu vào
- Nếu dựa vào đầu vào hoặc nỗ lực như “thời gian làm việc”, sẽ khuyến khích những hành vi sai lệch
- Ví dụ, nếu văn hóa công ty coi trọng và tưởng thưởng thời gian ngồi trước màn hình, lập trình viên có thể dồn rất nhiều thời gian vào đó nhưng khó đảm bảo chất lượng công việc
- Trong môi trường khắc nghiệt hơn, điều này có thể biến tướng thành cuộc cạnh tranh “ai đến sớm nhất và về muộn nhất”
- Vấn đề khi đo lường kết quả đầu ra
- Những chỉ số tệ nhất như số dòng code hoặc số lượng commit thuộc về nhóm này
- Lập trình viên có thể viết một lượng lớn code rất nhanh, nên việc đo lường này cũng rất dễ
- Mọi chỉ số đầu ra đều phải được hiểu trong bối cảnh cụ thể
- Vấn đề khi đo lường kết quả và tác động
- Thách thức của hai loại chỉ số này là xác định “đội DevOps chịu trách nhiệm đến mức nào”
- Khi đo mức tăng doanh thu kinh doanh, không thể quy hoàn toàn điều đó cho trách nhiệm của riêng lập trình viên
12 bình luận
Đúng là thấy rùng mình thật. Có lẽ sẽ có khác biệt giữa góc nhìn của quản lý và góc nhìn của người làm thực tế,,
Có vẻ đúng là phần cần đến LLM.
Vì đây là bài viết không đưa ra phương án thay thế nên có phần làm nhạt đi ý nghĩa muốn truyền tải. Tôi đồng ý với lập luận rằng nên loại lượng đầu ra khỏi việc đo lường kết quả, nhưng không thể đồng ý với việc loại hoàn toàn thời gian làm việc khỏi đo lường đầu vào vì điều đó không phù hợp với thực tế. Dù sao thì trong quá trình làm lao động tri thức, thời gian vẫn trôi qua, nên tôi cho rằng nhất định phải cân nhắc yếu tố thời gian trong việc ra quyết định.
Tôi nghĩ sẽ dễ hiểu và hiệu quả hơn nếu đo các chỉ số dẫn dắt như
tiến độ tổng thể = (số lượng yêu cầu đã đáp ứng / thời gian làm việc)rồi mới bàn về năng suất của lập trình viên.Gần đây tôi có xu hướng nhìn những bài viết kiểu này một cách khá phê phán, vì tôi nghĩ kết luận mà mọi người cuối cùng rút ra sau khi đọc những bài như vậy là chọn cách không quản lý gì cả. Dù quản lý bằng chỉ số nào thì rốt cuộc cũng có những vấn đề tương tự. Ngoài ra, nếu dùng bất kỳ chỉ số nào cho mục đích cạnh tranh hay so sánh giữa cá nhân hoặc giữa các nhóm thì sẽ phát sinh tác dụng phụ. Vì vậy không nên quản lý chỉ bằng một chỉ số duy nhất; cần quản lý đồng thời các chỉ số có tính bổ trợ lẫn nhau, và tôi nghĩ nên tận dụng các chỉ số đó để giúp đội ngũ tự cải thiện.
Mọi người nghĩ sao về việc đo lường bằng số lượng PR có ý nghĩa, ở mức đơn vị phù hợp, được đưa lên?
Thực tế, ở một tập đoàn lớn trong nước nào đó còn có nơi đo lường thành tích bằng số dòng code đã viết nữa huhu
Haha, tôi cũng từng thấy rồi.
Người đó cứ liên tục đẩy những commit chỉ để đổi tên biến.. haha
Có vẻ là môi trường không có code review nhỉ?
Haha, vì người review code cũng phải được review code mà
Nên mọi người đang hỗ trợ lẫn nhau thôi..
kkkk, trời ơi...
xin chào hell world ;)
Đây có phải là kiểu đo năng suất bằng LOC mà chỉ nghe đồn thôi không, run run run