Measuring Difficulty

It's difficult to measure difficulty

Tại sao?

Bạn đã bao giờ bị nhà tuyển dụng yêu cầu mô tả project khó nhất từng làm chưa? Hay đau đầu khi viết review mỗi mùa đánh giá hiệu suất cuối năm?

Trong ngành phần mềm, hiệu suất công việc thường được đánh giá dựa trên hai yếu tố: Độ khó (Difficulty) của công việc và Tác động (Impact) của công việc đó mang tại. Đây là 2 tiêu chí quan trọng mà nhiều công ty công nghệ sử dụng để đưa ra quyết định tuyển dụng hay thăng tiến.

Việc đo lường Tác động thường khá rõ ràng. Chúng ta có thể định lượng bằng những con số cụ thể. Ví dụ:

• project A đã giúp giảm 30% độ trễ p99 của API X.

• project B đã giúp công ty tiết kiệm $YY.

• project C đã giảm thời gian onboard khách hàng mới từ Z ngày xuống 1h.

Tuy nhiên, việc đánh giá Mức độ khó lại phức tạp hơn nhiều. Lí do là vì không có một “đơn vị đo lường” chuẩn nào cho sự khó khăn cả. Trong bài viết này, tôi sẽ chia sẻ một vài cách để “đo lường gián tiếp” mức độ khó của công việc.

Như thế nào?

1. Mức độ khó theo thời gian thực hiện:

   • “Project này mất 3 tháng để thực hiện.”

2. Mức độ khó theo quy mô code:

   • “Tôi đã refactor 7749 dòng code PHP 10 năm tuổi”

   • “Project ban đầu bao gồm 4 ngôn ngữ khác nhau và đã không ai maintain nó trong 2 năm vừa qua.”

3. Mức độ khó theo kiến thức cần học:

   • “Project này dùng Kotlin và trong team không ai biết Kotlin cả, tôi đã phải tự học từ đầu”.

4. Mức độ khó theo số lượng người/ team tham gia:

   • “Project này cần sự phối hợp của 8 SWE từ 3 văn phòng, cách nhau 2 múi giờ.”

   • “Design doc của project được thảo luận tích cực từ 10 reviewer.”

   • “Design doc được sign-off bởi đại diện của 3 teams: X, Y và Z.”

5. Mức độ khó so với project tương tự:

   • “Project này đã từng được xem xét nhưng tech lead cũ đánh giá rằng nó quá khó để thực hiện. Bằng chứng đây: <design doc link>”.

   • “Project này có scope tương tự dự án X, X được lead với Staff Engineer Y, yêu cầu Z SWE trong T tháng”.

6. Mức độ khó theo số lượng lựa chọn:

   • “Có X ứng viên cho hạ tầng (ví dụ database, framework), tôi đã đánh giá và đưa ra Y quyết định design lớn”.

7. Mức độ khó theo tần suất thay đổi của requirement:

   • “Yêu cầu từ biz team thay đổi mỗi ngày, có tổng cộng X feature request mới trong suốt quá trình thực hiện dự án.”

8. Mức độ khó theo hậu quả nếu dự án thất bại:

   • "Project này là tính năng cốt lõi, bất kỳ lỗi nào cũng có thể gây thiệt hại $XX."

Hi vọng sẽ hữu ích khi bạn muốn giải thích cho sếp hoặc interviewer tại sao project của mình lại khó đến vậy 😀.

Ngoài lề

Tháng 6 vừa rồi đánh dấu năm thứ 3 của tôi tại Google, note lại vài con số thú vị:

• làm việc tại 3 office.

• submit 623 pull request (~1 shot/ngày 😀).

• fix 467 bug.

• 9 peer bonus và 5 spot bonus.