Cách đo đạc hiệu suất làm việc của một product team (Phần 1)
Dora, Space, Engineering Metrics, Devlake
Ngày thứ 8 của tháng “adventofsharing” trên Slack cộng đồng WeBuild có bài viết giới thiệu về chủ đề “Developer Productivity”. Nhân tiện tôi cũng đang hỗ trợ dựng lên một hệ thống phục vụ nhu cầu tương tự, nên sẽ viết thêm để bổ sung ý cho bài viết đó. Dưới đây là bài viết gốc.
#adventofsharing Bàn về developer productivity
Năng suất lao động (productivity) luôn là một chủ đề được quan tâm. Từ thời tiền sử sống trong xã hội bầy đàn, tiến lên xã hội hiện đại với cách mạng công nghiệp; rồi gần đây hơn là thời đại của máy tính, internet, block chen, AI,... loài người luôn ám ảnh với việc làm được nhiều hơn, sản xuất nhiều hơn, nhanh hơn. Ngành phần mềm cũng không phải ngoại lệ. Vậy productivity trong ngành phần mềm được định nghĩa như thế nào? Câu hỏi nghe đơn giản nhưng câu trả lời lại khá phức tạp. Một research gần đây [1] tại Microsoft cho thấy developer có xu hướng nghĩ về input: số bug/task đã hoàn thành, số lượng commit, thời gian tập trung cho deep work, thời gian teamwork khi được hỏi về productivity. Trong khi các manager có xu hướng tập trung vào output như performance, velocity, cũng như chất lượng của sản phẩm được tạo ra. Và nếu bạn hỏi những người ở vị trí non-tech như CEO, CFO, khả năng cao họ chỉ quan tâm team phần mềm làm được ra bao nhiêu tiền và đốt bao nhiêu vào quỹ lương.
Như rất nhiều thứ khác trong ngành phần mềm, it depends. Sẽ không thể tìm được một câu trả lời chung nào cho định nghĩa về productivity để áp dụng cho tất cả các team. Vậy thì các công ty phần mềm lớn nhỏ ngoài kia họ đang làm thế nào để đo lường productivity, hãy điểm qua một số cách thông thường.Cách thứ nhất: không làm gì cả. Nghe có vẻ hơi anti-pattern, nhưng khá phổ biến ở các team nhỏ, ở những team này manager có thể nắm khá rõ về khối lượng công việc cũng như output của từng thành viên, cũng như của cả team, việc cụ thể hóa thành con số không có nghĩa lý và ít mang lại hiệu quả. Cách thứ hai: vậy team lớn thì họ dùng gì, hiện tại trong giới có hai tiêu chuẩn khá nổi là DORA [2] và SPACE [3]. DORA đề ra bốn metric cho một engineering team, focus chính vào việc delivery phần mềm.
Deployment Frequency – tần suất release lên production.
Lead Time for Changes – thời gian dành ra từ khi bắt đầu đến khi release của ticket.
Change Failure Rate – tỉ lệ các release tạo lỗi trên production.
Time to Restore Service – thời gian để fix production khi có release lỗi.
Trong khi SPACE đề ra năm tiêu chí:
Satisfaction and wellbeing: mức độ hạnh phúc và thỏa mãn của các thành viên trong team.
Performance: chất lượng đầu ra của sản phẩm.
Activity: số lượng output/task hoàn thành.
Communication and collaboration: mức độ teamwork và collab giữa các thành viên trong team.
Efficiency and flow: thời gian focus vào deep work của team.
Điểm cộng của DORA là các metric được định nghĩa rõ ràng, điểm trừ là tập trung quá nhiều vào việc delivery và hoàn toàn bỏ qua yếu tố con người. Team của mình hiện tại cũng đang dùng DORA và tác dụng khá hạn chế, khó nêu được điểm yếu cần cải thiện, và các metric khá dễ bị game, có thể dẫn đến phản tác dụng.
SPACE được ra đời để khắc phục nhược điểm của DORA, đề cao input và yếu tố con người, nhấn mạnh việc lấy survey từ các thành viên trong team, nhưng nhược điểm lại là các metric phức tạp, mơ hồ và cũng khó đo đạc báo cáo.Cách thứ ba: tự đặt ra metric riêng cho mình, thường được áp dụng ở các big tech, ví dụ như Uber [4], Meta, Amazon đề cao số lượng diff (commit), Linkedin [5] dùng top-down approach, bắt đầu với ba key metric Efficiency, Effectiveness, Happiness sau đó đi sâu vào và mở rộng ra các key metric nhỏ hơn như time to review, user satisfaction score, commit to publish time, etc. Việc xây dựng hệ thống để thu thập và báo cáo số liệu thường được đảm nhiệm bởi một team gọi là Developer Experience.
Tạm kết ở đây đã vì chủ đề này phức tạp và nếu nói nữa thì chắc phải viết cả series, bài viết cũng chỉ nhằm mục đích giới thiệu những khái niệm cơ bản ở bề mặt. Tóm lại thì mình thấy nhu cầu đo đạc productivity là chính đáng, tuy nhiên đo thế nào và đo cái gì là bài toán các team phần mềm sẽ phải tự tìm cho câu trả lời của riêng mình. Hãy nhớ rằng đằng sau các metric và con số là những con người, họ cũng có buồn vui hỉ nộ ái ố, và những con số thì khó có thể model hết hành vi của con người.
[1] https://arxiv.org/pdf/2111.04302.pdf
[3] https://queue.acm.org/detail.cfm?id=3454124
Peter Drucker, cha đẻ của ngành quản trị kinh doanh từng nói rằng thứ gì không đo đạc được thì không thể cải thiện được. Điều này có thể không đúng với từng cá nhân, khi có nhiều thứ thuộc về cảm giác là không thể đo đạc nhưng vẫn có thể cải thiện. Tuy nhiên với một tổ chức hay một doanh nghiệp, đo đạc là việc bắt buộc phải làm nếu những người quản lý muốn biết được những sự thay đổi sẽ đem lại kết quả ra sao.
Trở lại với bài viết ban đầu, ta có thể thấy được một bức tranh toàn cảnh về chủ đề Developer Productivity . Tuy nhiên, tác giả bài viết cũng đã nói rằng đó mới chỉ là những khái niệm rất cơ bản ở bề mặt. Còn rất nhiều chi tiết ở đi sâu vào bên dưới chưa được khai thác tới. Và trong bài viết dưới đây, tôi sẽ đi vào phần thực hành, khi cho các bạn thấy hình hài của những khái niệm trên trông sẽ như thế nào.
Giới thiệu về Devlake
Devlake là một mã nguồn mở giúp thu thập và xử lý data từ nhiều nguồn khác nhau. Các nguồn đó có thể kể đến như Github, Gitlab, Jira, Trello, vv. Từ nguồn data đó, ta có thể visualize thành các bảng biểu, các metric, giúp cho quá trình phát hiện và cải thiện các vấn đề liên quan đến productivity trở nên trực quan. Dưới đây là hình minh hoạ cách thức Devlake hoạt động.
Sau khi tiến hành config các nguồn dữ liệu, Devlake sẽ đi thu thập data và lưu chúng vào trong một relational database. Tiếp đó các phần mềm visualization như Grafana sẽ đọc data từ database ra và hiển thị thành các biểu đồ.
Một vài ví dụ tiêu biểu
Lấy một ví dụ như biểu đồ bên dưới, biểu thị sự phân bổ số commits của các thành viên vào các ngày trong tuần. Dựa vào biểu đồ ta dễ nhận thấy thứ ba có vẻ là ngày mà các anh dev hoạt động năng suất nhất. Thứ hai năng suất kém hơn cả thứ năm, cũng dễ hiểu vì thường đầu tuần sẽ phải họp hành nhiều. Trong khi thứ 6 là ngày có ít commit nhất, có thể là do những phần việc quan trọng thì đã được hoàn thành từ các ngày trước đó. Chỉ từ một thông số đơn giản, ta đã có thể suy ra được một số insights khá là thú vị.
Ví dụ trên nghe có vẻ thú vị, nhưng chưa cho ta thấy điều gì cần phải cải thiện. Dưới đây là một ví dụ khác về số lượng Pull Request (PR) mới được tạo hằng tháng. Qua biểu đồ ta thấy tháng 10, lượng PR giảm một cách đáng kể so với các tháng trước đó, vậy nguyên nhân là do đâu? Hoá ra tháng 10 có một project mới và các developer đã tập trung vào việc làm cho xong bản MVP nên đã không tạo PRs. Việc code không được review cẩn thận có thể gây ra những tech debt không mong muốn sau này, do đó cần có những cải thiện về mặt quy trình trong yêu cầu tạo PR cho những dự án mới tiếp theo. Bạn thấy đấy, có đo đạc vẫn hơn phải không.
Tiếp theo là một metrics về coding day của các developers. Có thể thấy thời gian thực tế một developer ngồi và code chỉ chiếm khoảng 40% tổng thời gian của họ khi đi làm. Tức một ngày đi làm 8 tiếng thì chỉ tầm 3 tiếng là dành để ngồi code, thời gian còn lại sẽ dành cho những việc khác như làm làm rõ requirements, họp hành, hay bảo trì hệ thống. Nếu phần trăm coding days bị quá thấp, hoặc quá cao, thì team cũng sẽ cần phải tìm hiểu nguyên nhân vì sao và từ đó có những action phù hợp.
Trên đây là một vài ví dụ về các metric dùng để đo đạc hiệu suất làm việc của các developer. Tuy nhiên trong một team làm sản phẩm, còn rất nhiều những role khác như Product Manager, QA, Designer, vv. Vậy làm sao để đo đạc được hiệu suất làm việc của các thành viên đó. Trong phần hai, tôi sẽ giới thiệu thêm một vài ví dụ tiêu biểu để trả lời cho câu hỏi trên.