Đâu mới là cách đo lường được hiệu quả công việc của một lập trình viên

Lập trình là một công việc sử dụng chất xám, cũng như một vài ngành đặc thù nó dường như khó có thể đo lường được thế nào là hiệu quả. Những câu hỏi đặt ra cho những người quản lý lại càng trở nên khó khăn, làm thế nào để biết được một anh lập trình viên X có hiệu quả công việc tốt, productivity cao trong dự án. Bài viết này cùng mình thử bàn luận về vấn đề này xem!

Trong phát triển phần mềm hay một số ngách nhỏ khác trong lĩnh vực công nghệ thông tin, chúng ta thường đánh giá hiệu quả công việc dựa vào inputs và outputs, tức ra một người nhận khối lượng đầu vào thế nào và kết quả công việc đó ra sao. Đôi khi chúng ta lại đánh giá thông qua mức lương, level hay thời gian làm việc của một lập trình viên để cho rằng anh ta làm việc hiệu quả hay không. Mức lương và số giờ làm việc cũng có thể coi là inputs có thể dễ dàng nhìn thấy được hay số lượng bugs được xử lý, sản phẩm được bàn giao, tài liệu và tính năng được hoàn thiện, nó cũng có thể coi là outputs của một lập trình viên.

Nếu bạn còn học là học sinh sinh viên thì có lẽ điểm số chính là thứ đánh giá năng lực hiệu quả học tập của bạn, nhưng khi đi làm thì mình thấy những con số kia lại biến thành những con số KPI chỉ tiêu đo lường hiệu suất làm việc. Liệu rằng những con số đó đã đủ để đánh giá năng lực của một lập trình viên hay không?

Mình nghĩ là không!

Mỗi công ty đều có những thang đo đánh giá năng lực khác nhau, nó có thể đánh giá đúng hoặc không năng lực làm việc của mỗi người, điều đó lại có nhiều quan điểm khác nhau với những nhân viên và vị trí khác nhau.

Mình không đưa ra cách đánh giá cụ thể nào là đúng hay sai nhưng ý kiến cá nhân của mình thì đối với lập trình viên, người tạo ra những sản phẩm phần mềm thì KHÔNG thể đo lường hiệu quả làm việc dựa trên những tiêu chí sau:

1. Thông qua số lượng dòng code (Lines of code)

Bạn đã từng tị nạnh so đo với ai đó là tôi code được nhiều, bạn code được ít chưa? Vấn đề số lượng dòng code không đánh giá được hiệu suất làm việc, đôi khi giải quyết một vấn đề phức tạp chỉ đơn thuần là xóa bớt code đi. Vậy bạn có còn so sánh ai hơn ai qua số lượng dòng code nữa không.

Phần mềm sinh ra để giải quyết vấn đề, nó không dựa vào số lượng mã nguồn bạn viết ra, gần đây có những công nghệ mà bạn chẳng phải code một dòng nào mà vẫn phát triển ra một sản phẩm chất lượng đó thôi.

Một số ít team leader hay project manager lại thường hay nhìn vào số lượng code của một lập trình viên có thể viết ra trong một khoảng thời gian nào đó để đánh giá hiệu suất lằm việc của họ, điều này e rằng khiến nhân viên đó sẽ bị thiệt thòi và khó lòng giữ chân được nhân viên.

2. Số giờ làm việc (Hours worked)

Điều này cũng xảy ra nhất nhiều và rất hiện hữu, thời gian làm việc luôn bị đánh đồng với hiệu suất làm việc. Một ngày 8 tiếng nếu sếp bạn thấy bạn ngồi làm việc lâu hơn chút, làm thêm giờ mà dân gian gọi là OT thì lại cho rằng anh ta làm việc năng suất. Thật buồn cười rằng đa số những người có năng lực tốt hiệu quả làm việc và năng suất làm việc giải quyết vấn đề của họ lại có thời gian ít đi. Vậy nên lấy thời gian làm việc ra để đong đếm dường như là một thứ gì đó thiếu khách quan nhưng lại rất hay được các sếp nhìn vào. Mình cũng chẳng hiểu lý do nữa.

3. Số lỗi được xử lý (Bugs fixed)

Có một sự thật rằng, ngoài số lượng công việc (tasks) ra thì chất lượng của một tính năng hay một sản phẩm là điều chắc chắn phải đưa lên bàn cân. Nhưng điều này không có nghĩa số lượng bug tỉ lệ thuận với chất lượng tệ, những bạn nào làm trong quá trình bảo trì sản phẩm hay phát triển mở rộng cho một sản phẩm cũ cách đây chục năm thì hiểu rõ. Và điều nữa là không phải ai fixed được nhiều bug nhất cũng được lên bảng phong thần “Dũng sĩ diệt bug”. Vậy nên đừng đưa ra số lượng những con bugs mà đánh giá hiệu suất làm việc. Mình đã từng ngồi cả tuần chỉ để fixed 1 con bug, hay cũng đã từng 1 ngày fixed mấy chục con cũng có. Vậy mình được đánh giá là tốt hay tồi đây 😞

4. Số lượng đầu việc được hoàn thành (Tasks completed)

Trước kia mình hay nghĩ rằng cứ làm được nhiều task thì được coi là hiệu quả, nhưng dần dần mình nhận ra rằng quan điểm đó không hoàn toàn đúng. Mỗi task có độ phức tạp và thời gian xử lý cho task đó khác nhau. Việc dựa trên số lượng đầu việc như vậy không hẳn đánh giá được hiệu suất, đôi khi còn chất lượng đầu ra của task đó nữa, xong nhanh, xong nhiều nhưng mà lại không đạt chất lượng thì hẳn có được tính là hiệu quả.

