Vì sao chủ đề quan trọng
Hỏi một nhóm sinh viên "đơn hàng của các bạn có những trạng thái nào?", câu trả lời thường là: đã đặt, đã xong. Hai trạng thái. Rồi khi chạy thử, mọi thứ ngoài hai trạng thái đó trở thành lỗi: sinh viên đặt rồi không tới, bếp hết món sau khi đơn đã trả tiền, sinh viên xin hoàn tiền mà không ai có nút để bấm.
Vòng đời dữ liệu (lifecycle) là danh sách mọi trạng thái một đối tượng có thể ở, và mọi cách để nó đi từ trạng thái này sang trạng thái khác. Bài này dạy vẽ vòng đời bằng sơ đồ trạng thái (state diagram), rồi đọc nó theo một cách rất thực dụng: mỗi mũi tên là một việc ai đó phải làm được, tức là một tính năng hoặc một chính sách tự động. Mũi tên bị quên chính là tính năng bị quên.
Đầu vào: dòng thời gian sự kiện từ bài 3, quy tắc R1 tới R6 từ bài 2, bảng thuật ngữ từ bài 1. Đầu ra: vòng đời của Đơn đặt trước và Phiếu suất hỗ trợ, kèm bảng chuyển trạng thái. Khóa "Không bỏ sót: kiểm tra độ đầy đủ" sẽ dùng các mũi tên này để kiểm tra ma trận vai trò và hành động.
Bức tranh lớn
Căng tin số có bảy đối tượng chính: Thực đơn ngày, Món, Đơn đặt trước, Khung giờ nhận, Thanh toán, Phiếu suất hỗ trợ, Phản hồi. Không phải đối tượng nào cũng cần vẽ vòng đời. Vẽ khi đối tượng có từ bốn trạng thái trở lên, hoặc khi tiền và quyền thay đổi theo trạng thái. Đơn đặt trước và Phiếu suất hỗ trợ thoả cả hai điều kiện.
Cách lấy trạng thái từ bài 3 rất đơn giản: mỗi sự kiện có chữ "đã" trên tường thường là một mũi tên, và trạng thái là chỗ đối tượng dừng lại giữa hai sự kiện. "Thanh toán đã nhận" là mũi tên; "Đã thanh toán" là trạng thái nằm sau nó.
Một sơ đồ trạng thái tốt trả lời bốn câu hỏi cho mỗi mũi tên:
- Từ trạng thái nào sang trạng thái nào?
- Ai làm, hoặc chính sách nào tự kích hoạt?
- Điều kiện gì phải đúng thì mới được đi?
- Quy tắc nghiệp vụ nào đứng sau nó?
Ví dụ chi tiết
Dưới đây là vòng đời Đơn đặt trước, giả định theo ý Anh Tuấn rằng "Đặt trước thì phải trả trước". Mâu thuẫn C1 giữa Anh Tuấn và Minh Anh được giải quyết ở khóa "Từ ghi chép tới insight"; nếu quyết định cuối là trả khi nhận, trạng thái Đã thanh toán sẽ dời xuống sau Sẵn sàng. Vòng đời là thứ phải đổi theo quyết định nghiệp vụ, không phải ngược lại.
stateDiagram-v2
Nhap : Nháp
DaDat : Đã đặt
DaTT : Đã thanh toán
DangNau : Đang nấu
SanSang : Sẵn sàng
DaNhan : Đã nhận
DaHuy : Đã huỷ
QuaHan : Quá hạn không tới
BanLai : Bán lại cho hàng
DaHoan : Đã hoàn tiền
Nhap --> DaDat : sinh viên gửi đơn trước 10h
DaDat --> DaTT : thanh toán đã nhận
DaDat --> DaHuy : sinh viên huỷ
DaTT --> DaHuy : sinh viên huỷ trước 10h hoặc căng tin hết món
DaTT --> DangNau : 10h30 bếp vào mẻ
DangNau --> SanSang : bếp chia phần
SanSang --> DaNhan : nhân viên quầy giao phần
SanSang --> QuaHan : quá 30 phút sau khung giờ nhận
QuaHan --> BanLai : nhân viên quầy bán cho hàng
DaHuy --> DaHoan : quản lý duyệt hoàn tiền
BanLai --> DaHoan : quản lý duyệt, đang là điểm nóngĐọc từng mũi tên như một câu hỏi "ai làm được việc này?" cho ra bảng chuyển trạng thái.
| Từ | Sang | Ai làm | Điều kiện | Quy tắc | Tính năng cần có |
|---|---|---|---|---|---|
| Nháp | Đã đặt | Sinh viên | Trước 10:00, đúng cấu trúc suất | R1, R2 | Màn hình đặt món có tính giá |
| Đã đặt | Đã thanh toán | Sinh viên, nhân viên quầy xác nhận | Đủ tiền | Chưa có mã | Thanh toán và xác nhận chuyển khoản |
| Đã thanh toán | Đã huỷ | Sinh viên hoặc quản lý | Trước 10:00, hoặc món đã hết | R2 | Nút huỷ và thông báo hết món |
| Sẵn sàng | Đã nhận | Nhân viên quầy | Đúng người, đúng phần | Chưa có mã | Màn hình giao phần |
| Sẵn sàng | Quá hạn không tới | Chính sách tự động | 30 phút sau khung giờ nhận | R3 | Bộ đếm giờ và danh sách phần quá hạn |
| Quá hạn không tới | Bán lại cho hàng | Nhân viên quầy | Phần còn trong hạn 4 giờ | R3, R5 | Nút bán lại |
| Đã huỷ | Đã hoàn tiền | Chỉ quản lý | Có yêu cầu hoàn | R6 | Màn hình duyệt hoàn tiền |
R3 hiện ra như một mũi tên không có người bấm. Sẵn sàng sang Quá hạn không tới là chính sách tự động. Nghĩa là hệ thống cần một bộ đếm giờ, và nhân viên quầy cần một danh sách "phần đã quá hạn" để biết phần nào được bán lại. Không có danh sách đó, nhân viên vẫn phải nhớ như hôm nay.
R6 hiện ra như hai mũi tên đổ về cùng một trạng thái, và cả hai chỉ một người được đi. Đã huỷ sang Đã hoàn tiền chỉ quản lý duyệt. Bây giờ ghép với mũi tên "căng tin hết món": nếu món hết lúc 12:00, mọi đơn đã trả tiền món đó cùng lúc sang Đã huỷ, và tất cả chờ Anh Tuấn duyệt hoàn tiền giữa giờ cao điểm. Đây là một hệ quả mà cả Anh Tuấn lẫn nhóm chưa nghĩ tới. Ghi thành điểm nóng cho bài 6.
Mũi tên Bán lại sang Đã hoàn tiền là chỗ tiền bị thu hai lần. Điểm nóng từ bài 3 giờ có vị trí chính xác trên sơ đồ.
Đối tượng thứ hai là Phiếu suất hỗ trợ. Vòng đời của nó không đi một chiều mà quay vòng mỗi ngày, do R4: tối đa 1 suất mỗi ngày, chỉ ngày thường, không dùng cho đồ uống.
stateDiagram-v2
SanDung : Sẵn dùng hôm nay
KhongDung : Không dùng được hôm nay
DaGiu : Đã giữ cho một đơn
DaDung : Đã dùng hôm nay
HetHieuLuc : Hết hiệu lực
SanDung --> DaGiu : Thảo Vy đặt một suất cơm
SanDung --> DaDung : dùng trực tiếp tại quầy
DaGiu --> SanDung : đơn bị huỷ
DaGiu --> DaDung : phần đã nhận
DaDung --> SanDung : sang ngày thường kế tiếp
KhongDung --> SanDung : sang ngày thường kế tiếp
SanDung --> KhongDung : thứ Bảy hoặc Chủ nhật
SanDung --> HetHieuLuc : Phòng Quản trị thu hồiTrạng thái Đã giữ cho một đơn sinh ra một câu hỏi mới: nếu Thảo Vy đặt bằng suất hỗ trợ rồi không tới, phần bị bán lại theo R3, thì hôm đó phiếu tính là đã dùng hay được trả lại? Chưa ai trả lời. Chủ quy tắc R4 là Chị Lan, nên câu hỏi đi tới Chị Lan. Mũi tên "không dùng cho đồ uống" không có trên sơ đồ vì nó là ràng buộc ở bước đặt, không phải một chuyển trạng thái.
Trạng thái Đã giữ cũng giải quyết một phần P12: Thảo Vy dùng phiếu khi đặt trên app, không phải đưa phiếu giấy ra giữa hàng người.
Lộ trình từng bước
- Chọn đối tượng. Bắt đầu với đối tượng có tiền hoặc quyền thay đổi theo trạng thái.
- Lấy sự kiện từ tường event storming. Mỗi sự kiện có chữ "đã" liên quan tới đối tượng là một ứng viên mũi tên.
- Đặt tên trạng thái bằng từ trong bảng thuật ngữ. "Sẵn sàng" chứ không phải "status 4".
- Vẽ đường thuận trước. Nháp tới Đã nhận, một hàng thẳng.
- Hỏi "nếu không thì sao" ở mỗi trạng thái. Nếu không thanh toán? Nếu không tới? Nếu món hết? Mỗi câu trả lời là một mũi tên rẽ nhánh.
- Gắn quy tắc vào mũi tên. Mũi tên nào có điều kiện thì ghi mã quy tắc. Mũi tên nào có điều kiện mà không có mã, bạn đang thiếu một quy tắc.
- Lập bảng chuyển trạng thái. Sáu cột: từ, sang, ai làm, điều kiện, quy tắc, tính năng.
- Tìm trạng thái cụt. Trạng thái không có mũi tên ra mà không phải trạng thái kết thúc là lỗi mô hình. Quá hạn không tới mà không có mũi tên ra thì phần nằm ở quầy mãi mãi.
Thói quen & kỷ luật
| Thói quen | Tần suất | Kết quả mong đợi |
|---|---|---|
| Hỏi nếu không thì sao ở mọi trạng thái | Mỗi lần vẽ vòng đời | Không thiếu nhánh huỷ, quá hạn, hoàn |
| Gắn mã quy tắc vào mọi mũi tên có điều kiện | Mỗi mũi tên | Phát hiện quy tắc còn thiếu |
| Đối chiếu bảng chuyển trạng thái với backlog | Mỗi tuần | Mỗi mũi tên có ít nhất một story |
| Cập nhật vòng đời khi một mâu thuẫn được giải quyết | Ngay khi có quyết định | Sơ đồ khớp quyết định nghiệp vụ |
Cần luyện tập
Drill một: Vẽ lại vòng đời Đơn đặt trước với giả định ngược lại: trả tiền khi nhận, theo mong muốn của Minh Anh. Những mũi tên nào biến mất? Trạng thái Đã hoàn tiền còn cần không? R3 trở nên dễ hay khó hơn với Anh Tuấn?
Drill hai: Vẽ vòng đời Thực đơn ngày dựa trên R2: soạn, chốt lúc 16:00 hôm trước, đang bán, có món hết. Lập bảng chuyển trạng thái sáu cột và chỉ ra mũi tên nào không có người thực hiện vào giờ cao điểm.
Drill ba: Chọn một đối tượng trong app bạn hay dùng, như đơn giao hàng hoặc vé xem phim. Liệt kê mọi trạng thái bạn từng thấy trên màn hình, rồi đoán thêm ba trạng thái bạn chưa thấy nhưng chắc chắn tồn tại.
Checklist hành động tuần này
- [ ] Chọn hai đối tượng có tiền hoặc quyền thay đổi theo trạng thái
- [ ] Vẽ đường thuận rồi hỏi nếu không thì sao ở mỗi trạng thái
- [ ] Lập bảng chuyển trạng thái sáu cột
- [ ] Đánh dấu mọi mũi tên chưa có quy tắc hoặc chưa có người làm
- [ ] Kiểm tra không còn trạng thái cụt
Chỉ số cho cách làm
Các con số dưới đây đo cách nhóm làm bước này, không đo app có thành công hay không. Câu hỏi app có hiệu quả không, và làm gì tiếp, là việc của khóa Đo lường thành công.
| Loại chỉ số | Ví dụ | Vai trò |
|---|---|---|
| North Star | Phần trăm mũi tên đã có ít nhất một story | Đo độ phủ từ mô hình tới backlog |
| Chỉ số chất lượng | Số trạng thái cụt | Phải bằng 0 |
| Chỉ số rủi ro | Số mũi tên có điều kiện nhưng chưa có mã quy tắc | Chỉ ra quy tắc còn thiếu |
| Chỉ số trễ | Số lỗi chạy thử do đơn kẹt ở một trạng thái | Kiểm tra mô hình sau khi đã muộn |
Dấu hiệu bạn đã thành thạo
Bạn nhìn một sơ đồ trạng thái và đếm được ngay số tính năng tối thiểu cần xây. Bạn thấy mũi tên "căng tin hết món" và lập tức hỏi ai sẽ duyệt hoàn tiền cho từng đó đơn. Bạn không còn vẽ vòng đời chỉ có đường thuận, và bạn biết khi nào một ràng buộc như "không dùng cho đồ uống" thuộc về bước đặt chứ không phải một mũi tên.
Cạm bẫy thường gặp
| Cạm bẫy | Biểu hiện | Cách tránh |
|---|---|---|
| Chỉ vẽ đường thuận | Đơn chỉ có đã đặt và đã xong | Hỏi nếu không thì sao ở mọi trạng thái |
| Trạng thái theo màn hình | Trạng thái tên là trang xác nhận | Đặt tên bằng từ trong bảng thuật ngữ |
| Mũi tên không có người làm | Không ai được chuyển Quá hạn sang Bán lại | Cột ai làm không được để trống |
| Trạng thái cụt | Phần quá hạn nằm mãi ở quầy | Kiểm tra mũi tên ra cho mọi trạng thái |
| Vẽ vòng đời cho mọi đối tượng | Mất hai ngày cho đối tượng Món | Chỉ vẽ khi có tiền hoặc quyền đổi theo trạng thái |
Chốt lại
Vòng đời là danh sách trạng thái và mũi tên; mỗi mũi tên là một việc phải có người làm được hoặc một chính sách tự động. R3 xuất hiện như một bộ đếm giờ, R6 như một cửa chỉ quản lý được đi qua, và khi đặt chúng cạnh nhau, bạn thấy cảnh Anh Tuấn phải duyệt hoàn tiền hàng loạt lúc 12:00. Bài 5 đặt các mũi tên này vào làn của từng người, để thấy chỗ việc bị rơi khi chuyển tay.