Đo lường sản phẩm · Project Handbook

Luật gắn chỉ số với quyết định

Trước khi thêm bất kỳ chỉ số nào, trả lời: nếu con số này thay đổi, ta sẽ làm gì khác đi?

Không trả lời được thì đừng đo. Bảng điều khiển 40 biểu đồ mà không biểu đồ nào dẫn tới một quyết định chỉ tạo cảm giác đang kiểm soát, trong khi thực tế thì không.

Bốn nhóm chỉ số

Nhóm	Trả lời câu hỏi	Ai nhìn	Nhịp
Sức khoẻ kỹ thuật	App có chạy được không	Chủ kỹ thuật	Hằng ngày
Hiệu quả giao hàng	Đội đưa giá trị ra nhanh chậm thế nào	Cả đội	Hằng tuần
Hành vi người dùng	Người dùng có làm được việc của họ không	Chủ sản phẩm	Hằng tuần
Kết quả nghiệp vụ	Sản phẩm có tạo ra giá trị không	Lãnh đạo	Hằng tháng

Ba nhóm đầu là chỉ số dẫn — thay đổi trước. Nhóm cuối là chỉ số theo sau — thay đổi sau, có khi chậm vài tháng. Quản lý bằng chỉ số dẫn, báo cáo bằng chỉ số theo sau.

Sức khoẻ kỹ thuật

Đã liệt kê ở giám sát và cảnh báo. Điểm cần nhắc: luôn đọc nhóm 95% hoặc nhóm 99%, không đọc trung bình.

Thời gian phản hồi trung bình 300 ms nghe rất tốt, trong khi 5% người dùng đang chờ 8 giây. Trung bình che mất đúng nhóm người đang chịu trải nghiệm tệ nhất, và đó lại là nhóm sắp bỏ app.

Hiệu quả giao hàng

Bốn chỉ số, đo được từ dữ liệu git và pipeline:

Chỉ số	Nghĩa	Mốc tốt
Tần suất triển khai	Bao lâu đưa được thay đổi ra một lần	Hằng ngày trở lên
Thời gian từ commit tới production	Code viết xong bao lâu thì tới người dùng	Dưới 1 ngày
Tỷ lệ thay đổi gây sự cố	Bao nhiêu phần trăm lần triển khai gây lỗi	Dưới 15%
Thời gian khôi phục	Hỏng rồi bao lâu thì phục hồi	Dưới 1 giờ

Bốn chỉ số này đi cùng nhau và không được nhìn riêng lẻ. Đẩy tần suất triển khai lên mà tỷ lệ gây sự cố cũng lên là đang đi lùi. Chúng chỉ có nghĩa khi hai cặp cùng tốt lên.

Thêm bốn chỉ số nội bộ về chất lượng chặng sớm:

Thời gian trung bình một PR nằm chờ review.
Tỷ lệ lỗi bị bắt ở chặng trước so với chặng sau.
Số lần quality gate đỏ do lỗi thật, so với số lần đỏ do cổng sai.
Thời gian chạy toàn bộ pipeline.

Hành vi người dùng

Đo theo luồng công việc, không đo theo màn hình.

Với mỗi luồng chính, đo ba thứ:

Đo gì	Nói lên điều gì
Tỷ lệ hoàn thành luồng	Người dùng có làm xong được không
Thời gian hoàn thành	Có bị vướng ở đâu không
Tỷ lệ bỏ dở theo từng bước	Vướng ở bước nào

Luồng chính của Alliance App:

Module	Luồng	Chỉ số quan trọng nhất
Chat	Gửi tin nhắn đầu tiên trong ngày	Tỷ lệ gửi thành công lần đầu
Task	Tạo task và giao cho người khác	Tỷ lệ hoàn thành luồng tạo
Bán hàng	Tạo đơn tới lúc chốt	Tỷ lệ bỏ dở ở bước thanh toán
Chung	Từ lúc cài tới lúc làm được việc đầu tiên	Thời gian tới giá trị đầu tiên

Dòng cuối là chỉ số quan trọng nhất với người dùng mới. Người dùng không làm được việc gì có ích trong 5 phút đầu thì phần lớn sẽ không quay lại.

Kết quả nghiệp vụ

Chỉ số	Định nghĩa cần chốt trước
Người dùng hoạt động hằng ngày và hằng tháng	"Hoạt động" nghĩa là gì — mở app, hay làm một hành động có nghĩa
Tỷ lệ giữ chân theo tuần	Tính theo nhóm vào cùng thời điểm
Tỷ lệ dùng nhiều hơn một module	Đo mức độ sản phẩm gắn kết
Doanh số qua module Bán hàng	Đối chiếu được với sổ sách

Chốt định nghĩa trước khi đo. "Người dùng hoạt động" hiểu theo hai cách khác nhau sẽ cho hai con số khác nhau, và đội sẽ tranh cãi về con số thay vì về sản phẩm. Định nghĩa được ghi vào tài liệu, kèm câu truy vấn sinh ra nó.

Chỉ số dễ bị lừa

Chỉ số	Vì sao dễ lừa
Tổng số lượt tải	Chỉ tăng, không bao giờ giảm, không nói gì về người đang dùng
Thời gian ở trong app	Tăng có thể vì giao diện khó dùng, người ta phải mò lâu hơn
Số màn hình xem mỗi phiên	Như trên
Số dòng code, số commit	Đo hoạt động, không đo kết quả
Số điểm hoàn thành mỗi sprint	Tự thổi phồng được, và chắc chắn sẽ bị thổi phồng nếu dùng để đánh giá người
Coverage tổng của repo	Ép lên bằng test rỗng rất dễ

Nguyên tắc chung: chỉ số dùng để đánh giá con người sẽ ngừng phản ánh sự thật. Dùng chỉ số để hiểu hệ thống, không dùng để chấm điểm cá nhân.

Cách đọc một con số

Một con số đứng một mình gần như vô nghĩa. Luôn kèm ba thứ:

So với cái gì — tuần trước, cùng kỳ, hay nhóm đối chứng.
Chia theo nhóm nào — nền tảng, phiên bản, thị trường, người mới với người cũ. Số tổng thường che mất một nhóm đang gặp vấn đề nặng.
Khoảng dao động bình thường — biết mức dao động tự nhiên thì mới phân biệt được biến động thật với nhiễu.

Ghi sự kiện cho đúng

Danh sách event, quy tắc đặt tên, thuộc tính đi kèm và cách đưa event vào acceptance criteria nằm ở Analytics event là một phần của yêu cầu. Không có event thì toàn bộ bảng chỉ số ở trên chỉ là mong muốn.

Hai chỉ số kỹ thuật trong bài này — crash-free, ANR, defect leakage và các chỉ số của hệ kiểm soát chất lượng — nằm ở Quality metrics. Bài này lo phần sản phẩm và người dùng; bài kia lo phần sức khoẻ của chính quy trình.

Bản đồ chung của cả hai — sổ tay tuyên bố kiểm soát những gì, mỗi thứ chứng minh bằng con số nào, con số đó nằm ở bài nào — ở Chưa đo được thì chưa kiểm soát được.