Vậy đâu mới là cách đo lường được hiệu quả công việc của một lập trình viên?

Thật sự rất khó để tìm ra được các tiêu chí để đánh giá đúng cả, đôi khi nó còn phụ thuộc vào dự án, khách hàng, và những hoàn cảnh giải quyết vấn đề khác nhau nữa.

Với cá nhân mình thì mình thấy một số outputs sau có thể cân nhắc đưa vào chỉ tiêu đánh giá được.

1. Tài liệu được tạo ra

Tài liệu của một phần mềm là một phần cũng khá quan trọng đi đôi với việc bàn giao sản phẩm, Một lập trình viên là một người xây dựng nên một hệ thống, mà họ dành thời gian đển ghi lại những tài liệu liên quan trong quá trình họ xây dựng, đồng nghĩa với việc họ rất hiểu về sản phẩm họ làm ra, cùng với sự tự tin này họ có thể nắm rất chắc nghiệp vụ của dự án khiến họ được đánh giá rất cao.

2. Số tính năng bàn giao thành công (Closed tickets)

Bên trên thì mình nhận xét rằng không nên đánh giá chỉ trên số lượng đầu việc, nhưng vấn đề là bạn nên hiểu rằng mục đích cuối cùng của sản phẩm chính là những tính năng bàn giao được cho khách hàng đã thông qua các gate kiểm thử của nhiều bên. Khi này tính năng (tickets) đó sẽ được coi là hoàn thành (closed). Tickets thì được tạo và định nghĩa ngay từ ban đầu và được duyệt và thẩm định từ bên khách hàng, vậy nên độ phức tạp cũng như thời gian làm cho mỗi ticket sẽ được thông qua, do vậy số lượng tickets bàn giao được đồng nghĩa với hiệu quả của team sẽ đi lên. Nó khác với tasks, có thể tạo ra trong quá trình làm việc, mình cũng từng gặp nhiều người cứ tạo hàng loạt task không đâu vào đâu chỉ để lấy số lượng report với khách hàng sau đó thì cứ tính theo đầu task nói rằng mình làm việc hiệu quả. Thực sự thì tính năng không hề được hoàn thành mà số task cứ đội lên để lấy kết quả report. Vậy nên với mình thì chỉ tiêu đúng phải là closed tickets chứ không phải completed tasks.

3. Code đã qua reviews

Số lượng dòng code thì khó có thể đánh giá hiệu suất, tính năng chạy được cũng chỉ đánh giá được một phần hoàn thiện. Code reviews chính là của ải mà giúp lập trình viên thẩm định được chất lượng code của mình. Nhiều khi không phải chỉ để tính năng đó chạy là xong, mà nó còn liên quan đến cách tổ chức, kiến trúc hệ thống, thuật toán xử lý, độ phực tạp hay tốc độ thực thi của tính năng đó nữa. Vậy nên để đánh giá được chất lượng mã nguồn thì phải qua nhiều gate reviews code mới có thể đảm bảo được. Tất nhiên trình độ và cách review của mỗi reviewers khác nhau nhưng để qua được tất cả các gate thì thật sự code của bạn cũng đã được phần nào đánh giá là ổn. Khi số lượng comment giảm dần qua mỗi gate thì đồng nghĩa với việc bạn sẽ được họ đánh giá tốt hơn về mặt hiệu quả làm việc. Vậy nên theo mình thì có thể xem đây là một tiêu chí đánh giá lập trình viên khá khách quan.

4. Quá trình vận hành bàn giao

Dù sao đi chăng nữa thì sản phẩm là output quan trọng nhất của phát triển phần mềm. Chính xác hơn nữa là khi sản phẩm được chạy thực tế, launching production và bàn giao thành công cho khách hàng. Chính những feedback của khách hàng và thành quả sau cùng sẽ là thứ đánh giá các thành viên trong team. Dù mọi người đánh giá rất cao một lập trình viên A nhưng dự án anh ta làm fail, khách hàng không hài lòng, phá bỏ hợp đồng thuê làm sản phẩm, vậy người lập trình A kia sẽ bị đánh giá như nào. Đổi lại, một dự án thành công xuất sắc đem về rất nhiều lợi nhuận thì chắc hẳn các tiêu chí đánh giá khác cũng sẽ được đánh giá với sự châm chước nhất định. 

Tóm lại thì có rất nhiều thước đo cho hiệu quả của một lập trình viên, và mỗi công ty sẽ có những thang đo khác nhau và dựa trong từng giai đoạn, vị trí, hoàn cảnh, dự án. Thật sự rất khó có thể đánh giá được dựa trên một hai tiêu chí, mà nó cần phải sự tổng hòa giữa tất cả các tiêu chí trên. Dù chủ quan hay khách quan thế nào thì nó cũng có thể đâu đó hiện diện ở ngoài chốn công sở kia. 

Vậy nên trên đây chỉ là những quan điểm cá nhân của mình về vấn đề tiêu chí đánh giá một lập trình viên làm việc hiệu quả hay không?

Còn bạn bạn có ý kiến nào nữa không? Bạn có thể góp ý thêm giúp mình dưới phần bình luận nhé!

#ntechdevelopers