Measuring Developer Productivity

Đánh giá hiệu quả làm việc của developer không phải là một công việc dễ dàng, luôn có những câu hỏi được đặt ra đại loại như: Làm sao để biết khi nào và ở đâu có vấn đề với năng suất làm việc ? Làm sao để biết một team đang làm việc tệ đi hay tốt hơn theo thời gian? Làm sao để một người quản lý có thể giải thích với cấp trên những developer của mình đang làm việc hiệu quả như nào ? Và còn rất nhiều thắc mắc khác nữa. Lập trình không giống với những ngành nghề khác. Bạn không thể đánh giá nó giống như là đánh giá các quy trình sản xuất, nơi mà có thể đơn giản đếm số lượng sản phẩm đúng quy cách lăn ra từ dây chuyền sản xuất. Vậy làm cách nào có thể đánh giá hiệu quả làm việc của một lập trình viên ?

Bí quyết nằm ở việc đánh giá chính xác định nghĩa thế nào là "năng suất" và chìa khóa đó là chúng ta phải công nhận một điều rằng năng suất gắn liền với sản phẩm. Một người làm việc năng suất là người chế tạo ra những sản phẩm một cách thường xuyên và hiệu quả.

The way to measure the productivity of a developer is to measure the product that they produce.

Một câu nói trên là chưa đủ để có thể giải quyết vấn đề. Hãy cùng đến với một số ví dụ về những thứ mà ta có thể đánh giá và những thứ ta không thể đo lường được.

Có lẽ hình thức đánh giá phổ biến nhất mà ngành công nghiệp phần mềm được xây dựng xung quanh số lượng dòng code(LoC) mà một lập trình viên viết. Số lượng dòng code chính xác là thứ mà ta có thể đo đếm được, một lập trình viên viết nhiều code hơn năng suất hơn phải không?!

“Computer programmer” is not actually a job.

Chúng ta đã xem đến hàng ngàn quảng cáo tuyển dụng cho vị trí "programmer" và trong đó chắc chắn coi lập trình viên như là một công việc (job). Nhưng chúng ta cũng xem các quảng cáo tuyển dụng thợ mộc nữa và thợ mộc thì sản xuất cái gì ? Trừ khi có thêm thông tin, câu trả lời thực sự vẫn còn mơ hồ. Lý thuyết mà nói thợ mộc tạo ra các mảnh gỗ đã được cắt gọt, nhưng đó không phải là một sản phẩm và cũng chẳng ai thuê bạn về để cắt gọt các mảnh gỗ ấy cả. Vì thế, công việc thợ mộc có thể tạo ra các sản phẩm khác nhau tùy theo yêu cầu, có thể là sửa nội thất, xây nhà hoặc làm bàn ghế. Nếu bạn là thợ sửa đồ nội thất, bạn sẽ được đánh giá bởi số lượng nội thất mà bạn sửa. Nếu bán là thợ xây nhà, số phòng bạn hoàn thành sẽ đánh giá năng suất của bạn.

Điểm mấu chốt ở đây chính là "computer programmer", giống như "thợ mộc" là một kỹ năng, không phải là một công việc. Chúng ta đánh giá sản phẩm mà kỹ năng đó tạo ra và hiển nhiên, một phần không thể thiếu của lập trình ngày nay liên quan đến việc gõ bàn phím. Việc đong đếm các dòng code rõ ràng đỡ vô lý hơn là đếm số lượng phím gõ trong một ngày, bởi vì một dòng code là một sản phẩm mà lập trình viên tạo ra - là thứ hoàn chỉnh có thể deliver cho dù có nhỏ đi nữa. Nhưng mặt khác, liệu có thể coi đó là một sản phẩm hoàn chỉnh ? Giả sử một task được ước lượng cần 1000 dòng code và có giá 1000, liệu khách hàng có đồng ý trả 1 cho mỗi dòng code được bàn giao. Không chắc chắn là bạn sẽ chẳng nhận được một xu nào cả.

Điều này là minh bạch nhất: thời gian "mông đặt trên ghế". Nếu bạn làm việc 10h thay vì 8h, bạn sẽ có 125% khối lượng công việc hoàn thành. Đó là toán học. Nhưng hết lần này tới lần khác, các nghiên cứu chỉ ra rằng điều đó không đúng với tất cả mọi người. Thực tế, thêm giờ làm chính là cách tuyệt vời để làm giảm năng suất.

Rất nhiều bằng chứng cho thấy làm việc hơn 40h một tuần dẫn đến tụt giảm năng suất, ngay cả với các công nhân trong các dây chuyền sản xuất. Mặt khác nếu một quản lý quá chú trọng đánh giá hiệu quả dựa vào kiểm tra thời gian sẽ dễ dẫn đến việc các thành viên trong team đẩy thêm thời gian cho meetings, các cuộc trao đổi, lunch break , vv vào trong báo cáo và điều đó dễ dẫn đến những cáo buộc về làm việc chưa đủ chăm chỉ hay trung thực. Nó không chỉ phá hủy đạo đức của team mà còn gây nghi ngờ lẫn nhau, niềm tin suy giảm.

Nghe có vẻ điên rồ nhưng không hề vô lý

Bug có thể được sinh ra từ code của bản thân hoặc của người khác và bất cứ lúc nào, sửa lỗi của chính mình hay cho người khác luôn được đánh giá cao.

Ý tưởng của việc này là đánh giá số lượng defect (nguyên nhân gây bug) mà mỗi lập trình viên tạo ra. Nghe có vẻ hợp lý và bạn có lẽ nên theo dõi nó, nhưng đây là một số lý do khiến nó là một phương thức đánh giá không phù hợp khi áp dụng:

