Đo lường: Đo gì trong app, kế hoạch tracking

Vì sao chủ đề quan trọng

Đường cơ sở ở bài 3 đo bằng tay, và một số chỉ số vẫn sẽ đo bằng tay suốt đợt chạy thử: thời gian xếp hàng thường, sổ của Cô Hạnh. Nhưng North Star, số suất đặt trước được nhận đúng khung giờ, và các chỉ số dẫn dắt như tỉ lệ xem thực đơn rồi chọn món chỉ có thể do chính app ghi lại.

Nếu không ai viết ra app phải ghi gì, lập trình viên sẽ làm một trong hai việc. Hoặc không ghi gì, và cuối tuần 4 nhóm biết có 205 đơn mỗi ngày nhưng không biết bao nhiêu người đã xem thực đơn rồi bỏ đi. Hoặc ghi tất cả, kể cả mã số sinh viên và ghi chú dị ứng của Thảo Vy, vào một công cụ phân tích mà cả nhóm đều đọc được.

Bài này nhận vào: kế hoạch đo lường từ bài 2 và đường cơ sở từ bài 3, cùng backlog user story từ khóa Từ journey tới user story. Bài này giao ra: một kế hoạch theo dõi sự kiện (tracking plan), viết dưới dạng user story có tiêu chí chấp nhận, nằm ngay trong backlog, và một dòng mới trong định nghĩa hoàn thành của nhóm.

Bức tranh lớn

Một sự kiện (event) là một dòng app ghi lại khi một điều có ý nghĩa vừa xảy ra: ai đó đã xem thực đơn, đã thanh toán, đã nhận món. Mỗi sự kiện có thuộc tính (property): thông tin đi kèm như khung nhận, số món mặn, quầy.

Ba nguyên tắc định hình kế hoạch:

• Bắt đầu từ câu hỏi, không từ màn hình. Mỗi sự kiện phải trả lời được một câu hỏi trong kế hoạch đo lường. Không có câu hỏi thì không ghi.
• Đặt tên ở thì quá khứ, theo hành động của người dùng. "Đã thanh toán", không phải "Bấm nút Thanh toán". Tên gắn với nút sẽ sai ngay khi thiết kế đổi nút; tên gắn với hành động thì không. Thì quá khứ nói rõ điều đó đã xảy ra xong, không phải mới bắt đầu.
• Theo dõi là một phần của story, không phải việc làm sau. Một story chưa bắn đúng sự kiện thì chưa xong.

sequenceDiagram
    participant S as Sinh viên
    participant A as App
    participant Q as Nhân viên quầy
    participant K as Kho sự kiện
    S->>A: Mở thực đơn trong ngày
    A->>K: Đã xem thực đơn
    S->>A: Thêm món vào đơn
    A->>K: Đã chọn món
    S->>A: Trả tiền
    A->>K: Đã thanh toán
    Q->>A: Quét mã nhận món 4 số
    A->>K: Đã nhận món
    Q->>A: Bấm nút hết món
    A->>K: Đã bấm hết món

Khóa Product Analytics thực chiến dạy cách dựng hệ thống tên sự kiện cho cả sản phẩm và đọc phễu, giữ chân người dùng. Ở đây bạn chỉ cần đủ sự kiện để trả lời các câu hỏi của đợt chạy thử.

Ví dụ chi tiết

Từ câu hỏi tới sự kiện

Nhóm đi từ kế hoạch đo lường ở bài 2, mỗi câu hỏi tìm sự kiện nhỏ nhất trả lời được nó.

Thuộc tính "trước hay sau giờ chốt" ở sự kiện Đã xem thực đơn được thêm vì giờ chốt đặt 10:00 là ràng buộc của Cô Hạnh trong mâu thuẫn C3, và nhật ký quyết định đã ghi rằng sinh viên đặt muộn là người chịu thiệt. Nếu không ghi thuộc tính này, nhóm sẽ không bao giờ biết bao nhiêu người xem thực đơn khi đã quá giờ đặt. Bài 5 sẽ cho thấy đây chính là chỗ rò lớn nhất.

