Lập trình viên tệ nhất mà tôi biết (2023)

• Bài viết này giải thích việc cố gắng đo lường năng suất của cả nhóm đã thất bại như thế nào
• Đã quyết định áp dụng chỉ số hiệu suất cá nhân cho mục đích đánh giá và phát triển
  • Loại trừ số dòng mã hoặc số lượng bug vì khả năng bị thao túng cao, thay vào đó quyết định đo hiệu suất bằng story point hoặc số lượng story đã bàn giao

Hiệu suất của Tim Mackinnon là ‘0’

• Đo hiệu suất của tất cả thành viên trong nhóm thông qua các công cụ đo năng suất của nhóm (Jira, v.v.)
• Điểm hiệu suất của Tim là 0 → vì anh không ghi nhận bất kỳ story point nào
• Quản lý yêu cầu thay Tim vì hiệu suất của Tim là 0

Vì sao Tim Mackinnon không tạo ra hiệu suất

• Tim không trực tiếp phụ trách story nào
• Thay vào đó, anh tập trung vào pair programming với các thành viên trong nhóm
  • Làm việc cùng các lập trình viên ít kinh nghiệm hơn và dẫn dắt họ giải quyết vấn đề
  • Không tự mình giải quyết mà giúp họ rút ra lời giải thông qua các câu hỏi
  • Với các lập trình viên senior, anh cùng họ suy nghĩ về vấn đề và cải thiện giải pháp
• Tim không trực tiếp viết code, nhưng đã cải thiện hiệu suất tổng thể của cả nhóm

Đóng góp thực sự của Tim Mackinnon

• Không thể đo đóng góp của Tim bằng điểm hiệu suất cá nhân
• Nhờ Tim mà năng suất của cả nhóm và chất lượng code đều được cải thiện
• Khi làm việc cùng Tim, mọi người có thể đạt được kết quả nhanh hơn và tốt hơn

Chuyển sang cách đánh giá theo năng suất của nhóm

• Đã giải thích mức độ đóng góp của Tim cho quản lý và tạo cơ hội để quan sát
• Sau khi xác nhận hiệu suất của cả nhóm được cải thiện, họ từ bỏ cách đo hiệu suất cá nhân
• Chuyển sang cách đánh giá dựa trên hiệu suất của nhóm và tác động kinh doanh thay vì hiệu suất cá nhân

Tóm tắt (tl;dr)

• Nên đo năng suất bằng kết quả kinh doanh (ví dụ: tiết kiệm chi phí, tạo doanh thu, v.v.)
• Trong các hệ thống phức tạp, việc đo hiệu suất cá nhân không có ý nghĩa
• DORA Metrics và các chỉ số tương tự là công cụ đo hiệu suất hệ thống, không phải công cụ đo mức độ đóng góp của từng cá nhân
• Nếu có cơ hội làm việc cùng Tim Mackinnon, đừng bỏ lỡ

[bus710]

Thật ra, khi vượt qua mức senior và lên cỡ staff engineer, bạn sẽ ngày càng xa hơn với phần code thực sự được triển khai ngoài môi trường vận hành.... Thay vào đó, có vẻ như sẽ làm nhiều việc coaching hơn cho các bạn senior/junior. Cũng phải nghe các manager than thở nữa.... Khi có sự cố thì bị gọi khắp nơi để đưa ra giải pháp....

Công việc kiểu như vậy nên cũng không thể định lượng bằng ticket Jira và điểm số được.

[castedice]

Với vai trò tech lead, tôi làm những việc như thế này khá nhiều. Việc thử định lượng dựa trên story point cũng tương tự, nhưng may là công ty chưa lớn nên các thành viên, bao gồm cả ban điều hành, đều nhận thức được tôi đang đảm nhiệm vai trò gì, nên có vẻ trước mắt chưa phát sinh vấn đề nào.
Khi tổ chức lớn hơn, chắc tôi cũng sẽ phải suy nghĩ về các phương pháp định lượng.

