Thử nghiệm có kiểm chứng

Vấn đề đang giải

Đội nào cũng có những thay đổi được làm vì "chắc chắn sẽ tốt hơn". Một phần trong số đó thật sự tốt hơn. Một phần không đổi gì. Và một phần làm tệ đi — nhưng không ai biết, vì không ai đo.

Ở quy mô 500.000 người dùng, một thay đổi giao diện làm giảm 2% tỷ lệ chốt đơn là mất mát lớn và hoàn toàn vô hình nếu chỉ nhìn bằng cảm nhận.

Thử nghiệm có kiểm chứng là cách biến câu "tôi nghĩ nó tốt hơn" thành câu "nó tốt hơn 6%, và đây là dữ liệu".

Ba mức, chọn theo giá của việc sai

Mức	Cách làm	Dùng khi
Hỏi trước	Đưa bản vẽ cho vài người dùng xem	Thay đổi nhỏ, dễ sửa
Bật dần và so sánh	Feature flag, so nhóm bật với nhóm chưa bật	Thay đổi vừa, có số liệu đo được
So sánh hai nhánh	Chia ngẫu nhiên A/B, đo cùng lúc	Thay đổi lớn, chạm tới chỉ số quan trọng

Đừng dùng mức 3 cho mọi thứ — nó tốn thời gian và cần đủ người dùng để có kết luận. Dùng đúng mức tương ứng với cái giá của việc quyết sai.

Một thử nghiệm phải khai báo trước

Viết ra trước khi bật, không viết sau khi có kết quả:

Giả thuyết:   Rút bước xác nhận ở luồng tạo đơn sẽ tăng tỷ lệ chốt đơn,
              vì bước đó không thêm thông tin gì cho người dùng.
Chỉ số chính: Tỷ lệ hoàn thành luồng tạo đơn.
Chỉ số bảo vệ: Tỷ lệ đơn bị huỷ trong 24 giờ, số phiếu hỗ trợ về đơn sai.
Nhóm:         50% người dùng mới, chia ngẫu nhiên.
Thời gian:    14 ngày, hoặc tới khi đủ 20.000 đơn mỗi nhánh.
Mức thay đổi đáng kể: tăng ít nhất 3% tương đối.
Quyết định:   Đạt thì bật 100%. Không đạt thì tắt và giữ nguyên bước xác nhận.

Dòng cuối là dòng quan trọng nhất: cam kết trước sẽ làm gì với từng kết quả. Không cam kết trước thì sau khi có số liệu, người ta luôn tìm ra một cách đọc số liệu ủng hộ điều họ đã muốn làm từ đầu.

Chỉ số bảo vệ

Mỗi thử nghiệm phải có ít nhất một chỉ số không được phép xấu đi, dù chỉ số chính có tốt lên.

Thử nghiệm về	Chỉ số bảo vệ bắt buộc
Bất kỳ thứ gì	Tỷ lệ crash, tỷ lệ lỗi API, thời gian phản hồi
Luồng bán hàng	Tỷ lệ huỷ đơn, tỷ lệ khiếu nại, chênh lệch đối soát
Luồng chat	Tỷ lệ tin nhắn gửi lại, độ trễ nhận
Thông báo	Tỷ lệ tắt thông báo, tỷ lệ gỡ app

Chỉ số bảo vệ tồn tại vì gần như mọi chỉ số đều có thể đẩy lên bằng cách hy sinh thứ khác. Tăng số lượt mở app bằng cách gửi thêm thông báo là ví dụ kinh điển: chỉ số chính đẹp lên, người dùng bực lên, và ba tháng sau tỷ lệ gỡ app tăng.

Đọc kết quả cho trung thực

Năm lỗi hay gặp:

Dừng sớm khi thấy số đẹp. Số liệu dao động mạnh ở vài ngày đầu. Đã khai báo 14 ngày thì chạy đủ 14 ngày.
Không đủ người dùng để kết luận. Chênh lệch 1% với 200 người là nhiễu. Tính trước cần bao nhiêu mẫu.
Đào số liệu tìm điều muốn thấy. Chia nhỏ ra 20 nhóm thì kiểu gì cũng có một nhóm "thắng" do ngẫu nhiên. Chỉ đọc chỉ số đã khai báo trước.
Quên ảnh hưởng của thời điểm. Chạy thử nghiệm trùng dịp lễ hoặc trùng một chiến dịch thì kết quả không dùng được.
Nhóm bị lẫn. Một người dùng thấy cả hai phiên bản thì thử nghiệm hỏng. Chia nhóm phải ổn định theo định danh người dùng, không theo phiên.

Kết quả âm cũng là kết quả

Một thử nghiệm cho kết quả "không khác gì" đã tiết kiệm cho đội công sức làm tiếp một hướng vô ích. Ghi lại và coi là thành công của quy trình.

Điều không được phép là: thử nghiệm thất bại, rồi bật 100% dù sao vì "đã làm rồi, tiếc". Công đã bỏ ra là chuyện quá khứ, không phải lý do để đẩy một thay đổi xấu tới 500.000 người.

Ghi lại mọi thử nghiệm

Một tệp duy nhất, mỗi dòng một thử nghiệm:

Cột	Nội dung
Ngày	Khoảng thời gian chạy
Giả thuyết	Một câu
Kết quả	Thắng, thua, hoặc không khác
Con số	Mức thay đổi thật đo được
Quyết định	Đã làm gì sau đó

Sau một năm, bảng này là tài sản đáng giá nhất về hiểu biết người dùng mà đội có — và là cách duy nhất để không thử đi thử lại cùng một ý tưởng mỗi khi có người mới vào.

Liên hệ với shift left

Thử nghiệm là shift left ở mức ý tưởng: nó bắt lỗi trong giả định về nhu cầu, trước khi giả định đó kịp biến thành một quý làm việc.

Thứ tự đúng, từ rẻ tới đắt: hỏi người dùng → vẽ thử → làm bản nhỏ nhất chạy được → bật cho 0,5% → đo → mở rộng. Nhảy cóc từ ý tưởng thẳng tới 100% là bỏ qua toàn bộ các chặng rẻ.