Viết sự kiện thành user story

Sự kiện Đã chọn món được viết như mọi story khác trong backlog, có người cần, lý do và tiêu chí chấp nhận:

Là nhóm sản phẩm Căng tin số
tôi muốn biết khi nào sinh viên thêm món đầu tiên vào đơn
để đo tỉ lệ xem thực đơn rồi chọn món trong phễu đặt trước.
Sự kiện       Đã chọn món
Thuộc tính    ma_an_danh, gio_chon, so_mon_man, truoc_gio_chot
Tiêu chí 1    Cho một sinh viên đã xem thực đơn hôm nay
              khi thêm món đầu tiên vào đơn
              thì ghi đúng một sự kiện Đã chọn món
Tiêu chí 2    Khi thêm món thứ hai trong cùng đơn
              thì không ghi thêm sự kiện Đã chọn món
Tiêu chí 3    Sự kiện không chứa mã số sinh viên dạng đọc được
              và không chứa ghi chú dị ứng

Tiêu chí 2 nghe vụn vặt nhưng chặn một lỗi rất hay gặp: mỗi món thêm vào bắn một sự kiện, phễu đếm ba lần cho một người, và tỉ lệ chọn món đẹp gấp ba lần sự thật.

Sự kiện của nhân viên quầy

Đã bấm hết món là sự kiện duy nhất do nhân viên quầy tạo ra, và nó đo một chỉ số bảo vệ: số lần quên bấm "hết". App không tự biết khi nào nhân viên quên, vì quên nghĩa là không có sự kiện. Cách đo: mỗi cuối ngày, đối chiếu giờ hết món trong sổ của Cô Hạnh với giờ của sự kiện Đã bấm hết món. Món hết trong sổ mà không có sự kiện tương ứng trong khoảng thời gian thỏa thuận, giả sử mười phút, là một lần quên.

Đây là bài học chung: những gì không xảy ra thì phải đo bằng nguồn thứ hai.

Những gì không thu

Danh sách này quan trọng ngang danh sách trên.

• Thông tin dị ứng. Thảo Vy dị ứng đậu phộng. Đó là dữ liệu sức khỏe. App có thể dùng nó để lọc món trên máy của em, nhưng không gửi nó vào kho sự kiện. Không câu hỏi nào trong kế hoạch đo lường cần nó.
• Mã số sinh viên dạng đọc được. Sự kiện dùng một mã ẩn danh sinh ra từ mã số sinh viên, đủ để đếm một người một lần, không đủ để ai đọc kho sự kiện biết đó là ai.
• Việc dùng suất hỗ trợ gắn với từng người. Thảo Vy đã nói "Đưa phiếu hỗ trợ ra giữa hàng người em hơi ngại." Số suất hỗ trợ được dùng mỗi ngày chỉ báo dạng tổng, không gắn với mã của ai.
• Vị trí điện thoại. Không câu hỏi nào cần biết sinh viên đang đứng ở đâu.

Chính sách dữ liệu là của trường, nên danh sách thu và không thu được gửi Chị Lan duyệt trước ngày ra mắt, và màn hình đăng nhập nói rõ app ghi lại những gì.

flowchart TD
    A[Story đã code xong] --> B{Sự kiện bắn đúng ở môi trường thử?}
    B -->|Không| X[Chưa xong]
    B -->|Có| C{Thuộc tính đủ và đúng kiểu?}
    C -->|Không| X
    C -->|Có| D{Không có dữ liệu cấm thu?}
    D -->|Có dữ liệu cấm| X
    D -->|Sạch| E{Sự kiện hiện trên báo cáo phễu?}
    E -->|Không| X
    E -->|Có| F[Story hoàn thành]

Lộ trình từng bước