[kallare]

Cứ thấy như là câu chuyện mình đã từng đọc ở đâu rồi.. hóa ra là bài viết từ năm 2023
Hình như bài y hệt này cũng đã được đăng lên 2 năm trước rồi https://vi.news.hada.io/topic?id=10680

[crawler]

Đúng là kiểu như GitHub Copilot vậy đó....

[GN⁺]

Ý kiến trên Hacker News

• Việc đo năng suất của từng lập trình viên là vô lý. Đo bằng số dòng code hay story point là đi ngược lại năng suất. Điều quan trọng là lập trình viên tạo ra nhiều giá trị hơn với ít code hơn

  • Đo kết quả kinh doanh là quan trọng, nhưng khó quy cho một lập trình viên cụ thể
  • Cuối cùng, tốt hơn là thừa nhận rằng không thể tránh khỏi việc phải dựa vào đánh giá chủ quan

• Đã tìm ra cách giải quyết vấn đề bằng cách gắn tên Tim vào ticket. Các thành viên trong nhóm sẽ sẵn sàng hỗ trợ

  • Các chỉ số năng suất không hoàn toàn vô giá trị. Nhìn vào tỷ lệ giữa PR và ticket Jira trong nhóm, có thể đoán ra người dẫn dắt đội

• Thật vui vì Tim vẫn ở lại nhóm và dẫn dắt quy trình theo đúng hướng. Cần những quản lý biết lắng nghe

  • OKR khiến các lập trình viên bị cô lập. OKR dựa trên cá nhân thay vì dựa trên nhóm sẽ gây ra vấn đề
  • Việc giải quyết vấn đề mất nhiều thời gian. Vì OKR nên không thể nhận được sự hỗ trợ

• Mô hình một lập trình viên chỉ đi hỗ trợ mọi người mà không có công việc cá nhân là không bình thường

  • Sẽ lành mạnh hơn nếu Tim cũng làm story như những người khác và chỉ nhờ nhóm khi cần giúp đỡ
  • Nếu đội quá mất cân bằng thì Tim nên đảm nhận vai trò mentor

• Việc Tim không làm việc cá nhân là điều kỳ lạ. Để tối đa hóa năng suất của nhóm, cần cân bằng giữa đóng góp cá nhân và hợp tác trong nhóm

  • Có thể Tim đã quá kiên nhẫn nên lãng phí thời gian

• Nếu Tim không đóng góp trực tiếp cho nhóm, tôi sẽ bảo anh ấy bắt tay vào việc và giao story. Việc Tim giúp người khác là tốt, nhưng anh ấy cũng phải làm phần việc của mình

• Không phải mọi thứ đều cần trở thành hoạt động nhóm. Nếu một lập trình viên mức trung bình không thể giao tính năng mà không cần Tim hỗ trợ liên tục thì đội đang có vấn đề

  • Phát triển phần mềm cần thời gian cho cả công việc cá nhân lẫn công việc nhóm

• Những đội tốt nhất luôn có một người như Tim. Sự hỗ trợ của Tim lan tỏa sang những người khác, giúp cả đội cùng trưởng thành

  • Khi lập trình viên bị mắc lại, họ nên tự cố gắng giải quyết trước rồi mới nhờ hỗ trợ khi cần

• Việc đo năng suất lập trình viên bằng story point là không tốt. Có một lập trình viên tên Zero không được giao story nào mà chỉ hỗ trợ cả nhóm

  • Quản lý hiểu tầm quan trọng của Zero. Thậm chí họ còn hoãn những đợt phát hành quan trọng khi Zero vắng mặt

• Rất khó định lượng giá trị của việc hỗ trợ. Nhưng hỗ trợ là thiết yếu. Cần tin tưởng các lãnh đạo sẽ đưa ra đánh giá đúng đắn