File spreadsheet đã được mở trước cả khi buổi planning bắt đầu. Vài dòng là tên feature, vài ô là ngày dự kiến, còn một cột đang chờ estimate. Ai trong phòng cũng biết nghi thức quen thuộc: một người hỏi con số, một người khác ngập ngừng, rồi cuối cùng cả team ghi xuống một giá trị trông đủ chính xác để cuộc họp tiếp tục.
Khoảnh khắc nhỏ đó là nơi software measurement trở nên rất thật. Không phải ở dashboard đẹp, không phải ở poster quy trình, mà ở khoảng trống giữa điều team muốn biết và điều team có thể nói một cách trung thực. Release này có đang đúng hướng không? Defect trend đã an toàn chưa? Estimate này là lời hứa hay một vùng bất định? Mình đang đo thứ giúp ra quyết định, hay chỉ thu thập số liệu vì dự án trưởng thành thì phải có số liệu?
Bài viết này là reflection cá nhân từ Software Measurement and Estimation: A Practical Approach của Linda M. Laird và M. Carol Brennan, do John Wiley & Sons cùng IEEE Computer Society xuất bản năm 2006. Mình không cố tóm tắt toàn bộ từng chương. Mình chỉ giữ lại những ý vẫn hữu ích khi một software team phải plan, ship, giải thích rủi ro và cải tiến cách làm.
Điều ở lại mạnh nhất với mình là: đo lường không phải để thờ phụng con số. Đo lường là cách giảm bớt sự mơ hồ có thể tránh được. Một con số nên giúp ai đó ra quyết định tốt hơn. Nếu nó không đổi quyết định, không giải thích rủi ro, không cho thấy xu hướng, có thể nó chỉ là vật trang trí.
Ví dụ rất đời là một team đang chuẩn bị mở tính năng thanh toán mới. Câu “đã xong 80% task” nghe có vẻ yên tâm, nhưng chưa chắc giúp ai quyết định release. Câu hữu ích hơn là: payment callback còn timeout không, tỉ lệ đơn bị treo sau khi người dùng đã bị trừ tiền là bao nhiêu, lỗi có tập trung ở một bank hay một loại thiết bị nào không, và khi lỗi xảy ra thì support có đủ thông tin để tra soát không. Những con số đó không đẹp hơn, nhưng chúng gần quyết định thật hơn.
Đo từ quyết định, không đo vì thèm dashboard
Một trong những ý quan trọng của sách là tinh thần GQM: Goal, Question, Metric. Bắt đầu từ mục tiêu, đặt câu hỏi giúp biết mục tiêu đó có đạt không, rồi mới chọn metric để trả lời câu hỏi. Nghe thì hiển nhiên, nhưng rất nhiều team làm ngược lại. Team bắt đầu từ dữ liệu đang có, dựng biểu đồ, rồi sau đó mới cố tìm lý do vì sao biểu đồ đó quan trọng.
Một luồng lành mạnh hơn thường khiêm tốn hơn. Nếu mục tiêu là biết release đã đủ ổn để ship chưa, câu hỏi có thể là: các lỗi nghiêm trọng còn xuất hiện nhanh hơn tốc độ team đóng lỗi không? Metric hữu ích lúc này có thể kết hợp defect arrival, defect closure và backlog. Nếu mục tiêu là biết vendor outsourcing có đang khỏe không, câu hỏi có thể là: họ có giao được phần việc dùng được, chất lượng chấp nhận được, và phản hồi đủ nhanh khi có vấn đề không? Bộ metric lúc đó cần progress, quality và responsiveness, không chỉ số giờ đã dùng.
Giả sử team đang làm một flow checkout mới. Nếu goal là giảm rơi rớt ở bước thanh toán, câu hỏi không nên dừng ở “team đã code xong chưa”. Câu hỏi tốt hơn là: người dùng rơi ở bước nào, lỗi kỹ thuật chiếm bao nhiêu phần, lỗi do validation copy khó hiểu chiếm bao nhiêu phần, và có nhóm người dùng nào bị ảnh hưởng nhiều hơn không. Metric khi đó có thể là funnel drop-off, payment error rate, số ticket support theo nguyên nhân, và thời gian xử lý đơn treo. Một dashboard nhỏ như vậy giúp product, QA, backend và support nhìn cùng một bức tranh.
| Cách đo yếu | Câu hỏi đo tốt hơn | Tín hiệu hữu ích hơn |
|---|---|---|
| Đếm tất cả bug | Pha nào đang để lỗi lọt sang pha sau? | Defect removal theo pha, escaped defects, backlog trend. |
| Đếm dòng code | Kích thước có đang tăng theo cách làm effort và rủi ro đổi không? | Size trend, functional size, complexity, review effort. |
| Track utilization | Team có đang tiến về outcome có giá trị không? | Milestone qua cổng, accepted work, blocker, rework. |
| Show thật nhiều chart | Tuần này leadership cần vài sự thật nào để quyết định? | Dashboard nhỏ có target, trend và đường drill-down. |
Sách cũng thêm một cảnh báo rất thực tế qua GQM²: metric cần mechanism. Ai thu thập? Bao lâu một lần? Từ nguồn nào? Theo định nghĩa nào? Một metric không có cơ chế thu thập sẽ nhanh chóng bị ôi thiu. Tệ hơn, mỗi người có thể đo cùng một khái niệm bằng một quy tắc khác nhau, rồi team cãi nhau về con số thay vì học từ nó.
Metric release-readiness thực tế có thể viết trong một dòng: theo dõi số P0 và P1 defect được mở, được đóng và vẫn chưa có owner trong 48 giờ gần nhất, lấy từ issue tracker, review mỗi thứ Hai và thứ Năm trong giai đoạn stabilization. Decision rule quan trọng không kém con số: nếu critical backlog tăng trong hai lần review liên tiếp, scope tùy chọn phải chuyển ra trước khi team tăng áp lực hoặc overtime.
Estimate không phải lời hứa khắc lên đá
Bài học thứ hai là về estimation. Estimate không phải cam kết đạo đức. Nó là một mô hình bất định dựa trên những gì team đang biết tại thời điểm đó. Phân biệt này quan trọng vì software work luôn có phần discovery. Requirement đổi, dependency gây bất ngờ, độ phức tạp ẩn xuất hiện, và con người học thêm trong lúc làm.
Sách đi qua nhiều họ estimation: expert estimation, decomposition, Wideband Delphi, Use Case Points, Function Points và các mô hình thuật toán kiểu COCOMO. Mình đọc chúng không như một danh sách công thức để học thuộc, mà như một lời nhắc rằng mỗi cách estimate đều mang một thế giới quan. Expert estimation có kinh nghiệm sống thật, nhưng dễ bias. Mô hình parametric nhìn có vẻ dễ bảo vệ hơn, nhưng phụ thuộc rất nặng vào định nghĩa input. Proxy method như Use Case Points hay Function Points có thể hữu ích, nhưng chỉ khi team đếm nhất quán.
Thói quen nghề nghiệp tốt hơn là triangulation. Nếu expert judgment, dữ liệu lịch sử, estimate theo kích thước và phân tích rủi ro đều chỉ về cùng một hướng, mức tự tin tăng lên. Nếu chúng lệch nhau, chính sự lệch đó là thông tin. Nó có thể nói rằng scope chưa rõ, công nghệ còn lạ, requirement yếu, hoặc có một assumption của team chưa ai nói ra.
Ví dụ một integration với cổng xác thực eKYC được một senior estimate 5 ngày vì “API cũng đơn giản”. Nhưng dữ liệu lịch sử cho thấy những lần integration với bên thứ ba trước đó thường mất 10 đến 15 ngày, chủ yếu vì sandbox thiếu ổn định, tài liệu thiếu case lỗi và legal review đi sau kỹ thuật. Nếu decomposition cũng cho thấy phần happy path chỉ 3 ngày nhưng xử lý retry, reconciliation, log tra soát và monitoring chiếm thêm nhiều ngày, thì sự chênh lệch giữa các estimate không phải vấn đề cần che đi. Nó chính là tín hiệu để team nói rõ assumption và buffer.
“Thêm người vào là rút ngắn được schedule” thường không phải một kế hoạch. Sách có nói về giới hạn nén tiến độ: sau một điểm, ép calendar time xuống sẽ làm effort và chi phí phối hợp tăng mạnh. Trong team thật, người mới còn cần context, review, communication và integration. Ngày trên giấy có thể ngắn hơn, nhưng hệ thống lại khó hoàn thành hơn.
Vì vậy, một estimate tốt nên đi kèm assumption. Scope nào được tính? Dependency nào đang được tin? Dữ liệu lịch sử nào đỡ cho con số? Rủi ro nào có budget dự phòng? Điều gì sẽ làm estimate này hết hiệu lực? Một con số không có assumption nhìn sạch sẽ, nhưng mong manh. Một range có assumption nhìn ít tự tin hơn, nhưng thường trung thực hơn.
Một cách nói thực tế hơn trong planning có thể là: “Nếu chỉ tính happy path và API đối tác ổn định, phần này khoảng 5 đến 7 ngày. Nếu phải xử lý đủ timeout, retry, reconciliation và dashboard vận hành, range hợp lý hơn là 9 đến 14 ngày. Nếu chưa có access sandbox trước thứ Tư, estimate này cần mở lại.” Câu trả lời dài hơn một con số, nhưng nó giúp PM, PO và engineer cùng thấy điều gì đang được đánh đổi.
Chất lượng nên hiện ra trước ngày release
Sách nhìn defect như nhiều hơn những sự cố khó chịu. Defect là dấu vết của quy trình kỹ thuật. Nó được tạo ra ở đâu, được phát hiện ở đâu, xuất hiện nhanh thế nào, và có bao nhiêu lỗi lọt ra production đều nói gì đó về cách team đang làm việc.
Mình thấy Defect Removal Efficiency là một ý rất đáng dùng. Công thức tổng thể khá đơn giản: so sánh số lỗi tìm được trước release với số lỗi người dùng tìm được sau release. Nhưng giá trị sâu hơn xuất hiện khi nhìn theo từng pha. Nếu lỗi requirement cứ lọt sang design và testing, câu trả lời không chỉ là test nhiều hơn. Có thể câu trả lời là review requirement tốt hơn, ví dụ rõ hơn, stakeholder alignment sớm hơn, hoặc batch công việc nhỏ hơn.
Lấy một màn hình đổi thông tin cá nhân làm ví dụ. Nếu QA liên tục tìm lỗi vì field bắt buộc không rõ, format ngày sinh mỗi nơi một kiểu, hoặc thông báo lỗi khiến người dùng không biết sửa gì, thì defect không chỉ thuộc về bước testing. Nó có thể đã được gieo từ requirement thiếu ví dụ, Figma chưa có state lỗi, hoặc API contract không nói rõ validation rule. Khi nhìn defect theo nơi tạo ra và nơi phát hiện, team bớt đổ lỗi cho giai đoạn cuối và quay lại cải thiện chỗ thật sự sinh vấn đề.
Điều này nối rất tự nhiên với in-process metrics. Team không nên đợi tới tuần cuối mới biết chất lượng đang nguy hiểm. Code integration trend, testing progress, pass rate, defect arrival, defect closure và backlog movement đều là tín hiệu sớm. Chúng không hoàn hảo, nhưng giúp team đặt câu hỏi tốt hơn khi vẫn còn thời gian hành động.
Một ví dụ khác là integration branch cứ đỏ mỗi buổi chiều vì nhiều merge nhỏ va vào nhau. Nếu chỉ nhìn cuối sprint, team thấy “release bị trễ”. Nếu nhìn sớm hơn, team có thể thấy pattern: build đỏ nhiều nhất sau khi ba module cùng đụng vào pricing rule, test tự động thiếu case discount kết hợp voucher, và bug closure chậm vì không ai rõ owner của rule đó. Đó là lúc metric giúp team đi tìm bottleneck thật, không chỉ tăng áp lực lên người sửa bug.
Trước khi hỏi đã chạy hết test case chưa, hãy hỏi hệ thống còn sinh lỗi quan trọng nhanh hơn tốc độ team hiểu và đóng lỗi không. Một release có thể rất bận rộn mà vẫn chưa thật sự hội tụ.
Metric có thể cũ đi, và con người có thể học cách lách metric
Sách rất tỉnh táo về một vấn đề tổ chức nào rồi cũng gặp: khi một metric trở thành mục tiêu, con người sẽ thích nghi với nó. Nếu thưởng số dòng code, code sẽ dài hơn. Nếu thưởng số ticket đóng, ticket sẽ nhỏ hoặc dễ hơn. Nếu thưởng số lượng test, test yếu có thể mọc lên nhiều hơn. Team có thể làm đẹp con số nhìn thấy được trong khi hệ thống thật không tốt hơn.
Velocity cũng vậy. Nếu một team bị hỏi mỗi tuần vì sao story point không tăng, họ rất dễ học cách split ticket nhỏ hơn, inflate point hoặc né những việc khó đo như refactor, đọc log production, viết migration an toàn. Trên chart, velocity có thể đều hơn. Trong codebase, technical debt vẫn âm thầm dày lên. Metric lúc đó không còn là kính soi thực tế, mà trở thành trò chơi mà mọi người phải chơi để tự vệ.
Điều đó không có nghĩa metric vô dụng. Nó nghĩa là metric cần được review. Một metric giúp team năm ngoái có thể đã cũ trong năm nay. Nó có thể đã giải quyết xong vấn đề ban đầu, mất giá trị ra quyết định, hoặc bắt đầu tạo hành vi không lành mạnh. Một chương trình đo lường tốt là một hệ thống sống. Nó biết retire metric cũ, đưa metric mới vào, và liên tục hỏi liệu con số còn phản ánh thực tế mà nó đại diện hay không.
Dashboard cũng vậy. Sách mô tả 4 Ds: decide metric, draw metric rõ ràng, đặt một bộ nhỏ lên dashboard, và cho phép drill down khi có tín hiệu đỏ. Mình thích cách này vì nó kéo dashboard khỏi vai trò trang trí. Một dashboard tốt nên có target, trend và đủ context để đặt câu hỏi tiếp theo. Nếu nó không dẫn tới quyết định hay drill-down, có thể nó chỉ là một thói quen báo cáo.
Nếu dùng trong team, mình sẽ bắt đầu rất nhỏ
Mình sẽ không bắt đầu bằng một chương trình đo lường đầy đủ. Với nhiều team, như vậy quá nặng. Mình sẽ bắt đầu từ một quyết định lặp lại đang quá cảm tính hoặc quá mơ hồ. Release readiness là ứng viên tốt. Estimation confidence cũng vậy. Vendor delivery, defect leakage, production reliability hoặc project financial health cũng có thể là điểm bắt đầu.
Sau đó mình viết chuỗi bằng ngôn ngữ rất đời: goal, question, metric, mechanism, nhịp review và decision rule. Ví dụ: mục tiêu là biết release có đang hội tụ không. Câu hỏi là lỗi quan trọng có xuất hiện chậm hơn tốc độ đóng lỗi không. Metric là arrival, closure và backlog theo severity mỗi tuần. Mechanism là issue tracker với một định nghĩa severity dùng chung. Nhịp review là hai lần mỗi tuần trong giai đoạn stabilization. Decision rule là nếu critical backlog tăng trong hai phiên review liên tiếp, team phải giảm scope hoặc xem lại ngày release.
Nếu đưa vào thực tế, mình sẽ chỉ làm một bảng rất nhỏ: số critical còn mở, số lỗi mới trừ số lỗi đã đóng trong 48 giờ gần nhất, số lỗi quá 5 ngày chưa có owner rõ, và phần scope chưa test theo risk level. Bốn dòng đó đủ để một buổi review bớt lan man. Nếu tất cả đều xanh, team có thêm cơ sở để đi tiếp. Nếu một dòng đỏ, team biết cần drill-down vào đâu trước, thay vì mở 12 chart rồi không ai quyết định gì.
Cách đo đó không làm software trở nên dễ đoán như dây chuyền nhà máy. Software vẫn có judgment, creativity, uncertainty và con người. Nhưng nó cho team một bề mặt chung bình tĩnh hơn. Thay vì tranh luận bằng ký ức, lo lắng hoặc thâm niên, team có thể chỉ vào một xu hướng và hỏi nó đang nói gì.
Những điều đọng lại
- Đo lường nên bắt đầu từ quyết định. Goal, question, metric và mechanism giúp team tránh gom số liệu không ai dùng.
- Estimate là mô hình bất định, không phải lời hứa. Hãy giữ assumption, range, risk và dữ liệu lịch sử đi cùng con số.
- Dùng nhiều lăng kính estimate. Expert judgment, decomposition, dữ liệu lịch sử và mô hình parametric mỗi cái thấy một phần khác nhau của công việc.
- Defect là tín hiệu quy trình. Lỗi được tạo ra và phát hiện ở đâu có thể hé lộ review yếu, requirement mơ hồ hoặc integration quá muộn.
- Dashboard nên nhỏ và hành động được. Một chart tốt có định nghĩa, target, trend, trạng thái và đường drill-down.
- Metric có tuổi thọ. Hãy review chúng trước khi con người tối ưu con số trong khi hệ thống thật ngừng tốt lên.
Giá trị còn lại của Software Measurement and Estimation với mình không phải là nó đưa cho software team một công thức hoàn hảo. Nó đưa ra một kỷ luật trầm hơn: nói rõ mình đang cần quyết định gì, định nghĩa con số cẩn thận, thu thập nhất quán, và đủ khiêm tốn để đổi metric khi thực tế đổi. Việc đó không hào nhoáng. Nhưng nhiều team khỏe hơn được xây từ đúng kiểu tích lũy âm thầm đó: một estimate rõ hơn, một tín hiệu review tốt hơn, một dashboard bớt trang trí hơn, và thêm một quyết định được đưa ra bằng bằng chứng thay vì chỉ bằng cảm giác.