• Mở kế hoạch đo lường, liệt kê mọi câu hỏi cần app trả lời.
• Với mỗi câu hỏi, tìm sự kiện nhỏ nhất trả lời được. Đặt tên thì quá khứ theo hành động.
• Chọn thuộc tính tối thiểu. Với mỗi thuộc tính, hỏi "câu hỏi nào cần nó?".
• Viết danh sách không thu, gửi người sở hữu chính sách dữ liệu duyệt.
• Viết mỗi sự kiện thành story có tiêu chí chấp nhận, kể cả tiêu chí chống đếm trùng và tiêu chí không chứa dữ liệu cấm.
• Thêm vào định nghĩa hoàn thành: story chỉ xong khi sự kiện của nó bắn đúng và hiện trên báo cáo.
• Với chỉ số đo điều không xảy ra, như quên bấm hết, chọn nguồn đối chiếu thứ hai.
• Chạy thử toàn bộ phễu một lần trước ngày ra mắt, đếm tay so với kho sự kiện.

Thói quen & kỷ luật

Cần luyện tập

Drill một: Viết story và ba tiêu chí chấp nhận cho sự kiện Đã nhận món, sao cho tính được cả North Star và tỉ lệ không tới lấy. Gợi ý: đơn bị bán cho hàng sau 30 phút thì ghi thế nào?

Drill hai: Một bạn đề xuất thêm thuộc tính "di_ung" và "ma_so_sinh_vien" vào sự kiện Đã thanh toán "để sau này phân tích". Viết đoạn trả lời, nêu câu hỏi nào trong kế hoạch đo lường cần chúng, và nếu không có câu hỏi nào thì vì sao không thu.

Drill ba: Chọn một tính năng trong đồ án của bạn. Viết ba sự kiện thì quá khứ, mỗi sự kiện có thuộc tính, câu hỏi nó trả lời, và một dòng không thu.

Checklist hành động tuần này

• [ ] Liệt kê câu hỏi từ kế hoạch đo lường mà app phải trả lời
• [ ] Viết bảng sự kiện với tên thì quá khứ và thuộc tính tối thiểu
• [ ] Viết danh sách không thu và gửi người sở hữu chính sách duyệt
• [ ] Thêm dòng theo dõi sự kiện vào định nghĩa hoàn thành
• [ ] Chạy thử phễu một lần và đối chiếu đếm tay

Chỉ số cho cách làm

Những con số này đo xem nhóm bạn lập kế hoạch theo dõi tốt tới đâu, không đo app có thành công không; app thành công hay không được đọc từ chính các sự kiện này ở bài 5.

Dấu hiệu bạn đã thành thạo

• Bạn viết "Đã thanh toán" mà không cần nghĩ, không viết "Click nút trả tiền".
• Mỗi thuộc tính bạn đề xuất đều chỉ được về một câu hỏi.
• Bạn từ chối thu thông tin dị ứng mà vẫn giải thích được vì sao app vẫn lọc món được.
• Trong buổi duyệt story, bạn hỏi "sự kiện của story này là gì?" trước khi ai hỏi.

Cạm bẫy thường gặp

Chốt lại

Kế hoạch theo dõi sự kiện đi từ câu hỏi tới sự kiện, không từ màn hình tới sự kiện. Tên ở thì quá khứ theo hành động: Đã xem thực đơn, Đã chọn món, Đã thanh toán, Đã nhận món, Đã bấm hết món. Mỗi sự kiện là một story có tiêu chí chấp nhận, kể cả tiêu chí chống đếm trùng và không chứa dữ liệu cấm. Dị ứng, mã số sinh viên dạng đọc được và việc dùng suất hỗ trợ gắn với từng người không đi vào kho sự kiện. Với kế hoạch này nằm trong định nghĩa hoàn thành, bốn tuần chạy thử sẽ để lại đủ dữ liệu cho bài 5 đọc.