• Nó ủng hộ việc fix bug hơn là phát triển các chức năng
• Nó làm nản lòng các lập trình viên khi muốn tham gia vào các dự án lớn hơn. Bạn sẽ muốn tham gia vào dự án nào: "thêm một form field vào một trang có sẵn" hay "phát triển một hệ thống phân tích log thời gian thực" ?
• Không phải mọi bug được tạo ra giống nhau:
  • Bug 1: Khi ai đó sử dụng nút "back", tất cả dữ liệu của người dùng bị xóa sạch trên môi trường production
  • Bug 2: Form field bị lệch
  • Bug 3: Nếu người dùng nhập vào năm nhuận, thời gian bị trừ đi 1s.
• Con người thường ngộ nhận chức năng là bug. Thiếu requirement không phải là bug, nhưng lại thường bị coi là như vậy.
• Có rất nhiều bug được báo cáo, có cùng nguyên nhân từ một bug khác.
• Lập trình viên sẽ không bao giờ động vào code của người khác, và tỏ ra hung hăng khi bảo vệ code của mình.

Story point được giải thích như là một phương thức để đánh giá hiệu quả và rủi ro. Nếu chúng ta có story point nhất quán, và tìm ra được mỗi lập trình viên hoàn thành bao nhiêu story point mỗi sprint, chúng ta có thể suy ra được năng suất của lập trình viên đó. Hãy xem điều gì xảy ra:

• Nếu bạn hoàn thành story point ít hơn sprint trước, bạn sẽ bị chỉ trích. Và bạn sẽ được một lần nữa nhắc lại về những gì bạn đã commit, cho dù điều gì đã xảy ra. Bạn đã giúp sửa một lỗi trên production, ốm đau, ..-- nhưng bạn đã commit.
• Nếu bạn hoàn thành chính xác, quản lý sẽ nghĩ rằng bạn hoàn thành sớm và đang ngồi nghỉ ngơi, hoặc đang nhét thêm vào estimate cho đủ. Điều đó dễ dẫn đến mất đoàn kết nội bộ. Một kết thúc hoàn hảo là có thể được xem như là trạng thái, nếu mọi người làm việc thêm vài giờ, chúng ta sẽ thấy thêm output.
• Nếu bạn hoàn thành nhiều point hơn, điều đó đồng nghĩa bạn sẽ phải commit nhiều point hơn vào sprint sau và đó là quá trình không bao giờ kết thúc. Nếu một quản lý yêu cầu năng suất gấp đôi, đơn giản, gấp đôi story point estimate Story point cũng không đồng nhất giữa các lập trình viên. Ngay cả khi mọi người đồng ý một task là 3 story point, dựa trên cố gắng và rủi ro, thời gian deliver vẫn khác nhau dựa trên ai là người làm. Một lập trình viên người quen thuộc với code có thể hoàn thành nó trong 2-3h, trong khi một new dev có thể vật lộn trong 1-2 ngày. Đó là bằng chứng cho thấy chúng ta đã tách rời năng suất khỏi point, và đó là lý do tại sao nó là hệ quy chiếu không phù hợp.

Gần như ở bất kì công ty nào, estimation là commitment. Nếu bạn nói "việc này làm trong 3 ngày", bạn sẽ gặp rắc rối nếu nó mất hơn 3 ngày. Mặt khác nếu bạn hoàn thành nó trước hạn định, bạn được khen ngợi. Điều đó khuyến khích lập trình viên có khuynh hướng estimate công việc trong trường hợp xấu nhất có thể. Bên cạnh đó, phương pháp này cũng tồn tại một số vấn đề:

• Nếu estimate với số giờ lý tưởng, những sự xao lãng không ngờ tới có thể biến một task 8h thành 3 ngày.
• Developer có thể quá lạc quan hoặc không nhất quán về estimate của bản thân.
• Pham vi scope không được định nghĩa hoặc đánh giá đầy đủ
• Khách hàng đòi hỏi những thứ bất khả thi, chỉ được phát hiện ra trong quá trình code

Lập trình viên không phải là người duy nhất ảnh hưởng tới thước đo để đánh giá sản phẩm của chính họ. Những nguời khác tham gia vào hệ thống ví như nhân viên sale có thể tác động đến hiệu quả của một phần mềm kế toán, bao nhiêu thuế được hoàn trả đúng hay được nộp đầy đủ bởi các cá nhân ... Tuy nhiên trách nhiệm chính vẫn thuộc về các lập trình viên, cho việc các tác vụ thực tế được hoàn thành dễ dàng và thành công ra sao. Hay cùng xem xét một website bán hàng. Một lập trình viên backend sẽ đánh giá vài thứ như số lượng request dữ liệu thành công, trong khí lập trình viên front end lại quan tâm đến bao nhiêu sản phẩm được thêm vào giỏ hàng thành công, bao nhiêu người dùng checkout thành công mỗi ngày. Giống như là một nghịch lý với các thước đo trên, phần lớn các lập trình viên đều cảm thấy dễ dàng để nhìn ra xung quanh họ ai là người đang làm tốt và chưa tốt. Dường như có điều gì đó mách bảo bạn rằng anh lập trình viên kia đang làm tốt hơn mình. Nó có thể là cách anh ta chia sẻ về công nghệ của mình, những suy nghĩ, hoặc cách anh ta trả lời các vấn đề. Hầu hết các lập trình viên sẽ sẵn lòng hy sinh thân mình để được làm việc với một cộng sự yêu thích. Với các quản lý, nếu bạn đang có một lập trình bạn yêu quý và tin tưởng, thì hãy tin tưởng cả cộng sự của anh ta nữa.

http://dev9.com/article/2015/1/the-myth-of-developer-productivity http://www.codesimplicity.com/post/measuring-developer-productivity/